From salvatore.loreto@ericsson.com Wed Jan 18 07:21:18 2012 Return-Path: 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 B0C2721F84EE for ; Wed, 18 Jan 2012 07:21:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.598 X-Spam-Level: X-Spam-Status: No, score=-110.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, 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 MDCr1S8lvvFT for ; Wed, 18 Jan 2012 07:21:16 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id F1DE621F84DE for ; Wed, 18 Jan 2012 07:21:15 -0800 (PST) X-AuditID: c1b4fb39-b7b3eae00000252a-01-4f16e36a66ba Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 1A.84.09514.A63E61F4; Wed, 18 Jan 2012 16:21:15 +0100 (CET) Received: from ESESSCMS0363.eemea.ericsson.se ([169.254.1.72]) by esessmw0237.eemea.ericsson.se ([153.88.115.90]) with mapi; Wed, 18 Jan 2012 16:21:14 +0100 From: Salvatore Loreto To: "hybi@ietf.org" Date: Wed, 18 Jan 2012 16:21:13 +0100 Thread-Topic: New charter for HyBi wg Thread-Index: AczV9NDcLG3qqhUYRnuolEHotiaefA== Message-ID: <0FDF715F51EF4B4BA69B4A7B865DBD9B3A637AB5D6@ESESSCMS0363.eemea.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_0FDF715F51EF4B4BA69B4A7B865DBD9B3A637AB5D6ESESSCMS0363e_" MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: [hybi] New charter for HyBi wg X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jan 2012 15:21:18 -0000 --_000_0FDF715F51EF4B4BA69B4A7B865DBD9B3A637AB5D6ESESSCMS0363e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi there, as you know the WebSocket Protocol has been published on December 2011 as RFC 6455. Thanks again to all of you for all your technical and editorial contributio= ns to the design of the protocol. Now having completed the work on the core protocol, we are ready as a group= to continue the discussion to define extensions for use by WebSocket implementations. Gabriel and I have worked on a draft of the new charter for the HyBi wg tha= t is focused on the main extensions that have already been discussed by the WG last year= . (See the charter below) Please let we know your opinion on the draft. All the feedback, suggestions and proposal are really welcome. New Charter ------------------ Description of Working Group: The BiDirectional or Server-Initiated HTTP (HyBi) working group defines= the WebSocket Protocol, a technology for bidirectional communication between an HTTP client and an = HTTP server that provides greater efficiency than previous approaches (e.g., use of hanging requests = or long polling). Having completed work on the core protocol (RFC 6455), the group contin= ues to define extensions for use by WebSocket implementations. The following extensions and optimization= s are currently in scope: 1. Define a per-frame compression extension to improve the bandwidth us= age. 2. Define a multiplexing extension to improve the scalability of the We= bSocket protocol 3. Define timeout-handling capabilities to reduce the chattiness of the= protocol The working group will also serve as a discussion forum for subprotocol= s. However, no subprotocol is currently chartered as official WG item. The HyBi working group will continue its liaison with the W3C WepApps w= orking group with respect to the above deliverables and to ensure the best match possible between the= WebSocket protocol and the WebSocket API. The WG will also continue coordinating with other WGs wi= thin the IETF (e.g., HTTPbis) as appropriate. Goal and Milestones: May 2012 - Issue WG last call on the per-frame compression extension Jun 2012 - Send per-frame compression extension to IESG for publication= as Proposed Standard Aug 2012 - Issue WG last call on timeout handling Sep 2012 - Issue WG last call on the multiplexing extension Oct 2012 - Send timeout handling to IESG for publication as Proposed St= andard Nov 2012 - Send Multiplexing extension to IESG for publication as Propo= sed Standard best regards Salvatore Loreto www.sloreto.com --_000_0FDF715F51EF4B4BA69B4A7B865DBD9B3A637AB5D6ESESSCMS0363e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi there,
 
as you know
the WebSocket Protocol has been published on December 2011 as RFC 6455= .
 
Thanks again to all of you for all your technical and editorial contri= butions to the design of the protocol.
 
 
Now having completed the work on the core protocol, we are ready as a = group to continue the discussion
to define extensions for use by WebSocket implementations.
 
Gabriel and I have worked on a draft of the new charter for the HyBi w= g that is focused
on the main extensions that have already been discussed by the WG last= year.
(See the charter below)
 
Please let we know your opinion on the draft.
All the feedback, suggestions and proposal are really welcome.
 
 
 
New Charter
------------------
 
Description of Working Group:
 
    The BiDirectional or Server-Initiated HTTP (HyBi) w= orking group defines the WebSocket Protocol,
a technology for bidirectional communication between an HTTP client an= d an HTTP server that provides
greater efficiency than previous approaches (e.g., use of hanging requ= ests or long polling).
 
    Having completed work on the core protocol (RFC 645= 5), the group continues to define extensions for
use by WebSocket implementations. The following extensions and optimiz= ations are currently in scope:
 
    1. Define a per-frame compression extension to impr= ove the bandwidth usage.
 
    2. Define a multiplexing extension to improve the s= calability of the WebSocket protocol
 
    3. Define timeout-handling capabilities to reduce t= he chattiness of the protocol
 
 
    The working group will also serve as a discussion f= orum for subprotocols.
However, no subprotocol is currently chartered as official WG item.
 
    The HyBi working group will continue its liaison wi= th the W3C WepApps working group with respect
to the above deliverables and to ensure the best match possible betwee= n the WebSocket protocol and
the WebSocket API. The WG will also continue coordinating with other W= Gs within the IETF (e.g., HTTPbis)
as appropriate.
 
    Goal and Milestones:
 
    May 2012 - Issue WG last call on the per-frame comp= ression extension
 
    Jun 2012 - Send per-frame compression extension to = IESG for publication as Proposed Standard
 
    Aug 2012 - Issue WG last call on timeout handling
 
    Sep 2012 - Issue WG last call on the multiplexing e= xtension
 
    Oct 2012 - Send timeout handling to IESG for public= ation as Proposed Standard
 
    Nov 2012 - Send Multiplexing extension to IESG for = publication as Proposed Standard
 
 
 
 
 
best regards
Salvatore Loreto
 
 
--_000_0FDF715F51EF4B4BA69B4A7B865DBD9B3A637AB5D6ESESSCMS0363e_-- From jat@google.com Fri Jan 20 04:45:35 2012 Return-Path: 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 05AEB21F85A3 for ; Fri, 20 Jan 2012 04:45:35 -0800 (PST) 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=[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 kZ-j0JOTAvVb for ; Fri, 20 Jan 2012 04:45:33 -0800 (PST) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0179421F8591 for ; Fri, 20 Jan 2012 04:45:25 -0800 (PST) Received: by qady23 with SMTP id y23so358413qad.10 for ; Fri, 20 Jan 2012 04:45:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:x-system-of-record:content-type; bh=L/J2wo9CtYgfIVRxm5vBY8PdqlG0V0uu10gfSX1CD0k=; b=OXhXCEdw9M08Kcg4DZwtuzdiFqHCzn4z+vdN+/y+TLIoHJM9yEL7bIXnl9Ewn5alic 4BgJ/T4+QsbyYMcAhHdPLSC8TH2STo61MJh4NVToNxCwP5+m/WCqT8WBvAhzZ/EFZIP+ poqcBXHvvycuRqmo6+xvvUykgBw63TjNrrpFE= Received: by 10.224.223.75 with SMTP id ij11mr32831669qab.3.1327063525433; Fri, 20 Jan 2012 04:45:25 -0800 (PST) Received: by 10.224.223.75 with SMTP id ij11mr32831660qab.3.1327063525319; Fri, 20 Jan 2012 04:45:25 -0800 (PST) MIME-Version: 1.0 Received: by 10.229.105.15 with HTTP; Fri, 20 Jan 2012 04:45:04 -0800 (PST) In-Reply-To: <0FDF715F51EF4B4BA69B4A7B865DBD9B3A637AB5D6@ESESSCMS0363.eemea.ericsson.se> References: <0FDF715F51EF4B4BA69B4A7B865DBD9B3A637AB5D6@ESESSCMS0363.eemea.ericsson.se> From: John Tamplin Date: Fri, 20 Jan 2012 07:45:04 -0500 Message-ID: To: Salvatore Loreto X-System-Of-Record: true Content-Type: multipart/alternative; boundary=20cf3074b4fe05655a04b6f50ed1 Cc: "hybi@ietf.org" Subject: Re: [hybi] New charter for HyBi wg X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jan 2012 12:45:35 -0000 --20cf3074b4fe05655a04b6f50ed1 Content-Type: text/plain; charset=UTF-8 On Wed, Jan 18, 2012 at 10:21 AM, Salvatore Loreto < salvatore.loreto@ericsson.com> wrote: > Gabriel and I have worked on a draft of the new charter for the HyBi wg > that is focused > on the main extensions that have already been discussed by the WG last > year. > (See the charter below) > > Please let we know your opinion on the draft. > All the feedback, suggestions and proposal are really welcome. > > > > New Charter > ------------------ > > Description of Working Group: > > The BiDirectional or Server-Initiated HTTP (HyBi) working group > defines the WebSocket Protocol, > a technology for bidirectional communication between an HTTP client and an > HTTP server that provides > greater efficiency than previous approaches (e.g., use of hanging requests > or long polling). > > Having completed work on the core protocol (RFC 6455), the group > continues to define extensions for > use by WebSocket implementations. The following extensions and > optimizations are currently in scope: > > 1. Define a per-frame compression extension to improve the bandwidth > usage. > > 2. Define a multiplexing extension to improve the scalability of the > WebSocket protocol > > 3. Define timeout-handling capabilities to reduce the chattiness of > the protocol > > > The working group will also serve as a discussion forum for > subprotocols. > However, no subprotocol is currently chartered as official WG item. > > The HyBi working group will continue its liaison with the W3C WepApps > working group with respect > to the above deliverables and to ensure the best match possible between > the WebSocket protocol and > the WebSocket API. The WG will also continue coordinating with other WGs > within the IETF (e.g., HTTPbis) > as appropriate. > > Goal and Milestones: > > May 2012 - Issue WG last call on the per-frame compression extension > > Jun 2012 - Send per-frame compression extension to IESG for > publication as Proposed Standard > > Aug 2012 - Issue WG last call on timeout handling > > Sep 2012 - Issue WG last call on the multiplexing extension > > Oct 2012 - Send timeout handling to IESG for publication as Proposed > Standard > > Nov 2012 - Send Multiplexing extension to IESG for publication as > Proposed Standard > This sounds fine to me -- from the sequence of milestones, I assume we would be working on these serially rather than in parallel, is that right? Regarding the dates, I think they are fine as a target, but I think it is likely to change as we start the discussions. Also, given the timeline of the base spec the dates seem perhaps optimistic :). -- John A. Tamplin Software Engineer (GWT), Google --20cf3074b4fe05655a04b6f50ed1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Wed, Jan 18, 2012 at 10:21 AM, Salvatore Lore= to <s= alvatore.loreto@ericsson.com> wrote:
Gabriel and I have worked on a draft of the new charter for the HyBi w= g that is focused
on the main extensions that have already been discussed by the WG last= year.
(See the charter below)
=C2=A0
Please let we know your opinion on the draft.
All the feedback, suggestions and proposal are really welcome.
=C2=A0
=C2=A0
=C2=A0
New Charter
------------------
=C2=A0
Description of Working Group:
=C2=A0
=C2=A0=C2=A0=C2=A0 The BiDirectional or Server-Initiated HTTP (HyBi) w= orking group defines the WebSocket Protocol,
a technology for bidirectional communication between an HTTP client an= d an HTTP server that provides
greater efficiency than previous approaches (e.g., use of hanging requ= ests or long polling).
=C2=A0
=C2=A0=C2=A0=C2=A0 Having completed work on the core protocol (RFC 645= 5), the group continues to define extensions for
use by WebSocket implementations. The following extensions and optimiz= ations are currently in scope:
=C2=A0
=C2=A0=C2=A0=C2=A0 1. Define a per-frame compression extension to impr= ove the bandwidth usage.
=C2=A0
=C2=A0=C2=A0=C2=A0 2. Define a multiplexing extension to improve the s= calability of the WebSocket protocol
=C2=A0
=C2=A0=C2=A0=C2=A0 3. Define timeout-handling capabilities to reduce t= he chattiness of the protocol
=C2=A0
=C2=A0
=C2=A0=C2=A0=C2=A0 The working group will also serve as a discussion f= orum for subprotocols.
However, no subprotocol is currently chartered as official WG item.
=C2=A0
=C2=A0=C2=A0=C2=A0 The HyBi working group will continue its liaison wi= th the W3C WepApps working group with respect
to the above deliverables and to ensure the best match possible betwee= n the WebSocket protocol and
the WebSocket API. The WG will also continue coordinating with other W= Gs within the IETF (e.g., HTTPbis)
as appropriate.
=C2=A0
=C2=A0=C2=A0=C2=A0 Goal and Milestones:
=C2=A0
=C2=A0=C2=A0=C2=A0 May 2012 - Issue WG last call on the per-frame comp= ression extension
=C2=A0
=C2=A0=C2=A0=C2=A0 Jun 2012 - Send per-frame compression extension to = IESG for publication as Proposed Standard
=C2=A0
=C2=A0=C2=A0=C2=A0 Aug 2012 - Issue WG last call on timeout handling
=C2=A0
=C2=A0=C2=A0=C2=A0 Sep 2012 - Issue WG last call on the multiplexing e= xtension
=C2=A0
=C2=A0=C2=A0=C2=A0 Oct 2012 - Send timeout handling to IESG for public= ation as Proposed Standard
=C2=A0
=C2=A0=C2=A0=C2=A0 Nov 2012 - Send Multiplexing extension to IESG for = publication as Proposed Standard

This sounds fine to me -- from the sequence of milestones, I assum= e we would be working on these serially rather than in parallel, is that ri= ght?

Regarding the dates, I think they are fine as a target,= but I think it is likely to change as we start the discussions. =C2=A0Also= , given the timeline of the base spec the dates seem perhaps optimistic :).=

--
John A. Tamplin
Software Engineer (GWT), Goo= gle
--20cf3074b4fe05655a04b6f50ed1-- From alexey.melnikov@isode.com Fri Jan 20 09:55:50 2012 Return-Path: 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 5DAF221F8682 for ; Fri, 20 Jan 2012 09:55:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.233 X-Spam-Level: X-Spam-Status: No, score=-102.233 tagged_above=-999 required=5 tests=[AWL=0.366, BAYES_00=-2.599, 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 7xmO4PKctESp for ; Fri, 20 Jan 2012 09:55:49 -0800 (PST) Received: from rufus.isode.com (cl-125.lon-03.gb.sixxs.net [IPv6:2a00:14f0:e000:7c::2]) by ietfa.amsl.com (Postfix) with ESMTP id 1B0B721F8565 for ; Fri, 20 Jan 2012 09:55:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1327082145; d=isode.com; s=selector; i=@isode.com; bh=2bnRWFCDDjnthfpdLEmyRg43Mh3Bq5YdPCgPQJdGd9w=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=ANd7T6o7zgiM1Qb2NGv8gexaFpnoGboSJMFpHNMh0v3Fm6HuLMvyq1n6aVkE2yhVFYewFx VnrgyX2ckcfff+WW3vxQ6YYFwR3RKQ3EpZ9qDkXoX7n1DeZ6A9mDZ4dXU+IZgWo0RB6MEs oKlk8H5c4QAMAetXb+1PpxYk1/Ij84M=; Received: from [188.28.86.130] (188.28.86.130.threembb.co.uk [188.28.86.130]) by rufus.isode.com (submission channel) via TCP with ESMTPSA id ; Fri, 20 Jan 2012 17:55:42 +0000 Message-ID: <4F19947A.6080904@isode.com> Date: Fri, 20 Jan 2012 16:21:14 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:8.0) Gecko/20111105 Thunderbird/8.0 To: John Tamplin References: <0FDF715F51EF4B4BA69B4A7B865DBD9B3A637AB5D6@ESESSCMS0363.eemea.ericsson.se> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "hybi@ietf.org" Subject: Re: [hybi] New charter for HyBi wg X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jan 2012 17:55:50 -0000 Hi John, On 20/01/2012 12:45, John Tamplin wrote: [...] > This sounds fine to me -- from the sequence of milestones, I assume we > would be working on these serially rather than in parallel, is that right? In general this is up to the WG chairs. They may or may not allow for some level of parallel processing. But the main idea is to concentrate on things listed first. > Regarding the dates, I think they are fine as a target, but I think it > is likely to change as we start the discussions. Also, given the > timeline of the base spec the dates seem perhaps optimistic :). They might be optimistic, but they can be adjusted later on. From jesse.mcconnell@gmail.com Fri Jan 20 10:14:48 2012 Return-Path: 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 BCCAD21F86D7 for ; Fri, 20 Jan 2012 10:14:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 r7994HsMRgRQ for ; Fri, 20 Jan 2012 10:14:48 -0800 (PST) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 09EC621F8650 for ; Fri, 20 Jan 2012 10:14:47 -0800 (PST) Received: by qady23 with SMTP id y23so557874qad.10 for ; Fri, 20 Jan 2012 10:14:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=l+3ABWaicJEiBUfrFj0k+soSXo7D0joWLrMY5nww2g8=; b=OXeb/wfa/4G4JeaAX2MRPiPerU++x4bBmpU1XWWrgWK5wos5mpztgzCEblZZWeMMwu WExhO84XlAGd4GmZBZAgxstmXbyUKo0t92+fnEYa//+bJw3RbpyYeWpQYE+7EBc96JYF P4R9ZHsPAC8bwO8BK/QL1t8KG0NkB5vQ9L5FQ= MIME-Version: 1.0 Received: by 10.224.192.10 with SMTP id do10mr34698015qab.50.1327083286445; Fri, 20 Jan 2012 10:14:46 -0800 (PST) Received: by 10.229.98.212 with HTTP; Fri, 20 Jan 2012 10:14:46 -0800 (PST) In-Reply-To: <4F19947A.6080904@isode.com> References: <0FDF715F51EF4B4BA69B4A7B865DBD9B3A637AB5D6@ESESSCMS0363.eemea.ericsson.se> <4F19947A.6080904@isode.com> Date: Fri, 20 Jan 2012 12:14:46 -0600 Message-ID: From: Jesse McConnell To: Alexey Melnikov Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "hybi@ietf.org" Subject: Re: [hybi] New charter for HyBi wg X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jan 2012 18:14:48 -0000 Is it safe to assume that the starting place for the mux extension will be John's google-mux draft? If so, would it make sense to start off the extensions discussions there, or does it make more sense to work on some 'official' simple extensions before tackling that more complex one? I am a bit torn on where it would be best to start. I would like to see the mux 'official' as soon as possible but I am unclear if individual extensions could have much of an effect on the mux extension or vis versa. Just curious as he has some nice work done there which could be a nice starting point. cheers, jesse -- jesse mcconnell jesse.mcconnell@gmail.com On Fri, Jan 20, 2012 at 10:21, Alexey Melnikov wrote: > Hi John, > > On 20/01/2012 12:45, John Tamplin wrote: > =C2=A0[...] > >> This sounds fine to me -- from the sequence of milestones, I assume we >> would be working on these serially rather than in parallel, is that righ= t? > > > In general this is up to the WG chairs. They may or may not allow for som= e > level of parallel processing. But the main idea is to concentrate on thin= gs > listed first. > >> Regarding the dates, I think they are fine as a target, but I think it i= s >> likely to change as we start the discussions. =C2=A0Also, given the time= line of >> the base spec the dates seem perhaps optimistic :). > > > They might be optimistic, but they can be adjusted later on. > > _______________________________________________ > hybi mailing list > hybi@ietf.org > https://www.ietf.org/mailman/listinfo/hybi From jat@google.com Fri Jan 20 11:36:15 2012 Return-Path: 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 A0E3121F8647 for ; Fri, 20 Jan 2012 11:36:15 -0800 (PST) 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=[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 tgXNnvDF6Xdg for ; Fri, 20 Jan 2012 11:36:15 -0800 (PST) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id E624D21F8646 for ; Fri, 20 Jan 2012 11:36:14 -0800 (PST) Received: by vbbfr13 with SMTP id fr13so685849vbb.31 for ; Fri, 20 Jan 2012 11:36:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:x-system-of-record:content-type; bh=6lIJT5OfLtqwMN3XgHVQBR7kdTDBRBz0hxUaCUBqYaQ=; b=OhgQ8MGQLRdtRjuaoQsaXMD1NTDDFXrt4s4YWnykN9RU6mDCZr1frfpwuSBk+owQo/ JwE/dfAVMqivcNEgkVnmNyvUJtvM/yZRBmH0SYdSnTX2noVSz0fmVFvDrA+CUkkD2RSG pNxyvo2AQnM79aVuP7LjbpCdNLSHsXpLmfmqE= Received: by 10.52.33.77 with SMTP id p13mr15570399vdi.18.1327088173526; Fri, 20 Jan 2012 11:36:13 -0800 (PST) Received: by 10.52.33.77 with SMTP id p13mr15570389vdi.18.1327088173371; Fri, 20 Jan 2012 11:36:13 -0800 (PST) MIME-Version: 1.0 Received: by 10.220.117.132 with HTTP; Fri, 20 Jan 2012 11:35:51 -0800 (PST) In-Reply-To: References: <0FDF715F51EF4B4BA69B4A7B865DBD9B3A637AB5D6@ESESSCMS0363.eemea.ericsson.se> <4F19947A.6080904@isode.com> From: John Tamplin Date: Fri, 20 Jan 2012 14:35:51 -0500 Message-ID: To: Jesse McConnell X-System-Of-Record: true Content-Type: multipart/alternative; boundary=20cf307d02e028d21504b6facbd4 Cc: "hybi@ietf.org" Subject: Re: [hybi] New charter for HyBi wg X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jan 2012 19:36:15 -0000 --20cf307d02e028d21504b6facbd4 Content-Type: text/plain; charset=UTF-8 On Fri, Jan 20, 2012 at 1:14 PM, Jesse McConnell wrote: > Is it safe to assume that the starting place for the mux extension > will be John's google-mux draft? If so, would it make sense to start > off the extensions discussions there, or does it make more sense to > work on some 'official' simple extensions before tackling that more > complex one? I am a bit torn on where it would be best to start. I > would like to see the mux 'official' as soon as possible but I am > unclear if individual extensions could have much of an effect on the > mux extension or vis versa. > > Just curious as he has some nice work done there which could be a nice > starting point. > If someone has an alternate proposal, that is fine, but in the absence of that I suggest http://tools.ietf.org/html/draft-tamplin-hybi-google-mux-01 is as good a place to start as any. I suspect per-frame compression will be easier to get agreement on, and so could be completed more quickly. There is a pressing need for both, but shortest-job-first scheduling gets something useful deployed faster. -- John A. Tamplin Software Engineer (GWT), Google --20cf307d02e028d21504b6facbd4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Fri, Jan 20, 2012 at 1:14 PM, Jesse McConnell= <jesse.mcconnell@gmail.com> wrote:
Is it safe to assume that the starting place for the mux extension
will be John's google-mux draft? =C2=A0If so, would it make sense to st= art
off the extensions discussions there, or does it make more sense to
work on some 'official' simple extensions before tackling that more=
complex one? =C2=A0I am a bit torn on where it would be best to start. =C2= =A0I
would like to see the mux 'official' as soon as possible but I am unclear if individual extensions could have much of an effect on the
mux extension or vis versa.

Just curious as he has some nice work done there which could be a nice
starting point.

If someone has an alter= nate proposal, that is fine, but in the absence of that I suggest=C2=A0http://= tools.ietf.org/html/draft-tamplin-hybi-google-mux-01=C2=A0is as good a = place to start as any.

I suspect per-frame compression will be easier to get a= greement on, and so could be completed more quickly. =C2=A0There is a press= ing need for both, but shortest-job-first scheduling gets something useful = deployed faster.

--
John A. Tamplin
Software Engineer (GWT), Goo= gle
--20cf307d02e028d21504b6facbd4-- From Gabriel.Montenegro@microsoft.com Fri Jan 20 11:56:16 2012 Return-Path: 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 5952C21F8508 for ; Fri, 20 Jan 2012 11:56:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 9frFl6VwqdII for ; Fri, 20 Jan 2012 11:56:15 -0800 (PST) Received: from DB3EHSOBE002.bigfish.com (db3ehsobe002.messaging.microsoft.com [213.199.154.140]) by ietfa.amsl.com (Postfix) with ESMTP id 0EB0E21F84FB for ; Fri, 20 Jan 2012 11:56:14 -0800 (PST) Received: from mail114-db3-R.bigfish.com (10.3.81.254) by DB3EHSOBE002.bigfish.com (10.3.84.22) with Microsoft SMTP Server id 14.1.225.23; Fri, 20 Jan 2012 19:56:11 +0000 Received: from mail114-db3 (localhost [127.0.0.1]) by mail114-db3-R.bigfish.com (Postfix) with ESMTP id B86EE20507; Fri, 20 Jan 2012 19:56:11 +0000 (UTC) X-SpamScore: -24 X-BigFish: VS-24(zz9371Ic89bhc857h98dKzz1202hzz1033IL8275bh8275dhz2fhc1bhc31hc1ahc1bhc31hc1ah2a8h668h839h) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC101.redmond.corp.microsoft.com; RD:none; EFVD:NLI Received-SPF: pass (mail114-db3: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Gabriel.Montenegro@microsoft.com; helo=TK5EX14HUBC101.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail114-db3 (localhost.localdomain [127.0.0.1]) by mail114-db3 (MessageSwitch) id 1327089371530003_8533; Fri, 20 Jan 2012 19:56:11 +0000 (UTC) Received: from DB3EHSMHS012.bigfish.com (unknown [10.3.81.252]) by mail114-db3.bigfish.com (Postfix) with ESMTP id 7378E600053; Fri, 20 Jan 2012 19:56:11 +0000 (UTC) Received: from TK5EX14HUBC101.redmond.corp.microsoft.com (131.107.125.8) by DB3EHSMHS012.bigfish.com (10.3.87.112) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 20 Jan 2012 19:56:10 +0000 Received: from TK5EX14MLTW653.wingroup.windeploy.ntdev.microsoft.com (157.54.24.14) by TK5EX14HUBC101.redmond.corp.microsoft.com (157.54.7.153) with Microsoft SMTP Server (TLS) id 14.2.247.5; Fri, 20 Jan 2012 11:56:11 -0800 Received: from TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com ([169.254.4.102]) by TK5EX14MLTW653.wingroup.windeploy.ntdev.microsoft.com ([157.54.24.14]) with mapi id 14.01.0355.003; Fri, 20 Jan 2012 11:56:10 -0800 From: Gabriel Montenegro To: John Tamplin , Jesse McConnell Thread-Topic: [hybi] New charter for HyBi wg Thread-Index: AczV9NDcLG3qqhUYRnuolEHotiaefABv5IEAAAeMrgAAA/cSAAAC1PGAABA+aKA= Date: Fri, 20 Jan 2012 19:56:10 +0000 Message-ID: References: <0FDF715F51EF4B4BA69B4A7B865DBD9B3A637AB5D6@ESESSCMS0363.eemea.ericsson.se> <4F19947A.6080904@isode.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.42] Content-Type: multipart/alternative; boundary="_000_CA566BAEAD6B3F4E8B5C5C4F61710C1147E51918TK5EX14MBXW604w_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Cc: "hybi@ietf.org" Subject: Re: [hybi] New charter for HyBi wg X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jan 2012 19:56:16 -0000 --_000_CA566BAEAD6B3F4E8B5C5C4F61710C1147E51918TK5EX14MBXW604w_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 WWVzLCB0aGUgYXNzdW1wdGlvbiBpcyB0aGF0IG11bHRpcGxleGluZyB3aWxsIHVzZSBKb2hu4oCZ cyBkcmFmdCBhcyBhIHN0YXJ0aW5nIHBvaW50LCBhbmQgdGhlIGNvbXByZXNzaW9uIHdpbGwgdXNl IFRha2VzaGnigJlzIGRyYWZ0IGFzIGEgc3RhcnRpbmcgcG9pbnQuIEkgYWdyZWUgdGhhdCB0aGUg Y29tcHJlc3Npb24gZXh0ZW5zaW9uIGlzIGJldHRlciB1bmRlcnN0b29kIGFuZCBtb3JlIGNvbnRh aW5lZCwgd2hpY2ggaXMgd2h5IGl0IGlzIHRhcmdldGVkIGFzIGZpbmlzaGluZyBlYXJsaWVyLCBh bHRob3VnaCBzb21lIHBhcmFsbGVsIHdvcmsgbWlnaHQgYmUgb2sgYXMgb25lIHRhcGVycyBvZmYu IFdlIGNhbiBhbHdheXMgbW9kaWZ5IGRhdGVzIGFuZCBlc3RpbWF0ZXMgbGF0ZXIgb24sIGJ1dCB0 aGlzIGlzIGp1c3QgYSBmaXJzdCBzdGFiLg0KDQpJIGFncmVlIHRoYXQgdGhlIG11eCBleHRlbnNp b24gaXMgbW9yZSBjb21wbGV4IGFuZCBpbnZpdGUgZGlzY3Vzc2lvbiBhcyB0byBob3cgdGhlIFdH IHNlZXMgaXQgYW5kIHdoZXRoZXIgdGhlIGN1cnJlbnRseSBwcm9wb3NlZCBtaWxlc3RvbmVzIGFy ZSB3aXRoaW4gdGhlIGJhbGxwYXJrIChpdOKAmXMgb2sgZm9yIHRoZW0gdG8gYmUgc29tZXdoYXQg b3B0aW1pc3RpYywgYXMgd2VyZSBvdXIgb3JpZ2luYWwgY2hhcnRlcuKAmXMgbWlsZXN0b25lcyku DQoNCkZyb206IGh5YmktYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmh5YmktYm91bmNlc0BpZXRm Lm9yZ10gT24gQmVoYWxmIE9mIEpvaG4gVGFtcGxpbg0KU2VudDogMjAgSmFudWFyeSwgMjAxMiAx MTozNg0KVG86IEplc3NlIE1jQ29ubmVsbA0KQ2M6IGh5YmlAaWV0Zi5vcmcNClN1YmplY3Q6IFJl OiBbaHliaV0gTmV3IGNoYXJ0ZXIgZm9yIEh5Qmkgd2cNCg0KT24gRnJpLCBKYW4gMjAsIDIwMTIg YXQgMToxNCBQTSwgSmVzc2UgTWNDb25uZWxsIDxqZXNzZS5tY2Nvbm5lbGxAZ21haWwuY29tPG1h aWx0bzpqZXNzZS5tY2Nvbm5lbGxAZ21haWwuY29tPj4gd3JvdGU6DQpJcyBpdCBzYWZlIHRvIGFz c3VtZSB0aGF0IHRoZSBzdGFydGluZyBwbGFjZSBmb3IgdGhlIG11eCBleHRlbnNpb24NCndpbGwg YmUgSm9obidzIGdvb2dsZS1tdXggZHJhZnQ/ICBJZiBzbywgd291bGQgaXQgbWFrZSBzZW5zZSB0 byBzdGFydA0Kb2ZmIHRoZSBleHRlbnNpb25zIGRpc2N1c3Npb25zIHRoZXJlLCBvciBkb2VzIGl0 IG1ha2UgbW9yZSBzZW5zZSB0bw0Kd29yayBvbiBzb21lICdvZmZpY2lhbCcgc2ltcGxlIGV4dGVu c2lvbnMgYmVmb3JlIHRhY2tsaW5nIHRoYXQgbW9yZQ0KY29tcGxleCBvbmU/ICBJIGFtIGEgYml0 IHRvcm4gb24gd2hlcmUgaXQgd291bGQgYmUgYmVzdCB0byBzdGFydC4gIEkNCndvdWxkIGxpa2Ug dG8gc2VlIHRoZSBtdXggJ29mZmljaWFsJyBhcyBzb29uIGFzIHBvc3NpYmxlIGJ1dCBJIGFtDQp1 bmNsZWFyIGlmIGluZGl2aWR1YWwgZXh0ZW5zaW9ucyBjb3VsZCBoYXZlIG11Y2ggb2YgYW4gZWZm ZWN0IG9uIHRoZQ0KbXV4IGV4dGVuc2lvbiBvciB2aXMgdmVyc2EuDQoNCkp1c3QgY3VyaW91cyBh cyBoZSBoYXMgc29tZSBuaWNlIHdvcmsgZG9uZSB0aGVyZSB3aGljaCBjb3VsZCBiZSBhIG5pY2UN CnN0YXJ0aW5nIHBvaW50Lg0KDQpJZiBzb21lb25lIGhhcyBhbiBhbHRlcm5hdGUgcHJvcG9zYWws IHRoYXQgaXMgZmluZSwgYnV0IGluIHRoZSBhYnNlbmNlIG9mIHRoYXQgSSBzdWdnZXN0IGh0dHA6 Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXRhbXBsaW4taHliaS1nb29nbGUtbXV4LTAxIGlz IGFzIGdvb2QgYSBwbGFjZSB0byBzdGFydCBhcyBhbnkuDQoNCkkgc3VzcGVjdCBwZXItZnJhbWUg Y29tcHJlc3Npb24gd2lsbCBiZSBlYXNpZXIgdG8gZ2V0IGFncmVlbWVudCBvbiwgYW5kIHNvIGNv dWxkIGJlIGNvbXBsZXRlZCBtb3JlIHF1aWNrbHkuICBUaGVyZSBpcyBhIHByZXNzaW5nIG5lZWQg Zm9yIGJvdGgsIGJ1dCBzaG9ydGVzdC1qb2ItZmlyc3Qgc2NoZWR1bGluZyBnZXRzIHNvbWV0aGlu ZyB1c2VmdWwgZGVwbG95ZWQgZmFzdGVyLg0KDQotLQ0KSm9obiBBLiBUYW1wbGluDQpTb2Z0d2Fy ZSBFbmdpbmVlciAoR1dUKSwgR29vZ2xlDQo= --_000_CA566BAEAD6B3F4E8B5C5C4F61710C1147E51918TK5EX14MBXW604w_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Ik1TIE1pbmNobyI7DQoJcGFub3NlLTE6MiAyIDYgOSA0IDIgNSA4IDMgNDt9DQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OiJNUyBNaW5jaG8iOw0KCXBhbm9zZS0xOjIgMiA2IDkgNCAyIDUgOCAz IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUg NSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6VGFob21hOw0KCXBh bm9zZS0xOjIgMTEgNiA0IDMgNSA0IDQgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IlxATVMgTWluY2hvIjsNCglwYW5vc2UtMToyIDIgNiA5IDQgMiA1IDggMyA0O30NCi8qIFN0eWxl IERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFs DQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4w cHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQphOmxpbmssIHNw YW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0K CXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlu a0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4 dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUt dHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYi Ow0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhw b3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjt9DQpAcGFnZSBX b3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEu MGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+ PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9 ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBt c28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0 PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0K PC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0K PGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5ZZXMsIHRoZSBhc3N1bXB0aW9uIGlz IHRoYXQgbXVsdGlwbGV4aW5nIHdpbGwgdXNlIEpvaG7igJlzIGRyYWZ0IGFzIGEgc3RhcnRpbmcg cG9pbnQsIGFuZCB0aGUgY29tcHJlc3Npb24gd2lsbCB1c2UgVGFrZXNoaeKAmXMgZHJhZnQgYXMg YSBzdGFydGluZyBwb2ludC4gSSBhZ3JlZQ0KIHRoYXQgdGhlIGNvbXByZXNzaW9uIGV4dGVuc2lv biBpcyBiZXR0ZXIgdW5kZXJzdG9vZCBhbmQgbW9yZSBjb250YWluZWQsIHdoaWNoIGlzIHdoeSBp dCBpcyB0YXJnZXRlZCBhcyBmaW5pc2hpbmcgZWFybGllciwgYWx0aG91Z2ggc29tZSBwYXJhbGxl bCB3b3JrIG1pZ2h0IGJlIG9rIGFzIG9uZSB0YXBlcnMgb2ZmLiBXZSBjYW4gYWx3YXlzIG1vZGlm eSBkYXRlcyBhbmQgZXN0aW1hdGVzIGxhdGVyIG9uLCBidXQgdGhpcyBpcyBqdXN0IGEgZmlyc3QN CiBzdGFiLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+SSBhZ3JlZSB0aGF0IHRoZSBtdXggZXh0ZW5zaW9uIGlzIG1vcmUg Y29tcGxleCBhbmQgaW52aXRlIGRpc2N1c3Npb24gYXMgdG8gaG93IHRoZSBXRyBzZWVzIGl0IGFu ZCB3aGV0aGVyIHRoZSBjdXJyZW50bHkgcHJvcG9zZWQgbWlsZXN0b25lcyBhcmUgd2l0aGluIHRo ZSBiYWxscGFyaw0KIChpdOKAmXMgb2sgZm9yIHRoZW0gdG8gYmUgc29tZXdoYXQgb3B0aW1pc3Rp YywgYXMgd2VyZSBvdXIgb3JpZ2luYWwgY2hhcnRlcuKAmXMgbWlsZXN0b25lcykuPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYg c3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzow aW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVy LXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9z cGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtU YWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IGh5YmktYm91bmNlc0BpZXRmLm9y ZyBbbWFpbHRvOmh5YmktYm91bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+Sm9o biBUYW1wbGluPGJyPg0KPGI+U2VudDo8L2I+IDIwIEphbnVhcnksIDIwMTIgMTE6MzY8YnI+DQo8 Yj5Ubzo8L2I+IEplc3NlIE1jQ29ubmVsbDxicj4NCjxiPkNjOjwvYj4gaHliaUBpZXRmLm9yZzxi cj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW2h5YmldIE5ldyBjaGFydGVyIGZvciBIeUJpIHdnPG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIEZy aSwgSmFuIDIwLCAyMDEyIGF0IDE6MTQgUE0sIEplc3NlIE1jQ29ubmVsbCAmbHQ7PGEgaHJlZj0i bWFpbHRvOmplc3NlLm1jY29ubmVsbEBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5qZXNzZS5t Y2Nvbm5lbGxAZ21haWwuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5JcyBpdCBzYWZlIHRvIGFzc3VtZSB0aGF0IHRoZSBzdGFydGluZyBwbGFj ZSBmb3IgdGhlIG11eCBleHRlbnNpb248YnI+DQp3aWxsIGJlIEpvaG4ncyBnb29nbGUtbXV4IGRy YWZ0PyAmbmJzcDtJZiBzbywgd291bGQgaXQgbWFrZSBzZW5zZSB0byBzdGFydDxicj4NCm9mZiB0 aGUgZXh0ZW5zaW9ucyBkaXNjdXNzaW9ucyB0aGVyZSwgb3IgZG9lcyBpdCBtYWtlIG1vcmUgc2Vu c2UgdG88YnI+DQp3b3JrIG9uIHNvbWUgJ29mZmljaWFsJyBzaW1wbGUgZXh0ZW5zaW9ucyBiZWZv cmUgdGFja2xpbmcgdGhhdCBtb3JlPGJyPg0KY29tcGxleCBvbmU/ICZuYnNwO0kgYW0gYSBiaXQg dG9ybiBvbiB3aGVyZSBpdCB3b3VsZCBiZSBiZXN0IHRvIHN0YXJ0LiAmbmJzcDtJPGJyPg0Kd291 bGQgbGlrZSB0byBzZWUgdGhlIG11eCAnb2ZmaWNpYWwnIGFzIHNvb24gYXMgcG9zc2libGUgYnV0 IEkgYW08YnI+DQp1bmNsZWFyIGlmIGluZGl2aWR1YWwgZXh0ZW5zaW9ucyBjb3VsZCBoYXZlIG11 Y2ggb2YgYW4gZWZmZWN0IG9uIHRoZTxicj4NCm11eCBleHRlbnNpb24gb3IgdmlzIHZlcnNhLjxi cj4NCjxicj4NCkp1c3QgY3VyaW91cyBhcyBoZSBoYXMgc29tZSBuaWNlIHdvcmsgZG9uZSB0aGVy ZSB3aGljaCBjb3VsZCBiZSBhIG5pY2U8YnI+DQpzdGFydGluZyBwb2ludC48bzpwPjwvbzpwPjwv cD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPklmIHNvbWVvbmUgaGFzIGFuIGFsdGVy bmF0ZSBwcm9wb3NhbCwgdGhhdCBpcyBmaW5lLCBidXQgaW4gdGhlIGFic2VuY2Ugb2YgdGhhdCBJ IHN1Z2dlc3QmbmJzcDs8YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC10 YW1wbGluLWh5YmktZ29vZ2xlLW11eC0wMSI+aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJh ZnQtdGFtcGxpbi1oeWJpLWdvb2dsZS1tdXgtMDE8L2E+Jm5ic3A7aXMgYXMgZ29vZCBhDQogcGxh Y2UgdG8gc3RhcnQgYXMgYW55LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5JIHN1c3BlY3QgcGVyLWZyYW1lIGNvbXByZXNzaW9uIHdpbGwgYmUg ZWFzaWVyIHRvIGdldCBhZ3JlZW1lbnQgb24sIGFuZCBzbyBjb3VsZCBiZSBjb21wbGV0ZWQgbW9y ZSBxdWlja2x5LiAmbmJzcDtUaGVyZSBpcyBhIHByZXNzaW5nIG5lZWQgZm9yIGJvdGgsIGJ1dCBz aG9ydGVzdC1qb2ItZmlyc3Qgc2NoZWR1bGluZyBnZXRzIHNvbWV0aGluZyB1c2VmdWwgZGVwbG95 ZWQgZmFzdGVyLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+LS0gPGJyPg0KSm9obiBBLiBUYW1wbGluPGJyPg0KU29mdHdhcmUgRW5naW5lZXIg KEdXVCksIEdvb2dsZTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwv aHRtbD4NCg== --_000_CA566BAEAD6B3F4E8B5C5C4F61710C1147E51918TK5EX14MBXW604w_-- From tyoshino@google.com Sun Jan 22 20:33:48 2012 Return-Path: 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 CD34321F85F6 for ; Sun, 22 Jan 2012 20:33:48 -0800 (PST) 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=[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 W+-dKxAZ3MhS for ; Sun, 22 Jan 2012 20:33:48 -0800 (PST) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id D20AD21F85E4 for ; Sun, 22 Jan 2012 20:33:47 -0800 (PST) Received: by ghbg16 with SMTP id g16so645215ghb.31 for ; Sun, 22 Jan 2012 20:33:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:x-system-of-record:x-gm-message-state:content-type; bh=z2Kt4K+sJsYEXk1D+n/ssJXv28nm20JGvfII4u3Rlts=; b=yaf4vKIDvw8l2sOZQU+W46qdG3LHXddRZv2cEH7M5v+EigYTdVnwHqxi9q1Oit8XXR 447ojYhlnVaIFe1MC8341gw0jKcJSGCFFfoT4i+jUDjolr3Zx5WWnEpi96Ux7//t6p1d hq+SawrVSV7aIqP3RyvBo6uXSQE+KnvqHwuhs= Received: by 10.236.85.230 with SMTP id u66mr8685412yhe.83.1327293227456; Sun, 22 Jan 2012 20:33:47 -0800 (PST) Received: by 10.236.85.230 with SMTP id u66mr8685396yhe.83.1327293227326; Sun, 22 Jan 2012 20:33:47 -0800 (PST) MIME-Version: 1.0 Received: by 10.100.236.35 with HTTP; Sun, 22 Jan 2012 20:33:26 -0800 (PST) In-Reply-To: References: <0FDF715F51EF4B4BA69B4A7B865DBD9B3A637AB5D6@ESESSCMS0363.eemea.ericsson.se> <4F19947A.6080904@isode.com> From: Takeshi Yoshino Date: Mon, 23 Jan 2012 13:33:26 +0900 Message-ID: To: Gabriel Montenegro X-System-Of-Record: true X-Gm-Message-State: ALoCoQmuXJuMN8enwj6EikcTo70+qfWAnwS1nBHzkcdGAyYtv9RWMlYCtLy3GvNIe+bB5HMp1Jrk2z/8ONGtMVu3N/rgORg2Eji2kQ2mLwDcFJBenYkl4RbQPb1u1GlWM5yRNjXRMkVy Content-Type: multipart/alternative; boundary=20cf300fa9c753dba504b72a8919 Cc: "hybi@ietf.org" Subject: Re: [hybi] New charter for HyBi wg X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jan 2012 04:33:48 -0000 --20cf300fa9c753dba504b72a8919 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I'm fine with the plan. Takeshi On Sat, Jan 21, 2012 at 04:56, Gabriel Montenegro < Gabriel.Montenegro@microsoft.com> wrote: > Yes, the assumption is that multiplexing will use John=92s draft as a > starting point, and the compression will use Takeshi=92s draft as a start= ing > point. I agree that the compression extension is better understood and mo= re > contained, which is why it is targeted as finishing earlier, although som= e > parallel work might be ok as one tapers off. We can always modify dates a= nd > estimates later on, but this is just a first stab.**** > > ** ** > > I agree that the mux extension is more complex and invite discussion as t= o > how the WG sees it and whether the currently proposed milestones are with= in > the ballpark (it=92s ok for them to be somewhat optimistic, as were our > original charter=92s milestones).**** > > ** ** > > *From:* hybi-bounces@ietf.org [mailto:hybi-bounces@ietf.org] *On Behalf > Of *John Tamplin > *Sent:* 20 January, 2012 11:36 > *To:* Jesse McConnell > *Cc:* hybi@ietf.org > *Subject:* Re: [hybi] New charter for HyBi wg**** > > ** ** > > On Fri, Jan 20, 2012 at 1:14 PM, Jesse McConnell < > jesse.mcconnell@gmail.com> wrote:**** > > Is it safe to assume that the starting place for the mux extension > will be John's google-mux draft? If so, would it make sense to start > off the extensions discussions there, or does it make more sense to > work on some 'official' simple extensions before tackling that more > complex one? I am a bit torn on where it would be best to start. I > would like to see the mux 'official' as soon as possible but I am > unclear if individual extensions could have much of an effect on the > mux extension or vis versa. > > Just curious as he has some nice work done there which could be a nice > starting point.**** > > ** ** > > If someone has an alternate proposal, that is fine, but in the absence of > that I suggest http://tools.ietf.org/html/draft-tamplin-hybi-google-mux-0= 1 is > as good a place to start as any.**** > > ** ** > > I suspect per-frame compression will be easier to get agreement on, and s= o > could be completed more quickly. There is a pressing need for both, but > shortest-job-first scheduling gets something useful deployed faster.**** > > ** ** > > -- > John A. Tamplin > Software Engineer (GWT), Google**** > > _______________________________________________ > hybi mailing list > hybi@ietf.org > https://www.ietf.org/mailman/listinfo/hybi > > --20cf300fa9c753dba504b72a8919 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
I'm fine with the plan.

Takeshi


On Sat, Jan 21, 2012 at 04:56, Gabriel M= ontenegro <Gabriel.Montenegro@microsoft.com> wrote:

Yes, the assumption is th= at multiplexing will use John=92s draft as a starting point, and the compre= ssion will use Takeshi=92s draft as a starting point. I agree that the compression extension is better understood and more contained, wh= ich is why it is targeted as finishing earlier, although some parallel work= might be ok as one tapers off. We can always modify dates and estimates la= ter on, but this is just a first stab.

=A0<= /p>

I agree that the mux exte= nsion is more complex and invite discussion as to how the WG sees it and wh= ether the currently proposed milestones are within the ballpark (it=92s ok for them to be somewhat optimistic, as were our original charte= r=92s milestones).

=A0<= /p>

From: hybi-bounces@ietf.org [mailto:hybi-= bounces@ietf.org] On Behalf Of John Tamplin
Sent: 20 January, 2012 11:36
To: Jesse McConnell
Cc: hybi@ietf.org=
Subject: Re: [hybi] New charter for HyBi wg

=A0

On Fri, Jan 20, 2012 at 1:14 PM, Jesse McConnell <= ;jesse.mccon= nell@gmail.com> wrote:

Is it safe to assume that the starting place for the= mux extension
will be John's google-mux draft? =A0If so, would it make sense to start=
off the extensions discussions there, or does it make more sense to
work on some 'official' simple extensions before tackling that more=
complex one? =A0I am a bit torn on where it would be best to start. =A0I would like to see the mux 'official' as soon as possible but I am unclear if individual extensions could have much of an effect on the
mux extension or vis versa.

Just curious as he has some nice work done there which could be a nice
starting point.

=A0

If someone has an alternate proposal, that is fine, = but in the absence of that I suggest=A0http://tools.ietf.org= /html/draft-tamplin-hybi-google-mux-01=A0is as good a place to start as any.

=A0

I suspect per-frame compression will be easier to ge= t agreement on, and so could be completed more quickly. =A0There is a press= ing need for both, but shortest-job-first scheduling gets something useful = deployed faster.

=A0

--
John A. Tamplin
Software Engineer (GWT), Google


_______________________________________________
hybi mailing list
hybi@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/hybi


--20cf300fa9c753dba504b72a8919-- From stpeter@stpeter.im Mon Jan 23 20:05:34 2012 Return-Path: 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 C368821F84B3 for ; Mon, 23 Jan 2012 20:05:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.719 X-Spam-Level: X-Spam-Status: No, score=-102.719 tagged_above=-999 required=5 tests=[AWL=-0.120, BAYES_00=-2.599, 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 7rLqcgE+ugNF for ; Mon, 23 Jan 2012 20:05:34 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 2F68721F8458 for ; Mon, 23 Jan 2012 20:05:34 -0800 (PST) Received: from squire.local (unknown [216.17.251.49]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 44FF140058; Mon, 23 Jan 2012 21:15:14 -0700 (MST) Message-ID: <4F1E2E0D.5070805@stpeter.im> Date: Mon, 23 Jan 2012 21:05:33 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: Salvatore Loreto References: <0FDF715F51EF4B4BA69B4A7B865DBD9B3A637AB5D6@ESESSCMS0363.eemea.ericsson.se> In-Reply-To: <0FDF715F51EF4B4BA69B4A7B865DBD9B3A637AB5D6@ESESSCMS0363.eemea.ericsson.se> X-Enigmail-Version: 1.3.4 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "hybi@ietf.org" Subject: Re: [hybi] New charter for HyBi wg X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jan 2012 04:05:34 -0000 On 1/18/12 8:21 AM, Salvatore Loreto wrote: > Please let we know your opinion on the draft. > All the feedback, suggestions and proposal are really welcome. I'm encouraged by the positive response so far. If no one raises significant concerns by the end of the week, I will introduce this topic during the IESG telechat on February 2. Peter -- Peter Saint-Andre https://stpeter.im/ From tyoshino@google.com Thu Jan 26 20:55:01 2012 Return-Path: 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 2167021F8623 for ; Thu, 26 Jan 2012 20:55:01 -0800 (PST) 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=[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 R20i7UlhlLqQ for ; Thu, 26 Jan 2012 20:55:00 -0800 (PST) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8A0CE21F85F4 for ; Thu, 26 Jan 2012 20:55:00 -0800 (PST) Received: by yhnn12 with SMTP id n12so681480yhn.31 for ; Thu, 26 Jan 2012 20:55:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=gamma; h=mime-version:from:date:message-id:subject:to:x-system-of-record :content-type; bh=0c3T7+NHi3aG6HrqkbeVEdxmWJahrsBq6X1s2n3htMI=; b=p1Ua3MuZXDVXyHooi7diZ7B2yPrDQgDMsfP78jvszHF2L6Ilx879y3H5pLpctg+FQ9 aarcYgN2p2sQsuSWHH2l60MDTg/XlgiFAWKIUvSC/42wHMGhc9lwIQDlgL77bE7U4rT5 anKZFb7CnBOlo9SBnopjouUV8fwAUE9hQLoiM= Received: by 10.236.193.68 with SMTP id j44mr7355404yhn.117.1327640098431; Thu, 26 Jan 2012 20:54:58 -0800 (PST) Received: by 10.236.193.68 with SMTP id j44mr7355396yhn.117.1327640098311; Thu, 26 Jan 2012 20:54:58 -0800 (PST) MIME-Version: 1.0 Received: by 10.100.236.35 with HTTP; Thu, 26 Jan 2012 20:54:38 -0800 (PST) From: Takeshi Yoshino Date: Fri, 27 Jan 2012 13:54:38 +0900 Message-ID: To: hybi@ietf.org X-System-Of-Record: true Content-Type: multipart/alternative; boundary=20cf305b0c64730eb304b77b4c9c Subject: [hybi] Multiplexing extension spec draft 02 X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jan 2012 04:55:01 -0000 --20cf305b0c64730eb304b77b4c9c Content-Type: text/plain; charset=ISO-8859-1 http://tools.ietf.org/html/draft-tamplin-hybi-google-mux-02 Diff http://tools.ietf.org/rfcdiff?url2=draft-tamplin-hybi-google-mux-02.txt No semantic change. - some typo fixes - named "control channel" explicitly - updated reference to point RFC - added some vertical space for readability --20cf305b0c64730eb304b77b4c9c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

No semantic change.

- some typo fixes
- named "c= ontrol channel" explicitly
- updated reference to point RFC<= /div>
- added some vertical space for readability

--20cf305b0c64730eb304b77b4c9c-- From sustrik@250bpm.com Thu Jan 26 22:57:23 2012 Return-Path: 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 2C66821F84A5 for ; Thu, 26 Jan 2012 22:57:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.694 X-Spam-Level: X-Spam-Status: No, score=-1.694 tagged_above=-999 required=5 tests=[AWL=-1.000, BAYES_00=-2.599, HELO_EQ_SK=1.35, HOST_EQ_SK=0.555] 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 fyzNfxCyU8Sd for ; Thu, 26 Jan 2012 22:57:22 -0800 (PST) Received: from mail.moloch.sk (chrocht.moloch.sk [62.176.169.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9761D21F8498 for ; Thu, 26 Jan 2012 22:57:21 -0800 (PST) Received: from [130.100.142.206] (unknown [211.175.81.2]) by mail.moloch.sk (Postfix) with ESMTPSA id 7FA481800F72; Fri, 27 Jan 2012 07:57:19 +0100 (CET) Message-ID: <4F224ACB.60602@250bpm.com> Date: Fri, 27 Jan 2012 15:57:15 +0900 From: Martin Sustrik User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20111124 Thunderbird/8.0 MIME-Version: 1.0 To: Takeshi Yoshino References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: hybi@ietf.org Subject: Re: [hybi] Multiplexing extension spec draft 02 X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jan 2012 06:57:23 -0000 On 01/27/2012 01:54 PM, Takeshi Yoshino wrote: > http://tools.ietf.org/html/draft-tamplin-hybi-google-mux-02 I would say it's worth explicitly stating that an endpoint MUST NOT announce larger quota than it can immediately read from the network (i.e. the amount of empty space in channel's rx buffer). Failure to do so can result in all the channels being stuck because of the single offending channel. Martin From tyoshino@google.com Sun Jan 29 21:09:18 2012 Return-Path: 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 9A28F21F84F7 for ; Sun, 29 Jan 2012 21:09:18 -0800 (PST) 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=[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 JIU4DHtcl-c2 for ; Sun, 29 Jan 2012 21:09:18 -0800 (PST) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id B7C4721F84DC for ; Sun, 29 Jan 2012 21:09:17 -0800 (PST) Received: by yhnn12 with SMTP id n12so1736842yhn.31 for ; Sun, 29 Jan 2012 21:09:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:x-system-of-record:content-type; bh=WuE/jKnbaZgEhpwejbO2mLUJ5/h1vmA/P8b0DZEg6xs=; b=I8qmvRQbSKRCUuCZ+TOSvP8h9mv89HfSYVXjZSEc+fJIKlga1T3sQbWeNx5pUt6+ai SbRp/LZodFXjKuPx7QAkkR7rbS0E6MStZI3Lqs1xBAtfmvmuAS8jaOGCuLlEVK6HfRzD fKnZmffib2B40s7t83O9q0i3T5B1jsmXd4aWg= Received: by 10.236.124.2 with SMTP id w2mr9865953yhh.83.1327900157336; Sun, 29 Jan 2012 21:09:17 -0800 (PST) Received: by 10.236.124.2 with SMTP id w2mr9865859yhh.83.1327900155541; Sun, 29 Jan 2012 21:09:15 -0800 (PST) MIME-Version: 1.0 Received: by 10.100.236.35 with HTTP; Sun, 29 Jan 2012 21:08:55 -0800 (PST) In-Reply-To: <4F224ACB.60602@250bpm.com> References: <4F224ACB.60602@250bpm.com> From: Takeshi Yoshino Date: Mon, 30 Jan 2012 14:08:55 +0900 Message-ID: To: Martin Sustrik X-System-Of-Record: true Content-Type: multipart/alternative; boundary=20cf300e50b711782904b7b7d93a Cc: hybi@ietf.org Subject: Re: [hybi] Multiplexing extension spec draft 02 X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jan 2012 05:09:18 -0000 --20cf300e50b711782904b7b7d93a Content-Type: text/plain; charset=ISO-8859-1 Hi, On Fri, Jan 27, 2012 at 15:57, Martin Sustrik wrote: > On 01/27/2012 01:54 PM, Takeshi Yoshino wrote: > >> http://tools.ietf.org/html/**draft-tamplin-hybi-google-mux-**02 >> > > I would say it's worth explicitly stating that an endpoint MUST NOT > announce larger quota than it can immediately read from the network (i.e. > the amount of empty space in channel's rx buffer). > I agree it's a caveat good to note, but we shouldn't limit flexibility of scheduling granularity by putting such MUST NOT in the protocol spec, I think. There might be some case where one wants to give more slot to some particular logical channel greater than size of that channel's buffer (any demand of large time slot for a particular channel, or any special QoS algorithm). > Failure to do so can result in all the channels being stuck because of the > single offending channel. I'd add this generalized implementation note if necessary. Be careful when you assign big quota for some logical channel. There is risk that the quota exceeds the processing capacity (buffer size, processing power, bandwidth, etc.) for that channel, and the endpoint can get stuck by getting excess data for that single offending channel occupying one shared TCP connection while there's room of processing capacity for the other channels. --20cf300e50b711782904b7b7d93a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,

On Fri, Jan 27, 2012 at 15:57, Martin Sustrik= <sustrik@250bpm= .com> wrote:
On 01/27/2012 01:54 PM, Takeshi Yoshino wrot= e:
http://tools.ietf.org/html/draft-tamplin-hybi-google-= mux-02

I would say it's worth explicitly stating that an endpoint MUST NOT ann= ounce larger quota than it can immediately read from the network (i.e. the = amount of empty space in channel's rx buffer).

I agree it's a caveat good to note, but we shouldn't= limit flexibility of=A0scheduling=A0granularity=A0by putting such MUST NOT= in the protocol spec, I think. There might be some case where one wants to= give more slot to some particular logical channel greater than size of tha= t channel's buffer (any demand of large time slot for a particular chan= nel, or any special QoS algorithm).
=A0
Failure to do so can result in all the channels being stuck because of the = single offending channel.

I'd add this = generalized implementation note if necessary.

Be careful when you assign=A0big quota for some logical channel. There is r= isk that the quota=A0exceeds the processing capacity (buffer size, processi= ng power, bandwidth, etc.) for that channel, and=A0the endpoint can get stu= ck by getting excess data for that single offending channel occupying one s= hared TCP connection while there's room of processing capacity for the = other channels.

--20cf300e50b711782904b7b7d93a-- From sustrik@250bpm.com Sun Jan 29 22:05:42 2012 Return-Path: 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 1097C21F858E for ; Sun, 29 Jan 2012 22:05:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.194 X-Spam-Level: X-Spam-Status: No, score=-1.194 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, HELO_EQ_SK=1.35, HOST_EQ_SK=0.555] 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 9RSNE+ciwl2b for ; Sun, 29 Jan 2012 22:05:41 -0800 (PST) Received: from mail.moloch.sk (chrocht.moloch.sk [62.176.169.44]) by ietfa.amsl.com (Postfix) with ESMTP id 36CAA21F8585 for ; Sun, 29 Jan 2012 22:05:41 -0800 (PST) Received: from [130.100.142.206] (unknown [211.175.81.2]) by mail.moloch.sk (Postfix) with ESMTPSA id D9F831800F67; Mon, 30 Jan 2012 07:05:38 +0100 (CET) Message-ID: <4F26332F.20806@250bpm.com> Date: Mon, 30 Jan 2012 15:05:35 +0900 From: Martin Sustrik User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20111124 Thunderbird/8.0 MIME-Version: 1.0 To: Takeshi Yoshino References: <4F224ACB.60602@250bpm.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: hybi@ietf.org Subject: Re: [hybi] Multiplexing extension spec draft 02 X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jan 2012 06:05:42 -0000 On 01/30/2012 02:08 PM, Takeshi Yoshino wrote: > I would say it's worth explicitly stating that an endpoint MUST NOT > announce larger quota than it can immediately read from the network > (i.e. the amount of empty space in channel's rx buffer). > > > I agree it's a caveat good to note, but we shouldn't limit flexibility > of scheduling granularity by putting such MUST NOT in the protocol spec, > I think. There might be some case where one wants to give more slot to > some particular logical channel greater than size of that channel's > buffer (any demand of large time slot for a particular channel, or any > special QoS algorithm). The scenario that I was referring to looks like this: 1. Receiver on channel 1 has 100 bytes in rx buffer free. 2. Despite of that it announces quota of 200 bytes. 3. Sender on channel 1 sends two 100-byte frames. 4. Sender on channel 2 sends another 100-byte frame. 5. Receiver on channel 1 receives the first 100-byte frame and stores it in the rx buffer. 6. Receiver on channel 1 can't receive the next 100-byte frame because its rx buffer is full. 7. Receiver on channel 2 has an empty rx buffer but cannot receive the frame send on the channel 2 because there's the pending channel 1 frame still lurking in the TCP rx buffer in front of it. This way overcommiting the quota on channel 1 caused channel 2 to be stuck (as well as channel 3 or any other channel on the same TCP connection). My original proposition was meant to explicitly prevent this kind of situation. Martin From w@1wt.eu Sun Jan 29 22:10:14 2012 Return-Path: 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 1D44421F8599 for ; Sun, 29 Jan 2012 22:10:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.55 X-Spam-Level: X-Spam-Status: No, score=-5.55 tagged_above=-999 required=5 tests=[AWL=-3.507, BAYES_00=-2.599, HELO_IS_SMALL6=0.556] 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 6hXBC8ljDHa5 for ; Sun, 29 Jan 2012 22:10:13 -0800 (PST) Received: from 1wt.eu (1wt.eu [62.212.114.60]) by ietfa.amsl.com (Postfix) with ESMTP id 0C26521F8596 for ; Sun, 29 Jan 2012 22:10:12 -0800 (PST) Received: (from willy@localhost) by mail.home.local (8.14.4/8.14.4/Submit) id q0U6A7iC000434; Mon, 30 Jan 2012 07:10:07 +0100 Date: Mon, 30 Jan 2012 07:10:07 +0100 From: Willy Tarreau To: Takeshi Yoshino Message-ID: <20120130061007.GL28091@1wt.eu> References: <4F224ACB.60602@250bpm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: hybi@ietf.org Subject: Re: [hybi] Multiplexing extension spec draft 02 X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jan 2012 06:10:14 -0000 Hi, On Mon, Jan 30, 2012 at 02:08:55PM +0900, Takeshi Yoshino wrote: > > I would say it's worth explicitly stating that an endpoint MUST NOT > > announce larger quota than it can immediately read from the network (i.e. > > the amount of empty space in channel's rx buffer). > > I agree it's a caveat good to note, but we shouldn't limit flexibility > of scheduling granularity by putting such MUST NOT in the protocol spec, I > think. There might be some case where one wants to give more slot to some > particular logical channel greater than size of that channel's buffer (any > demand of large time slot for a particular channel, or any special QoS > algorithm). In fact it is exactly similar to how TCP announces its receive window size, helping the sender not to overflow it. (...) > I'd add this generalized implementation note if necessary. > > Be careful when you assign big quota for some logical channel. There is > risk that the quota exceeds the processing capacity (buffer size, > processing power, bandwidth, etc.) for that channel, and the endpoint can > get stuck by getting excess data for that single offending channel > occupying one shared TCP connection while there's room of processing > capacity for the other channels. This means the endpoint should be smart enough not to announce the whole buffer for a single channel, and always announce less than what remains divided by the number of channels, in order to be able to infinitely divide it. That's suboptimal but offers equal space to everyone. On top of that, congestion control can be added to scale the advertised buffer size depending on how it's used. Multiplexing always comes with congestion control unfortunately, so it's not surprizing we're getting back to the same issues as lower layer protocols. I've already seen some papers about receive-side algorithms to modulate the advertised window but I can't find them right now. Regards, Willy From sustrik@250bpm.com Sun Jan 29 22:42:22 2012 Return-Path: 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 1567221F8576 for ; Sun, 29 Jan 2012 22:42:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.027 X-Spam-Level: X-Spam-Status: No, score=-1.027 tagged_above=-999 required=5 tests=[AWL=-0.333, BAYES_00=-2.599, HELO_EQ_SK=1.35, HOST_EQ_SK=0.555] 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 Q84CEnox5ViQ for ; Sun, 29 Jan 2012 22:42:21 -0800 (PST) Received: from mail.moloch.sk (chrocht.moloch.sk [62.176.169.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8716421F8499 for ; Sun, 29 Jan 2012 22:42:21 -0800 (PST) Received: from [130.100.142.206] (unknown [211.175.81.2]) by mail.moloch.sk (Postfix) with ESMTPSA id 3C84D1800F67; Mon, 30 Jan 2012 07:42:18 +0100 (CET) Message-ID: <4F263BC7.70400@250bpm.com> Date: Mon, 30 Jan 2012 15:42:15 +0900 From: Martin Sustrik User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20111124 Thunderbird/8.0 MIME-Version: 1.0 To: Willy Tarreau References: <4F224ACB.60602@250bpm.com> <20120130061007.GL28091@1wt.eu> In-Reply-To: <20120130061007.GL28091@1wt.eu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: hybi@ietf.org Subject: Re: [hybi] Multiplexing extension spec draft 02 X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jan 2012 06:42:22 -0000 On 01/30/2012 03:10 PM, Willy Tarreau wrote: > This means the endpoint should be smart enough not to announce the whole > buffer for a single channel, and always announce less than what remains > divided by the number of channels, in order to be able to infinitely divide > it. That's suboptimal but offers equal space to everyone. This way one overloaded channel can starve out other channels, although it'll happen in multiple iterations. In case of 2 channels, one idle, the other one overloaded the overloaded channel would first advertise 1/2 of the rx buffer, then 1/2 of the remaining part of the buffer (1/4 of the whole buffer) then 1/2 of that etc. The whole algorithm asymptotically approaches the entire buffer size. Once it is full, both channels are stuck, even the innocent one that was sending no data. The only way to ensure that one channel won't starve another one is to allocate separate buffer for each channel. That in turn means that you can DoS your peer by simply asking for inordinate number of channels and running it out of memory that way. SCTP which is another protocol with multiplexing built in solves this problem by asking user to specify the max number of channels when the endpoint is established. Martin From tyoshino@google.com Sun Jan 29 23:00:37 2012 Return-Path: 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 8922821F859B for ; Sun, 29 Jan 2012 23:00:37 -0800 (PST) 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 kG9Km4l0UpZy for ; Sun, 29 Jan 2012 23:00:37 -0800 (PST) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 05AB521F858E for ; Sun, 29 Jan 2012 23:00:36 -0800 (PST) Received: by yhnn12 with SMTP id n12so1762712yhn.31 for ; Sun, 29 Jan 2012 23:00:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:x-system-of-record:content-type; bh=w4lx1cweTATaM3n7U9yQBR6Evm63RmYw/W/sr19TCh4=; b=egjM28MtR8c+IsY0L+QpQiReBUclAlfBbPKL5j/jg5cLsCGYjbd6kuOa6LgyvFTmoR oiGDTxw9D2Vgf53wlUYyXWgFSDpOIj9tIjk26pZFvRXQNZpmaTpPpZ0sEdiGBwjB3FJ+ 4WLQpx9AxjW+x3HxztHLqv1ZMgcraNHBUORYs= Received: by 10.236.179.38 with SMTP id g26mr23716798yhm.100.1327906836443; Sun, 29 Jan 2012 23:00:36 -0800 (PST) Received: by 10.236.179.38 with SMTP id g26mr23716792yhm.100.1327906836377; Sun, 29 Jan 2012 23:00:36 -0800 (PST) MIME-Version: 1.0 Received: by 10.100.236.35 with HTTP; Sun, 29 Jan 2012 23:00:16 -0800 (PST) In-Reply-To: <4F26332F.20806@250bpm.com> References: <4F224ACB.60602@250bpm.com> <4F26332F.20806@250bpm.com> From: Takeshi Yoshino Date: Mon, 30 Jan 2012 16:00:16 +0900 Message-ID: To: Martin Sustrik X-System-Of-Record: true Content-Type: multipart/alternative; boundary=20cf303ddac446f03804b7b9670c Cc: hybi@ietf.org Subject: Re: [hybi] Multiplexing extension spec draft 02 X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jan 2012 07:00:37 -0000 --20cf303ddac446f03804b7b9670c Content-Type: text/plain; charset=ISO-8859-1 On Mon, Jan 30, 2012 at 15:05, Martin Sustrik wrote: > The scenario that I was referring to looks like this: > > 1. Receiver on channel 1 has 100 bytes in rx buffer free. > 2. Despite of that it announces quota of 200 bytes. > > ...snip... > My original proposition was meant to explicitly prevent this kind of > situation. Yes, I imagined similar example from your original post, and proposed the generalized text. --20cf303ddac446f03804b7b9670c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Mon, Jan 30, 2012 at 15:05, Martin Sustrik <sustrik@250bpm.co= m> wrote:
The scenario that I was referring to looks like this:
1. Receiver on channel 1 has 100 bytes in rx buffer free.
2. Despite of that it announces quota of 200 bytes.

...snip...=A0
My original proposition was meant to explicitly prevent this kind of situat= ion.

Yes, I imagined similar example from y= our original post, and proposed the generalized text.

--20cf303ddac446f03804b7b9670c--