From sustrik@250bpm.com Fri Jun 1 01:43:25 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 F1D3A21F85A2 for ; Fri, 1 Jun 2012 01:43:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.694 X-Spam-Level: X-Spam-Status: No, score=-0.694 tagged_above=-999 required=5 tests=[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 hS8UKaEkfKek for ; Fri, 1 Jun 2012 01:43:24 -0700 (PDT) Received: from mail.moloch.sk (chrocht.moloch.sk [62.176.169.44]) by ietfa.amsl.com (Postfix) with ESMTP id 035B321F85A0 for ; Fri, 1 Jun 2012 01:43:24 -0700 (PDT) Received: from [192.168.0.5] (host47-36-dynamic.181-80-r.retail.telecomitalia.it [80.181.36.47]) by mail.moloch.sk (Postfix) with ESMTPSA id F3FA118011A3; Fri, 1 Jun 2012 10:43:20 +0200 (CEST) Message-ID: <4FC880A7.9070007@250bpm.com> Date: Fri, 01 Jun 2012 10:43:19 +0200 From: Martin Sustrik User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.24) Gecko/20111109 Thunderbird/3.1.16 MIME-Version: 1.0 To: Arman Djusupov References: <001a01cd3e69$4a221c10$de665430$@noemax.com> <4FC732DC.3000308@250bpm.com> <000e01cd3f1c$af15ad40$0d4107c0$@noemax.com> In-Reply-To: <000e01cd3f1c$af15ad40$0d4107c0$@noemax.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: hybi@ietf.org Subject: Re: [hybi] Flow control quota 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, 01 Jun 2012 08:43:25 -0000 On 31/05/12 13:01, Arman Djusupov wrote: > When the per-frame compression extension is being used on a logical channel, > it is impossible to create a frame of exactly the desired size. A few bytes > of quota will always be unutilized unless some padding is used. The mux > specification prohibits sending frames bigger than the available quota. When > per-frame compression is applied on the payload before mux, this payload > cannot be fragmented any more. Even if we make compression extension mux > aware, it cannot produce a 1 byte compressed frame, it can only flag a frame > as uncompressed and simply send 1 byte. In general, sending 1 byte in a > separate frame is not desirable. That seems to suggest there's some kind of mis-layering happening here. Frames are used for flow control. Does it make sense to use them for compression as well? Shouldn't the compression rather happen on top of mutliplexing layer? The situation is similar to compressing the payload in TCP packets. It is feasible, but in corner cases it can clash with MTU limits, cause re-fragmentation etc. The clean solution would be to layer compression on top of TCP layer. Martin From tyoshino@google.com Fri Jun 1 04:04:43 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 C690921F864C for ; Fri, 1 Jun 2012 04:04:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.847 X-Spam-Level: X-Spam-Status: No, score=-102.847 tagged_above=-999 required=5 tests=[AWL=0.129, 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 mr1zKXVwtlcr for ; Fri, 1 Jun 2012 04:04:43 -0700 (PDT) Received: from mail-gg0-f172.google.com (mail-gg0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id F1AAA21F8642 for ; Fri, 1 Jun 2012 04:04:42 -0700 (PDT) Received: by ggnc4 with SMTP id c4so1801843ggn.31 for ; Fri, 01 Jun 2012 04:04:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=sUy1hrmwNegQbHx+muVLuvEj+F+RaFGD8KXMdl314jg=; b=Mf4Ws0qqXyBcqpqz8zEHv2ZIvrQUPssFVIllyZbQhK1LhyBzOluTP0Wal0vD/UbFti 2tpYQYSrmAfpLUs/+Nk7K94PpFIjaWxef36tt0XamGNUJsGN5TlhSI1v7x/my2nK5bSW rU+EkEB7pjFrpltxx8CjD3cpBGlJj4XUPQ/RAyCQTutPV3Mr4Mcv6OykfcDOWLzlPvDh HWkQzCwAEYIWt0uSF3TvivOtNYA2ha8ZtJ0sAX8Zu31GNJidGNaXBiop2QkI6uL01WQT VyNiznQNCF582ZtLeYh9Lx/nYaJr3EnEKOsd3XQAX2XnIni3MdxKSnu38pfGlblssQmj /Q4Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=sUy1hrmwNegQbHx+muVLuvEj+F+RaFGD8KXMdl314jg=; b=hBBxgGf16Nhws4pNzHeWLl9LD3WaMSkenetW5nyzuepPomWwHttnOUiycWN3zaSd2t l/UbvLBCEYf7LP4cTfmWL1Jo9d5tHZO1xuPYKO5DHCM3hmuB0pblIFiUPUrfEfOhPXxn jOAw8V8PVvEm//glLKzYOFl7ZmwKmR3y8x0kJZmcyt7GEXoGX1xdy7pPCoOs9vIkyc8C UL3YQCuRuKxWTy1D7ipOsufGe+lHCyu8Fr1xn+gP7KPOIcjR2jsM0hJ+IRIstLN3FRln RU8DD4my81daP4l8fAyYApyf4/z79jksDN4L2DFQSZ155uYj77RGGE7JWFnzqUH/lLuf Zz6w== Received: by 10.43.69.83 with SMTP id yb19mr1175005icb.29.1338548682055; Fri, 01 Jun 2012 04:04:42 -0700 (PDT) Received: by 10.43.69.83 with SMTP id yb19mr1174992icb.29.1338548681930; Fri, 01 Jun 2012 04:04:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.66.7 with HTTP; Fri, 1 Jun 2012 04:04:21 -0700 (PDT) In-Reply-To: <000e01cd3f1c$af15ad40$0d4107c0$@noemax.com> References: <001a01cd3e69$4a221c10$de665430$@noemax.com> <4FC732DC.3000308@250bpm.com> <000e01cd3f1c$af15ad40$0d4107c0$@noemax.com> From: Takeshi Yoshino Date: Fri, 1 Jun 2012 20:04:21 +0900 Message-ID: To: Arman Djusupov Content-Type: multipart/alternative; boundary=bcaec51b1ea3b3783e04c16726cb X-System-Of-Record: true X-Gm-Message-State: ALoCoQn4umgh/Sr6HJriI/RGeZo83gNLUkb6VhMcN5WD0mhKTctkVoWsdbpgbRmGdB/lVGNzGIyj9Dh88NFruPcYUQ4Vm8eb3+4ZBje9CGa0bEbL0Nf2Z6ihxu/C57g272u1xNVJ612A Cc: hybi@ietf.org Subject: Re: [hybi] Flow control quota 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, 01 Jun 2012 11:04:43 -0000 --bcaec51b1ea3b3783e04c16726cb Content-Type: text/plain; charset=ISO-8859-1 Hi Arman, Thanks for point out these risks. OK, we should note that the quota need to be replenished to some quantity without waiting for full consumption, maybe with the example of compression extension you mentioned. On Thu, May 31, 2012 at 8:01 PM, Arman Djusupov wrote: > When the per-frame compression extension is being used on a logical > channel, > it is impossible to create a frame of exactly the desired size. A few bytes > of quota will always be unutilized unless some padding is used. The mux > specification prohibits sending frames bigger than the available quota. > When > per-frame compression is applied on the payload before mux, this payload > cannot be fragmented any more. Even if we make compression extension mux > aware, it cannot produce a 1 byte compressed frame, it can only flag a > frame > as uncompressed and simply send 1 byte. In general, sending 1 byte in a > separate frame is not desirable. > > Extensions that set RSV bits prohibit frame fragmentation. This causes a > general incompatibility issue with mux FC when an extension is applied > before the mux. We need to consider whether there is a solution to this. > Yes, the multiplexing code need to feed back to extensions behind it to control fragment size. Limiting quota to very small value such as 1 byte persistently is not practical. The bandwidth will be quota / RTT. It's really slow. I think that warning the risk of dead lock is enough. --bcaec51b1ea3b3783e04c16726cb Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Arman,

Thanks for point out these risks.

OK, we should no= te that the=A0quota need to be replenished to some quantity without waiting= for full consumption, maybe with the example of compression extension you = mentioned.

On Thu, May 31, 2012 at 8:01 PM, Arman Djusupov <arman@no= emax.com> wrote:
When the pe= r-frame compression extension is being used on a logical channel,
it is impossible to create a frame of exactly the desired size. A few bytes=
of quota will always be unutilized unless some padding is used. The mux
specification prohibits sending frames bigger than the available quota. Whe= n
per-frame compression is applied on the payload before mux, this payload cannot be fragmented any more. Even if we make compression extension mux aware, it cannot produce a 1 byte compressed frame, it can only flag a fram= e
as uncompressed and simply send 1 byte. In general, sending 1 byte in a
separate frame is not desirable.

Extensions that set RSV bits prohibit frame fragmentation. This causes a general incompatibility issue with mux FC when an extension is applied
before the mux. We need to consider whether there is a solution to this.

Yes, the multiplexing code need to feed b= ack to extensions behind it to control fragment size.

Limiting quota t= o very small value such as 1 byte persistently is not practical. The bandwi= dth will be quota / RTT. It's really slow.=A0I think that warning the r= isk of dead lock is enough.
=A0
--bcaec51b1ea3b3783e04c16726cb-- From tyoshino@google.com Fri Jun 1 05:33:33 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 A7F8511E8450 for ; Fri, 1 Jun 2012 05:33:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.868 X-Spam-Level: X-Spam-Status: No, score=-102.868 tagged_above=-999 required=5 tests=[AWL=0.108, 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 Oek+wDr7XQdd for ; Fri, 1 Jun 2012 05:33:33 -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 1F43111E83EC for ; Fri, 1 Jun 2012 05:33:32 -0700 (PDT) Received: by yenq13 with SMTP id q13so1874918yen.31 for ; Fri, 01 Jun 2012 05:33:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=xzFWJ0+u/iUKgVm+nA8U5lMBXXLuR+a8YyyEoRG1FLQ=; b=FyT/cueVFqZd0rDx/D1LO7xp1NDdKVW4KNmXmAxz9k0pVn5fqVhL1ERw+9xbrBGUTM TivDPPFjqEaYzYm9HiUh3LtXzbbVWgHvPmRtzTFsZIil0B2bwU54uebghbndWE8iXnhI MdwtT/08RIL6KLTSi1HRnxeEA/+vLK6JhP+Gxl2aBsgoQEqqtQ5Mj3WCGTBnUaVf/XCG LFgEYjt2UyOx/XsFFHBBEBIYHeSV8A86A1AmSneovaTF+OLBhqG9CIrkhdfx+YwI+4oi MMopmxBpzj0i5HkReYq3FazsrU1mLUHLOLrsXxytsqobVvs/Cy/AKzz+UKBB7JarWBYr tEPQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=xzFWJ0+u/iUKgVm+nA8U5lMBXXLuR+a8YyyEoRG1FLQ=; b=kQQqfkRCCYZqdG1T4LebgXYMnYEuAxXCMNkmOKDQLd6PAv8zoYW1IBCBYd9lmuIwtt ouUc3O/FGWJGI9/cXb19O/9HvPGwDpDCPTI4fXSR5DspmQLcMqGT/0s1ieSJZXttm57U pyvTFIuLFSSirxgmvHwwWSi8+swmbFttp8smlChQecPxYU2t9//gbM+ln/N0imyqGa/e CioJaBTbQrkv4vmMw7OP7vIyAkKAClrP56wZ7H4sHnIhMExY84rSVKzXkl64HLaucKyc E7+pjnCwS6l6cR6KEK8LiRXbLLDQeCM2SrNYy696/+hwke+nxDBcjt0HN+3++mPWrFCv z+Hg== Received: by 10.50.185.165 with SMTP id fd5mr1220687igc.46.1338554012401; Fri, 01 Jun 2012 05:33:32 -0700 (PDT) Received: by 10.50.185.165 with SMTP id fd5mr1220673igc.46.1338554012238; Fri, 01 Jun 2012 05:33:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.66.7 with HTTP; Fri, 1 Jun 2012 05:33:11 -0700 (PDT) In-Reply-To: <4FC880A7.9070007@250bpm.com> References: <001a01cd3e69$4a221c10$de665430$@noemax.com> <4FC732DC.3000308@250bpm.com> <000e01cd3f1c$af15ad40$0d4107c0$@noemax.com> <4FC880A7.9070007@250bpm.com> From: Takeshi Yoshino Date: Fri, 1 Jun 2012 21:33:11 +0900 Message-ID: To: Martin Sustrik Content-Type: multipart/alternative; boundary=14dae9340d8369847604c1686489 X-System-Of-Record: true X-Gm-Message-State: ALoCoQmohYxT289siBP7roaHxfY7+5LJErXxpA1Hn8FrDV5MRU0Ia0OM5ukTh10m5PIq+0E9RmDuRCtvxPJbHH0pqSH/h4kE8fk9yX2VtILkSafsfjbVnnvz4Wp5LjLYEnbvXjEbZ8ch Cc: hybi@ietf.org Subject: Re: [hybi] Flow control quota 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, 01 Jun 2012 12:33:33 -0000 --14dae9340d8369847604c1686489 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Jun 1, 2012 at 5:43 PM, Martin Sustrik wrote: > That seems to suggest there's some kind of mis-layering happening here. > Frames are used for flow control. Does it make sense to use them for > compression as well? Shouldn't the compression rather happen on top of > mutliplexing layer? > > The situation is similar to compressing the payload in TCP packets. It is > feasible, but in corner cases it can clash with MTU limits, cause > re-fragmentation etc. The clean solution would be to layer compression on > top of TCP layer. Mux want to control fragmentation while per-frame compression locks down fragmentation. Yes, it's not healthy to use of per-frame compression before mux. Shall we discourage this layering (preframe-compress then mux)? --14dae9340d8369847604c1686489 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Fri, Jun 1, 2012 at 5:43 PM, Martin Sustrik <= span dir=3D"ltr"><sustrik@250bpm.com> wrote:
=A0
--14dae9340d8369847604c1686489-- From arman@noemax.com Fri Jun 1 07:16: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 5DAE121F897E for ; Fri, 1 Jun 2012 07:16:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.198 X-Spam-Level: X-Spam-Status: No, score=-2.198 tagged_above=-999 required=5 tests=[AWL=0.400, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 CQUTlCpvPwIR for ; Fri, 1 Jun 2012 07:16:20 -0700 (PDT) Received: from mail.noemax.com (mail.noemax.com [64.34.201.8]) by ietfa.amsl.com (Postfix) with ESMTP id D476521F897B for ; Fri, 1 Jun 2012 07:16:19 -0700 (PDT) DKIM-Signature: a=rsa-sha1; t=1338560177; x=1339164977; s=m1024; d=noemax.com; c=relaxed/relaxed; v=1; bh=qG9/RoFLb7VOtPD7ELaX3bCjXOs=; h=From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:In-Reply-To:References; b=B9JzpAYCNooFIUVWTVGx9WKL47UjXu7Dy8xDzD/3+94xPXfsCUTD3ZGNm8wLl6HGhULBrfv89ySt7fnJqL4H69240VffqaR0OnkRQBsYMBvZTaC2evckvDjAO0qPM2myq0jpmzXcjeVTtvSgR2cZ0cjgDQfFrLEMzzs0C7JfCzE= Received: from mail.noemax.com by mail.noemax.com (IceWarp 10.4.0) with ASMTP (SSL) id LUR96815; Fri, 01 Jun 2012 17:16:15 +0300 From: "Arman Djusupov" To: "'Takeshi Yoshino'" , "'Martin Sustrik'" References: <001a01cd3e69$4a221c10$de665430$@noemax.com> <4FC732DC.3000308@250bpm.com> <000e01cd3f1c$af15ad40$0d4107c0$@noemax.com> <4FC880A7.9070007@250bpm.com> In-Reply-To: Date: Fri, 1 Jun 2012 17:15:19 +0300 Message-ID: <001001cd4000$fe2c82c0$fa858840$@noemax.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0011_01CD401A.237BB690" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQDnHEYxNcL9Xb2UVJoRm1lbL/BkAQFoH3KRAV1ppa8CZ6BgXAIpbgj4mHcUAXA= Content-Language: en-us Cc: hybi@ietf.org Subject: Re: [hybi] Flow control quota 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, 01 Jun 2012 14:16:23 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0011_01CD401A.237BB690 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Unfortunately making extensions mutually aware of each other at the implementation level does not prevent problems from being encountered by a mux intermediary that receives a frame with an RSV bit set. An intermediary is not permitted to fragment a frame with an RSV bit set especially when the extension is unknown. If such a frame is larger than the available quota then the intermediary would have to wait until the quota becomes larger than the frame size before it can send it. This will result in the frame never being sent if its size is larger than the flow control window. A practical example of this problem is that a mux intermediary might end up being unable to forward compressed frames larger than the flow control window, unless it first decompresses them and refragments them. I am trying to figure out a general purpose solution that would allow us to deal with non-fragmentable frames, even if the extension that is applied to them is unknown. So far I have two ideas: 1. Allow the sender to send a frame with an RSV bit set even if it is bigger that the available quota. In such a case the quota becomes negative and from that moment on the sending side MUST wait until the quota becomes positive before sending the subsequent frame. This way the flow control would work and the sender would be able to send a frame that is larger than the available quota but cannot be fragmented. Flow control is not intended to limit the maximum frame size, but rather to prevent a logical channel from exclusively using a physical connection. This solution would satisfy this requirement. A logical channel would wait as long as necessary until the quota becomes positive. This would let other channels use the physical connection. However, this solution would not prevent a sender from forcing the receiver to buffer an amount of bytes that is a larger than the amount it had agreed to buffer. But the amount of extra buffering required would not exceed the size of a single frame so a mux intermediary would at least be able to forward frames of reasonable size. 2. An alternative solution is to introduce a WebSocket fragmentation extension. Using this extension, multiplexing intermediaries would advertise the maximum frame size limit for non-mux clients. Non-mux clients that want their connections to be multiplexed by an intermediary would have to stick to the frame size limits required by that intermediary. By supporting this extension WebSocket client/browser vendors will be able to make their clients mux-intermediary-friendly. This would help not only in non-mux-client-to-mux-intermediary scenarios (and flow control in general) but would also permit us to advertise a frame size limit in any scenario where such limits are present. This was discussed by the WG but didn't made it into RFC 6455, the idea at that time was that it could go in a separate extension. So currently we have section 10.4 that requires implementations to protect themselves against exceeding frame size limits. A fragmentation extension would enable us to advertise these limits. 10.4. Implementation-Specific Limits Implementations that have implementation- and/or platform-specific limitations regarding the frame size or total message size after reassembly from multiple frames MUST protect themselves against exceeding those limits. (For example, a malicious endpoint can try to exhaust its peer's memory or mount a denial-of-service attack by sending either a single big frame (e.g., of size 2**60) or by sending a long stream of small frames that are a part of a fragmented message.) Such an implementation SHOULD impose a limit on frame sizes and the total message size after reassembly from multiple frames. With best regards, Arman From: Takeshi Yoshino [mailto:tyoshino@google.com] Sent: Friday, June 01, 2012 3:33 PM To: Martin Sustrik Cc: Arman Djusupov; hybi@ietf.org Subject: Re: [hybi] Flow control quota On Fri, Jun 1, 2012 at 5:43 PM, Martin Sustrik wrote: That seems to suggest there's some kind of mis-layering happening here. Frames are used for flow control. Does it make sense to use them for compression as well? Shouldn't the compression rather happen on top of mutliplexing layer? The situation is similar to compressing the payload in TCP packets. It is feasible, but in corner cases it can clash with MTU limits, cause re-fragmentation etc. The clean solution would be to layer compression on top of TCP layer. Mux want to control fragmentation while per-frame compression locks down fragmentation. Yes, it's not healthy to use of per-frame compression before mux. Shall we discourage this layering (preframe-compress then mux)? ------=_NextPart_000_0011_01CD401A.237BB690 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Unfortunately making extensions mutually aware of each other at the = implementation level does not prevent problems from being encountered by = a mux intermediary that receives a frame with an RSV bit set. An = intermediary is not permitted to fragment a frame with an RSV bit set = especially when the extension is unknown. If such a frame is larger than = the available quota then the intermediary would have to wait until the = quota becomes larger than the frame size before it can send it. This = will result in the frame never being sent if its size is larger than the = flow control window.

 

A practical example of this problem is that a mux intermediary might = end up being unable to forward compressed frames larger than the flow = control window, unless it first decompresses them and refragments = them.

 

I am trying to figure out a general purpose solution that would allow = us to deal with non-fragmentable frames, even if the extension that is = applied to them is unknown. So far I have two = ideas:

 

1.

 

Allow the sender to send a frame with an RSV bit set even if it is = bigger that the available quota. In such a case the quota becomes = negative and from that moment on the sending side MUST wait until the = quota becomes positive before sending the subsequent frame. This way the = flow control would work and the sender would be able to send a frame = that is larger than the available quota but cannot be = fragmented.

 

Flow control is not intended to limit the maximum frame size, but = rather to prevent a logical channel from exclusively using a physical = connection. This solution would satisfy this requirement. A logical = channel would wait as long as necessary until the quota becomes = positive. This would let other channels use the physical connection. = However, this solution would not prevent a sender from forcing the = receiver to buffer an amount of bytes that is a larger than the amount = it had agreed to buffer. But the amount of extra buffering required = would not exceed the size of a single frame so a mux intermediary would = at least be able to forward frames of reasonable size. =

 

 

2.

 

An alternative solution is to introduce a WebSocket fragmentation = extension. Using this extension, multiplexing intermediaries would = advertise the maximum frame size limit for non-mux clients. Non-mux = clients that want their connections to be multiplexed by an intermediary = would have to stick to the frame size limits required by that = intermediary. By supporting this extension WebSocket client/browser = vendors will be able to make their clients mux-intermediary-friendly. = This would help not only in non-mux-client-to-mux-intermediary scenarios = (and flow control in general) but would also permit us to advertise a = frame size limit in any scenario where such limits are present. This was = discussed by the WG but didn’t made it into RFC 6455, the idea at = that time was that it could go in a separate extension. So currently we = have section 10.4 that requires implementations to protect themselves = against exceeding frame size limits. A fragmentation extension would = enable us to advertise these limits.

 

 

10.4.  Implementation-Specific Limits

 

   Implementations that have implementation- and/or = platform-specific

   limitations regarding the frame size or total message = size after

   reassembly from multiple frames MUST protect themselves = against

   exceeding those limits.  (For example, a malicious = endpoint can try

   to exhaust its peer's memory or mount a = denial-of-service attack by

   sending either a single big frame (e.g., of size 2**60) = or by sending

   a long stream of small frames that are a part of a = fragmented

   message.)  Such an implementation SHOULD impose a = limit on frame

   sizes and the total message size after reassembly from = multiple

   frames.

 

 

With best regards,

Arman

 

 

From:= = Takeshi Yoshino [mailto:tyoshino@google.com]
Sent: Friday, = June 01, 2012 3:33 PM
To: Martin Sustrik
Cc: Arman = Djusupov; hybi@ietf.org
Subject: Re: [hybi] Flow control = quota

 

On Fri, = Jun 1, 2012 at 5:43 PM, Martin Sustrik <sustrik@250bpm.com> = wrote:

That seems to suggest = there's some kind of mis-layering happening here. Frames are used for = flow control. Does it make sense to use them for compression as well? = Shouldn't the compression rather happen on top of mutliplexing = layer?


The situation is = similar to compressing the payload in TCP packets. It is feasible, but = in corner cases it can clash with MTU limits, cause re-fragmentation = etc. The clean solution would be to layer compression on top of TCP = layer.

 

Mux want to control fragmentation while per-frame = compression locks down fragmentation. Yes, it's not healthy to use of = per-frame compression before mux.

 

Shall we discourage this layering (preframe-compress = then mux)?

 

------=_NextPart_000_0011_01CD401A.237BB690-- From jduell.mcbugs@gmail.com Fri Jun 1 12:20:00 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 6072011E8127 for ; Fri, 1 Jun 2012 12:20:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.676 X-Spam-Level: X-Spam-Status: No, score=-1.676 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, HTML_MESSAGE=0.001] 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 0sYjoqAz-Bwd for ; Fri, 1 Jun 2012 12:19:59 -0700 (PDT) Received: from smtp.mozilla.org (mx2.corp.phx1.mozilla.com [63.245.216.70]) by ietfa.amsl.com (Postfix) with ESMTP id CAB5621F860E for ; Fri, 1 Jun 2012 12:19:54 -0700 (PDT) Received: from [192.168.1.25] (c-24-7-112-181.hsd1.ca.comcast.net [24.7.112.181]) (Authenticated sender: jduell@mozilla.com) by mx2.mail.corp.phx1.mozilla.com (Postfix) with ESMTPSA id D2A03F2377; Fri, 1 Jun 2012 12:19:53 -0700 (PDT) Message-ID: <4FC915D9.6020703@gmail.com> Date: Fri, 01 Jun 2012 12:19:53 -0700 From: Jason Duell User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Alexey Melnikov References: <4FB3765D.5060308@isode.com> <001401cd340c$446034e0$cd209ea0$@noemax.com> <4FBE2F1E.1030307@isode.com> <4FC011B4.1080508@gmail.com> <4FC4AFD1.8080100@isode.com> In-Reply-To: <4FC4AFD1.8080100@isode.com> Content-Type: multipart/alternative; boundary="------------050204090604020804040706" Cc: hybi@ietf.org Subject: Re: [hybi] Additional WebSocket Close Error Codes 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, 01 Jun 2012 19:20:00 -0000 This is a multi-part message in MIME format. --------------050204090604020804040706 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 05/29/2012 04:15 AM, Alexey Melnikov wrote: > >> I never got much of an answer about adding a new code for "client has >> too many websockets open", but let me ask it again. We could >> conceivably have your proposed 1013 code ("try again later") cover >> this case. But one downside of this is that it doesn't distinguish >> between the case where the application could open a connection to >> another server (a particular server is overloaded), > > I think having a new code for "try another server" would be better, as > it is more explicit that an immediate action can be attempted (where > "server overload" or "try again later" imply that an action in a > future can be attempted). Would such split work for you? There may not be another server, so "try another server" isn't always applicable. So my vote would go to "server overload". But I don't have strong feelings about it, so long as it's differentiated from client websocket limit reached. cheers, Jason Mozilla >> and the case where no websockets are going to work unless/until some >> existing ones go away (Client websocket limit reached). So I suggest >> we want different codes for these. >> >> This could look like >> >> 1013 "Server busy" >> 1014 "Too many websockets open in client" >> --------------050204090604020804040706 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 05/29/2012 04:15 AM, Alexey Melnikov wrote:

I never got much of an answer about adding a new code for "client has too many websockets open", but let me ask it again.   We could conceivably have your proposed 1013 code  ("try again later") cover this case.   But one downside of this is that it doesn't distinguish between the case where the application could open a connection to another server (a particular server is overloaded),

I think having a new code for "try another server" would be better, as it is more explicit that an immediate action can be attempted (where "server overload" or "try again later" imply that an action in a future can be attempted). Would such split work for you?

There may not be another server, so "try another server" isn't always applicable.   So my vote would go to "server overload".   But I don't have strong feelings about it, so long as it's differentiated from client websocket limit reached.

cheers,

Jason
Mozilla


and the case where no websockets are going to work unless/until some existing ones go away (Client websocket limit reached).  So I suggest we want different codes for these.

This could look like

   1013    "Server busy"
   1014     "Too many websockets open in client"   


--------------050204090604020804040706-- From sustrik@250bpm.com Mon Jun 4 05:47:44 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 A54D521F871A for ; Mon, 4 Jun 2012 05:47:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.694 X-Spam-Level: X-Spam-Status: No, score=-0.694 tagged_above=-999 required=5 tests=[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 rTO-1jehD8LJ for ; Mon, 4 Jun 2012 05:47:44 -0700 (PDT) Received: from mail.moloch.sk (chrocht.moloch.sk [62.176.169.44]) by ietfa.amsl.com (Postfix) with ESMTP id 94CED21F870F for ; Mon, 4 Jun 2012 05:47:43 -0700 (PDT) Received: from [192.168.0.5] (unknown [95.239.54.134]) by mail.moloch.sk (Postfix) with ESMTPSA id 48398182BC03; Mon, 4 Jun 2012 14:47:41 +0200 (CEST) Message-ID: <4FCCAE6B.1010306@250bpm.com> Date: Mon, 04 Jun 2012 14:47:39 +0200 From: Martin Sustrik User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.24) Gecko/20111109 Thunderbird/3.1.16 MIME-Version: 1.0 To: Arman Djusupov References: <001a01cd3e69$4a221c10$de665430$@noemax.com> <4FC732DC.3000308@250bpm.com> <000e01cd3f1c$af15ad40$0d4107c0$@noemax.com> <4FC880A7.9070007@250bpm.com> <001001cd4000$fe2c82c0$fa858840$@noemax.com> In-Reply-To: <001001cd4000$fe2c82c0$fa858840$@noemax.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: hybi@ietf.org Subject: Re: [hybi] Flow control quota 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, 04 Jun 2012 12:47:44 -0000 Hi Arman, I am not following the hybi mailing list thoroughly, so I am not familiar with the technical details... However, it seems that the problem here is that it's possible to use any combination of extensions. This pattern doesn't work well. The problem is that with the growing number of extensions the number of possible combinations and (mis)interactions between them is growing exponentially, so it's basically impossible to deliver a fully functional stack. The approach that standard Internet protocols take is separating the functionality into layers where each layer can be filled by only a single protocol at a time. E.g. if you are using TCP at L4 for a particular connection you can't use SCTP at the same time. I don't understand the details of WS, so I don't want to make any strong proposals, but maybe separating the extensions into several well-defined layers where each layer can be occupied only by a single extension instance may help. Martin On 01/06/12 16:15, Arman Djusupov wrote: > Unfortunately making extensions mutually aware of each other at the > implementation level does not prevent problems from being encountered by > a mux intermediary that receives a frame with an RSV bit set. An > intermediary is not permitted to fragment a frame with an RSV bit set > especially when the extension is unknown. If such a frame is larger than > the available quota then the intermediary would have to wait until the > quota becomes larger than the frame size before it can send it. This > will result in the frame never being sent if its size is larger than the > flow control window. > > A practical example of this problem is that a mux intermediary might end > up being unable to forward compressed frames larger than the flow > control window, unless it first decompresses them and refragments them. > > I am trying to figure out a general purpose solution that would allow us > to deal with non-fragmentable frames, even if the extension that is > applied to them is unknown. So far I have two ideas: > > 1. > > Allow the sender to send a frame with an RSV bit set even if it is > bigger that the available quota. In such a case the quota becomes > negative and from that moment on the sending side MUST wait until the > quota becomes positive before sending the subsequent frame. This way the > flow control would work and the sender would be able to send a frame > that is larger than the available quota but cannot be fragmented. > > Flow control is not intended to limit the maximum frame size, but rather > to prevent a logical channel from exclusively using a physical > connection. This solution would satisfy this requirement. A logical > channel would wait as long as necessary until the quota becomes > positive. This would let other channels use the physical connection. > However, this solution would not prevent a sender from forcing the > receiver to buffer an amount of bytes that is a larger than the amount > it had agreed to buffer. But the amount of extra buffering required > would not exceed the size of a single frame so a mux intermediary would > at least be able to forward frames of reasonable size. > > 2. > > An alternative solution is to introduce a WebSocket fragmentation > extension. Using this extension, multiplexing intermediaries would > advertise the maximum frame size limit for non-mux clients. Non-mux > clients that want their connections to be multiplexed by an intermediary > would have to stick to the frame size limits required by that > intermediary. By supporting this extension WebSocket client/browser > vendors will be able to make their clients mux-intermediary-friendly. > This would help not only in non-mux-client-to-mux-intermediary scenarios > (and flow control in general) but would also permit us to advertise a > frame size limit in any scenario where such limits are present. This was > discussed by the WG but didnt made it into RFC 6455, the idea at that > time was that it could go in a separate extension. So currently we have > section 10.4 that requires implementations to protect themselves against > exceeding frame size limits. A fragmentation extension would enable us > to advertise these limits. > > 10.4. Implementation-Specific Limits > > Implementations that have implementation- and/or platform-specific > > limitations regarding the frame size or total message size after > > reassembly from multiple frames MUST protect themselves against > > exceeding those limits. (For example, a malicious endpoint can try > > to exhaust its peer's memory or mount a denial-of-service attack by > > sending either a single big frame (e.g., of size 2**60) or by sending > > a long stream of small frames that are a part of a fragmented > > message.) Such an implementation SHOULD impose a limit on frame > > sizes and the total message size after reassembly from multiple > > frames. > > With best regards, > > Arman > > *From:*Takeshi Yoshino [mailto:tyoshino@google.com] > *Sent:* Friday, June 01, 2012 3:33 PM > *To:* Martin Sustrik > *Cc:* Arman Djusupov; hybi@ietf.org > *Subject:* Re: [hybi] Flow control quota > > On Fri, Jun 1, 2012 at 5:43 PM, Martin Sustrik > wrote: > > That seems to suggest there's some kind of mis-layering happening here. > Frames are used for flow control. Does it make sense to use them for > compression as well? Shouldn't the compression rather happen on top of > mutliplexing layer? > > > The situation is similar to compressing the payload in TCP packets. It > is feasible, but in corner cases it can clash with MTU limits, cause > re-fragmentation etc. The clean solution would be to layer compression > on top of TCP layer. > > Mux want to control fragmentation while per-frame compression locks down > fragmentation. Yes, it's not healthy to use of per-frame compression > before mux. > > Shall we discourage this layering (preframe-compress then mux)? > From gregw@intalio.com Mon Jun 4 06:54:45 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 9238C21F87F5 for ; Mon, 4 Jun 2012 06:54:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.877 X-Spam-Level: X-Spam-Status: No, score=-2.877 tagged_above=-999 required=5 tests=[AWL=0.101, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 dlgehnc6NOZk for ; Mon, 4 Jun 2012 06:54:45 -0700 (PDT) Received: from mail-qa0-f49.google.com (mail-qa0-f49.google.com [209.85.216.49]) by ietfa.amsl.com (Postfix) with ESMTP id 0043B21F85EA for ; Mon, 4 Jun 2012 06:54:44 -0700 (PDT) Received: by qabj40 with SMTP id j40so1871261qab.15 for ; Mon, 04 Jun 2012 06:54:44 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=jb6TUN4eTet5lZrxrhAEqtMlAfInswcw0u94ZB8oAkg=; b=hdKqUOlwN1ZcnuMRPjbSV1k/SP2fUFQ2y1IYGr3T3sPwgWynAO+lSOxlpXuWP/GrVO 4qxNSMODxZFUDlMCsIQnSgPJ6E7kxm6+XuuRjqn1ttbzSGljtUqCUJcK9x6X0ZBUNzeJ B1gdV+NMlJTS2T7FFNTDuZd+B92zzEFuVZUw7uMmaX6UQ28Hxj70tfT07bBVYmfWjPdV B+zR53roGw9W4N57GmXo8l8/9xI4mubknnACiXCRhhP1kw0EpQzHk8ei3f4rpPk95/ct JCqwbIFMLjM9pUkqJC+NGDvkqKuAmamx59dhWLL2KXyNyv+vYjrbBunJeT8UbLgrz74u AqYg== MIME-Version: 1.0 Received: by 10.224.203.201 with SMTP id fj9mr13793183qab.9.1338818084328; Mon, 04 Jun 2012 06:54:44 -0700 (PDT) Received: by 10.229.154.5 with HTTP; Mon, 4 Jun 2012 06:54:44 -0700 (PDT) In-Reply-To: <001001cd4000$fe2c82c0$fa858840$@noemax.com> References: <001a01cd3e69$4a221c10$de665430$@noemax.com> <4FC732DC.3000308@250bpm.com> <000e01cd3f1c$af15ad40$0d4107c0$@noemax.com> <4FC880A7.9070007@250bpm.com> <001001cd4000$fe2c82c0$fa858840$@noemax.com> Date: Mon, 4 Jun 2012 15:54:44 +0200 Message-ID: From: Greg Wilkins To: Arman Djusupov Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQkhBHU8coDQMXkAhNF1tF+fhTs4jLEOfu2qZl2IyUQWS9RSXNuYyHhyvKoG6ZlJFPIFCICx Cc: hybi@ietf.org Subject: Re: [hybi] Flow control quota 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, 04 Jun 2012 13:54:45 -0000 Arman, I think a solution could be to allow the sender to send a control message, "No remaining Quota" meaning that the sender would send more data if it had more quota. This control method could be used in this case where there are not sufficient window bytes available so as to allow a minimal frame to be sent. This control frame is also useful even if the quota is completely consumed because if you follow the flow control discussion over on the SPDY lists, you will see that fixed quotas will restrict the usage of available bandwidth. Thus I suspect that we will need to go to dynamic window sizes. If the sender can tell the receiver that it has consumed it's window (and no the receiver can't tell that itself because of network latency), then that can inform any receiver decisions to increase the window size. cheers From arman@noemax.com Mon Jun 4 07:58:19 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 0F4BF21F88A9 for ; Mon, 4 Jun 2012 07:58:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.279 X-Spam-Level: X-Spam-Status: No, score=-2.279 tagged_above=-999 required=5 tests=[AWL=0.320, BAYES_00=-2.599] 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 QOrJpd8T8OTL for ; Mon, 4 Jun 2012 07:58:17 -0700 (PDT) Received: from mail.noemax.com (mail.noemax.com [64.34.201.8]) by ietfa.amsl.com (Postfix) with ESMTP id 6981621F88A2 for ; Mon, 4 Jun 2012 07:58:17 -0700 (PDT) DKIM-Signature: a=rsa-sha1; t=1338821892; x=1339426692; s=m1024; d=noemax.com; c=relaxed/relaxed; v=1; bh=ZOSYoiuKHnOSYGcq47HqEm2GZkc=; h=From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding:In-Reply-To:References; b=MyDT4QpxsVnxmM67usqbCZX89EJfRY+k+KdjuJtClEaJf05xpbHND4XKiQ4kljkTl/SD6VbWgwzqqnhjDo3QA6NHsZoZ4IUywNZErrkamcp+L581ciNHH8wejIggoQZ5RPZBhU1LRpK1Hf+m2OcuQl+lUqxUxWo0K6Bn9oSKsGU= Received: from mail.noemax.com by mail.noemax.com (IceWarp 10.4.0) with ASMTP (SSL) id OUK67110; Mon, 04 Jun 2012 17:58:10 +0300 From: "Arman Djusupov" To: "'Martin Sustrik'" References: <001a01cd3e69$4a221c10$de665430$@noemax.com> <4FC732DC.3000308@250bpm.com> <000e01cd3f1c$af15ad40$0d4107c0$@noemax.com> <4FC880A7.9070007@250bpm.com> <001001cd4000$fe2c82c0$fa858840$@noemax.com> <4FCCAE6B.1010306@250bpm.com> In-Reply-To: <4FCCAE6B.1010306@250bpm.com> Date: Mon, 4 Jun 2012 17:58:00 +0300 Message-ID: <002d01cd4262$747957b0$5d6c0710$@noemax.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 thread-index: AQDnHEYxNcL9Xb2UVJoRm1lbL/BkAQFoH3KRAV1ppa8CZ6BgXAIpbgj4AsMo47wDBdtyY5hNjtWA Content-Language: en-us Cc: hybi@ietf.org Subject: Re: [hybi] Flow control quota 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, 04 Jun 2012 14:58:19 -0000 According to the WebSocket specification extensions are layered and should be applied in a specific order. In this particular case the mux specification provides two ways of applying the per frame compression extension: compression can be applied either before or after the mux extension. In the first case the frame being multiplexed is already compressed and should not be fragmented. This allows intermediaries to de-multiplex frames without decompressing them. In the second case the mux frame is compressed along with the mux header, so it cannot be de-multiplexed unless it is first decompressed. Supporting both options is beneficial. In any case the problem preventing unfragmentable frames from being relayed over flow-controlled logical connections should be resolved. The per frame compression is not the only case when it might be impossible to fragment a frame. A mux intermediary should either be able to control the size of the frame that the sending side produces or should be able to fragment them. Yes, the number of extensions may grow and some of them might be mutually exclusive, that's why WebSocket supports negotiation of the extensions stack so that each side can validate whether it can apply the requested set of extensions in the given order. But I firmly believe that mux and per frame compression are not mutually exclusive extensions. With best regards, Arman -----Original Message----- From: Martin Sustrik [mailto:sustrik@250bpm.com] Sent: Monday, June 04, 2012 3:48 PM To: Arman Djusupov Cc: 'Takeshi Yoshino'; hybi@ietf.org Subject: Re: [hybi] Flow control quota Hi Arman, I am not following the hybi mailing list thoroughly, so I am not familiar with the technical details... However, it seems that the problem here is that it's possible to use any combination of extensions. This pattern doesn't work well. The problem is that with the growing number of extensions the number of possible combinations and (mis)interactions between them is growing exponentially, so it's basically impossible to deliver a fully functional stack. The approach that standard Internet protocols take is separating the functionality into layers where each layer can be filled by only a single protocol at a time. E.g. if you are using TCP at L4 for a particular connection you can't use SCTP at the same time. I don't understand the details of WS, so I don't want to make any strong proposals, but maybe separating the extensions into several well-defined layers where each layer can be occupied only by a single extension instance may help. Martin On 01/06/12 16:15, Arman Djusupov wrote: > Unfortunately making extensions mutually aware of each other at the > implementation level does not prevent problems from being encountered > by a mux intermediary that receives a frame with an RSV bit set. An > intermediary is not permitted to fragment a frame with an RSV bit set > especially when the extension is unknown. If such a frame is larger > than the available quota then the intermediary would have to wait > until the quota becomes larger than the frame size before it can send > it. This will result in the frame never being sent if its size is > larger than the flow control window. > > A practical example of this problem is that a mux intermediary might > end up being unable to forward compressed frames larger than the flow > control window, unless it first decompresses them and refragments them. > > I am trying to figure out a general purpose solution that would allow > us to deal with non-fragmentable frames, even if the extension that is > applied to them is unknown. So far I have two ideas: > > 1. > > Allow the sender to send a frame with an RSV bit set even if it is > bigger that the available quota. In such a case the quota becomes > negative and from that moment on the sending side MUST wait until the > quota becomes positive before sending the subsequent frame. This way > the flow control would work and the sender would be able to send a > frame that is larger than the available quota but cannot be fragmented. > > Flow control is not intended to limit the maximum frame size, but > rather to prevent a logical channel from exclusively using a physical > connection. This solution would satisfy this requirement. A logical > channel would wait as long as necessary until the quota becomes > positive. This would let other channels use the physical connection. > However, this solution would not prevent a sender from forcing the > receiver to buffer an amount of bytes that is a larger than the amount > it had agreed to buffer. But the amount of extra buffering required > would not exceed the size of a single frame so a mux intermediary > would at least be able to forward frames of reasonable size. > > 2. > > An alternative solution is to introduce a WebSocket fragmentation > extension. Using this extension, multiplexing intermediaries would > advertise the maximum frame size limit for non-mux clients. Non-mux > clients that want their connections to be multiplexed by an > intermediary would have to stick to the frame size limits required by > that intermediary. By supporting this extension WebSocket > client/browser vendors will be able to make their clients mux-intermediary-friendly. > This would help not only in non-mux-client-to-mux-intermediary > scenarios (and flow control in general) but would also permit us to > advertise a frame size limit in any scenario where such limits are > present. This was discussed by the WG but didn't made it into RFC > 6455, the idea at that time was that it could go in a separate > extension. So currently we have section 10.4 that requires > implementations to protect themselves against exceeding frame size > limits. A fragmentation extension would enable us to advertise these limits. > > 10.4. Implementation-Specific Limits > > Implementations that have implementation- and/or platform-specific > > limitations regarding the frame size or total message size after > > reassembly from multiple frames MUST protect themselves against > > exceeding those limits. (For example, a malicious endpoint can try > > to exhaust its peer's memory or mount a denial-of-service attack by > > sending either a single big frame (e.g., of size 2**60) or by sending > > a long stream of small frames that are a part of a fragmented > > message.) Such an implementation SHOULD impose a limit on frame > > sizes and the total message size after reassembly from multiple > > frames. > > With best regards, > > Arman > > *From:*Takeshi Yoshino [mailto:tyoshino@google.com] > *Sent:* Friday, June 01, 2012 3:33 PM > *To:* Martin Sustrik > *Cc:* Arman Djusupov; hybi@ietf.org > *Subject:* Re: [hybi] Flow control quota > > On Fri, Jun 1, 2012 at 5:43 PM, Martin Sustrik > wrote: > > That seems to suggest there's some kind of mis-layering happening here. > Frames are used for flow control. Does it make sense to use them for > compression as well? Shouldn't the compression rather happen on top of > mutliplexing layer? > > > The situation is similar to compressing the payload in TCP packets. It > is feasible, but in corner cases it can clash with MTU limits, cause > re-fragmentation etc. The clean solution would be to layer compression > on top of TCP layer. > > Mux want to control fragmentation while per-frame compression locks > down fragmentation. Yes, it's not healthy to use of per-frame > compression before mux. > > Shall we discourage this layering (preframe-compress then mux)? > From arman@noemax.com Mon Jun 4 08:54:04 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 BF01D21F88DA for ; Mon, 4 Jun 2012 08:54:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.332 X-Spam-Level: X-Spam-Status: No, score=-2.332 tagged_above=-999 required=5 tests=[AWL=0.266, BAYES_00=-2.599, MISSING_MIMEOLE=0.001] 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 bF+Sa3lav2um for ; Mon, 4 Jun 2012 08:54:03 -0700 (PDT) Received: from mail.noemax.com (mail.noemax.com [64.34.201.8]) by ietfa.amsl.com (Postfix) with ESMTP id 6633921F88D8 for ; Mon, 4 Jun 2012 08:54:03 -0700 (PDT) DKIM-Signature: a=rsa-sha1; t=1338825238; x=1339430038; s=m1024; d=noemax.com; c=relaxed/relaxed; v=1; bh=nMrmMlJuqkqkJBzMgCxaEUuPilo=; h=From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding:In-Reply-To:References; b=DRrfeeOzK2skF8Jg6FoR8NKs6eNvdj0r3871Xp64zJrkFl8iOIS4F72DPq7pR9USPH6BCK+5KWsmAsk/VlIwszRNfq86Mqa0biNbDcFRdfgs+a39XsWcgXjEnjNfg1R7AX5AuiWoQ0UU0Hk5d1HHH2YPnos/EF4hlybTcrEhTdc= Received: from mail.noemax.com by mail.noemax.com (IceWarp 10.4.0) with ASMTP (SSL) id OVF32857; Mon, 04 Jun 2012 18:53:57 +0300 From: "Arman Djusupov" To: "'Greg Wilkins'" References: <001a01cd3e69$4a221c10$de665430$@noemax.com> <4FC732DC.3000308@250bpm.com> <000e01cd3f1c$af15ad40$0d4107c0$@noemax.com> <4FC880A7.9070007@250bpm.com> <001001cd4000$fe2c82c0$fa858840$@noemax.com> In-Reply-To: Date: Mon, 4 Jun 2012 18:53:44 +0300 Message-ID: <003001cd426a$3e437fb0$baca7f10$@noemax.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 1 (Highest) X-MSMail-Priority: High X-Mailer: Microsoft Outlook 14.0 thread-index: AQDnHEYxNcL9Xb2UVJoRm1lbL/BkAQFoH3KRAV1ppa8CZ6BgXAIpbgj4AsMo47wCD8yUE5hVTvsg Importance: High Content-Language: en-us Cc: hybi@ietf.org Subject: Re: [hybi] Flow control quota 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, 04 Jun 2012 15:54:04 -0000 Sending a control message requesting flow control quota would be too slow. It would make the sending side wait for a full RT before it can send the frame. Sticking to a frame size below the flow control window is a simpler solution. If both sides would use a maximum frame size that is smaller than the flow control window, then the receiving side would send a flow control quota every time the estimated quota on the sending side drops below the maximum frame size. This should eliminate the risk of a deadlock. Another alternative I have mentioned in the past is to let the sender send a frame over the quota capacity, if the frame is larger than the quota. Then the sender would have to wait for the quota to be fully replenished before it can send more frames. This may result in a large frame that exceeds the available quota, but this situation would either be overcomeable or the receiver would have to drop the logical channel. According to the WebSocket specification the receiver can drop a connection when it decides that the remote side abuses its limits. Since this can happen to a normal connection, it's ok if it can happen to a logical channel too. The quota should not be fixed and it does not have to be fixed. The receiving side can dynamically grow the flow control window when more buffering capacity is available and stop sending FC frames when there is no buffer space available. Overcoming quota starvation is all up to flow control optimization, if the receiver is optimistic and proactive in sending quotas to the sender then the quota will not drop to 0. The sender doesn't really need to tell the receiver that it has run out of quota, if the receiver counts the bytes received from the sender it already knows how many bytes are left in the sender's quota. With best regards, Arman -----Original Message----- From: Greg Wilkins [mailto:gregw@intalio.com] Sent: Monday, June 04, 2012 4:55 PM To: Arman Djusupov Cc: Takeshi Yoshino; Martin Sustrik; hybi@ietf.org Subject: Re: [hybi] Flow control quota Arman, I think a solution could be to allow the sender to send a control message, "No remaining Quota" meaning that the sender would send more data if it had more quota. This control method could be used in this case where there are not sufficient window bytes available so as to allow a minimal frame to be sent. This control frame is also useful even if the quota is completely consumed because if you follow the flow control discussion over on the SPDY lists, you will see that fixed quotas will restrict the usage of available bandwidth. Thus I suspect that we will need to go to dynamic window sizes. If the sender can tell the receiver that it has consumed it's window (and no the receiver can't tell that itself because of network latency), then that can inform any receiver decisions to increase the window size. cheers From jamie@shareable.org Wed Jun 6 19:23:32 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 551A611E80FF for ; Wed, 6 Jun 2012 19:23:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 DKnh0Uo-Cj47 for ; Wed, 6 Jun 2012 19:23:31 -0700 (PDT) Received: from mail2.shareable.org (mail2.shareable.org [80.68.89.115]) by ietfa.amsl.com (Postfix) with ESMTP id C059011E80FC for ; Wed, 6 Jun 2012 19:23:16 -0700 (PDT) Received: from jamie by mail2.shareable.org with local (Exim 4.63) (envelope-from ) id 1ScSNU-0001Vv-VY; Thu, 07 Jun 2012 03:23:12 +0100 Date: Thu, 7 Jun 2012 03:23:12 +0100 From: Jamie Lokier To: Arman Djusupov Message-ID: <20120607022312.GA26406@jl-vm1.vm.bytemark.co.uk> References: <001a01cd3e69$4a221c10$de665430$@noemax.com> <4FC732DC.3000308@250bpm.com> <000e01cd3f1c$af15ad40$0d4107c0$@noemax.com> <4FC880A7.9070007@250bpm.com> <001001cd4000$fe2c82c0$fa858840$@noemax.com> <4FCCAE6B.1010306@250bpm.com> <002d01cd4262$747957b0$5d6c0710$@noemax.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <002d01cd4262$747957b0$5d6c0710$@noemax.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: hybi@ietf.org Subject: Re: [hybi] Flow control quota 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: Thu, 07 Jun 2012 02:23:32 -0000 Hi everyone, I haven't been following the hybi list for a while (it was too depressing/exhausting), but I'm really pleased to see deadlock-free, starvation-free mux is being taken more seriously now. I guess SPDY's helped with that. The problem being described in this thread occurs because the layers aren't really being kept separate. If they are properly separated, everything works, and it's easier to implement and even a bit faster on the network. I see a lot of confusion about the role and purpose of "fragments". Particularly the idea that where something produces fragments, those must literally correspond with the wire protocol, despite having another transformative layer before the wire. Arman Djusupov wrote: > According to the WebSocket specification extensions are layered and should > be applied in a specific order. In this particular case the mux > specification provides two ways of applying the per frame compression > extension: compression can be applied either before or after the mux > extension. In the first case the frame being multiplexed is already > compressed and should not be fragmented. ^^^^^^^^^^^^^^^^^^^^^^^^ Mux should be able to further fragment - in a way that compression does not see. > This allows intermediaries to de-multiplex frames without > decompressing them. In the second case the mux frame is compressed > along with the mux header, so it cannot be de-multiplexed unless it > is first decompressed. Supporting both options is beneficial. > > In any case the problem preventing unfragmentable frames from being relayed > over flow-controlled logical connections should be resolved. The per frame > compression is not the only case when it might be impossible to fragment a > frame. A mux intermediary should either be able to control the size of the > frame that the sending side produces or should be able to fragment them. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Imo, that's the only sensible answer. Anything else leads to a spiral of hacks - see this thread for examples! Basically the output of compression is a stream of "unfragmentable" things. But several things, mux being one, need ability to break up the data stream where it's useful - which is the point of fragments. Deadlock-free mux pretty much _requires_ per-channel flow control and fragmentation at the mux. And it should be visible only to the mux. Compression (and other layers) need to be _strictly_ separate. But in these discussions they've been combined in a fuzzy way, which makes everything complicated. I guess it was a misguided attempt to keep the wire concepts simple (fit everything into "frames" and "fragments"), which actually makes it more complicated. It doesn't really matter whether compression is layered above or below, both work fine, as long as it's a separate layer. If you treat mux like this: 1. Zero or more "stream of fragments" (of next layer up) in. 2. One "stream of fragments" (of mux protocol) out. and demux like this: 1. One "stream of fragments" (of mux protocol) in. 2. Zero or more "stream of fragments" (of next layer up) down. Where "mux protocol" means it's encapsulating channel numbers, flow control and fragmentation, everything behaves nicely. There is no need of oddities like negative flow control tokens, wasteful round trips, no deadlock, starvation, buffer overflow at intermediaries due to large fragments or bandwidth limitations. It just works(tm). (Well you do have to implement a good mux - but that's all, it's confined to the mux implementation.) For compression above the mux, this means: - Compression layer outputs a stream of compressed fragments. - Mux takes it in, and produces its _own_ stream of mux fragments. - Demux takes that, and recombines to make the original fragments. - Decompression gets what it needed. Compression below the mux is similar, but the other way. See? In many cases the fragement boundaries of the two layers will coincide, but it shouldn't be assumed or restricted to that. If there is a desire to encode _that case_ efficiently, that's fine, as long as it's just an encoding. It breaks the whole point of flow-control and deadlock-avoidance if the layers have to maintain the same boundaries - as this thread demonstrates. One large compressed frame/fragement, and all other channels are starved - nobody will use mux if it's that unreliable! Certainly not cooperatively/opportunistically. Or, if you limit the compression size to the whole path's capacity - that's also a waste (of compression opportunity). In that case, the attempt to save a few bytes in the header encoding is counterproductive (but you can still save those bytes, just make sure it's purely a syntax optimisation.). Oh, one other thing: It's best if compression is free to make the best compression decisions without blocking _other_ things that need fragmentation below - namely control frames, that must be sendable, and maybe prioritisable. As a practical matter, I'm thinking it makes sense for the compression layer to see things this way: 1. Receive stream of application frames (WS messages). -> Compressor -> 2. Stream of "frames" (not fragments) out, meaning "non-fragmentable". -> Decompresor -> 3. Emit stream of application frames (WS messages) The "frames" in 2 above are compression-protocol messages, and do not have to correspond with application messages. They are actually the output that current compression proposals would call "fragments". The only difference, really, is syntax in the pipeline when passed to the layer below. So actually this is a very small change. The compression method, decisions it makes, etc. are unchanged. My summary: Keep the mux and other layers separate, not leaky, and all the muxy things (flow control etc.) can be implemented in the mux layer alone. Everything will work, and the implementation will be simpler as well (more modular, less dependencies). When a layer (such as compression) outputs a stream of things with essential boundaries, treat it as stream of frames, don't conflate it with "fragments" at the wire level - even if it did involve splitting the WS application's original messages. Keep the relationship between these frames and application (or higher layer) frames internal to the compression layer and protocol (same for other layers). It is much better to maintain clear semantics: frame boundaries are immutable because the upper layer requires them, fragment boundaries are _always_ allowed to be split and merged for optimal transport decisions, and they only correspond _literally_ to the wire protocol for the lowest layer in the stack. As the wire protocol is now defined, it doesn't match up well with the above semantics, but it's a syntax (header encoding) issue only. It will even go faster on the network due to freeing up each component to do the best for its part. Think about the different combinations of layers when several fragments/frames are in flight, and also multi-hop paths. They all benefit. All the best, -- Jamie From jamie@shareable.org Wed Jun 6 19:39:20 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 9D96111E80D6 for ; Wed, 6 Jun 2012 19:39:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 00LZ16ecM7ln for ; Wed, 6 Jun 2012 19:39:20 -0700 (PDT) Received: from mail2.shareable.org (mail2.shareable.org [80.68.89.115]) by ietfa.amsl.com (Postfix) with ESMTP id 0193811E80C1 for ; Wed, 6 Jun 2012 19:39:20 -0700 (PDT) Received: from jamie by mail2.shareable.org with local (Exim 4.63) (envelope-from ) id 1ScSd4-0001dt-MS; Thu, 07 Jun 2012 03:39:18 +0100 Date: Thu, 7 Jun 2012 03:39:18 +0100 From: Jamie Lokier To: Alexey Melnikov Message-ID: <20120607023918.GC26406@jl-vm1.vm.bytemark.co.uk> References: <4FB3765D.5060308@isode.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4FB3765D.5060308@isode.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Hybi Subject: Re: [hybi] Additional WebSocket Close Error Codes 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: Thu, 07 Jun 2012 02:39:20 -0000 Alexey Melnikov wrote: > Hi WG, > I am sorry I didn't followup on this when the following 2 codes were > suggested (See > ): > > 1012/Service Restart > 1012 indicates that the service is restarted. a client may > reconnect, and if it choses to do, should reconnect using a > randomized delay of 5 - 30s. > > Use case: > restart a service with 100k clients connected > clients present an informative user notification ("service > restarting .. reconnecting in N secs) > clients should not reconnect all at exactly the same time .. thus > the randomized delay On the other hand, if you have almost real-time requirements and you simply restarted a service, sometimes 5-30s is uncomfortable long. For some applications it means the client is effectively frozen for 5-30s. Sometimes, you want restarting the service to be as invisible to the user as reasonably possible. Your server knows the current load, so has an idea if it could handle immediate or faster reconnection attempts. On an intranet, you might want it randomised as 0-1s for 10k clients. Any reason you chose this length of time? Could a suggested delay be included with the error, with 5-30s being the default? > 1013/Service Overload > 1013 indicates that the service is experiencing overload. a client > should only connect to a different IP (when there are multiple for > the target) or reconnect to the same IP upon user action. Maybe it could suggest which different IP(s) (and/or URL(s))? -- Jamie From jamie@shareable.org Wed Jun 6 20:44:44 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 EA41D21F864D for ; Wed, 6 Jun 2012 20:44:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 MquwfsqAe1EM for ; Wed, 6 Jun 2012 20:44:44 -0700 (PDT) Received: from mail2.shareable.org (mail2.shareable.org [80.68.89.115]) by ietfa.amsl.com (Postfix) with ESMTP id 00E9E21F8639 for ; Wed, 6 Jun 2012 20:44:44 -0700 (PDT) Received: from jamie by mail2.shareable.org with local (Exim 4.63) (envelope-from ) id 1ScTeK-0001pU-2q; Thu, 07 Jun 2012 04:44:40 +0100 Date: Thu, 7 Jun 2012 04:44:40 +0100 From: Jamie Lokier To: Arman Djusupov Message-ID: <20120607034440.GD26406@jl-vm1.vm.bytemark.co.uk> References: <002f01cd3cc4$4791b380$d6b51a80$@noemax.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <002f01cd3cc4$4791b380$d6b51a80$@noemax.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: hybi@ietf.org Subject: Re: [hybi] Multiplexing: Pre-AddChannelResponse quota 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: Thu, 07 Jun 2012 03:44:45 -0000 Arman Djusupov wrote: > > Resending would be required when the allocation of a logical channel > has failed on the server or the intermediary due to any kind of mux > related error. For example: “Maximum number of logical channels per > physical connection has been reached “ or “Intermediary cannot reach > the destination endpoint”. The current draft requires that if an > AddChannelResponse is received with a failed flag, the client attempts > to open a new physical connection. Since the browser must keep the mux > extension transparent it cannot let the JS application handle the > recovery from mux related errors. If there is a max_simultaneous_handshakes - why not recast that as "initial new-channels window" - meaning a flow control grant, which is updated by further grants from the server. (Very similar to the flow control per channel). Then it means initially you can set a number, and subsequently, the server will control the rate of admission of new channels. Then it can regulate it at a smaller or larger value, be conservative if appropriate until a client has proven not to be an attack, etc. There's basically zero message overhead, as the grant update would follow AddChannelResponse if the server wants to maintain a constant number in flight. Having redefined max_simultaneous_handshakes that way.... It removes the need to re-send due to "maximum number of channels reached" - because it can't happen. The token is a promise. (If the server can't take it, there's a fault so it's a reason for a hard error). "Intermediate cannot reach destination endpoint" ought to be a non-retry error for the same reason that it would be for an HTTP intermediary. I guess this is debatable. But assuming that debate was won :-) there would be no reason for re-sending. That said, it doesn't really matter, the client is free to limit the amount of data it sends before a channel is confirmed, to an amount it considers reasonable to store. A goal that I think is worthwhile are zero-latency-creation channels, That is where a JS would be free to create channels, with no round-trip overhead to start a request-response pattern over them. It's currently paradoxical that HTTP (and especially SPDY) use one _less_ round-trip to send short AJAX-style requests from independent code (or independent pages), compared with multiplexed WebSocket. Zero-latency-creation channels would make WS behave at least as well as AJAX in the small-request-response pattern, which is after all extremely common. > I like the idea of using the total pre-handshake quota for all logical > channels. This would allow high throughput channels to utilize a common > pre-handshake quota when other channels do not require to send any data > prior to receiving an AddChannelResponse. I believe that this solution > would be more optimal than having a pre-handshake quota per logical > channel. It's more flexible for the client, which can choose to abuse it or not. I like the idea - but... does it make any problems for the server? The server may know it has enough memory for N bytes per channel buffer, but it may not have a data structure which can efficiently assign M*N bytes to a single channel (for example due to memory fragmentation or pre-allocation issues, or simply how "malloc" works). It might also want to prevent M*N for heuristic reasons such as channel fairness - which it is already responsible for when channels are up and running. In my view, the server must have the ability to constrain the initial parameters of each channel that the client can assume. It would be fine to allow the server to grant a total pre-handshake quota, as an optional extra, but there should definitely be some constraint on pre-handshake per-channel data. But I do favour that being non-zero. > However, this solution would require the client to subtract the > required value from the common quota and specify this value in > the AddChannelRequest header, so that the server knows from which > initial value to start counting the remote side quota. Isn't it clear without it? The client sends pre-handshake data, the server moves it from the common pool to the new channel buffer, potentially freeing up space in the common pool (if it wants), and the server simply treats the data, for flow control window purposes, as if it came after the channel was set up. Everyone agrees. Anyway, the client shouldn't have to pause/delay sending data after AddChannelRequest, until the response, if there is sufficient quota to keep sending. Specifying the amount used in the request would seem to enforce that delay, which is unnecessary in principle. > There should also be a way to restore the common quota, e.g. in > AddChannelResponse the server can send a header which would > specify the value that should be added to the common > pre-handshake quota. If there is a common pre-handshake data quota, I agree with this. However, it should not be attached specifically to AddChannelResponse. Rather, the server should be able to increase this amount granted at any time, so have its own message. It parallels what I suggested at the start of this mail, about making the physical handshake quota be a window that is maintained by flow control grants from the server, rather than a fixed in-flight constant, in the same way as per-channel flow control does. All the best, -- Jamie From arman@noemax.com Thu Jun 7 04:03: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 4981B21F87BA for ; Thu, 7 Jun 2012 04:03:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.37 X-Spam-Level: X-Spam-Status: No, score=-2.37 tagged_above=-999 required=5 tests=[AWL=0.229, BAYES_00=-2.599] 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 J+j2AP5RN1MR for ; Thu, 7 Jun 2012 04:03:13 -0700 (PDT) Received: from mail.noemax.com (mail.noemax.com [64.34.201.8]) by ietfa.amsl.com (Postfix) with ESMTP id E3AE121F8773 for ; Thu, 7 Jun 2012 04:03:12 -0700 (PDT) DKIM-Signature: a=rsa-sha1; t=1339066988; x=1339671788; s=m1024; d=noemax.com; c=relaxed/relaxed; v=1; bh=9PgxLpPrfNAasYFFpv5igd+xaGk=; h=From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding:In-Reply-To:References; b=UULtv8gTvqrDLatdEdpyBlO3t6yWIvXyBzYvFZJ0Ya2QL+9x+Jv6TdK7uyS249xf0ZldrC8D2f3rCeK3O8gKClLBIs9O1SN4rRAmBFy5oRxMlURQI1s0AH8VjUcEirBWH7x+pFcN3S82X1CeRD48J9AZSPt5toA2/YqCxLddHdk= Received: from mail.noemax.com by mail.noemax.com (IceWarp 10.4.1) with ASMTP (SSL) id RRK84306; Thu, 07 Jun 2012 14:03:06 +0300 From: "Arman Djusupov" To: "'Jamie Lokier'" References: <001a01cd3e69$4a221c10$de665430$@noemax.com> <4FC732DC.3000308@250bpm.com> <000e01cd3f1c$af15ad40$0d4107c0$@noemax.com> <4FC880A7.9070007@250bpm.com> <001001cd4000$fe2c82c0$fa858840$@noemax.com> <4FCCAE6B.1010306@250bpm.com> <002d01cd4262$747957b0$5d6c0710$@noemax.com> <20120607022312.GA26406@jl-vm1.vm.bytemark.co.uk> In-Reply-To: <20120607022312.GA26406@jl-vm1.vm.bytemark.co.uk> Date: Thu, 7 Jun 2012 14:02:56 +0300 Message-ID: <000e01cd449d$1c0ed220$542c7660$@noemax.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 thread-index: AQDnHEYxNcL9Xb2UVJoRm1lbL/BkAQFoH3KRAV1ppa8CZ6BgXAIpbgj4AsMo47wDBdtyYwH7TrBAAdzt12qYMz+uIA== Content-Language: en-us Cc: hybi@ietf.org Subject: Re: [hybi] Flow control quota 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: Thu, 07 Jun 2012 11:03:14 -0000 We have been trying to find some sort of workaround in order to avoid enveloping the WebSocket frame within a mux frame. If mux was a separate layer then a WebSocket frame would need to be enveloped within a mux frame including the WebSocket frame header. This would resolve the unfragmentable frame issue. But this would also mean that in most cases WebSocket would be writing two headers per frame. Writing a frame header twice (once for mux and once the actual frame header) would have a performance overhead. Note that enveloping the frame would produce considerable bandwidth usage when lots of small messages are being enveloped. However the performance overhead of mux in such a case is not tested yet. We can try to experiment with this design. A mux frame should be able to include fragments or multiple WebSocket frames that belong to the same channel. If the length of an enveloped frame is less that length of the mux frame then the mux frame contains more than one enveloped frames. If the number of bytes remaining in a mux frame is less than the length of the last enveloped frame encountered, then the frame is fragmented and the remaining bytes are expected to arrive in a subsequent mux frame of the same channel. Going towards this direction is a big change from the original spec design, so I wasn't even considering it. But if the group decides that it needs to be evaluated, I can try working on this direction. With best regards, Arman -----Original Message----- From: Jamie Lokier [mailto:jamie@shareable.org] Sent: Thursday, June 07, 2012 5:23 AM To: Arman Djusupov Cc: 'Martin Sustrik'; hybi@ietf.org Subject: Re: [hybi] Flow control quota Hi everyone, I haven't been following the hybi list for a while (it was too depressing/exhausting), but I'm really pleased to see deadlock-free, starvation-free mux is being taken more seriously now. I guess SPDY's helped with that. The problem being described in this thread occurs because the layers aren't really being kept separate. If they are properly separated, everything works, and it's easier to implement and even a bit faster on the network. I see a lot of confusion about the role and purpose of "fragments". Particularly the idea that where something produces fragments, those must literally correspond with the wire protocol, despite having another transformative layer before the wire. Arman Djusupov wrote: > According to the WebSocket specification extensions are layered and > should be applied in a specific order. In this particular case the mux > specification provides two ways of applying the per frame compression > extension: compression can be applied either before or after the mux > extension. In the first case the frame being multiplexed is already > compressed and should not be fragmented. ^^^^^^^^^^^^^^^^^^^^^^^^ Mux should be able to further fragment - in a way that compression does not see. > This allows intermediaries to de-multiplex frames without > decompressing them. In the second case the mux frame is compressed > along with the mux header, so it cannot be de-multiplexed unless it is > first decompressed. Supporting both options is beneficial. > > In any case the problem preventing unfragmentable frames from being > relayed over flow-controlled logical connections should be resolved. > The per frame compression is not the only case when it might be > impossible to fragment a frame. A mux intermediary should either be > able to control the size of the frame that the sending side produces or should be able to fragment them. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Imo, that's the only sensible answer. Anything else leads to a spiral of hacks - see this thread for examples! Basically the output of compression is a stream of "unfragmentable" things. But several things, mux being one, need ability to break up the data stream where it's useful - which is the point of fragments. Deadlock-free mux pretty much _requires_ per-channel flow control and fragmentation at the mux. And it should be visible only to the mux. Compression (and other layers) need to be _strictly_ separate. But in these discussions they've been combined in a fuzzy way, which makes everything complicated. I guess it was a misguided attempt to keep the wire concepts simple (fit everything into "frames" and "fragments"), which actually makes it more complicated. It doesn't really matter whether compression is layered above or below, both work fine, as long as it's a separate layer. If you treat mux like this: 1. Zero or more "stream of fragments" (of next layer up) in. 2. One "stream of fragments" (of mux protocol) out. and demux like this: 1. One "stream of fragments" (of mux protocol) in. 2. Zero or more "stream of fragments" (of next layer up) down. Where "mux protocol" means it's encapsulating channel numbers, flow control and fragmentation, everything behaves nicely. There is no need of oddities like negative flow control tokens, wasteful round trips, no deadlock, starvation, buffer overflow at intermediaries due to large fragments or bandwidth limitations. It just works(tm). (Well you do have to implement a good mux - but that's all, it's confined to the mux implementation.) For compression above the mux, this means: - Compression layer outputs a stream of compressed fragments. - Mux takes it in, and produces its _own_ stream of mux fragments. - Demux takes that, and recombines to make the original fragments. - Decompression gets what it needed. Compression below the mux is similar, but the other way. See? In many cases the fragement boundaries of the two layers will coincide, but it shouldn't be assumed or restricted to that. If there is a desire to encode _that case_ efficiently, that's fine, as long as it's just an encoding. It breaks the whole point of flow-control and deadlock-avoidance if the layers have to maintain the same boundaries - as this thread demonstrates. One large compressed frame/fragement, and all other channels are starved - nobody will use mux if it's that unreliable! Certainly not cooperatively/opportunistically. Or, if you limit the compression size to the whole path's capacity - that's also a waste (of compression opportunity). In that case, the attempt to save a few bytes in the header encoding is counterproductive (but you can still save those bytes, just make sure it's purely a syntax optimisation.). Oh, one other thing: It's best if compression is free to make the best compression decisions without blocking _other_ things that need fragmentation below - namely control frames, that must be sendable, and maybe prioritisable. As a practical matter, I'm thinking it makes sense for the compression layer to see things this way: 1. Receive stream of application frames (WS messages). -> Compressor -> 2. Stream of "frames" (not fragments) out, meaning "non-fragmentable". -> Decompresor -> 3. Emit stream of application frames (WS messages) The "frames" in 2 above are compression-protocol messages, and do not have to correspond with application messages. They are actually the output that current compression proposals would call "fragments". The only difference, really, is syntax in the pipeline when passed to the layer below. So actually this is a very small change. The compression method, decisions it makes, etc. are unchanged. My summary: Keep the mux and other layers separate, not leaky, and all the muxy things (flow control etc.) can be implemented in the mux layer alone. Everything will work, and the implementation will be simpler as well (more modular, less dependencies). When a layer (such as compression) outputs a stream of things with essential boundaries, treat it as stream of frames, don't conflate it with "fragments" at the wire level - even if it did involve splitting the WS application's original messages. Keep the relationship between these frames and application (or higher layer) frames internal to the compression layer and protocol (same for other layers). It is much better to maintain clear semantics: frame boundaries are immutable because the upper layer requires them, fragment boundaries are _always_ allowed to be split and merged for optimal transport decisions, and they only correspond _literally_ to the wire protocol for the lowest layer in the stack. As the wire protocol is now defined, it doesn't match up well with the above semantics, but it's a syntax (header encoding) issue only. It will even go faster on the network due to freeing up each component to do the best for its part. Think about the different combinations of layers when several fragments/frames are in flight, and also multi-hop paths. They all benefit. All the best, -- Jamie From tobias.oberstein@tavendo.de Thu Jun 7 04:50:05 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 D27CC21F876F for ; Thu, 7 Jun 2012 04:50:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, WEIRD_PORT=0.001] 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 COudMayiNZYg for ; Thu, 7 Jun 2012 04:50:05 -0700 (PDT) Received: from EXHUB020-2.exch020.serverdata.net (exhub020-2.exch020.serverdata.net [206.225.164.29]) by ietfa.amsl.com (Postfix) with ESMTP id 192C721F8736 for ; Thu, 7 Jun 2012 04:50:04 -0700 (PDT) Received: from EXVMBX020-12.exch020.serverdata.net ([169.254.3.81]) by EXHUB020-2.exch020.serverdata.net ([206.225.164.29]) with mapi; Thu, 7 Jun 2012 04:50:03 -0700 From: Tobias Oberstein To: Jamie Lokier , Alexey Melnikov Date: Thu, 7 Jun 2012 04:50:02 -0700 Thread-Topic: [hybi] Additional WebSocket Close Error Codes Thread-Index: Ac1EVsEiMsk2Pah+Q/WbnBqRLzURpwAOcDyg Message-ID: <634914A010D0B943A035D226786325D43377ECB6A4@EXVMBX020-12.exch020.serverdata.net> References: <4FB3765D.5060308@isode.com> <20120607023918.GC26406@jl-vm1.vm.bytemark.co.uk> In-Reply-To: <20120607023918.GC26406@jl-vm1.vm.bytemark.co.uk> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE, en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Hybi Subject: Re: [hybi] Additional WebSocket Close Error Codes 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: Thu, 07 Jun 2012 11:50:06 -0000 > > 1012/Service Restart > > 1012 indicates that the service is restarted. a client may reconnect, > > and if it choses to do, should reconnect using a randomized delay of 5 > > - 30s. > > > > Use case: > > restart a service with 100k clients connected clients present an > > informative user notification ("service restarting .. reconnecting in > > N secs) clients should not reconnect all at exactly the same time .. > > thus the randomized delay >=20 > On the other hand, if you have almost real-time requirements and you simp= ly > restarted a service, sometimes 5-30s is uncomfortable long. > For some applications it means the client is effectively frozen for 5-30s= . > Sometimes, you want restarting the service to be as invisible to the user= as > reasonably possible. >=20 > Your server knows the current load, so has an idea if it could handle imm= ediate > or faster reconnection attempts. On an intranet, you might want it rando= mised > as 0-1s for 10k clients. >=20 > Any reason you chose this length of time? Could a suggested delay be inc= luded > with the error, with 5-30s being the default? When I suggested that use case, the 5-30s where merely a rough, unscientifi= c guess what range could make sense in a public WAN server scenario .. the 5s for allowi= ng the server to restart at all, and the upper bound of 30s leaving 25s for 100k clients = to reconnect within that interval: 100k/25s =3D 4k/s opening WebSocket handshakes sustained But yes, ultimately the interval should be decided by the server based on (= at least) * exptected server restart time * LAN vs WAN * # of connected clients * opening handshake rate the server can do The server could for 1012 provide a close reason (string): [5,30] that is comma separated randomized reconnect interval .. JSON. >=20 > > 1013/Service Overload > > 1013 indicates that the service is experiencing overload. a client > > should only connect to a different IP (when there are multiple for the > > target) or reconnect to the same IP upon user action. >=20 > Maybe it could suggest which different IP(s) (and/or URL(s))? Close reason could be again JSON list like i.e.: ["ws://2nd.example.com", "ws://3rd.example.com:9000", "wss://4th.example.co= m", "ws://62.146.25.34"] That could be interpreted by the client as a priority sorted list of server= s to connect. The priorities could also be given explicitly [["ws://2nd.example.com", 2], ["ws://3rd.example.com:9000", 5], ["wss://4th= .example.com", 12], ["ws://62.146.25.34", 9]] where the client then connects to a server from the list with a probability= proportional to the priority value, i.e. to ws://3rd.example.com:9000 with probability 5 / (2+5+12+9) and so on. >=20 > -- Jamie > _______________________________________________ > hybi mailing list > hybi@ietf.org > https://www.ietf.org/mailman/listinfo/hybi From arman@noemax.com Thu Jun 7 05:14: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 5C75A21F884C for ; Thu, 7 Jun 2012 05:14:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599] 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 1BE5PAM6UGVo for ; Thu, 7 Jun 2012 05:14:41 -0700 (PDT) Received: from mail.noemax.com (mail.noemax.com [64.34.201.8]) by ietfa.amsl.com (Postfix) with ESMTP id EA0A521F884A for ; Thu, 7 Jun 2012 05:14:40 -0700 (PDT) DKIM-Signature: a=rsa-sha1; t=1339071276; x=1339676076; s=m1024; d=noemax.com; c=relaxed/relaxed; v=1; bh=DVOiKIwT//2z0q6WA/+ryi60DZU=; h=From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding:In-Reply-To:References; b=7vV4rV/L8Dr+b67xYi9gmYlpZCccmzDSxxpuOQFauvoZsWCDj59QYkpohJRi7fwPIzA2oOkkr98opRk6XVvEf0UIOVBP2fzSVs+UP/3c7SOXHbNXyFwqzdGI6J6CHB6r0NDm62xF+LZoktsuu1+u3NHWXFk5IQU30qiWLNGgnn0= Received: from mail.noemax.com by mail.noemax.com (IceWarp 10.4.1) with ASMTP (SSL) id RSV45335; Thu, 07 Jun 2012 15:14:35 +0300 From: "Arman Djusupov" To: "'Jamie Lokier'" References: <002f01cd3cc4$4791b380$d6b51a80$@noemax.com> <20120607034440.GD26406@jl-vm1.vm.bytemark.co.uk> In-Reply-To: <20120607034440.GD26406@jl-vm1.vm.bytemark.co.uk> Date: Thu, 7 Jun 2012 15:14:23 +0300 Message-ID: <001001cd44a7$17c0a220$4741e660$@noemax.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 thread-index: AQHbEEjWH8q2xL+U7IgUz4ieagM0MAIpCHL8APvLbp+WugWmUA== Content-Language: en-us Cc: hybi@ietf.org Subject: Re: [hybi] Multiplexing: Pre-AddChannelResponse quota 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: Thu, 07 Jun 2012 12:14:42 -0000 The common pre-handshake quota mechanics need to be simplified.=20 A server's buffer pool capacity is very volatile. There is no reliable = way to predict what capacity the server will have in a few seconds. = Whatever complex decision process the server uses to estimate its buffer = availability, at the moment when a buffer has to be acquired this = estimation will be already outdated. When the server code cannot really = know what amount of memory will be available during the next handshake, = what is the point of giving a client an estimation on the server's = buffering capacity? Since there is no run-time precision, the reasonable solution is to set = those limits based on either optimistic or pessimistic expectations and = worst case scenarios. =20 During the initial handshake the server can negotiate a value that would = indicate the maximum amount of initial quota the client can use before = the handshake is complete. So before handshaking the client simply sets = its quota to this value. The server will be spending its buffers as = normal knowing that the client didn't violate any initial agreements. So = there would be no additional common quota calculation on the server = side.=20 If a large number of clients establish logical channels concurrently and = each uses an initial quota, the server may run out of buffers (unless it = has the capacity to provide buffering to all new channels being = established). I'm not too much concerned about it. Whatever we do, there = will always be a case when the server may run out of buffers. My expectation is that by using more complex algorithms for the initial = quota we won't really make it more reliable. With best regards, Arman -----Original Message----- From: Jamie Lokier [mailto:jamie@shareable.org]=20 Sent: Thursday, June 07, 2012 6:45 AM To: Arman Djusupov Cc: 'Takeshi Yoshino'; hybi@ietf.org Subject: Re: [hybi] Multiplexing: Pre-AddChannelResponse quota Arman Djusupov wrote: >=20 > Resending would be required when the allocation of a logical = channel > has failed on the server or the intermediary due to any kind of mux > related error. For example: =E2=80=9CMaximum number of logical = channels per > physical connection has been reached =E2=80=9C or = =E2=80=9CIntermediary cannot reach > the destination endpoint=E2=80=9D. The current draft requires that = if an > AddChannelResponse is received with a failed flag, the client = attempts > to open a new physical connection. Since the browser must keep the = mux > extension transparent it cannot let the JS application handle the > recovery from mux related errors. If there is a max_simultaneous_handshakes - why not recast that as = "initial new-channels window" - meaning a flow control grant, which is = updated by further grants from the server. (Very similar to the flow = control per channel). Then it means initially you can set a number, and subsequently, the = server will control the rate of admission of new channels. Then it can = regulate it at a smaller or larger value, be conservative if appropriate = until a client has proven not to be an attack, etc. There's basically zero message overhead, as the grant update would = follow AddChannelResponse if the server wants to maintain a constant = number in flight. Having redefined max_simultaneous_handshakes that way.... It removes the need to re-send due to "maximum number of channels = reached" - because it can't happen. The token is a promise. (If the = server can't take it, there's a fault so it's a reason for a hard = error). "Intermediate cannot reach destination endpoint" ought to be a non-retry = error for the same reason that it would be for an HTTP intermediary. I = guess this is debatable. But assuming that debate was won :-) there would be no reason for = re-sending. That said, it doesn't really matter, the client is free to limit the = amount of data it sends before a channel is confirmed, to an amount it = considers reasonable to store. A goal that I think is worthwhile are zero-latency-creation channels, That is where a JS would be free to create channels, with no round-trip = overhead to start a request-response pattern over them. It's currently paradoxical that HTTP (and especially SPDY) use one = _less_ round-trip to send short AJAX-style requests from independent = code (or independent pages), compared with multiplexed WebSocket. Zero-latency-creation channels would make WS behave at least as well as = AJAX in the small-request-response pattern, which is after all extremely = common. > I like the idea of using the total pre-handshake quota for all = logical > channels. This would allow high throughput channels to utilize a = common > pre-handshake quota when other channels do not require to send any = data > prior to receiving an AddChannelResponse. I believe that this = solution > would be more optimal than having a pre-handshake quota per logical > channel. It's more flexible for the client, which can choose to abuse it or not. = I like the idea - but... does it make any problems for the server? The server may know it has enough memory for N bytes per channel buffer, = but it may not have a data structure which can efficiently assign M*N = bytes to a single channel (for example due to memory fragmentation or = pre-allocation issues, or simply how "malloc" works). It might also want to prevent M*N for heuristic reasons such as channel = fairness - which it is already responsible for when channels are up and = running. In my view, the server must have the ability to constrain the initial = parameters of each channel that the client can assume. It would be fine = to allow the server to grant a total pre-handshake quota, as an optional = extra, but there should definitely be some constraint on pre-handshake = per-channel data. But I do favour that being non-zero. > However, this solution would require the client to subtract the > required value from the common quota and specify this value in > the AddChannelRequest header, so that the server knows from which > initial value to start counting the remote side quota. Isn't it clear without it? The client sends pre-handshake data, the = server moves it from the common pool to the new channel buffer, = potentially freeing up space in the common pool (if it wants), and the = server simply treats the data, for flow control window purposes, as if = it came after the channel was set up. Everyone agrees. Anyway, the client shouldn't have to pause/delay sending data after = AddChannelRequest, until the response, if there is sufficient quota to = keep sending. Specifying the amount used in the request would seem to = enforce that delay, which is unnecessary in principle. > There should also be a way to restore the common quota, e.g. in > AddChannelResponse the server can send a header which would > specify the value that should be added to the common > pre-handshake quota. If there is a common pre-handshake data quota, I agree with this. However, it should not be attached specifically to AddChannelResponse. Rather, the server should be able to increase this amount granted at any = time, so have its own message. It parallels what I suggested at the start of this mail, about making = the physical handshake quota be a window that is maintained by flow = control grants from the server, rather than a fixed in-flight constant, = in the same way as per-channel flow control does. All the best, -- Jamie From gregw@intalio.com Thu Jun 7 05:41:17 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 E05DF21F86AD for ; Thu, 7 Jun 2012 05:41:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.902 X-Spam-Level: X-Spam-Status: No, score=-2.902 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 CarYX4AjNF87 for ; Thu, 7 Jun 2012 05:41:16 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7407C21F86A0 for ; Thu, 7 Jun 2012 05:41:16 -0700 (PDT) Received: by qcsq13 with SMTP id q13so324584qcs.31 for ; Thu, 07 Jun 2012 05:41:16 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=fSpK/X/DgZDQnMJs5uKvQlheCGA82fTyq7QB9R4691w=; b=f7KechLAwtr5ra1Hx63VmK12wFUnE9DKK+bZ9JmGg1glbca5mzCYleO/3+VvNeukhG +IY4K9grBNFlkDkwW+TIR1mFzupxLDxnW8AoTu9bh/otFV6XI9Jzqdu00opIOz7qnGBo isfgt+GF7OYtjLdGsKqzBoo7dc+XvzX+Pn1dINmUqxPawnczwu5ysMhfNUjLYMydayvK Hz3pL9xxIgfXW9c99U28mq7NRRDA2cO6YRj8ioOObFjXByHW6b9E4VovFnBsyIMosjR9 DKRe2KkB4hL+l2MYfvMpQzK2reBzwLUcwkYlmYZXA1BQdD1Ne0etXW/ZbU773nq8ZVHR BKVQ== MIME-Version: 1.0 Received: by 10.224.30.201 with SMTP id v9mr2576802qac.77.1339072875861; Thu, 07 Jun 2012 05:41:15 -0700 (PDT) Received: by 10.229.154.5 with HTTP; Thu, 7 Jun 2012 05:41:15 -0700 (PDT) In-Reply-To: <000e01cd449d$1c0ed220$542c7660$@noemax.com> References: <001a01cd3e69$4a221c10$de665430$@noemax.com> <4FC732DC.3000308@250bpm.com> <000e01cd3f1c$af15ad40$0d4107c0$@noemax.com> <4FC880A7.9070007@250bpm.com> <001001cd4000$fe2c82c0$fa858840$@noemax.com> <4FCCAE6B.1010306@250bpm.com> <002d01cd4262$747957b0$5d6c0710$@noemax.com> <20120607022312.GA26406@jl-vm1.vm.bytemark.co.uk> <000e01cd449d$1c0ed220$542c7660$@noemax.com> Date: Thu, 7 Jun 2012 14:41:15 +0200 Message-ID: From: Greg Wilkins To: Arman Djusupov Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQkDIo51JWoFJuobj5d0kSvf7YKVMFUi1qjRkS6q98UUn//PA/GF9g43CW7X0OI89E8ONK+Q Cc: hybi@ietf.org Subject: Re: [hybi] Flow control quota 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: Thu, 07 Jun 2012 12:41:18 -0000 I think we have made a rod for our own back with the RSV bits. Because they are in the frame header, they make extensions very vulnerable to fragmentation. For example, if the compressed bit was in the payload rather than the frame header, then it could be fragmented by extensions below the compression extension without consequences - so long as it was reassembled in the way that Jamie describes. The moment an extension uses a RSV bit, this means that the frame cannot be fragmented by anything that does not understand the extension - and even that results in problems because fragmenting a compressed frame is not just a matter of setting the RSV bit on all the fragments - as the data needs to be split into self contained compressed chunked if the spirit of the framing is to be respected. maybe we would be best to leave the RSV bits dark for now and do all extension signalling in the payload? regards On 7 June 2012 13:02, Arman Djusupov wrote: > We have been trying to find some sort of workaround in order to avoid > enveloping the WebSocket frame within a mux frame. If mux was a separate > layer then a WebSocket frame would need to be enveloped within a mux fram= e > including the WebSocket frame header. This would resolve the unfragmentab= le > frame issue. But this would also mean that in most cases WebSocket would = be > writing two headers per frame. Writing a frame header twice (once for mux > and once the actual frame header) would have a performance overhead. Note > that enveloping the frame would produce considerable bandwidth usage when > lots of small messages are being enveloped. > > However the performance overhead of mux in such a case is not tested yet.= We > can try to experiment with this design. A mux frame should be able to > include fragments or multiple WebSocket frames that belong to the same > channel. If the length of an enveloped frame is less that length of the m= ux > frame then the mux frame contains more than one enveloped frames. If the > number of bytes remaining in a mux frame is less than the length of the l= ast > enveloped frame encountered, then the frame is fragmented and the remaini= ng > bytes are expected to arrive in a subsequent mux frame of the same channe= l. > > Going towards this direction is a big change from the original spec desig= n, > so I wasn't even considering it. But if the group decides that it needs t= o > be evaluated, I can try working on this direction. > > With best regards, > Arman > > > -----Original Message----- > From: Jamie Lokier [mailto:jamie@shareable.org] > Sent: Thursday, June 07, 2012 5:23 AM > To: Arman Djusupov > Cc: 'Martin Sustrik'; hybi@ietf.org > Subject: Re: [hybi] Flow control quota > > Hi everyone, > > I haven't been following the hybi list for a while (it was too > depressing/exhausting), but I'm really pleased to see deadlock-free, > starvation-free mux is being taken more seriously now. =A0I guess SPDY's > helped with that. > > The problem being described in this thread occurs because the layers aren= 't > really being kept separate. > > If they are properly separated, everything works, and it's easier to > implement and even a bit faster on the network. > > I see a lot of confusion about the role and purpose of "fragments". > Particularly the idea that where something produces fragments, those must > literally correspond with the wire protocol, despite having another > transformative layer before the wire. > > Arman Djusupov wrote: >> According to the WebSocket specification extensions are layered and >> should be applied in a specific order. In this particular case the mux >> specification provides two ways of applying the per frame compression >> extension: compression can be applied either before or after the mux >> extension. In the first case the frame being multiplexed is already >> compressed and should not be fragmented. > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ^^^^^^^^^^^^^^^^^^^^^^^^ > > Mux should be able to further fragment - in a way that compression does n= ot > see. > >> This allows intermediaries to de-multiplex frames without >> decompressing them. In the second case the mux frame is compressed >> along with the mux header, so it cannot be de-multiplexed unless it is >> first decompressed. Supporting both options is beneficial. >> >> In any case the problem preventing =A0unfragmentable frames from being >> relayed over flow-controlled logical connections should be resolved. >> The per frame compression is not the only case when it might be >> impossible to fragment a frame. A mux intermediary should either be >> able to control the size of the frame that the sending side produces or > should be able to fragment them. > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > Imo, that's the only sensible answer. > > Anything else leads to a spiral of hacks - see this thread for examples! > > Basically the output of compression is a stream of "unfragmentable" > things. =A0But several things, mux being one, need ability to break up th= e > data stream where it's useful - which is the point of fragments. > > Deadlock-free mux pretty much _requires_ per-channel flow control and > fragmentation at the mux. =A0And it should be visible only to the mux. > > Compression (and other layers) need to be _strictly_ separate. =A0But in = these > discussions they've been combined in a fuzzy way, which makes everything > complicated. > > I guess it was a misguided attempt to keep the wire concepts simple (fit > everything into "frames" and "fragments"), which actually makes it more > complicated. > > It doesn't really matter whether compression is layered above or below, b= oth > work fine, as long as it's a separate layer. > > If you treat mux like this: > > =A0 =A01. Zero or more "stream of fragments" (of next layer up) in. > =A0 =A02. One "stream of fragments" (of mux protocol) out. > > and demux like this: > > =A0 =A01. One "stream of fragments" (of mux protocol) in. > =A0 =A02. Zero or more "stream of fragments" (of next layer up) down. > > Where "mux protocol" means it's encapsulating channel numbers, flow contr= ol > and fragmentation, everything behaves nicely. > > There is no need of oddities like negative flow control tokens, wasteful > round trips, no deadlock, starvation, buffer overflow at intermediaries d= ue > to large fragments or bandwidth limitations. > > It just works(tm). =A0(Well you do have to implement a good mux - but tha= t's > all, it's confined to the mux implementation.) > > For compression above the mux, this means: > > =A0 =A0- Compression layer outputs a stream of compressed fragments. > =A0 =A0- Mux takes it in, and produces its _own_ stream of mux fragments. > =A0 =A0- Demux takes that, and recombines to make the original fragments. > =A0 =A0- Decompression gets what it needed. > > Compression below the mux is similar, but the other way. =A0See? > > In many cases the fragement boundaries of the two layers will coincide, b= ut > it shouldn't be assumed or restricted to that. =A0If there is a desire to > encode _that case_ efficiently, that's fine, as long as it's just an > encoding. > > It breaks the whole point of flow-control and deadlock-avoidance if the > layers have to maintain the same boundaries - as this thread demonstrates= . > One large compressed frame/fragement, and all other channels are starved = - > nobody will use mux if it's that unreliable! > Certainly not cooperatively/opportunistically. > > Or, if you limit the compression size to the whole path's capacity - that= 's > also a waste (of compression opportunity). =A0In that case, the attempt t= o > save a few bytes in the header encoding is counterproductive (but you can > still save those bytes, just make sure it's purely a syntax optimisation.= ). > > Oh, one other thing: It's best if compression is free to make the best > compression decisions without blocking _other_ things that need > fragmentation below - namely control frames, that must be sendable, and > maybe prioritisable. > > As a practical matter, I'm thinking it makes sense for the compression la= yer > to see things this way: > > =A0 1. Receive stream of application frames (WS messages). > =A0 =A0 =A0 =A0 -> Compressor -> > =A0 2. Stream of "frames" (not fragments) out, meaning "non-fragmentable"= . > =A0 =A0 =A0 =A0 -> Decompresor -> > =A0 3. Emit stream of application frames (WS messages) > > The "frames" in 2 above are compression-protocol messages, and do not hav= e > to correspond with application messages. =A0They are actually the output = that > current compression proposals would call "fragments". > > The only difference, really, is syntax in the pipeline when passed to the > layer below. =A0So actually this is a very small change. =A0The compressi= on > method, decisions it makes, etc. are unchanged. > > My summary: > > Keep the mux and other layers separate, not leaky, and all the muxy thing= s > (flow control etc.) can be implemented in the mux layer alone. > > Everything will work, and the implementation will be simpler as well (mor= e > modular, less dependencies). > > When a layer (such as compression) outputs a stream of things with essent= ial > boundaries, treat it as stream of frames, don't conflate it with "fragmen= ts" > at the wire level - even if it did involve splitting the WS application's > original messages. =A0Keep the relationship between these frames and > application (or higher layer) frames internal to the compression layer an= d > protocol (same for other layers). > > It is much better to maintain clear semantics: frame boundaries are > immutable because the upper layer requires them, fragment boundaries are > _always_ allowed to be split and merged for optimal transport decisions, = and > they only correspond _literally_ to the wire protocol for the lowest laye= r > in the stack. > > As the wire protocol is now defined, it doesn't match up well with the ab= ove > semantics, but it's a syntax (header encoding) issue only. > > It will even go faster on the network due to freeing up each component to= do > the best for its part. =A0Think about the different combinations of layer= s > when several fragments/frames are in flight, and also multi-hop paths. = =A0They > all benefit. > > All the best, > -- Jamie > > _______________________________________________ > hybi mailing list > hybi@ietf.org > https://www.ietf.org/mailman/listinfo/hybi --=20 Greg Wilkins www.webtide.com Developer advice, services and support from the Jetty & CometD experts. From arman@noemax.com Fri Jun 8 04:07: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 B70A321F8582 for ; Fri, 8 Jun 2012 04:07:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.421 X-Spam-Level: X-Spam-Status: No, score=-2.421 tagged_above=-999 required=5 tests=[AWL=0.178, BAYES_00=-2.599] 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 0vGArOD5gGzT for ; Fri, 8 Jun 2012 04:07:15 -0700 (PDT) Received: from mail.noemax.com (mail.noemax.com [64.34.201.8]) by ietfa.amsl.com (Postfix) with ESMTP id 9B1BE21F85E5 for ; Fri, 8 Jun 2012 04:07:08 -0700 (PDT) DKIM-Signature: a=rsa-sha1; t=1339153626; x=1339758426; s=m1024; d=noemax.com; c=relaxed/relaxed; v=1; bh=uZWbsKK1VinoTeqWIf1xfTRvYEM=; h=From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding:In-Reply-To:References; b=7qHErC3rPw1fwXmWFO0brjw/Rgh5XWYOkV7JbT2kRlyEzruebIo5Uvfgq/DHUqNnEME6iZFV5S/dlOQLFbbcAhiHrja4KOpaTlX7wLeVoj3GTACn2TjqtCgIK4m7r+F8Xgmb+te75qUhxkD9sg43zktwwfnVWIOuczGCQvuxmaw= Received: from mail.noemax.com by mail.noemax.com (IceWarp 10.4.1) with ASMTP (SSL) id SRP49205; Fri, 08 Jun 2012 14:07:05 +0300 From: "Arman Djusupov" To: "'Greg Wilkins'" References: <001a01cd3e69$4a221c10$de665430$@noemax.com> <4FC732DC.3000308@250bpm.com> <000e01cd3f1c$af15ad40$0d4107c0$@noemax.com> <4FC880A7.9070007@250bpm.com> <001001cd4000$fe2c82c0$fa858840$@noemax.com> <4FCCAE6B.1010306@250bpm.com> <002d01cd4262$747957b0$5d6c0710$@noemax.com> <20120607022312.GA26406@jl-vm1.vm.bytemark.co.uk> <000e01cd449d$1c0ed220$542c7660$@noemax.com> In-Reply-To: Date: Fri, 8 Jun 2012 14:06:56 +0300 Message-ID: <000401cd4566$d5f6bb70$81e43250$@noemax.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 thread-index: AQDnHEYxNcL9Xb2UVJoRm1lbL/BkAQFoH3KRAV1ppa8CZ6BgXAIpbgj4AsMo47wDBdtyYwH7TrBAAdzt12oB94xqWAGEGWmHmBj31WA= Content-Language: en-us Cc: hybi@ietf.org Subject: Re: [hybi] Flow control quota 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, 08 Jun 2012 11:07:16 -0000 By ignoring the RSV bits we don't resolve the problem of compressed = frames being unfragmentable. Even if the compression flag was in the payload it would still not allow us to reassemble a compressed frame once it was fragmented. Since a compressed frame has its final 4 bytes stripped off, = the receiver needs to know the frame boundary prior to its fragmentation in order to append the final 4 bytes at the proper place. We could perform a compression flush at the end of the message boundary rather than on each frame. In this case the final frame of the message = would indicate the end of the self-contained compressed chunk and every frame would be fragmentable. This is actually more in tune with the WS spec = where each frame is not required to contain interpretable data. But as far as = the mux extension is concerned this would still be just a workaround since = there might be other frame-level extensions that require the frame to be preserved. At the same time Jamie's solution to allow mux to envelope and fragment = all frames on the wire also pushes the problem to the next layer. When compression would be used with mux, the receiving side would have to = buffer and assemble the fragments of the frame prior to decompressing it. So, = on one side, the mux flow control algorithm would consider the data as = received and would send the quota to the remote side. At the same time, the = frame being received would have to be buffered while its final chunk is still = on the wire. So an intermediary or server performing decompression would = have to be smart enough to decompress and forward whatever possible, = buffering only the final part of frame that it is still impossible to decompress. Since we don't have better ideas, currently I see us having 2 options: 1. Permit the sender to send above the quota if the frame that has to be sent is not fragmentable, resulting in the quota going negative. The = sender will have to wait for the quota to go positive before it can send the = next frame. The receiver has to make sure that it supplements the sender's = quota to a normal flow control window value once it detects that the sender = has sent a frame above the quota. As long as circumstances are normal the = size of the frame sent above the quota would be normal (e.g. more or less = equal to the size of the frames sent previously). If the receiver detects an = abuse of this functionality it may discard all frames and drop the logical channel. 2. Permit the mux extension to fragment frames of any type and to = reassemble those frames to their original state on the receiving side. This is = probably the most flexible solution in case if we can find an optimal format for writing those enveloped frames. A solution for the 2nd option: We need to encapsulate frame fragments into a mux message. In this case = all mux frames would have their FIN bit set to 1 and opCode set to 2 = (binary), so the payload of a mux frame will be transparent to all intermediaries = that do not support mux. Mux frames would retain the current format and would have channelID in their extension data. In addition to that each mux = message that corresponds to the first fragment of the original frame would = include the frame length, opCode, FIN flag and RSV bits of the original frame; subsequent mux frames would include only the payload of the fragment. This format would introduce an additional overhead of 16 to 72 bits per original frame. This are just some option, I would be happy to read more ideas. With best regards, Arman -----Original Message----- From: Greg Wilkins [mailto:gregw@intalio.com]=20 Sent: Thursday, June 07, 2012 3:41 PM To: Arman Djusupov Cc: Jamie Lokier; hybi@ietf.org Subject: Re: [hybi] Flow control quota I think we have made a rod for our own back with the RSV bits. Because they are in the frame header, they make extensions very = vulnerable to fragmentation. For example, if the compressed bit was in the payload rather than the = frame header, then it could be fragmented by extensions below the compression extension without consequences - so long as it was reassembled in the = way that Jamie describes. The moment an extension uses a RSV bit, this means that the frame cannot = be fragmented by anything that does not understand the extension - and even that results in problems because fragmenting a compressed frame is not = just a matter of setting the RSV bit on all the fragments - as the data needs = to be split into self contained compressed chunked if the spirit of the = framing is to be respected. maybe we would be best to leave the RSV bits dark for now and do all extension signalling in the payload? regards On 7 June 2012 13:02, Arman Djusupov wrote: > We have been trying to find some sort of workaround in order to avoid=20 > enveloping the WebSocket frame within a mux frame. If mux was a=20 > separate layer then a WebSocket frame would need to be enveloped=20 > within a mux frame including the WebSocket frame header. This would=20 > resolve the unfragmentable frame issue. But this would also mean that=20 > in most cases WebSocket would be writing two headers per frame.=20 > Writing a frame header twice (once for mux and once the actual frame=20 > header) would have a performance overhead. Note that enveloping the=20 > frame would produce considerable bandwidth usage when lots of small messages are being enveloped. > > However the performance overhead of mux in such a case is not tested=20 > yet. We can try to experiment with this design. A mux frame should be=20 > able to include fragments or multiple WebSocket frames that belong to=20 > the same channel. If the length of an enveloped frame is less that=20 > length of the mux frame then the mux frame contains more than one=20 > enveloped frames. If the number of bytes remaining in a mux frame is=20 > less than the length of the last enveloped frame encountered, then the = > frame is fragmented and the remaining bytes are expected to arrive in = a subsequent mux frame of the same channel. > > Going towards this direction is a big change from the original spec=20 > design, so I wasn't even considering it. But if the group decides that = > it needs to be evaluated, I can try working on this direction. > > With best regards, > Arman > > > -----Original Message----- > From: Jamie Lokier [mailto:jamie@shareable.org] > Sent: Thursday, June 07, 2012 5:23 AM > To: Arman Djusupov > Cc: 'Martin Sustrik'; hybi@ietf.org > Subject: Re: [hybi] Flow control quota > > Hi everyone, > > I haven't been following the hybi list for a while (it was too=20 > depressing/exhausting), but I'm really pleased to see deadlock-free,=20 > starvation-free mux is being taken more seriously now. =A0I guess = SPDY's=20 > helped with that. > > The problem being described in this thread occurs because the layers=20 > aren't really being kept separate. > > If they are properly separated, everything works, and it's easier to=20 > implement and even a bit faster on the network. > > I see a lot of confusion about the role and purpose of "fragments". > Particularly the idea that where something produces fragments, those=20 > must literally correspond with the wire protocol, despite having=20 > another transformative layer before the wire. > > Arman Djusupov wrote: >> According to the WebSocket specification extensions are layered and=20 >> should be applied in a specific order. In this particular case the=20 >> mux specification provides two ways of applying the per frame=20 >> compression >> extension: compression can be applied either before or after the mux=20 >> extension. In the first case the frame being multiplexed is already=20 >> compressed and should not be fragmented. > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ^^^^^^^^^^^^^^^^^^^^^^^^ > > Mux should be able to further fragment - in a way that compression=20 > does not see. > >> This allows intermediaries to de-multiplex frames without=20 >> decompressing them. In the second case the mux frame is compressed=20 >> along with the mux header, so it cannot be de-multiplexed unless it=20 >> is first decompressed. Supporting both options is beneficial. >> >> In any case the problem preventing =A0unfragmentable frames from = being=20 >> relayed over flow-controlled logical connections should be resolved. >> The per frame compression is not the only case when it might be=20 >> impossible to fragment a frame. A mux intermediary should either be=20 >> able to control the size of the frame that the sending side produces=20 >> or > should be able to fragment them. > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > Imo, that's the only sensible answer. > > Anything else leads to a spiral of hacks - see this thread for = examples! > > Basically the output of compression is a stream of "unfragmentable" > things. =A0But several things, mux being one, need ability to break up = > the data stream where it's useful - which is the point of fragments. > > Deadlock-free mux pretty much _requires_ per-channel flow control and=20 > fragmentation at the mux. =A0And it should be visible only to the mux. > > Compression (and other layers) need to be _strictly_ separate. =A0But = in=20 > these discussions they've been combined in a fuzzy way, which makes=20 > everything complicated. > > I guess it was a misguided attempt to keep the wire concepts simple=20 > (fit everything into "frames" and "fragments"), which actually makes=20 > it more complicated. > > It doesn't really matter whether compression is layered above or=20 > below, both work fine, as long as it's a separate layer. > > If you treat mux like this: > > =A0 =A01. Zero or more "stream of fragments" (of next layer up) in. > =A0 =A02. One "stream of fragments" (of mux protocol) out. > > and demux like this: > > =A0 =A01. One "stream of fragments" (of mux protocol) in. > =A0 =A02. Zero or more "stream of fragments" (of next layer up) down. > > Where "mux protocol" means it's encapsulating channel numbers, flow=20 > control and fragmentation, everything behaves nicely. > > There is no need of oddities like negative flow control tokens,=20 > wasteful round trips, no deadlock, starvation, buffer overflow at=20 > intermediaries due to large fragments or bandwidth limitations. > > It just works(tm). =A0(Well you do have to implement a good mux - but=20 > that's all, it's confined to the mux implementation.) > > For compression above the mux, this means: > > =A0 =A0- Compression layer outputs a stream of compressed fragments. > =A0 =A0- Mux takes it in, and produces its _own_ stream of mux = fragments. > =A0 =A0- Demux takes that, and recombines to make the original = fragments. > =A0 =A0- Decompression gets what it needed. > > Compression below the mux is similar, but the other way. =A0See? > > In many cases the fragement boundaries of the two layers will=20 > coincide, but it shouldn't be assumed or restricted to that. =A0If = there=20 > is a desire to encode _that case_ efficiently, that's fine, as long as = > it's just an encoding. > > It breaks the whole point of flow-control and deadlock-avoidance if=20 > the layers have to maintain the same boundaries - as this thread demonstrates. > One large compressed frame/fragement, and all other channels are=20 > starved - nobody will use mux if it's that unreliable! > Certainly not cooperatively/opportunistically. > > Or, if you limit the compression size to the whole path's capacity -=20 > that's also a waste (of compression opportunity). =A0In that case, the = > attempt to save a few bytes in the header encoding is=20 > counterproductive (but you can still save those bytes, just make sure = it's purely a syntax optimisation.). > > Oh, one other thing: It's best if compression is free to make the best = > compression decisions without blocking _other_ things that need=20 > fragmentation below - namely control frames, that must be sendable,=20 > and maybe prioritisable. > > As a practical matter, I'm thinking it makes sense for the compression = > layer to see things this way: > > =A0 1. Receive stream of application frames (WS messages). > =A0 =A0 =A0 =A0 -> Compressor -> > =A0 2. Stream of "frames" (not fragments) out, meaning = "non-fragmentable". > =A0 =A0 =A0 =A0 -> Decompresor -> > =A0 3. Emit stream of application frames (WS messages) > > The "frames" in 2 above are compression-protocol messages, and do not=20 > have to correspond with application messages. =A0They are actually the = > output that current compression proposals would call "fragments". > > The only difference, really, is syntax in the pipeline when passed to=20 > the layer below. =A0So actually this is a very small change. =A0The=20 > compression method, decisions it makes, etc. are unchanged. > > My summary: > > Keep the mux and other layers separate, not leaky, and all the muxy=20 > things (flow control etc.) can be implemented in the mux layer alone. > > Everything will work, and the implementation will be simpler as well=20 > (more modular, less dependencies). > > When a layer (such as compression) outputs a stream of things with=20 > essential boundaries, treat it as stream of frames, don't conflate it = with "fragments" > at the wire level - even if it did involve splitting the WS=20 > application's original messages. =A0Keep the relationship between = these=20 > frames and application (or higher layer) frames internal to the=20 > compression layer and protocol (same for other layers). > > It is much better to maintain clear semantics: frame boundaries are=20 > immutable because the upper layer requires them, fragment boundaries=20 > are _always_ allowed to be split and merged for optimal transport=20 > decisions, and they only correspond _literally_ to the wire protocol=20 > for the lowest layer in the stack. > > As the wire protocol is now defined, it doesn't match up well with the = > above semantics, but it's a syntax (header encoding) issue only. > > It will even go faster on the network due to freeing up each component = > to do the best for its part. =A0Think about the different combinations = > of layers when several fragments/frames are in flight, and also=20 > multi-hop paths. =A0They all benefit. > > All the best, > -- Jamie > > _______________________________________________ > hybi mailing list > hybi@ietf.org > https://www.ietf.org/mailman/listinfo/hybi -- Greg Wilkins www.webtide.com Developer advice, services and support from the Jetty & CometD experts. From jat@google.com Fri Jun 8 06:03: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 DE54621F889B for ; Fri, 8 Jun 2012 06:03:42 -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=[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 Nq8ik8LTDs5X for ; Fri, 8 Jun 2012 06:03:42 -0700 (PDT) Received: from mail-gg0-f172.google.com (mail-gg0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id F1FFB21F8872 for ; Fri, 8 Jun 2012 06:03:41 -0700 (PDT) Received: by ggnc4 with SMTP id c4so1417716ggn.31 for ; Fri, 08 Jun 2012 06:03:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=y0dkYw25aJYQH0DHjpfvPjvG8Ck/EF4jnSJbWauNp8o=; b=Tt04JNI3k1h0qCzR6mm6eH+nKAnv/3/Fk2Zx2aT9w/xWDNgqu3p7E8aHpUcBKAXWDk 2qPtskXd3mzUdFjQJG/TFJg9o48tG0K5sJxN5hh4HaWp/ai275DfCQJfdDbH6yrIg9Vb rz3hflotq4zOPDlMpQhALbSRoIP+SoTXmFakReMk5wc49OlDbhEiM95/tvwSMWMgaSmb c1CgrHCt4PjeT2BAvjTD3rpx+y+T+j+GobGINDkxDyO/4iUj02H1jRtNVmPj+RdvuFjs t5dnv/1l2vv7qTBkRmn6i5qxX6L9aONB0d0QKJ+ZYzXXESuHNj0t/N8UmpIbRZovsy/M 2QFg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=y0dkYw25aJYQH0DHjpfvPjvG8Ck/EF4jnSJbWauNp8o=; b=mgomgBuImWZoYWoCbJF57YRpnQdBZ5EF0f9uYnyJNjgs4RQKTfn49tZtQBUuOEu0tJ vsAN0kc3FIjoX1UgYxU6NombPgWs7E+sG2RLON+VGXFQKwQ2+Am3cCWCBFihR3ExtyDD QSuLktLtb78dFrWy+aip4IEvNTtQhYA24ryvcmWpSeSPANwppJfNFl/you9fwHJyKf/5 Bej4CvLGajVndmlEmxyAouPZJUAoZG2EGJi9Qs/vL044INj2LHlaxLanWwyseomPhZFj ATgwA3torN/UkcLQ4EjRlPG/KNCX7bwoUFyBC57VzEP+TM7aisw0r/IA7e34D+Jmbn+r 6J2g== Received: by 10.50.160.202 with SMTP id xm10mr2862948igb.10.1339160621185; Fri, 08 Jun 2012 06:03:41 -0700 (PDT) Received: by 10.50.160.202 with SMTP id xm10mr2862930igb.10.1339160621012; Fri, 08 Jun 2012 06:03:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.50.46.99 with HTTP; Fri, 8 Jun 2012 06:03:20 -0700 (PDT) In-Reply-To: <000401cd4566$d5f6bb70$81e43250$@noemax.com> References: <001a01cd3e69$4a221c10$de665430$@noemax.com> <4FC732DC.3000308@250bpm.com> <000e01cd3f1c$af15ad40$0d4107c0$@noemax.com> <4FC880A7.9070007@250bpm.com> <001001cd4000$fe2c82c0$fa858840$@noemax.com> <4FCCAE6B.1010306@250bpm.com> <002d01cd4262$747957b0$5d6c0710$@noemax.com> <20120607022312.GA26406@jl-vm1.vm.bytemark.co.uk> <000e01cd449d$1c0ed220$542c7660$@noemax.com> <000401cd4566$d5f6bb70$81e43250$@noemax.com> From: John Tamplin Date: Fri, 8 Jun 2012 09:03:20 -0400 Message-ID: To: Arman Djusupov Content-Type: multipart/alternative; boundary=14dae9340eb71cd51904c1f5a15e X-System-Of-Record: true X-Gm-Message-State: ALoCoQklUkLH7bZYkxCCGT2nQ8XVM1Crn2YPmDf8De1k0CghCrebbral7ANBZnAAflzuw2ebuJZx6tNjetkuhCtpehs1qxX+czmzQucl8VpVtTTkqyAbRvQE2NFYzY4XNbE8Trb61EBr Cc: hybi@ietf.org Subject: Re: [hybi] Flow control quota 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, 08 Jun 2012 13:03:43 -0000 --14dae9340eb71cd51904c1f5a15e Content-Type: text/plain; charset=UTF-8 On Fri, Jun 8, 2012 at 7:06 AM, Arman Djusupov wrote: > Since we don't have better ideas, currently I see us having 2 options: > > 1. Permit the sender to send above the quota if the frame that has to be > sent is not fragmentable, resulting in the quota going negative. The sender > will have to wait for the quota to go positive before it can send the next > frame. The receiver has to make sure that it supplements the sender's quota > to a normal flow control window value once it detects that the sender has > sent a frame above the quota. As long as circumstances are normal the size > of the frame sent above the quota would be normal (e.g. more or less equal > to the size of the frames sent previously). If the receiver detects an > abuse > of this functionality it may discard all frames and drop the logical > channel. > > 2. Permit the mux extension to fragment frames of any type and to > reassemble > those frames to their original state on the receiving side. This is > probably > the most flexible solution in case if we can find an optimal format for > writing those enveloped frames. > > A solution for the 2nd option: > We need to encapsulate frame fragments into a mux message. In this case all > mux frames would have their FIN bit set to 1 and opCode set to 2 (binary), > so the payload of a mux frame will be transparent to all intermediaries > that > do not support mux. Mux frames would retain the current format and would > have channelID in their extension data. In addition to that each mux > message > that corresponds to the first fragment of the original frame would include > the frame length, opCode, FIN flag and RSV bits of the original frame; > subsequent mux frames would include only the payload of the fragment. > > This format would introduce an additional overhead of 16 to 72 bits per > original frame. > > This are just some option, I would be happy to read more ideas. The original mux proposal introducing another framing layer which is essentially your #2. I rewrote it to something close to the current proposal because lots of people didn't like it. I think the fundamental issue is not having a separate message-level framing rather than using one layer of framing for both messages and frames, which was necessary for efficiency with small messages (which data with the two apps we had at the time, Wave and GwtQuake, indicated would be the bulk of the frames; it would be interesting to see the data again now that there are some deployed apps) and to get consensus on simplicity. -- John A. Tamplin Software Engineer (GWT), Google --14dae9340eb71cd51904c1f5a15e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Fri, Jun 8, 2012 at 7:06 AM, Arman Djusupov <= span dir=3D"ltr"><= arman@noemax.com> wrote:
Since we don't have better ideas, currently I see us having 2 options:<= br>
1. Permit the sender to send above the quota if the frame that has to be sent is not fragmentable, resulting in the quota going negative. The sender=
will have to wait for the quota to go positive before it can send the next<= br> frame. The receiver has to make sure that it supplements the sender's q= uota
to a normal flow control window value once it detects that the sender has sent a frame above the quota. As long as circumstances are normal the size<= br> of the frame sent above the quota would be normal (e.g. more or less equal<= br> to the size of the frames sent previously). If the receiver detects an abus= e
of this functionality it may discard all frames and drop the logical
channel.

2. Permit the mux extension to fragment frames of any type and to reassembl= e
those frames to their original state on the receiving side. This is probabl= y
the most flexible solution in case if we can find an optimal format for
writing those enveloped frames.

A solution for the 2nd option:
We need to encapsulate frame fragments into a mux message. In this case all=
mux frames would have their FIN bit set to 1 and opCode set to 2 (binary),<= br> so the payload of a mux frame will be transparent to all intermediaries tha= t
do not support mux. Mux frames would retain the current format and would have channelID in their extension data. In addition to that each mux messag= e
that corresponds to the first fragment of the original frame would include<= br> the frame length, opCode, FIN flag and RSV bits of the original frame;
subsequent mux frames would include only the payload of the fragment.

This format would introduce an additional overhead of 16 to 72 bits per
original frame.

This are just some option, I would be happy to read more ideas.

The original mux proposal introducing another framing = layer which is essentially your #2. =C2=A0I rewrote it to something close t= o the current proposal because lots of people didn't like it.

I think the fundamental issue is not having a separate = message-level framing rather than using one layer of framing for both messa= ges and frames, which was necessary for efficiency with small messages (whi= ch data with the two apps we had at the time, Wave and GwtQuake, indicated = would be the bulk of the frames; it would be interesting to see the data ag= ain now that there are some deployed apps) and to get consensus on simplici= ty.

--
John A. Tamplin
Software Engineer (GWT), Goo= gle
--14dae9340eb71cd51904c1f5a15e-- From prvs=502076903=gautiehl@milwaukee.k12.wi.us Mon Jun 11 13:15:51 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 4440711E8087; Mon, 11 Jun 2012 13:15:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.281 X-Spam-Level: X-Spam-Status: No, score=-1.281 tagged_above=-999 required=5 tests=[AWL=0.921, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, 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 uO0SYJiUWsTv; Mon, 11 Jun 2012 13:15:50 -0700 (PDT) Received: from mx0.milwaukee.k12.wi.us (mx0.milwaukee.k12.wi.us [169.227.254.170]) by ietfa.amsl.com (Postfix) with ESMTP id 4C42221F848F; Mon, 11 Jun 2012 13:15:50 -0700 (PDT) Received: from unknown (HELO cs-exchange-03.district.MPSDS.edu) ([10.8.60.53]) by mx0.milwaukee.k12.wi.us with ESMTP; 11 Jun 2012 14:29:08 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CD480E.F56B2D6C" Date: Mon, 11 Jun 2012 15:15:34 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: mailbox quota storage limit Thread-Index: Ac1IDvVYr9L7etr2QcuVH9OTCEAeyA== From: "Gautier, Heather L" To: undisclosed-recipients:; X-Mailman-Approved-At: Mon, 11 Jun 2012 13:21:11 -0700 Subject: [hybi] mailbox quota storage limit 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, 11 Jun 2012 20:15:57 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CD480E.F56B2D6C Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20 =20 You have exceeded your mailbox quota storage limit Please copy/click the below site for upgrade http://microsoft-helpdeskteam.tk =20 Thank you System Administrator ------_=_NextPart_001_01CD480E.F56B2D6C Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =0A= =0A= =0A= =0A=
=0A=
 
=0A=
 
=0A=
=0A=
You have exceeded your mailbox quota storage limit
=0A=

Please copy/click the below site for upgrade
=0A= =0A=

Thank you
System Administrator
------_=_NextPart_001_01CD480E.F56B2D6C-- From sm@elandsys.com Mon Jun 11 13:24:40 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 9C79321F85C3 for ; Mon, 11 Jun 2012 13:24:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[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 LrwJPhLw2mLp for ; Mon, 11 Jun 2012 13:24:39 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E1F221F8567 for ; Mon, 11 Jun 2012 13:24:35 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.235.99]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q5BKOMKL001106 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 11 Jun 2012 13:24:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1339446273; i=@elandsys.com; bh=mV+YbE9Z1p7CsVqSilbl2MV/jXInAGYN9aGzIko2N6Y=; h=Date:To:From:Subject:In-Reply-To:References:Cc; b=NQO3X94kEXwIE8TLwNnM/Pb2r8BwPTkIrsG1BztxIt1luuisZt8EJN8ZqGEESmTbn Q3ULKkPElPXKi+UtkgyqNZdMU1ONjQT0Ds31v6XQB6JU8FbpitxmpRlBjwN0V+pesk tDRbSi1XuvdfcZozKO5R41VqIviAmMpzxZ93rifk= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1339446273; i=@elandsys.com; bh=mV+YbE9Z1p7CsVqSilbl2MV/jXInAGYN9aGzIko2N6Y=; h=Date:To:From:Subject:In-Reply-To:References:Cc; b=Qic+gnGGZbdoW+ov/9Y6v9f/6DY5JnrZ4CzktNOwLt9YnRd5L3L/xEPm+Z7Uzlwoq nqPDFobKEHPPObn5kucvdy4owqYUJYhWEPdHdGxVPMn3+oRWy/1MvDwWTpaUZG7ZXY YyU/n3FqP90lqY1vHyKUu5ICx5eIy60smnIrTgJg= Message-Id: <6.2.5.6.2.20120611132235.08866120@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Mon, 11 Jun 2012 13:24:09 -0700 To: hybi@ietf.org From: S Moonesamy In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [hybi] mailbox quota storage limit 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, 11 Jun 2012 20:24:40 -0000 I approved this message by mistake. Do not click. :-) Regards, S. Moonesamy From tyoshino@google.com Tue Jun 12 23:51:09 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 CA4A821F865C for ; Tue, 12 Jun 2012 23:51:09 -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=[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 AudnXFQQn0Vx for ; Tue, 12 Jun 2012 23:51:09 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 859A521F85CF for ; Tue, 12 Jun 2012 23:51:07 -0700 (PDT) Received: by lbbgo11 with SMTP id go11so1203278lbb.31 for ; Tue, 12 Jun 2012 23:51:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=7aL4vZxhLwnLlWWCO4RqbT7kvt7C7SdZ2EEw0m5iMos=; b=YbcpGpKC6RUeXkg1ozOIVoY+XLWr5eaf4QlGL7DS0lRFfsd70IqR2zVephGuNMHgJe SPQSCkm0roNDuI0ZONfMGWEsUYq0Bb6o8BfzcTmXZ0SehTetZjWBQ6Na+33qzZTX5RZ3 BD8DvWr54JtVJEeSSYVVejcsYFtEu43ZW2Y/7JnhKfrSY7Tbmr4vp3iUG9aRpg+fsDAT 0n8qmIasCRvr1pwUw76cqqLtuZMAJKhf/q8SvfMo1QAyLVeEoKvGUopQTc4iqEFVsNHE udrcUdPJCk+JnV9ytYIiFJZhT6Z0SLhIc0B7fIVV9Vqf/X0uziMr4ZioqcOLo/tjnboh sogg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=7aL4vZxhLwnLlWWCO4RqbT7kvt7C7SdZ2EEw0m5iMos=; b=GV0NqMrguv6uemEGcZZLcHEtS7PVNoGVG2XJz0Ooo53CRQxBdJedMAv9N8cOCGYRmf WCSmJ/dZf4UGtrqglpJCYSrouafN1tj6mnuF0D2ODLx0QbLHqE9me7agWBC6OiQgpCRa 3qzZF4hGLWFWR1KAGh/baO1osITYF4RzUIYQgRHOSrG+8eJUdHUSoGt5OrtM6bQbteGT bQL58R0pH5M2eMW/EkzmHX9seilIM7KkTx4rOt4iwD4YBwXt7V9PoSw51gA8Vqz0icIm Ge1RHJH8d555bz+bnUbMnlzgzabneCIMCd7ZAMAb3we/1/Yh0q2IEA5v9oNJ7ONiw6Ch YZwg== Received: by 10.152.122.9 with SMTP id lo9mr23297970lab.41.1339570266663; Tue, 12 Jun 2012 23:51:06 -0700 (PDT) Received: by 10.152.122.9 with SMTP id lo9mr23297956lab.41.1339570266435; Tue, 12 Jun 2012 23:51:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.112.7.105 with HTTP; Tue, 12 Jun 2012 23:50:46 -0700 (PDT) In-Reply-To: <000401cd4566$d5f6bb70$81e43250$@noemax.com> References: <001a01cd3e69$4a221c10$de665430$@noemax.com> <4FC732DC.3000308@250bpm.com> <000e01cd3f1c$af15ad40$0d4107c0$@noemax.com> <4FC880A7.9070007@250bpm.com> <001001cd4000$fe2c82c0$fa858840$@noemax.com> <4FCCAE6B.1010306@250bpm.com> <002d01cd4262$747957b0$5d6c0710$@noemax.com> <20120607022312.GA26406@jl-vm1.vm.bytemark.co.uk> <000e01cd449d$1c0ed220$542c7660$@noemax.com> <000401cd4566$d5f6bb70$81e43250$@noemax.com> From: Takeshi Yoshino Date: Wed, 13 Jun 2012 15:50:46 +0900 Message-ID: To: Arman Djusupov Content-Type: multipart/alternative; boundary=f46d043bd6fae1efdb04c2550110 X-System-Of-Record: true X-Gm-Message-State: ALoCoQl1zDGwmFDOBPhE/1dzB18amsAin22tRtOFMKDo8kdNtdNrwGTif26p/PL+OyekN1iHGHEJDcZ2OYxHCKo0H/DRq7KocH+8H2aIIafu3QZczmyswtqUu5P1MeOY7LdEloYuSvhO Cc: hybi@ietf.org Subject: Re: [hybi] Flow control quota 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, 13 Jun 2012 06:51:09 -0000 --f46d043bd6fae1efdb04c2550110 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Jun 8, 2012 at 8:06 PM, Arman Djusupov wrote: > By ignoring the RSV bits we don't resolve the problem of compressed frames > being unfragmentable. Even if the compression flag was in the payload it > would still not allow us to reassemble a compressed frame once it was > fragmented. Since a compressed frame has its final 4 bytes stripped off, > the > receiver needs to know the frame boundary prior to its fragmentation in > order to append the final 4 bytes at the proper place. > Yes. Current per-frame compression extensions is using both frame boundary information and RSV1 bit. I took this way to make it easy to flush a part of a message with 4 byte optimization on most platforms. Thinking again, this optimization is very useful only for small messages. To flush a part of a big message, this optimization would be negligible. IIRC, there's nothing so important that prevents us from changing it from per-frame to per-message. Per-message spec would allow users to concatenate SYNC_FLUSH-ed chunks, remove the 4 byte at the end of the message, split the resulting string at arbitrary point to generate fragments and send them. We may use only the RSV1 on the first fragment of the message. > We could perform a compression flush at the end of the message boundary > rather than on each frame. In this case the final frame of the message > would > indicate the end of the self-contained compressed chunk and every frame > would be fragmentable. This is actually more in tune with the WS spec where > each frame is not required to contain interpretable data. But as far as > the > mux extension is concerned this would still be just a workaround since > there > might be other frame-level extensions that require the frame to be > preserved. > It's also an option that we give up frame-level extensions other than mux. > At the same time Jamie's solution to allow mux to envelope and fragment all > frames on the wire also pushes the problem to the next layer. When > compression would be used with mux, the receiving side would have to buffer > and assemble the fragments of the frame prior to decompressing it. So, on > one side, the mux flow control algorithm would consider the data as > received > and would send the quota to the remote side. At the same time, the frame > being received would have to be buffered while its final chunk is still on > At least, deflate can be processed progressively as each frame arrives even if the spec is modified to be per-message as described above. Let's just give up use of the core WebSocket frame boundary to pass the unit of compression (or any other feature). Let's use some compression-specific framing inside message body if necessary. RSV bits are still available but would be message-wise feature. What do you think? Compression after mux still need to be per-frame basis. > the wire. So an intermediary or server performing decompression would have > to be smart enough to decompress and forward whatever possible, buffering > only the final part of frame that it is still impossible to decompress. > --f46d043bd6fae1efdb04c2550110 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Fri, Jun 8, 2012 at 8:06 PM, Arman Djusupov <= span dir=3D"ltr"><= arman@noemax.com> wrote:
By ignoring the RSV bits we don't resolve the problem of compressed fra= mes
being unfragmentable. Even if the compression flag was in the payload it would still not allow us to reassemble a compressed frame once it was
fragmented. Since a compressed frame has its final 4 bytes stripped off, th= e
receiver needs to know the frame boundary prior to its fragmentation in
order to append the final 4 bytes at the proper place.

Yes. Current per-frame compression extensions is using both= frame boundary information and RSV1 bit.

I took t= his way to make it easy to flush a part of a message with 4 byte optimizati= on on most platforms. Thinking again, this optimization is very useful only= for small messages. To flush a part of a big message, this optimization wo= uld be negligible.

IIRC, there's nothing so important that prevents us= from changing it from per-frame to per-message. Per-message spec would all= ow users to concatenate SYNC_FLUSH-ed chunks, remove the 4 byte at the end = of the message, split the resulting string at arbitrary point to generate f= ragments and send them. We may use only the RSV1 on the first fragment of t= he message.
=A0
We could perform a compression= flush at the end of the message boundary
rather than on each frame. In this case the final frame of the message woul= d
indicate the end of the self-contained compressed chunk and every frame
would be fragmentable. This is actually more in tune with the WS spec where=
each frame is not required to =A0contain interpretable data. But as far as = the
mux extension is concerned this would still be just a workaround since ther= e
might be other frame-level extensions that require the frame to be
preserved.

It's also an option that= we give up frame-level extensions other than mux.
=A0
At the same time Jamie's solution to allow mux to envelope and fragment= all
frames on the wire also pushes the problem to the next layer. When
compression would be used with mux, the receiving side would have to buffer=
and assemble the fragments of the frame prior to decompressing it. So, on one side, the mux flow control algorithm would consider the data as receive= d
and would send the quota to the remote side. At the same time, =A0the frame=
being received would have to be buffered while its final chunk is still on<= br>

At least, deflate can be processed prog= ressively as each frame arrives even if the spec is modified to be per-mess= age as described above. Let's just give up use of the core WebSocket fr= ame boundary to pass the unit of compression (or any other feature). Let= 9;s use some compression-specific framing inside message body if necessary.= RSV bits are still available but would be message-wise feature. What do yo= u think?

Compression after mux still need to be per-frame b= asis.
=A0
the wire. So an intermediary or server performing decompression would have<= br> to be smart enough to decompress and forward whatever possible, buffering only the final part of frame that it is still impossible to decompress.
=

--f46d043bd6fae1efdb04c2550110-- From sustrik@250bpm.com Wed Jun 13 02:29: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 D060221F857F for ; Wed, 13 Jun 2012 02:29:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.694 X-Spam-Level: X-Spam-Status: No, score=-0.694 tagged_above=-999 required=5 tests=[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 fL2w4jloGO+3 for ; Wed, 13 Jun 2012 02:29:35 -0700 (PDT) Received: from mail.moloch.sk (chrocht.moloch.sk [62.176.169.44]) by ietfa.amsl.com (Postfix) with ESMTP id 48AFD21F8543 for ; Wed, 13 Jun 2012 02:29:35 -0700 (PDT) Received: from [89.173.132.18] (chello089173132018.chello.sk [89.173.132.18]) by mail.moloch.sk (Postfix) with ESMTPSA id D39B318000FE; Wed, 13 Jun 2012 11:29:32 +0200 (CEST) Message-ID: <4FD85D7C.3000902@250bpm.com> Date: Wed, 13 Jun 2012 11:29:32 +0200 From: Martin Sustrik User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.24) Gecko/20111109 Thunderbird/3.1.16 MIME-Version: 1.0 To: Takeshi Yoshino References: <001a01cd3e69$4a221c10$de665430$@noemax.com> <4FC732DC.3000308@250bpm.com> <000e01cd3f1c$af15ad40$0d4107c0$@noemax.com> <4FC880A7.9070007@250bpm.com> <001001cd4000$fe2c82c0$fa858840$@noemax.com> <4FCCAE6B.1010306@250bpm.com> <002d01cd4262$747957b0$5d6c0710$@noemax.com> <20120607022312.GA26406@jl-vm1.vm.bytemark.co.uk> <000e01cd449d$1c0ed220$542c7660$@noemax.com> <000401cd4566$d5f6bb70$81e43250$@noemax.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] Flow control quota 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, 13 Jun 2012 09:29:35 -0000 On 13/06/12 08:50, Takeshi Yoshino wrote: > It's also an option that we give up frame-level extensions other than mux. That makes sense IMO. Fragmentation is an integral part of multiplexing. Using it for other purposes is just asking for trouble. Martin From tyoshino@google.com Wed Jun 13 03:18:55 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 D91D821F8475 for ; Wed, 13 Jun 2012 03:18:55 -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=[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 QYVP3t9ZQCE6 for ; Wed, 13 Jun 2012 03:18:55 -0700 (PDT) Received: from mail-gh0-f172.google.com (mail-gh0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 368B121F846F for ; Wed, 13 Jun 2012 03:18:55 -0700 (PDT) Received: by ghbg16 with SMTP id g16so270364ghb.31 for ; Wed, 13 Jun 2012 03:18:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=cNRzxlpTzDnJqGL7OcsPbb9fezwokZx+tpjwY6H2DOg=; b=pxj29zgmD6YusLPOCuxdZVMa3+yfyKxbOl01X7i3E7X3vuT6aqxFmQLEjitVOxzc0U oJiJ1oAESP8cceZhrHxKKF7CYO0k9RmgE7xkQ839MTSq6V3B5rDBpeOpDFAN2zizlAj1 mDfTRaf20UwxFUTiFDi0KHRjLpz0PJOQpr86lfK+m3R8tE8/S+W8iW6xbKNfEQ7FgaL9 /7V7Y5khap9FSZ+TiOQ5kHd7jHwRL3+Bu/mOUcctRIdSREbHRFPfN3Z1nRR83rRIugb6 Z1d3Zdeq3yTY4Nkh0j6JLzPQrJn5vDroQFmOJTuHWPvnKB78vuubGJOh2y38N8m5oPu/ oBmA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=cNRzxlpTzDnJqGL7OcsPbb9fezwokZx+tpjwY6H2DOg=; b=Jdn+VhFFHIFGbD06CtpSbbkPaV6ztdNfRBax7uLjVK2VpXDngwcHoRjIaTDruKdWXO Wz7ECvX4HZvw5QPbP4Nj0h42qd4OVcyEC2gCcRt5meAsc8OBCGau+G0zfgrc+8283IoW SvWXs8ppS17ik8ofdMYym70Fkg1QyO2PTrnYL8ymBNRB6xUbE4l3YKC7xqHJ9v9Jy3QD WBvPRLOqLMRTp5/JFeoGzyaa/Q2bJsi2mOITsNFCmJDD49OvFoT9WSu5C7VKb/E9sEVh l8m/MrKmp/rRy3kKKzS7/JIl407z0a6I5Kh0rAJgBfojr+qOTPXZv53s+M8hAHzrbGCI m6pA== Received: by 10.50.160.202 with SMTP id xm10mr10108058igb.10.1339582734485; Wed, 13 Jun 2012 03:18:54 -0700 (PDT) Received: by 10.50.160.202 with SMTP id xm10mr10108050igb.10.1339582734335; Wed, 13 Jun 2012 03:18:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.66.7 with HTTP; Wed, 13 Jun 2012 03:18:33 -0700 (PDT) In-Reply-To: <20120607034440.GD26406@jl-vm1.vm.bytemark.co.uk> References: <002f01cd3cc4$4791b380$d6b51a80$@noemax.com> <20120607034440.GD26406@jl-vm1.vm.bytemark.co.uk> From: Takeshi Yoshino Date: Wed, 13 Jun 2012 19:18:33 +0900 Message-ID: To: Jamie Lokier Content-Type: multipart/alternative; boundary=14dae9340eb706ff8b04c257e9d7 X-System-Of-Record: true X-Gm-Message-State: ALoCoQmUe2gNrPL9une7aSaoAiphnDyEOfJwd80Eq4CyhIbiWy+UG/T+OwiKWHJ4Aw1w1HTgfzqMhrBbyTXG/wM4V4eDDSsBC6LJUPVWtkGyMNH9O7pbtiCqOofKmRVM1z+FHxyRfI65 Cc: hybi@ietf.org Subject: Re: [hybi] Multiplexing: Pre-AddChannelResponse quota 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, 13 Jun 2012 10:18:56 -0000 --14dae9340eb706ff8b04c257e9d7 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Thu, Jun 7, 2012 at 12:44 PM, Jamie Lokier wrote: > Arman Djusupov wrote: > > > > Resending would be required when the allocation of a logical channel > > has failed on the server or the intermediary due to any kind of mux > > related error. For example: =93Maximum number of logical channels pe= r > > physical connection has been reached =93 or =93Intermediary cannot r= each > > the destination endpoint=94. The current draft requires that if an > > AddChannelResponse is received with a failed flag, the client attemp= ts > > to open a new physical connection. Since the browser must keep the m= ux > > extension transparent it cannot let the JS application handle the > > recovery from mux related errors. > > If there is a max_simultaneous_handshakes - why not recast that as > "initial new-channels window" - meaning a flow control grant, which is > updated by further grants from the server. (Very similar to the flow > control per channel). > Good idea. I'll take it. Specifying the amount used in the request would seem to > enforce that delay, which is unnecessary in principle. > Sorry, why? --14dae9340eb706ff8b04c257e9d7 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
On Thu, Jun 7, 2012 at 12:44 PM, Jamie Lokier <jamie@shareable.org> wrote:
Arman Djusupov wrote:
>
> =A0 =A0Resending would be required when the allocation of a logical ch= annel
> =A0 =A0has failed on the server or the intermediary due to any kind of= mux
> =A0 =A0related error. For example: =93Maximum number of logical channe= ls per
> =A0 =A0physical connection has been reached =93 or =93Intermediary can= not reach
> =A0 =A0the destination endpoint=94. The current draft requires that if= an
> =A0 =A0AddChannelResponse is received with a failed flag, the client a= ttempts
> =A0 =A0to open a new physical connection. Since the browser must keep = the mux
> =A0 =A0extension transparent it cannot let the JS application handle t= he
> =A0 =A0recovery from mux related errors.

If there is a max_simultaneous_handshakes - why not recast that as "initial new-channels window" - meaning a flow control grant, whi= ch is
updated by further grants from the server. =A0(Very similar to the flow
control per channel).

Good idea. I'= ll take it.

Specifying t= he amount used in the request would seem to
enforce that delay, which is unnecessary in principle.

Sorry, why?

--14dae9340eb706ff8b04c257e9d7-- From tyoshino@google.com Wed Jun 13 03:37:39 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 E667321F856C for ; Wed, 13 Jun 2012 03:37:39 -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=[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 wgkQoKO3E3Ie for ; Wed, 13 Jun 2012 03:37:39 -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 66B1421F8564 for ; Wed, 13 Jun 2012 03:37:39 -0700 (PDT) Received: by yenq13 with SMTP id q13so399185yen.31 for ; Wed, 13 Jun 2012 03:37:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=LALBIx9ARWpG5HXX3FtfG/QCbxqQKoMDay2nhmu+tS4=; b=SFkD9EEoUW5bRBFia66aqd9Bj82KqOoem8p2imKDRqF+JcJGF/eTV19mzTS2K8h2J8 1fWZdllvjzTgVoYKY2XKKy6nyTq9tX5kkgDlgywpQrYHIkfEyTACpLaaaWfwc6jFewCW c9ObXw5zrPcMuig7LIX+1W/eHgmfdshaASbcF25n9Q43hlnNtkmoxvainjhNZUhvMiC2 mhU8wKA231ZirkF8iH2ZT2ofyJuE24HecXR1fbL2tTj4vfNVBnMCHbATKwj/iYIiWO6S yrik2ulelwAkM+Itk1WVXgc5npPdwuG1J8hzpEWqlAQofITaShQ7UBNXOWJxILtZ9Ibc lPJg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=LALBIx9ARWpG5HXX3FtfG/QCbxqQKoMDay2nhmu+tS4=; b=YwLviOF/W5ncnp8Svb6yCZTYfvP6K70eof8qaGKFiJw9HakhrOWQMZR9QeF4bBz+5L S/nQ+aF/EixeiGLBcmdzuZLyg6ZB/fM2zclR+5iqrNcgReapBsMTdcdoVfbnBDWdcTGu wxnk6hLXaduyxHHrFi6FBxVaC7ipTeTU3cZtHeNK6VH1JREVAe2bX0sji4s+cJgWYMMo HqKdQNLHBiXO56fChOuR/Dxa6+sLKTv6nFsEkIU9gX02HaYl84RPJey8SgR95Cvinulk aOG9x9toor46O2WCErq3wo6nlNZSeXwcL3ybC9axyU6/bmZpueVy4+7ihX6Xi/viMYWI WgEw== Received: by 10.50.222.162 with SMTP id qn2mr2264212igc.46.1339583858774; Wed, 13 Jun 2012 03:37:38 -0700 (PDT) Received: by 10.50.222.162 with SMTP id qn2mr2264208igc.46.1339583858616; Wed, 13 Jun 2012 03:37:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.66.7 with HTTP; Wed, 13 Jun 2012 03:37:17 -0700 (PDT) In-Reply-To: <001001cd44a7$17c0a220$4741e660$@noemax.com> References: <002f01cd3cc4$4791b380$d6b51a80$@noemax.com> <20120607034440.GD26406@jl-vm1.vm.bytemark.co.uk> <001001cd44a7$17c0a220$4741e660$@noemax.com> From: Takeshi Yoshino Date: Wed, 13 Jun 2012 19:37:17 +0900 Message-ID: To: Arman Djusupov Content-Type: multipart/alternative; boundary=14dae9340fbf0a28db04c2582ce9 X-System-Of-Record: true X-Gm-Message-State: ALoCoQksEL+QfOzr0MutUjaK9Sji990ErQjVEUNtSJuK0Zf0oDobVjZtglB6InASA99LeNND4yAFNh7k0rX/lQHa6e8Ano/5DHk6SNuZJ4C3/OByxLTxQo2VkyKS2jOTkPDJxbeHAc6j Cc: hybi@ietf.org Subject: Re: [hybi] Multiplexing: Pre-AddChannelResponse quota 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, 13 Jun 2012 10:37:40 -0000 --14dae9340fbf0a28db04c2582ce9 Content-Type: text/plain; charset=ISO-8859-1 Adopting both common and channel-wise pre-handshake quota sounds too much. I slightly prefer to take only one of them. I was wondering if the risk of head-of-line blocking on pre-handshake quota is significant or not. That's why I proposed two-parameter method in the first mail in this thread rather than common pre-handshake quota. Any other opinions? --14dae9340fbf0a28db04c2582ce9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Adopting both common and channel-wise pre-handshake quota sounds too much. = I slightly prefer to take only one of them.

I was wondering if the risk of head-of-line blocking = on pre-handshake quota is significant or not. That's why I proposed two= -parameter method in the first mail in this thread rather than common pre-h= andshake quota.

Any o= ther opinions?

--14dae9340fbf0a28db04c2582ce9-- From arman@noemax.com Wed Jun 13 05:17:19 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 3CDB321F863B for ; Wed, 13 Jun 2012 05:17:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 F8+4uswzyr1b for ; Wed, 13 Jun 2012 05:17:18 -0700 (PDT) Received: from mail.noemax.com (mail.noemax.com [64.34.201.8]) by ietfa.amsl.com (Postfix) with ESMTP id 52EA521F85D0 for ; Wed, 13 Jun 2012 05:17:18 -0700 (PDT) DKIM-Signature: a=rsa-sha1; t=1339589832; x=1340194632; s=m1024; d=noemax.com; c=relaxed/relaxed; v=1; bh=WKnzoV4sWNhSqU8G3oYmPaIWLKc=; h=From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding:In-Reply-To:References; b=5WT8fISg9kNzMP7MA0WoNj5pS2T/1EblIYrVQBIvvB3pCwp/hI8W477sl2DKTOudoyQjJZ/ZzTS9vaZPhmJeCvt8lJIdYcoixmY/cYnv5ZKXli5CokiiqDPM4pGQLGBNvDNiVtV+1OX6qg9Yrd0G9VL30IaJjpOAxsTfp3ZhCsE= Received: from mail.noemax.com by mail.noemax.com (IceWarp 10.4.1) with ASMTP (SSL) id XSE77311; Wed, 13 Jun 2012 15:17:11 +0300 From: "Arman Djusupov" To: "'Martin Sustrik'" , "'Takeshi Yoshino'" References: <001a01cd3e69$4a221c10$de665430$@noemax.com> <4FC732DC.3000308@250bpm.com> <000e01cd3f1c$af15ad40$0d4107c0$@noemax.com> <4FC880A7.9070007@250bpm.com> <001001cd4000$fe2c82c0$fa858840$@noemax.com> <4FCCAE6B.1010306@250bpm.com> <002d01cd4262$747957b0$5d6c0710$@noemax.com> <20120607022312.GA26406@jl-vm1.vm.bytemark.co.uk> <000e01cd449d$1c0ed220$542c7660$@noemax.com> <000401cd4566$d5f6bb70$81e43250$@noemax.com> <4FD85D7C.3000902@250bpm.com> In-Reply-To: <4FD85D7C.3000902@250bpm.com> Date: Wed, 13 Jun 2012 15:17:01 +0300 Message-ID: <000c01cd495e$751e5cd0$5f5b1670$@noemax.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQDnHEYxNcL9Xb2UVJoRm1lbL/BkAQFoH3KRAV1ppa8CZ6BgXAIpbgj4AsMo47wDBdtyYwH7TrBAAdzt12oB94xqWAGEGWmHAlGfbXgB++MmyQHjTxijl+9gaoA= Content-Language: en-us Cc: hybi@ietf.org Subject: Re: [hybi] Flow control quota 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, 13 Jun 2012 12:17:19 -0000 We can resolve the problem with per-frame compression by aligning compression to the message boundary. But by doing so we dodge the problem with non fragmentable frames that might be produced by any future extension that is unknown to the intermediary. For example we may need a reliable streaming extension that numbers all the frames and adds the frame number in the extension data so that it can resume sending the message if the connection fails. Such an extension would not support fragmentation so it would set the RSV bit of each frame to prevent it from being fragmented by intermediaries. As long as the parent specification allows extensions to place their data at the beginning of the frame payload, this extension's data would not be recoverable if the frame is fragmented, so such an extensions would be incompatible with mux. It's ok if some extensions are not compatible with mux intermediaries, since the WebSocket specification allows intermediaries to refuse extensions that are not known to them. But ideally mux should be transparent to all extensions, so that mux intermediaries can be unobtrusively introduced at any point of the communication path without placing any restrictions on the extensions that may be used and the type of payload being exchanged. So I think we should take a bit more time to think on how we can resolve the problem with mux without changing per-frame compression. The second problem is that changing per-frame compression so that it is applied on the message boundaries would create an issue if it is applied after mux. Since after mux there are no message boundaries any more as message frames are intermixed, the compression would have to be applied on each frame separately. So effectively per-frame compression extensions would have two modes of operation, which would be very hard to define in a specification. It would practically make it a requirement that this per-frame compression extension be aware that mux is being used. IMO having such coupling between extensions would be a bad design. It's preferable that we define a clean/final solution to the problem, so that whatever extensions are in use in 2050, " good old mux" is still applicable. I'm trying to work out Jemie's suggestion to let mux be transparent to intermediaries but haven't figured out any cheap way of enveloping the frame fragment yet. With best -----Original Message----- From: Martin Sustrik [mailto:sustrik@250bpm.com] Sent: Wednesday, June 13, 2012 12:30 PM To: Takeshi Yoshino Cc: Arman Djusupov; hybi@ietf.org Subject: Re: [hybi] Flow control quota On 13/06/12 08:50, Takeshi Yoshino wrote: > It's also an option that we give up frame-level extensions other than mux. That makes sense IMO. Fragmentation is an integral part of multiplexing. Using it for other purposes is just asking for trouble. Martin From arman@noemax.com Wed Jun 13 05:36: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 0BC8F21F849B for ; Wed, 13 Jun 2012 05:36:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 dP4-IPSiMlOq for ; Wed, 13 Jun 2012 05:35:59 -0700 (PDT) Received: from mail.noemax.com (mail.noemax.com [64.34.201.8]) by ietfa.amsl.com (Postfix) with ESMTP id 83D9421F85E7 for ; Wed, 13 Jun 2012 05:35:59 -0700 (PDT) DKIM-Signature: a=rsa-sha1; t=1339590954; x=1340195754; s=m1024; d=noemax.com; c=relaxed/relaxed; v=1; bh=Ym8hWxsHnB69FEsDcbYZGjEVNH4=; h=From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:In-Reply-To:References; b=Iylor462LCDeZbl+9g4BsSA3E+pNRuBeD96Ig3Gnbsm8XFDT74IR46YNv5xlAE8S2hZhrIFNtnbcClPCx0H5mlwHb2MA1ReEx5Fh6EYLbGdcAQd2tTliJPEsOrlzU6HBdgy2Qkmf/sr/z8xX9mjuF4Utlx1vJq0+05GSiwZSq/0= Received: from mail.noemax.com by mail.noemax.com (IceWarp 10.4.1) with ASMTP (SSL) id XSW97652; Wed, 13 Jun 2012 15:35:52 +0300 From: "Arman Djusupov" To: "'Takeshi Yoshino'" References: <002f01cd3cc4$4791b380$d6b51a80$@noemax.com> <20120607034440.GD26406@jl-vm1.vm.bytemark.co.uk> <001001cd44a7$17c0a220$4741e660$@noemax.com> In-Reply-To: Date: Wed, 13 Jun 2012 15:35:41 +0300 Message-ID: <001101cd4961$112f99c0$338ecd40$@noemax.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0012_01CD497A.367DE330" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHbEEjWH8q2xL+U7IgUz4ieagM0MAIpCHL8APvLbp8ByjwYEAHOwXoRlqayOmA= Content-Language: en-us Cc: hybi@ietf.org Subject: Re: [hybi] Multiplexing: Pre-AddChannelResponse quota 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, 13 Jun 2012 12:36:02 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0012_01CD497A.367DE330 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Agree, I also came to this conclusion. It's better if there is simply a per-channel pre-handshake quota. The server should not send any "quota" value in its AddChannelResponse. It should be assumed to be always equal to the pre-handshake quota agreed. This solution would be fine with me. With best regards, Arman From: Takeshi Yoshino [mailto:tyoshino@google.com] Sent: Wednesday, June 13, 2012 1:37 PM To: Arman Djusupov Cc: Jamie Lokier; hybi@ietf.org Subject: Re: [hybi] Multiplexing: Pre-AddChannelResponse quota Adopting both common and channel-wise pre-handshake quota sounds too much. I slightly prefer to take only one of them. I was wondering if the risk of head-of-line blocking on pre-handshake quota is significant or not. That's why I proposed two-parameter method in the first mail in this thread rather than common pre-handshake quota. Any other opinions? ------=_NextPart_000_0012_01CD497A.367DE330 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Agree, I also came to this conclusion. It’s better if there is = simply a per-channel pre-handshake quota. The server should not send = any  “quota” value in its AddChannelResponse. It should = be assumed to be always equal to the pre-handshake quota = agreed.

 

This solution would be fine with me.

 

With best regards,

Arman

 

 

From:= = Takeshi Yoshino [mailto:tyoshino@google.com]
Sent: Wednesday, = June 13, 2012 1:37 PM
To: Arman Djusupov
Cc: Jamie = Lokier; hybi@ietf.org
Subject: Re: [hybi] Multiplexing: = Pre-AddChannelResponse quota

 

Adopting = both common and channel-wise pre-handshake quota sounds too much. I = slightly prefer to take only one of them.

I was = wondering if the risk of head-of-line blocking on pre-handshake quota is = significant or not. That's why I proposed two-parameter method in the = first mail in this thread rather than common pre-handshake = quota.

 

Any other opinions?

 

------=_NextPart_000_0012_01CD497A.367DE330-- From arman@noemax.com Thu Jun 14 01:55: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 2795221F8697 for ; Thu, 14 Jun 2012 01:55:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] 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 VU5dEofE9B7x for ; Thu, 14 Jun 2012 01:55:20 -0700 (PDT) Received: from mail.noemax.com (mail.noemax.com [64.34.201.8]) by ietfa.amsl.com (Postfix) with ESMTP id 9F59521F8698 for ; Thu, 14 Jun 2012 01:55:19 -0700 (PDT) DKIM-Signature: a=rsa-sha1; t=1339664110; x=1340268910; s=m1024; d=noemax.com; c=relaxed/relaxed; v=1; bh=uEO+OsnTUGQZl9i9O4ilD8n68xo=; h=From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding:In-Reply-To:References; b=XWELGv+qSyvJOisn/5EGKjD4ibeAyCtdRqdgMKu85gaR9aa1MMmnc5AT+yrm2QFuvkOb9g9+0CkQ0cNfWZHHJY9yLpuTeFq3Je/NNHUWWWxzLKC3w7Tqw7eT/x9o+zyGnFsf5wJtoZKT2kdzlfEIw7e2XOLJL7UYv+pJwnjPyqA= Received: from mail.noemax.com by mail.noemax.com (IceWarp 10.4.1) with ASMTP (SSL) id YOR39809; Thu, 14 Jun 2012 11:55:09 +0300 From: "Arman Djusupov" To: "'Jamie Lokier'" , "'Takeshi Yoshino'" References: <002f01cd3cc4$4791b380$d6b51a80$@noemax.com> <20120607034440.GD26406@jl-vm1.vm.bytemark.co.uk> <20120613175433.GC5812@jl-vm1.vm.bytemark.co.uk> In-Reply-To: <20120613175433.GC5812@jl-vm1.vm.bytemark.co.uk> Date: Thu, 14 Jun 2012 11:54:57 +0300 Message-ID: <000701cd4a0b$640f1c60$2c2d5520$@noemax.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHbEEjWH8q2xL+U7IgUz4ieagM0MAIpCHL8APvLbp8B3rSIHAH8ws5ulqXzKqA= Content-Language: en-us Cc: hybi@ietf.org Subject: Re: [hybi] Multiplexing: Pre-AddChannelResponse quota 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: Thu, 14 Jun 2012 08:55:22 -0000 We should not overestimate the difference between pessimistic and optimistic scenarios. The major difference is in the amount of quota they grant to the remote side. In the pessimistic case the receiver sends a small quota, assuming that it will be able to buffer all input in a worst case scenario. While in the optimistic the case receiver sends a larger quota based on the rate with which it was able to process incoming frames so far, not relying entirely on its buffering capacity. Both strategies might work fine and both might end up in failure. In the worst case scenario when the receiver runs out of buffers both should be ready to fall back to TCP flow control or to discard data. If the mux client can send data up to the pre-handshake quota after the AddChannelRequest without waiting for an AddChannelResponse, this would already minimize the roundtrip in case when the data that has to be sent is not larger than the pre-handshake quota. If this data is larger than the pre-handshake quota than a delay may happen (it depends on how fast the server is going to send the AddChannelResponse and the first FC frame). The same applies to an HTTP server that does not use any mux, the client would not be able to send a complete request if the server is not going to process or buffer it right way. Servers usually buffer inbound requests up to some limit and then wait for the working thread to pick up the request and process it, only then can the client send the remaining data. In case of HTTP such a quota is enforced by the TCP flow control, due to the server's refusal to buffer the complete request. HTTP also supports the Expect: 100-Continue header and 100-Continue response which practically constitute flow control. In other words it is fine to impose pre-handshake quota limits. In cases when this causes delays it is natural, such delays would happen with mux or without it. With best regards, Arman -----Original Message----- From: Jamie Lokier [mailto:jamie@shareable.org] Sent: Wednesday, June 13, 2012 8:55 PM To: Takeshi Yoshino Cc: Arman Djusupov; hybi@ietf.org Subject: Re: [hybi] Multiplexing: Pre-AddChannelResponse quota Takeshi Yoshino wrote: > On Thu, Jun 7, 2012 at 12:44 PM, Jamie Lokier <[1]jamie@shareable.org> > wrote: > > Arman Djusupov wrote: > > > > Resending would be required when the allocation of a logical > > channel has failed on the server or the intermediary due to > > any kind of mux related error. For example: Maximum number > > of logical channels per physical connection has been reached > > or Intermediary cannot reach the destination endpoint. The > > current draft requires that if an AddChannelResponse is > > received with a failed flag, the client attempts to open a > > new physical connection. Since the browser must keep the mux > > extension transparent it cannot let the JS application > > handle the recovery from mux related errors. > > If there is a max_simultaneous_handshakes - why not recast that as > "initial new-channels window" - meaning a flow control grant, > which is updated by further grants from the server. (Very > similar to the flow control per channel). > > Good idea. I'll take it. Excellent :-) The idea isn't entirely random, it's prompted by some general principles of flow control which apply in a lot of situations; see my "some thoughts" further down. > Specifying the amount used in the request would seem to > enforce that delay, which is unnecessary in principle. The original paragraph said: >> Anyway, the client shouldn't have to pause/delay sending data after >> AddChannelRequest, until the response, if there is sufficient quota >> to keep sending. Specifying the amount used in the request would >> seem to enforce that delay, which is unnecessary in principle. Consider this scenario: This is WebSocket, so it's quite likely client and server application processes are generating a continuous flow of messages in each direction, with a wide variety of timings. In all cases we would like to minimise latency, and with mux we also want Client process (C) generates initial data stream. The first bytes available from the client process are included in the initial channel request. Server process (S) can begin processing those initial bytes, and generates a stream of response bytes. Those will follow immediately after the channel response. Client process (C) is still generating data 0.1 second later, 0.2, 0.3... But round-trip time is 2 seconds. If the client is allowed to send initial data with AddChannelRequest, but then not allowed to send more data until it receives the AddChannelResponse, there is a pause in the flow: data produced at 0.1, 0.2, 0.3 seconds cannot be sent until 2 seconds pass, cannot be processed by the server etc. This is the unnecessary delay. Client should be able to send more data up to the presumed initial-channel data window, in packets after the AddChannelRequest. This also means client must be able to choose the channel identifier (for sending at least). If those are little request messages over WebSocket, then it will be *4* seconds before they get responses, due to doubling the round trip. (On mobile networks, the delays are often larger.) This additional overhead is not present without the Mux protocol, or to applications doing their own app-mux instead. So the Mux adds overheads on top of non-Mux, and may even accumulate multiple such delays per-Mux/Demux hop (multiple proxies), which is quite bad. Since it's unnecessary, it shouldn't do it. There is no practical complexity to implementations allowing data after the request as opposed to just with the request itself. The protocol is possibly simpler that way: The request doesn't need to handle a data payload. All initial data can follow in their own messages. Some thoughts on the subject of flow control and channel setup: - Receive without blocking other flows (channels) is a semantic requirement, not just a nicety. Otherwise the flows don't have the same behaviour as separate TCP connections. Applications (including event-driven scripts) that use separate connections, expect them to behave quite independently, meaning data on one can't permanently block the flow of data on another. If Mux connections aren't that independent, supposedly independent operations can get in a tangle waiting on messages from each other. (Even in a browser app, with just one server). (I wrote out more detail but it went on a bit long.) It is horrible to debug when that happens, it's one of those "nearly always doesn't happen, spend hours trying to understand why the app is broke" things, and we should never inflict it on anyone. It's just a bad model, and unnecessary. But it's worse if Mux is a hidden optimisation, in the browser and/or intermediaries, as it changes the semantics. Going from no-deadlock to deadlock possible is a change of semantics. That is the most important reason for pessimistic flow control: It is necessary for Mux to have the same semantics as non-Mux, before it can be safely deployed as a hidden transport optimisation. (Same applies to mux in SPDY, HTTP/2 etc.) (The various proposed standards could do with more explanation of why channel flow control is so important, and why it must use the patterns it uses to get independent flow semantics.) - The basic method is to never block TCP at the receiver while you have more than 1 flow muxed over it. Blocking TCP is fine when you have only 1 flow. But new channel setup requests are, logically, another flow, and so are control messages (such as clean shutdown). So the 1 flow case doesn't happen, except during initial handshake. Assuming all that: - Pessimistic flow control, aka. grants or promises to receive without blocking other channels. This keeps the complexity low at the sender. The receiver is responsible for allocating its memory and managing fairness. The principle applies just as well to connection setup counts, and initial channel data, as to regular channel data. - Optimistic flow control (commands to allow sending more than the receiver can accept), mean the sender may need to abort and re-send (or flows will become deadlocked). These are more complex for everyone, but in some circumstances provide on-average less latency (and sometimes the other way). But think about it: TCP doesn't do this, and it's fine without it. (It uses an exponentially rising method of handing out more window as long as there is no congestion.) So is this ever worth the complication? I don't know, but I would suggest anything like this be explored as an experimental extension, on top of the basic pessimistic methods. - "Xon/xoff" start-stop style flow control is a disaster: the receiver cannot guarantee to store all that it receives before the stop token reaches the sender, so TCP will block the flow instead and there's no way forward until the receiver gains more memory. Which it won't if it's deadlocked. This is a form of optimistic flow control. - Start-stop and optimistic need pessimistic flow control anyway!! Otherwise, if TCP is blocked due to over-sending what the receiver cannot buffer, there's no way "stop" or "re-send later" messages can get through in that direction. Think about it. - Summing up: You *have* to have pessimistic flow control tokens at some stage. You can build other things on top, but there is no avoiding this if you want the protocol to be unable to get stuck. (I'm fairly confident of this but would love to be proven wrong.) - Whoever is initiating a new channel should select the channel id for binding data blocks together, and be allowed to send more data immediately after the initiating request (subject to normal flow control). This effectively makes the channel exist immediately, so the initiator can send data as as it generates it. Otherwise, the initiator can send an initial "pulse" of data, followed by a round-trip delay until it can send more, which may not match the pattern of data generation, and causes mux to add latency, sometimes accumulating per-hop, in places where it isn't necessary. Example: Without the delay, it is possible to send HTTP-style requests and responses, creating a new channel for each request, as efficient as pipelining with independent response orders, with all the benefits of flow control etc. With the round-trip delay, this is not an efficient pattern, and the application will likely devise its own request muxing protocol over a single channel, sometimes accidentally reproducing some of the deadlock/flow control scenarious discussed above. - When assigning new channels, it's useful to have a data window known in advance (or negotiated) for new channels. It could be shared among all new channels or per-channel immediately; does not matter. Although a protocol where channels are setup first seems simpler, it does not actually save any memory at the receiver (which needs to have dedicated memory per-channel for the control structures anyway), nor make it any simpler. - Finally, whether to use pessimistic flow control for channel requests, or allow them to be rejected for resource reasons and tell the sender to try again later, or on another TCP connection. The discussion above about pessimistic vs. optimistic applies to these as well. Just like data, channels use memory and their setup has similar flow control issues. So the same flow control mechanisms can apply to channel setup allowances. That's the "initial new-channels window" idea. However, here there's a stronger case for at least evaluating optimistic with retry. Think about the way a web server regulates the load from new TCP connections, with an unknown number of clients: It simply ignores new TCP SYN packets, when there are too many connections. Clients retry, and back off exponentially, thus regulating the load over a considerable range (it's not perfect). This works because clients back off exponentially, and servers use the minimum of resources for denied requests (i.e. ignore them). With pessimistic flow control of new channels, an initiator will wait until it gets a message saying it can use another one. While everything is running smoothly, that's a good balancing of resources. But if there's a load spike, and at the same time TCP stalls at a series of retransmits due to congestion, after the load spike the message saying it's ok to use more channels may be delayed for a long time, such as 30s, because of the TCP stall waiting for the next retransmit. In that situation, a client may find making a new TCP connections and start Mux over it can get a new channel more quickly. I don't know if, in that situation, it is better to allow optimistic channel setup requests on the existing TCP connection instead of a new TCP, or if there is no point because a stalled TCP would delay the request anyway. As with data flow control, I would suggest making the optimistic variation (setup requests with refusal and retry) an experimental extension, and the pessimistic variation the basic standard. Experiments may show if the optimistic extension is net positive or negative at high loads; it's not obvious to me which. All the best, -- Jamie From tyoshino@google.com Thu Jun 14 01:56:08 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 8AB4F21F8692 for ; Thu, 14 Jun 2012 01:56:08 -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 MqbAOTjMmj9R for ; Thu, 14 Jun 2012 01:56:08 -0700 (PDT) Received: from mail-gh0-f172.google.com (mail-gh0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9B1EC21F8697 for ; Thu, 14 Jun 2012 01:56:07 -0700 (PDT) Received: by ghbg16 with SMTP id g16so1270577ghb.31 for ; Thu, 14 Jun 2012 01:56:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=TEBndd0Y4lnrcCnQ8WKd56jNr+P5lwRH7373IlU3SIQ=; b=QsCrT+6H6dJS7o2ek9W/Z34hKs2GZVK8FQUFtES8CR3IaC+Fa5eNe1VL0dQrd8ASEL +gM6TYZISgeyK9QLTPQTvq08mIoJombkopvoyAMsonGZ+6uo8jFuT4LdJgSVZLTgCmrh k5LWhBeM3wfUtYN6HH9KOahdqB8oO++AYL7DiTETn3TBI8oEAX4C4i5HSlzowgpCzV1x Bo+zNUDYDYqKnqeXfEcPWC0EJmKRzDsauhkV5G8y27rogC40LIRCOy65WE8ZGNWWiqKH xQ6L8F6/0LkEGllAQkVALMyVftIgY7GpUqlWZWtMZjaMFhOwWmEvpLnokO37FTCriKcr 6vjw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=TEBndd0Y4lnrcCnQ8WKd56jNr+P5lwRH7373IlU3SIQ=; b=lD3YjVJR4KfQqpyXrkvEWOz0aLmjMEq192b94Pzhd+PVAtz+S8jtqqfrINH1TZggAG 1voRlEW1SRvlvu+L+j+s6e91lhOAJBHhtoeiO2DvGce2y/7pIjTnqRIv5SGsU2EDXEb1 tPg4XxMkYiUlFi/CW/veG/+QYodCjw0H9PI6ARqu1B/tuscyOFhDdjbb3aeS1Q4vum1L Hhaz6PI+vWTLdeH9hSUaCW9qtQMpFpbTfyclJilC2z7CENqtIdrVOqQ8HJuEIhVHJO3F Anv7Sur0H/aT/ZnnixW3XJqj6TtfiJoNg/MjFSJ8p4HkqFHCBW4+mz+nDwbrLjVf8DB4 R7Xw== Received: by 10.50.156.194 with SMTP id wg2mr330929igb.46.1339664166793; Thu, 14 Jun 2012 01:56:06 -0700 (PDT) Received: by 10.50.156.194 with SMTP id wg2mr330923igb.46.1339664166683; Thu, 14 Jun 2012 01:56:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.66.7 with HTTP; Thu, 14 Jun 2012 01:55:46 -0700 (PDT) In-Reply-To: References: <002f01cd3cc4$4791b380$d6b51a80$@noemax.com> <20120607034440.GD26406@jl-vm1.vm.bytemark.co.uk> From: Takeshi Yoshino Date: Thu, 14 Jun 2012 17:55:46 +0900 Message-ID: To: Jamie Lokier Content-Type: multipart/alternative; boundary=e89a8f3bafd5c603f304c26ade4d X-System-Of-Record: true X-Gm-Message-State: ALoCoQndwQFW7vCEo7wo2lWS0HYcr0xz9jgmH1T3pLQUbhjaj4uX1BmtvfHGa+bFA4Mj90/hHpjvElApBbaKh4zfkGa07N1mzvFsreWac4puO+TaVpp3tNIEc+OSqK/vjb6fpXmRA+2f Cc: hybi@ietf.org Subject: Re: [hybi] Multiplexing: Pre-AddChannelResponse quota 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: Thu, 14 Jun 2012 08:56:08 -0000 --e89a8f3bafd5c603f304c26ade4d Content-Type: text/plain; charset=ISO-8859-1 On Wed, Jun 13, 2012 at 7:18 PM, Takeshi Yoshino wrote: > On Thu, Jun 7, 2012 at 12:44 PM, Jamie Lokier wrote: > >> If there is a max_simultaneous_handshakes - why not recast that as >> "initial new-channels window" - meaning a flow control grant, which is >> updated by further grants from the server. (Very similar to the flow >> control per channel). >> > > Good idea. I'll take it. > I'm designing algorithm to realize this. My current idea is as follows. Just a first strawman. It's very complicated. - New channel window is a set of slots for new channel creation attempts -- Each slot corresponds to one future/in-flight AddChannelRequest -- Each slot (Slot_k) has pre-handshake quota (PQ_k) -- When received, say, NewChannelQuota block, add a new slot. The new slot has pre-handshake quota of 0 - When received, say, PreHandshakeQuota block, split it up and add to slots so that PQ_k are leveled (older ones first) among all slots - To issue an AddChannelRequest with channel ID X, the client picks oldest unused slot (Slot_i) for it - The client MAY send pre-handshake data for the channel X up to PQ_i - When received the corresponding AddChannelResponse, -- send quota for X is set to (PQ_i) - (total pre-handshake data sent) + (initial send quota assigned by the AddChannelResponse) -- Slot_i is removed from the new channel window Goals are: - make it able to increase the pre-handshake send quota for already allocated slots - give pre-handshake quota equally to all active slots - carry over remaining pre-handshake quota into post-handshake quota - deterministic, not affected by timing --e89a8f3bafd5c603f304c26ade4d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed, Jun 13, 2012 at 7:18 PM, Takeshi Yoshino <tyoshino@g= oogle.com> wrote:
On Thu, Jun 7, 2012 at 12:44 PM, Jamie Lokier <jamie@shareable.org&= gt; wrote:
If there is a max_simultaneous_handshakes - why not recast that as "initial new-channels window" - meaning a flow control grant, whi= ch is
updated by further grants from the server. =A0(Very similar to the flow
control per channel).

Good idea. = I'll take it.

I'm desig= ning algorithm to realize this. My current idea is as follows. Just a first= strawman. It's very complicated.

- New channel window is a set of slots for new channel = creation attempts
-- Each slot corresponds to one future/in-fligh= t AddChannelRequest
-- Each slot (Slot_k) has pre-handshake quota= (PQ_k)
-- When received, say, NewChannelQuota block, add a new slot.=A0The ne= w slot has pre-handshake quota of 0
- When received, say, PreHand= shakeQuota block, split it up and add to slots so that PQ_k are leveled (ol= der ones first) among all slots
- To issue an AddChannelRequest with channel ID X, the client picks ol= dest unused slot (Slot_i) for it
- The client MAY send pre-handsh= ake data for the channel X up to PQ_i
- When received the corresp= onding AddChannelResponse,
-- send quota for X is set to (PQ_i) - (total pre-handshake data sent)= + (initial send quota assigned by the AddChannelResponse)
-- Slo= t_i is removed from the new channel window

Goals a= re:

- make it able to increase the pre-handshake send quota= for already allocated slots
- give pre-handshake quota equally t= o all active slots
- carry over remaining pre-handshake quota int= o post-handshake quota
- deterministic, not affected by timing

--e89a8f3bafd5c603f304c26ade4d-- From arman@noemax.com Thu Jun 14 02:59: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 88E9F21F86A4 for ; Thu, 14 Jun 2012 02:59:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 JxD-c6Dh8hKh for ; Thu, 14 Jun 2012 02:59:17 -0700 (PDT) Received: from mail.noemax.com (mail.noemax.com [64.34.201.8]) by ietfa.amsl.com (Postfix) with ESMTP id E3FBF21F86A1 for ; Thu, 14 Jun 2012 02:59:16 -0700 (PDT) DKIM-Signature: a=rsa-sha1; t=1339667949; x=1340272749; s=m1024; d=noemax.com; c=relaxed/relaxed; v=1; bh=2swRttiIR1ewIbMgPAJpcydLzgo=; h=From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:In-Reply-To:References; b=ulWkJKkSUOy+agA7jLGPLIc3ySGePBYC+ZlDGHzN7nB+O9zx3Ons1hNCG4wn5rXAMh6FdvBoCbU/CJiOAafKKVLubp/BtOQ5swjsPNthtlLbIjYJ7o9Vg3Jh6213nyU7z81jcTp+3A05IfvAMCDer0uWN55+ym3yNUvd94IC18E= Received: from mail.noemax.com by mail.noemax.com (IceWarp 10.4.1) with ASMTP (SSL) id YPV89807; Thu, 14 Jun 2012 12:59:07 +0300 From: "Arman Djusupov" To: "'Takeshi Yoshino'" , "'Jamie Lokier'" References: <002f01cd3cc4$4791b380$d6b51a80$@noemax.com> <20120607034440.GD26406@jl-vm1.vm.bytemark.co.uk> In-Reply-To: Date: Thu, 14 Jun 2012 12:58:54 +0300 Message-ID: <002001cd4a14$53eb66f0$fbc234d0$@noemax.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0021_01CD4A2D.793AE8E0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHbEEjWH8q2xL+U7IgUz4ieagM0MAIpCHL8APvLbp8B3rSIHAHfCnvqlqbynPA= Content-Language: en-us Cc: hybi@ietf.org Subject: Re: [hybi] Multiplexing: Pre-AddChannelResponse quota 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: Thu, 14 Jun 2012 09:59:18 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0021_01CD4A2D.793AE8E0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit -- send quota for X is set to (PQ_i) - (total pre-handshake data sent) + (initial send quota assigned by the AddChannelResponse) The quota header in AddChannelResponse is not needed, the server can supplement the client quota using normal flow control frames. This would simplify it a bit. If the server needs to grant additional quota right after the AddChannelResponse, it can send an FC block in the same frame with the AddChannelResponse. The FC block format is more efficient than the literal format of the AddChannelResponse header. A more simple description would be that the client simply sets its quota to the PQ-I value and continues using it until it gets an FC block from the server that would increment it. The server keeps track of the number of active slots on the client side so it knows the current PQ-I value and also starts keeping track of the client quota based on the PQ-I value. - When received, say, PreHandshakeQuota block, split it up and add to slots so that PQ_k are leveled (older ones first) among all slots Why to split up the quota? This leave room for strange cases when the quota is not divisible by the number of channels. Why not simply set or add a value to each already allocated slot? With best regards, Arman From: Takeshi Yoshino [mailto:tyoshino@google.com] Sent: Thursday, June 14, 2012 11:56 AM To: Jamie Lokier Cc: Arman Djusupov; hybi@ietf.org Subject: Re: [hybi] Multiplexing: Pre-AddChannelResponse quota On Wed, Jun 13, 2012 at 7:18 PM, Takeshi Yoshino wrote: On Thu, Jun 7, 2012 at 12:44 PM, Jamie Lokier wrote: If there is a max_simultaneous_handshakes - why not recast that as "initial new-channels window" - meaning a flow control grant, which is updated by further grants from the server. (Very similar to the flow control per channel). Good idea. I'll take it. I'm designing algorithm to realize this. My current idea is as follows. Just a first strawman. It's very complicated. - New channel window is a set of slots for new channel creation attempts -- Each slot corresponds to one future/in-flight AddChannelRequest -- Each slot (Slot_k) has pre-handshake quota (PQ_k) -- When received, say, NewChannelQuota block, add a new slot. The new slot has pre-handshake quota of 0 - When received, say, PreHandshakeQuota block, split it up and add to slots so that PQ_k are leveled (older ones first) among all slots - To issue an AddChannelRequest with channel ID X, the client picks oldest unused slot (Slot_i) for it - The client MAY send pre-handshake data for the channel X up to PQ_i - When received the corresponding AddChannelResponse, -- send quota for X is set to (PQ_i) - (total pre-handshake data sent) + (initial send quota assigned by the AddChannelResponse) -- Slot_i is removed from the new channel window Goals are: - make it able to increase the pre-handshake send quota for already allocated slots - give pre-handshake quota equally to all active slots - carry over remaining pre-handshake quota into post-handshake quota - deterministic, not affected by timing ------=_NextPart_000_0021_01CD4A2D.793AE8E0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

-- send quota for X is set to = (PQ_i) - (total pre-handshake data sent) + (initial send quota assigned = by the AddChannelResponse)

 

The quota header in AddChannelResponse is not needed, the server can = supplement the client quota using normal flow control frames. This would = simplify it a bit. If the server needs to grant additional quota right = after the AddChannelResponse, it can send an FC block in the same frame = with the AddChannelResponse. The FC block format is more efficient than = the literal format of the AddChannelResponse = header.

 

A more simple description would be that the client simply sets its = quota to the PQ-I value and continues using it until it gets an FC block = from the server that would increment it. The server keeps track of the = number of active slots on the client side so it knows the current PQ-I = value and also starts keeping track of the client quota based on the = PQ-I value.

 

- When received, say, = PreHandshakeQuota block, split it up and add to slots so that PQ_k are = leveled (older ones first) among all slots

 

Why to split up the quota? This leave room for strange cases when the = quota is not divisible by the number of channels. Why not simply set or = add a value to each already allocated slot?

 

With best regards,

Arman

 

 

From:= = Takeshi Yoshino [mailto:tyoshino@google.com]
Sent: Thursday, = June 14, 2012 11:56 AM
To: Jamie Lokier
Cc: Arman = Djusupov; hybi@ietf.org
Subject: Re: [hybi] Multiplexing: = Pre-AddChannelResponse quota

 

On = Wed, Jun 13, 2012 at 7:18 PM, Takeshi Yoshino <tyoshino@google.com> = wrote:

On Thu, Jun 7, 2012 at 12:44 = PM, Jamie Lokier <jamie@shareable.org> = wrote:

If there is a = max_simultaneous_handshakes - why not recast that = as

"initial new-channels = window" - meaning a flow control grant, which is
updated by = further grants from the server.  (Very similar to the = flow
control per channel).

 

Good idea. I'll take = it.

 

I'm designing algorithm to = realize this. My current idea is as follows. Just a first strawman. It's = very complicated.

 

- New channel window is a set = of slots for new channel creation = attempts

-- Each slot corresponds to = one future/in-flight = AddChannelRequest

-- = Each slot (Slot_k) has pre-handshake quota = (PQ_k)

-- When received, say, = NewChannelQuota block, add a new slot. The new slot has = pre-handshake quota of 0

- = When received, say, PreHandshakeQuota block, split it up and add to = slots so that PQ_k are leveled (older ones first) among all = slots

- To issue an = AddChannelRequest with channel ID X, the client picks oldest unused slot = (Slot_i) for it

- The = client MAY send pre-handshake data for the channel X up to = PQ_i

- When received the = corresponding AddChannelResponse,

-- = send quota for X is set to (PQ_i) - (total pre-handshake data sent) + = (initial send quota assigned by the = AddChannelResponse)

-- = Slot_i is removed from the new channel = window

 

Goals = are:

 

- make it able to increase = the pre-handshake send quota for already allocated = slots

- give pre-handshake quota = equally to all active slots

- = carry over remaining pre-handshake quota into post-handshake = quota

- deterministic, not affected = by timing

 

------=_NextPart_000_0021_01CD4A2D.793AE8E0-- From julian.reschke@gmx.de Thu Jun 14 06:46:12 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 36BC421F86AF for ; Thu, 14 Jun 2012 06:46:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.479 X-Spam-Level: X-Spam-Status: No, score=-105.479 tagged_above=-999 required=5 tests=[AWL=-2.880, 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 r8rP7mleRXbS for ; Thu, 14 Jun 2012 06:46:11 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 1198C21F86AD for ; Thu, 14 Jun 2012 06:46:10 -0700 (PDT) Received: (qmail invoked by alias); 14 Jun 2012 13:46:09 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.140]) [217.91.35.233] by mail.gmx.net (mp038) with SMTP; 14 Jun 2012 15:46:09 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1/gRzIfNKLgc7r9YTUfh7RxGQwc9WEeX3uH07wTkE //4j8ZZD/PLR5s Message-ID: <4FD9EB1F.6020408@gmx.de> Date: Thu, 14 Jun 2012 15:46:07 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120604 Thunderbird/13.0 MIME-Version: 1.0 To: hybi@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Subject: [hybi] Opera 12 vs RFC 6455 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: Thu, 14 Jun 2012 13:46:12 -0000 Hi there, so does Opera 12 now support RFC 6455? Julian (couldn't quickly find anything substantive) From tobias.oberstein@tavendo.de Thu Jun 14 11:12:53 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 3B61C21F8628 for ; Thu, 14 Jun 2012 11:12:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 WV8LC1C71St1 for ; Thu, 14 Jun 2012 11:12:52 -0700 (PDT) Received: from EXHUB020-4.exch020.serverdata.net (exhub020-4.exch020.serverdata.net [206.225.164.31]) by ietfa.amsl.com (Postfix) with ESMTP id D298321F8559 for ; Thu, 14 Jun 2012 11:12:50 -0700 (PDT) Received: from EXVMBX020-12.exch020.serverdata.net ([169.254.3.81]) by EXHUB020-4.exch020.serverdata.net ([206.225.164.31]) with mapi; Thu, 14 Jun 2012 11:12:49 -0700 From: Tobias Oberstein To: Julian Reschke , "hybi@ietf.org" Date: Thu, 14 Jun 2012 11:12:47 -0700 Thread-Topic: [hybi] Opera 12 vs RFC 6455 Thread-Index: Ac1KNBNGfxIAgHlfSei4I79X9SNFpAAJLPjw Message-ID: <634914A010D0B943A035D226786325D4337803AAB0@EXVMBX020-12.exch020.serverdata.net> References: <4FD9EB1F.6020408@gmx.de> In-Reply-To: <4FD9EB1F.6020408@gmx.de> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE, en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [hybi] Opera 12 vs RFC 6455 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: Thu, 14 Jun 2012 18:12:53 -0000 > so does Opera 12 now support RFC 6455? No. Just tested: it's still on Hixie-76, which is .. irritating given that = Opera was always quite quick with implementing and close to Web standards. From tyoshino@google.com Thu Jun 14 20:19:10 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 BF1BF11E80B6 for ; Thu, 14 Jun 2012 20:19:10 -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=[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 yiXDT9KBnUl9 for ; Thu, 14 Jun 2012 20:19:10 -0700 (PDT) Received: from mail-gg0-f172.google.com (mail-gg0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0316611E8089 for ; Thu, 14 Jun 2012 20:19:09 -0700 (PDT) Received: by ggnc4 with SMTP id c4so2171830ggn.31 for ; Thu, 14 Jun 2012 20:19:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=BUuL+6T1klyF6EtZJ4pEcmWBUzKVw8mt6NNUkEk/ndE=; b=QANSrTG3C2euvEPrjPVJ0MLRcdriX3NSJDoNarcuAgkmk3x6BRWuJJTKkuPLlY0+6C E6vMl4rieurvazbOUxBtdb5L1yuQ/K5Hk/Pkb2MjfQzxksg8IC+W56lHQaz22DdB8Yt2 ZIzx1X2ScJkQE9V3jB8h5Ff8Ed/iXRVwEslRBzAiXd2vApx7pl9K9m3DniYjPmXCGqe/ 7NBL9SR09LAKe9yclqtH+6MfmE/Dh4Kai9rrASt4K+u+jlvcTaw3B1/1VxdtZo5bIjpL RvbFoonXusWH1jGrf8RYvDoWvAaG+3drt+E6JMjJnbWQkv0bZQK6lKWjn+DmQt6wMjdr 6dfw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=BUuL+6T1klyF6EtZJ4pEcmWBUzKVw8mt6NNUkEk/ndE=; b=TucOHRn+QjZgh6rlpMhZ2Z97MGwWqMdnP2RLkMbtDyb8xsjD1HV6XhxXOpSCkBwwzj R96dkSzRM7jJuwtO9Uua0iTpDc8ksSd05f++28gR6A48KNAu/Or+itLbEmr6AoMsvIrT wttwC7SGx1Oj/Tqhge6VOn7rwWquzTrAq/slkZVlKDpwvUO+hEZr6sipPnouXPQ/Qpr+ O0gIjn9NUXNtZKTBY0YbFVKtGP647DzBL01DGkuIaZNQZSBotX1kzTEB7HyxP5vz2eF6 bKk9Erd6DtToGShNpLvivX39+G5QRwIhMtelyZuSXCuwGQ21SgOvDFg5fFxZPXakNqvL XoAw== Received: by 10.50.179.74 with SMTP id de10mr165850igc.61.1339730349234; Thu, 14 Jun 2012 20:19:09 -0700 (PDT) Received: by 10.50.179.74 with SMTP id de10mr165838igc.61.1339730349126; Thu, 14 Jun 2012 20:19:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.66.7 with HTTP; Thu, 14 Jun 2012 20:18:48 -0700 (PDT) In-Reply-To: <002001cd4a14$53eb66f0$fbc234d0$@noemax.com> References: <002f01cd3cc4$4791b380$d6b51a80$@noemax.com> <20120607034440.GD26406@jl-vm1.vm.bytemark.co.uk> <002001cd4a14$53eb66f0$fbc234d0$@noemax.com> From: Takeshi Yoshino Date: Fri, 15 Jun 2012 12:18:48 +0900 Message-ID: To: Arman Djusupov Content-Type: multipart/alternative; boundary=14dae934041b8df5f204c27a47c5 X-System-Of-Record: true X-Gm-Message-State: ALoCoQk8rOJk4+ldffx/wJpvVy5I4eRummQw2oq7mM5ReI/kipXmU4RWdjepIkLe6J+v1Da6FE5xQB/cdcfHkn/3zmCQgHdhED3eV63sorNttJ1wn6/2aVdktnPmzMFGywjBgS0P/+TU Cc: hybi@ietf.org Subject: Re: [hybi] Multiplexing: Pre-AddChannelResponse quota 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, 15 Jun 2012 03:19:10 -0000 --14dae934041b8df5f204c27a47c5 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Jun 14, 2012 at 6:58 PM, Arman Djusupov wrote: > -- send quota for X is set to (PQ_i) - (total pre-handshake data sent) + > (initial send quota assigned by the AddChannelResponse)**** > > ** ** > > The quota header in AddChannelResponse is not needed, the server can > supplement the client quota using normal flow control frames. This would > simplify it a bit. If the server needs to grant additional quota right > after the AddChannelResponse, it can send an FC block in the same frame > with the AddChannelResponse. The FC block format is more efficient than the > literal format of the AddChannelResponse header. > OK > **** > > - When received, say, PreHandshakeQuota block, split it up and add to > slots so that PQ_k are leveled (older ones first) among all slots > > ** ** > > Why to split up the quota? This leave room for strange cases when the > quota is not divisible by the number of channels. Why not simply set or add > a value to each already allocated slot? > I tried to make it able to gradually decrease PQ_i for new slots when the server is overloaded. If PreHandshakeQuota adds the same value to each allocated slot, PQ_i for a new channel needs to be initialized to the same value as the other slots' on NewChannelQuota. Otherwise, PQ_i values are in-balanced between the new one and the others. Then, ... there's no way to decrease PQ_i. We may add a new channel with slightly smaller PQ_i to allow for suppression. This works, but one of its cons is that we cannot level PQ_i of allocated slots even when the server gets less loaded again because the PreHandshakeQuota keeps high slots high and low slots low. --14dae934041b8df5f204c27a47c5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Thu, Jun 14, 2012 at 6:58 PM, Arman Djusupov <arman@noemax.c= om> wrote:

-- send quota for X is set to (PQ_i) - (total pre-handshake data sent) += (initial send quota assigned by the AddChannelResponse)

=A0<= /p>

The quota header= in AddChannelResponse is not needed, the server can supplement the client = quota using normal flow control frames. This would simplify it a bit. If th= e server needs to grant additional quota right after the AddChannelResponse= , it can send an FC block in the same frame with the AddChannelResponse. Th= e FC block format is more efficient than the literal format of=A0the AddCha= nnelResponse header.


OK
=A0
<= p class=3D"MsoNormal">

= - When received, say, PreHands= hakeQuota block, split it up and add to slots so that PQ_k are leveled (old= er ones first) among all slots

=A0

Why to spli= t up the quota? This leave room for strange cases when the quota is not div= isible by the number of channels. Why not simply set or add a value to each= already allocated slot?


I tried to make it able to gradually= decrease PQ_i for new slots when the server is overloaded.

<= /div>
If PreHandshakeQuota adds the same value to each allocated slot, = PQ_i for a new channel needs to be initialized to the same value as the oth= er slots' on NewChannelQuota. Otherwise, PQ_i values are in-balanced be= tween the new one and the others. Then, ... there's no way to =A0decrea= se PQ_i.

We may add a new channel with slightly smaller PQ_i to = allow for suppression. This works, but one of its cons is that we cannot le= vel PQ_i of allocated slots even when the server gets less loaded again bec= ause the PreHandshakeQuota keeps high slots high and low slots low.
=A0
--14dae934041b8df5f204c27a47c5-- From arman@noemax.com Fri Jun 15 01:21:41 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 6B25021F844F for ; Fri, 15 Jun 2012 01:21:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 SncSD7qk1qXT for ; Fri, 15 Jun 2012 01:21:39 -0700 (PDT) Received: from mail.noemax.com (mail.noemax.com [64.34.201.8]) by ietfa.amsl.com (Postfix) with ESMTP id AB9F321F8449 for ; Fri, 15 Jun 2012 01:21:36 -0700 (PDT) DKIM-Signature: a=rsa-sha1; t=1339748501; x=1340353301; s=m1024; d=noemax.com; c=relaxed/relaxed; v=1; bh=8mevG7+sTlRewIgkJeb6HToM7jY=; h=From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:In-Reply-To:References; b=0v3+ZPGR8uCdTjNCX6s9pxNCLbfN0jAg1O1C+FX5nJQEQxkjyBfS/LAtbRDSoT5OQPEvuSFG1kjrEAVf2SGZSU8s2BecuiipZChnG3gxlHRQSryqi4qeI65hOWZPbtUUQ+HsdLPNuFXLak5UmEPo9i6cBTcLZfqwbbCdJNIGr9U= Received: from mail.noemax.com by mail.noemax.com (IceWarp 10.4.1) with ASMTP (SSL) id ZOK64239; Fri, 15 Jun 2012 11:21:39 +0300 From: "Arman Djusupov" To: "'Takeshi Yoshino'" References: <002f01cd3cc4$4791b380$d6b51a80$@noemax.com> <20120607034440.GD26406@jl-vm1.vm.bytemark.co.uk> <002001cd4a14$53eb66f0$fbc234d0$@noemax.com> In-Reply-To: Date: Fri, 15 Jun 2012 11:21:14 +0300 Message-ID: <001301cd4acf$d8c5cda0$8a5168e0$@noemax.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0014_01CD4AE8.FE1576A0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHbEEjWH8q2xL+U7IgUz4ieagM0MAIpCHL8APvLbp8B3rSIHAHfCnvqAiE9EN8B8r7HPJaHycvA Content-Language: en-us Cc: hybi@ietf.org Subject: Re: [hybi] Multiplexing: Pre-AddChannelResponse quota 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, 15 Jun 2012 08:21:41 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0014_01CD4AE8.FE1576A0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Since we go that far in flexibility why not just give the client a quota and let it distribute it in the channels any way the client likes. This way the client will be able to give a higher or lower priority to newly established channels. The client will need to state the amount of quota it assigned to a channel slot when sending an AddChannelRequest. So when receiving a PreHandshakeQuota the client does not level it between available slots, but uses a share of this quota later when creating a new channel. This would be a simplified common quota. With best regards, Arman From: Takeshi Yoshino [mailto:tyoshino@google.com] Sent: Friday, June 15, 2012 6:19 AM To: Arman Djusupov Cc: Jamie Lokier; hybi@ietf.org Subject: Re: [hybi] Multiplexing: Pre-AddChannelResponse quota On Thu, Jun 14, 2012 at 6:58 PM, Arman Djusupov wrote: -- send quota for X is set to (PQ_i) - (total pre-handshake data sent) + (initial send quota assigned by the AddChannelResponse) The quota header in AddChannelResponse is not needed, the server can supplement the client quota using normal flow control frames. This would simplify it a bit. If the server needs to grant additional quota right after the AddChannelResponse, it can send an FC block in the same frame with the AddChannelResponse. The FC block format is more efficient than the literal format of the AddChannelResponse header. OK - When received, say, PreHandshakeQuota block, split it up and add to slots so that PQ_k are leveled (older ones first) among all slots Why to split up the quota? This leave room for strange cases when the quota is not divisible by the number of channels. Why not simply set or add a value to each already allocated slot? I tried to make it able to gradually decrease PQ_i for new slots when the server is overloaded. If PreHandshakeQuota adds the same value to each allocated slot, PQ_i for a new channel needs to be initialized to the same value as the other slots' on NewChannelQuota. Otherwise, PQ_i values are in-balanced between the new one and the others. Then, ... there's no way to decrease PQ_i. We may add a new channel with slightly smaller PQ_i to allow for suppression. This works, but one of its cons is that we cannot level PQ_i of allocated slots even when the server gets less loaded again because the PreHandshakeQuota keeps high slots high and low slots low. ------=_NextPart_000_0014_01CD4AE8.FE1576A0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Since we go that far in flexibility why not just give the client a = quota and let it distribute it in the channels any way the client likes. = This way the client will be able to give a higher or lower priority to = newly established channels. The client will need to state = the amount of quota it assigned to a channel slot when sending an = AddChannelRequest. So when receiving a PreHandshakeQuota the client does = not level it between available slots, but uses a share of this quota = later when creating a new channel. This would be a simplified common = quota.

 

With best regards,

Arman

 

 

From:= = Takeshi Yoshino [mailto:tyoshino@google.com]
Sent: Friday, = June 15, 2012 6:19 AM
To: Arman Djusupov
Cc: Jamie = Lokier; hybi@ietf.org
Subject: Re: [hybi] Multiplexing: = Pre-AddChannelResponse quota

 

On = Thu, Jun 14, 2012 at 6:58 PM, Arman Djusupov <arman@noemax.com> = wrote:

-- send quota for X is set to = (PQ_i) - (total pre-handshake data sent) + (initial send quota assigned = by the AddChannelResponse)

 

The quota header in AddChannelResponse is not needed, the server can = supplement the client quota using normal flow control frames. This would = simplify it a bit. If the server needs to grant additional quota right = after the AddChannelResponse, it can send an FC block in the same frame = with the AddChannelResponse. The FC block format is more efficient than = the literal format of the AddChannelResponse = header.

 

OK

=

 

- When received, say, = PreHandshakeQuota block, split it up and add to slots so that PQ_k are = leveled (older ones first) among all slots

 

Why to split up the quota? This leave room for strange cases when the = quota is not divisible by the number of channels. Why not simply set or = add a value to each already allocated = slot?

 

I tried to make it able to = gradually decrease PQ_i for new slots when the server is = overloaded.

 

If PreHandshakeQuota adds the = same value to each allocated slot, PQ_i for a new channel needs to be = initialized to the same value as the other slots' on NewChannelQuota. = Otherwise, PQ_i values are in-balanced between the new one and the = others. Then, ... there's no way to  decrease = PQ_i.

 

We may add a new channel with = slightly smaller PQ_i to allow for suppression. This works, but one of = its cons is that we cannot level PQ_i of allocated slots even when the = server gets less loaded again because the PreHandshakeQuota keeps high = slots high and low slots low.

 

------=_NextPart_000_0014_01CD4AE8.FE1576A0-- From tyoshino@google.com Mon Jun 18 22:49:38 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 46FCD21F872D for ; Mon, 18 Jun 2012 22:49:38 -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=[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 0PdQI4Amhm85 for ; Mon, 18 Jun 2012 22:49:37 -0700 (PDT) Received: from mail-gg0-f172.google.com (mail-gg0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8723D21F872A for ; Mon, 18 Jun 2012 22:49:37 -0700 (PDT) Received: by ggnc4 with SMTP id c4so4776282ggn.31 for ; Mon, 18 Jun 2012 22:49:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=jSCKQ7kvX/loMCXycnzNb5TQGdYAG8kEmABQ1Wdgul0=; b=UfSVnepWLOj0+DR3794vmf5WQxyv2bQW7E8Fox+6ZBcwAneovj6F1OyibwuXyARAxQ yx/YrVDwzkTJgzUO+ZO8TSvzhi7PR7lQuC+UWjoeMukcAIVwXNY9RfL+W8D2If6dEMr6 l1uIHROfQ2N3Xrz2v6gth2o1KE1WlocaZDO2/Ncv11SPqUSRlxDmNGURA4i/P3qnP4Xs l1bZFYS98Dqjh6kRUebTuFsQB86t8Dw5N9eVtYFRyhGmuenrBfty8tLiXX4NUTktEzgP lZD8wuQhnJV0sVSB+BJjQW9hXCgjjdbbmJKGs8qH4Zsu8Rs3G0Oj8qjMXsAPWjYnUlG5 1wWg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=jSCKQ7kvX/loMCXycnzNb5TQGdYAG8kEmABQ1Wdgul0=; b=oaQeuiof0O1q3HlcY9JSmuFD7GMICSDtehxYXO85ONHpYADcibm7vOiGHVbD7FrZF2 r9b5v7gf7B+I08kn12WFEgEhz20Jw+8FjvhKAareAqgz997X5nwHTX/L/181LZgkMZuP qmz1evCoyKbE1bpBKD0UinmqcCrw+QghP3VA39zoqBHXuiT5e0jlmYURsNVCe9Uf1DCm AITLTeiN1nbuJJreGREwadTIZr/OO3Z8CZC7+QaoR4AwheNxGsA4V7s+ooc031r5SnPc p1KhVN9Wi8Qvfz7SGBPLdoMfcT1/SLFghlwlZuJfM/dfqza1vBMRoNwom91KL3M19K1b BDvA== Received: by 10.50.187.228 with SMTP id fv4mr79348igc.10.1340084976914; Mon, 18 Jun 2012 22:49:36 -0700 (PDT) Received: by 10.50.187.228 with SMTP id fv4mr79342igc.10.1340084976827; Mon, 18 Jun 2012 22:49:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.66.7 with HTTP; Mon, 18 Jun 2012 22:49:16 -0700 (PDT) In-Reply-To: <001301cd4acf$d8c5cda0$8a5168e0$@noemax.com> References: <002f01cd3cc4$4791b380$d6b51a80$@noemax.com> <20120607034440.GD26406@jl-vm1.vm.bytemark.co.uk> <002001cd4a14$53eb66f0$fbc234d0$@noemax.com> <001301cd4acf$d8c5cda0$8a5168e0$@noemax.com> From: Takeshi Yoshino Date: Tue, 19 Jun 2012 14:49:16 +0900 Message-ID: To: Arman Djusupov Content-Type: multipart/alternative; boundary=14dae9340a6b033ced04c2ccd993 X-System-Of-Record: true X-Gm-Message-State: ALoCoQl628c1OfoS8JHVtpqP5YxeVXvnuMHytOpFEHtuzqsLbN9CC+ydAoeszMhgoXobJyRgmiD19CNWB0HQ6kRVcbFOs/XMOjQ+foop5TAVu11LomUGnFqMXC6/LsnHjwqvA0XTVNPW Cc: hybi@ietf.org Subject: Re: [hybi] Multiplexing: Pre-AddChannelResponse quota 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, 19 Jun 2012 05:49:38 -0000 --14dae9340a6b033ced04c2ccd993 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Jun 15, 2012 at 5:21 PM, Arman Djusupov wrote: > Since we go that far in flexibility why not just give the client a quota > and let it distribute it in the channels any way the client likes. This way > the client will be able to give a higher or lower priority to newly > established channels. The client will need to state the amount of quota it > assigned to a channel slot when sending an AddChannelRequest. So when > receiving a PreHandshakeQuota the client does not level it between > available slots, but uses a share of this quota later when creating a new > channel. This would be a simplified common quota. > I still wonder if grabbing per-channel basis quota control away from server-side (which post-handshake quota allows for) makes sense or not. Pre-handshake data processing may be designed similarly as post-handshake. Algorithm based on your proposal would be like this: - NC_WIN = 0 -- # of future/in-flight AddChannelRequest <= NC_WIN -- When received, say, NewChannelQuota block, add the value to NC_WIN - PQ = 0 -- When received, say, PreHandshakeQuota block, add the value to PQ - To issue an AddChannelRequest with channel ID X -- On AddChannelRequest, the client declares the amount of PQ to assign for X (IQ_X) -- PQ = PQ - IQ_X -- The quota for channel X is initialized to be IQ_X (can be used for both pre- and post-handshake data) - When received the corresponding AddChannelResponse, NC_WIN = NC_WIN - 1 Very simple. Assignment to channels is done by client-side (different from post-handshake). Am I understanding correctly? --14dae9340a6b033ced04c2ccd993 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Fri, Jun 15, 2012 at 5:21 PM, Arman Djusupov <arman@noemax.c= om> wrote:

Since we go that f= ar in flexibility why not just give the client a quota and let it distribut= e it in the channels any way the client likes. This way the client will be = able to give a higher or lower priority to newly established channels. The = client will need to state the=A0amount of quota it assigned to a channel sl= ot when sending an AddChannelRequest. So when receiving a PreHandshakeQuota= the client does not level it between available slots, but uses a share of = this quota later when creating a new channel. This would be a simplified co= mmon quota.=A0


I still wonder if grabbing per-chann= el basis quota control away from server-side (which post-handshake quota al= lows for) makes sense or not. Pre-handshake data processing may be designed= similarly as post-handshake.

Algorithm based on your proposal would be like this:

- NC_WIN =3D 0
-- # of future/in-flig= ht AddChannelRequest <=3D NC_WIN
-- When received, say, NewChannelQ= uota block, add the value to NC_WIN
- PQ =3D 0
-- When received, say, PreHandshakeQuota block, a= dd the value to PQ
- To issue an AddChannelRequest with channel I= D X
-- On AddChannelRequest, the client declares the amount of PQ= to assign for X (IQ_X)
-- PQ =3D PQ - IQ_X
-- The quota for channel X is initialize= d to be IQ_X (can be used for both pre- and post-handshake data)
= - When received the corresponding AddChannelResponse,=A0NC_WIN =3D NC_WIN -= 1
=A0
Very simple. Assignment to channels is done by cli= ent-side (different from post-handshake). Am I understanding correctly?

--14dae9340a6b033ced04c2ccd993-- From arman@noemax.com Tue Jun 19 00:06:49 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 51DE621F863D for ; Tue, 19 Jun 2012 00:06:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 rq4rqfXPwfVB for ; Tue, 19 Jun 2012 00:06:48 -0700 (PDT) Received: from mail.noemax.com (mail.noemax.com [64.34.201.8]) by ietfa.amsl.com (Postfix) with ESMTP id E396E21F8634 for ; Tue, 19 Jun 2012 00:06:47 -0700 (PDT) DKIM-Signature: a=rsa-sha1; t=1340089608; x=1340694408; s=m1024; d=noemax.com; c=relaxed/relaxed; v=1; bh=FhaHBrqm3feemkTaQ//C5eQV/iE=; h=From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:In-Reply-To:References; b=GgK00e+qgIAX+nnUjlbbzMc1mdHNcc3Q1PkL9biszWUhHQVjgQU9n2BhkTioJBa3+70BiCiLnHtM/bfmt4ISJZ6FokpREuDDJCFJr6+oSdAAUCxHkJiYjtMEd/xCiLC4Rq2k3go7iQwJnsG8HYOL6WJFTSmGdrml17mIGBrKaiw= Received: from mail.noemax.com by mail.noemax.com (IceWarp 10.4.1) with ASMTP (SSL) id DNZ07047; Tue, 19 Jun 2012 10:06:47 +0300 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/alternative; boundary="Apple-Mail=_684307C1-55CF-40E7-B0D4-F03BB50CF81C" From: Arman Djusupov In-Reply-To: Date: Tue, 19 Jun 2012 10:06:34 +0300 Message-Id: <6A3569A8-C253-4363-B00C-F336B0CA3128@noemax.com> References: <002f01cd3cc4$4791b380$d6b51a80$@noemax.com> <20120607034440.GD26406@jl-vm1.vm.bytemark.co.uk> <002001cd4a14$53eb66f0$fbc234d0$@noemax.com> <001301cd4acf$d8c5cda0$8a5168e0$@noemax.com> To: Takeshi Yoshino X-Mailer: Apple Mail (2.1278) Cc: hybi@ietf.org Subject: Re: [hybi] Multiplexing: Pre-AddChannelResponse quota 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, 19 Jun 2012 07:06:49 -0000 --Apple-Mail=_684307C1-55CF-40E7-B0D4-F03BB50CF81C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Yes, that's correct. =20 Only I would do NC_WIN =3D NC_WIN - 1 before AddChannelResponse is = received, to indicate that the slot is considered occupied when an = AddChannelRequest is outstanding, since the client already uses the = channel ID to send pre-handshake data. =20 Giving a client control over distributing the quota is not bad, since = this value is limited by the common quota. E.g. if the client has a file = to upload it could use all available quota when beginning to send it and = before the AddChannelResponse is received. The server only cares that = the client does not use more of buffer space than that granted to it; = the server does not care how the client distributes the quota along the = channels. Using this model does not prohibit leveling the quota along = all channel slots. =20 For reasons of simplicity and API limitations, browsers may simply = always level the quota along the channels, or they might prefer to = slightly delay sending the AddChannelRequest to check what is the size = of the first message being sent so that the AddChannelRequest with IQ_X = =3D message size is sent along with the first message, to avoid an extra = roundtrip. With best regards, Arman On Jun 19, 2012, at 8:49 AM, Takeshi Yoshino wrote: > On Fri, Jun 15, 2012 at 5:21 PM, Arman Djusupov = wrote: > Since we go that far in flexibility why not just give the client a = quota and let it distribute it in the channels any way the client likes. = This way the client will be able to give a higher or lower priority to = newly established channels. The client will need to state the amount of = quota it assigned to a channel slot when sending an AddChannelRequest. = So when receiving a PreHandshakeQuota the client does not level it = between available slots, but uses a share of this quota later when = creating a new channel. This would be a simplified common quota.=20 >=20 >=20 > I still wonder if grabbing per-channel basis quota control away from = server-side (which post-handshake quota allows for) makes sense or not. = Pre-handshake data processing may be designed similarly as = post-handshake. >=20 > Algorithm based on your proposal would be like this: >=20 > - NC_WIN =3D 0 > -- # of future/in-flight AddChannelRequest <=3D NC_WIN > -- When received, say, NewChannelQuota block, add the value to NC_WIN > - PQ =3D 0 > -- When received, say, PreHandshakeQuota block, add the value to PQ > - To issue an AddChannelRequest with channel ID X > -- On AddChannelRequest, the client declares the amount of PQ to = assign for X (IQ_X) > -- PQ =3D PQ - IQ_X > -- The quota for channel X is initialized to be IQ_X (can be used for = both pre- and post-handshake data) > - When received the corresponding AddChannelResponse, NC_WIN =3D = NC_WIN - 1 > =20 > Very simple. Assignment to channels is done by client-side (different = from post-handshake). Am I understanding correctly? >=20 --Apple-Mail=_684307C1-55CF-40E7-B0D4-F03BB50CF81C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 Yes, that's = correct.
 
Only I would = do NC_WIN =3D NC_WIN - 1 before AddChannelResponse is received, to = indicate that the slot is considered occupied when an AddChannelRequest = is outstanding, since the client already uses the channel ID to send = pre-handshake data.
 
Giving a = client control over distributing the quota is not bad, since this value = is limited by the common quota. E.g. if the client has a file to upload = it could use all available quota when beginning to send it and before = the AddChannelResponse is received. The server only cares that the = client does not use more of buffer space than that granted to it; the = server does not care how the client distributes the quota along the = channels. Using this model does not prohibit leveling the quota along = all channel slots.
 
For reasons = of simplicity and API limitations, browsers may simply always level the = quota along the channels, or they might prefer to slightly delay sending = the AddChannelRequest to check what is the size of the first message = being sent so that the AddChannelRequest with IQ_X =3D message size is = sent along with the first message, to avoid an extra = roundtrip.

With best = regards,
Arman


On Jun 19, 2012, at = 8:49 AM, Takeshi Yoshino wrote:

On Fri, Jun 15, 2012 at 5:21 PM, Arman Djusupov = <arman@noemax.com> wrote:

Since we go that far in flexibility why not just = give the client a quota and let it distribute it in the channels any way = the client likes. This way the client will be able to give a higher or = lower priority to newly established channels. The client will need to = state the amount of quota it assigned to a channel slot when = sending an AddChannelRequest. So when receiving a PreHandshakeQuota the = client does not level it between available slots, but uses a share of = this quota later when creating a new channel. This would be a simplified = common quota. 


I still wonder if grabbing = per-channel basis quota control away from server-side (which = post-handshake quota allows for) makes sense or not. Pre-handshake data = processing may be designed similarly as post-handshake.

Algorithm based on your proposal would be like = this:

- NC_WIN =3D 0
-- # of = future/in-flight AddChannelRequest <=3D NC_WIN
-- When received, = say, NewChannelQuota block, add the value to NC_WIN
- PQ =3D 0
-- When received, say, PreHandshakeQuota = block, add the value to PQ
- To issue an AddChannelRequest = with channel ID X
-- On AddChannelRequest, the client declares = the amount of PQ to assign for X (IQ_X)
-- PQ =3D PQ - IQ_X
-- The quota for channel X is = initialized to be IQ_X (can be used for both pre- and post-handshake = data)
- When received the corresponding = AddChannelResponse, NC_WIN =3D NC_WIN - 1
 
Very simple. Assignment to channels is done = by client-side (different from post-handshake). Am I understanding = correctly?


= --Apple-Mail=_684307C1-55CF-40E7-B0D4-F03BB50CF81C-- From tyoshino@google.com Thu Jun 21 05:27:04 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 7DE2721F852E for ; Thu, 21 Jun 2012 05:27:04 -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 wSBC6Fnkw4vL for ; Thu, 21 Jun 2012 05:27:03 -0700 (PDT) Received: from mail-gh0-f172.google.com (mail-gh0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id BC68A21F8528 for ; Thu, 21 Jun 2012 05:27:03 -0700 (PDT) Received: by ghbg16 with SMTP id g16so437419ghb.31 for ; Thu, 21 Jun 2012 05:27:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=AoGglYZD2rzotcQNDlba2eb8nZtO0d9xJOxp2x4+HTY=; b=BE/kgiEwWstcnvLLCrXBU7sRS083+m7csJwENMN8LlIcnsjPKTN1bHNppJk8FdXA9a bZtktOXr7ixpYIScfODMDyaOZs8HlTW6kx8c8Ke8slxg+AcazUEln/xru9edLI0uQVZl ExAxsxNAEDRuLjFYBpGlONgZ7XIBtNuiAKVMgmJs3rquynnjE3WfX19UHstNUMtqpyB2 S494YsZJjVBBNmJQ+61DfQb3VwKzsjplyWCy33M8Bl5DuCuzO0hka5gUnOYHFP0VNX/B 58f00mLMaK7IflwqmvprncdJvhd9MJ2Y578cqtya6z4fp/96Z+jCbhDc3apxAjNMUcMt wqGw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=AoGglYZD2rzotcQNDlba2eb8nZtO0d9xJOxp2x4+HTY=; b=kpv0xzAr/nlT8+gow0S3gkcNyxHxl6FXH7O9vuJiCARRt/E+0DYNhxXOvOQgqIYSTo bAGOqblJYZkg8yJpxH0XtW9OwrUOEl8+SrUlpZREndLoSR6CxMOhcvGG0wfrSLE9TLeH xbW4kQsC+xrVr85v94xjIiBNzhyMKr2a5kJI0qXM3SWmNGArRXTIk4+7GbBiViFL/w6F YBDh6t7ILWiub6Qm91mgXgrh7f54JomtVRDWHd62ubUEanYKHhsCBMH9B/LqKZX1wKm1 RozROK+/DK/T3BXyFLC5ri4SrNWsuY+4wzhJrAp2Rrru4dOe7n8Hfj31ee6Io+ljmCg2 VGuA== Received: by 10.50.173.65 with SMTP id bi1mr7198842igc.10.1340281622994; Thu, 21 Jun 2012 05:27:02 -0700 (PDT) Received: by 10.50.173.65 with SMTP id bi1mr7198829igc.10.1340281622881; Thu, 21 Jun 2012 05:27:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.66.7 with HTTP; Thu, 21 Jun 2012 05:26:42 -0700 (PDT) In-Reply-To: <6A3569A8-C253-4363-B00C-F336B0CA3128@noemax.com> References: <002f01cd3cc4$4791b380$d6b51a80$@noemax.com> <20120607034440.GD26406@jl-vm1.vm.bytemark.co.uk> <002001cd4a14$53eb66f0$fbc234d0$@noemax.com> <001301cd4acf$d8c5cda0$8a5168e0$@noemax.com> <6A3569A8-C253-4363-B00C-F336B0CA3128@noemax.com> From: Takeshi Yoshino Date: Thu, 21 Jun 2012 21:26:42 +0900 Message-ID: To: Arman Djusupov Content-Type: multipart/alternative; boundary=e89a8f6430e007e5eb04c2faa262 X-System-Of-Record: true X-Gm-Message-State: ALoCoQk2BBbVmrq81T6N+XWL3T56WDYDlZZep76vK3k+bxLlQIKSGa3PJIZGek4SiKChJfzKBaqPbijqAUltco1Qhjsp3cf85dNVaFAeXgrZDYGBnAM2sJsPaYP8y3UQZnvU4v9qdhMJ Cc: hybi@ietf.org Subject: Re: [hybi] Multiplexing: Pre-AddChannelResponse quota 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: Thu, 21 Jun 2012 12:27:04 -0000 --e89a8f6430e007e5eb04c2faa262 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Jun 19, 2012 at 4:06 PM, Arman Djusupov wrote: > For reasons of simplicity and API limitations, browsers may simply always > level the quota along the channels, or they might prefer to slightly delay > sending the AddChannelRequest to check what is the size of the first > message being sent so that the AddChannelRequest with IQ_X = message size > is sent along with the first message, to avoid an extra roundtrip. > Considering the concern Jamie showed, how about sending some FlowControl frame variant indicating the end of pre-handshake data after pre-handshake frames? The client consumes total pre-handshake data quota it has for the new channel as it like. And then, sends the end-of-pre-handshake-data frame. It can be after or before receiving AddChannelResponse for the request. The server knows how much pre-handshake data quota has been spent for the new channel attempt by summing the data size of frames before the end-of-pre-handshake-data frame. Delaying AddChannelRequest is fine but not so flexible enough to address the concern Jamie showed. --e89a8f6430e007e5eb04c2faa262 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Tue, Jun 19, 2012 at 4:06 PM, Arman Djusupov <arman@noemax.c= om> wrote:
For reasons of simplicity and API limitations, browsers may simply = always level the quota along the channels, or they might prefer to slightly= delay sending the AddChannelRequest to check what is the size of the first= message being sent so that the AddChannelRequest with IQ_X =3D message siz= e is sent along with the first message, to avoid an extra roundtrip.=

Considering the concern Jamie showed= , how about sending some FlowControl frame variant indicating the end of pr= e-handshake data after pre-handshake frames? The client consumes total pre-= handshake data quota it has for the new channel=A0as it like. And then, sen= ds the end-of-pre-handshake-data frame. It can be after or before receiving= AddChannelResponse for the request. The server knows how much pre-handshak= e data quota has been spent for the new channel attempt by summing the data= size of frames before the end-of-pre-handshake-data frame. Delaying AddCha= nnelRequest is fine but not so flexible enough to address the concern Jamie= showed.
--e89a8f6430e007e5eb04c2faa262-- From arman@noemax.com Thu Jun 21 23:05:47 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 67E2E11E8083 for ; Thu, 21 Jun 2012 23:05:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.391 X-Spam-Level: X-Spam-Status: No, score=-1.391 tagged_above=-999 required=5 tests=[AWL=-1.207, BAYES_40=-0.185, HTML_MESSAGE=0.001] 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 S+HaBu0Gp7bi for ; Thu, 21 Jun 2012 23:05:46 -0700 (PDT) Received: from mail.noemax.com (mail.noemax.com [64.34.201.8]) by ietfa.amsl.com (Postfix) with ESMTP id 5503A21F8617 for ; Thu, 21 Jun 2012 23:05:46 -0700 (PDT) DKIM-Signature: a=rsa-sha1; t=1340345149; x=1340949949; s=m1024; d=noemax.com; c=relaxed/relaxed; v=1; bh=CVX270XkXS8QJYJPMOKCqGhq0jE=; h=From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:In-Reply-To:References; b=F9cqqSr4FlmIL2UsF3p+ZYgcMXRUA+qEP7IVY72O+Upgke130ABAoKcSp5j2qUpCyBawMbrkCMUvmq7EF0jWieAqchoC+yJ5IuF2r/joBQL3qe3RPHKiGP4bqZUK73Nlpa0zszx1JOWnrtI1hbpA7bQljZ9MCr/+wCdal7DY9kI= Received: from mail.noemax.com by mail.noemax.com (IceWarp 10.4.1) with ASMTP (SSL) id GMB73747; Fri, 22 Jun 2012 09:05:47 +0300 From: "Arman Djusupov" To: "'Takeshi Yoshino'" References: <002f01cd3cc4$4791b380$d6b51a80$@noemax.com> <20120607034440.GD26406@jl-vm1.vm.bytemark.co.uk> <002001cd4a14$53eb66f0$fbc234d0$@noemax.com> <001301cd4acf$d8c5cda0$8a5168e0$@noemax.com> <6A3569A8-C253-4363-B00C-F336B0CA3128@noemax.com> In-Reply-To: Date: Fri, 22 Jun 2012 09:05:29 +0300 Message-ID: <000301cd503d$0aff8f00$20fead00$@noemax.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0004_01CD5056.304CC700" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHbEEjWH8q2xL+U7IgUz4ieagM0MAIpCHL8APvLbp8B3rSIHAHfCnvqAiE9EN8B8r7HPACD0WVjAIKfMBgB696tEgIeY34vlmoe0KA= Content-Language: en-us Cc: hybi@ietf.org Subject: Re: [hybi] Multiplexing: Pre-AddChannelResponse quota 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, 22 Jun 2012 06:05:47 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0004_01CD5056.304CC700 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hello Takeshi, This will result in the protocol having two different stages of communication. One stage before the handshake during which flow control should be based on the common quota, and a second stage after the end-of-pre-handshake-data frame is received during which flow control is based on the logical channel quota. I'm ok with this solution, but I have the impression that this is a bit of overkill. It will be difficult to implement in a high concurrency multithreaded environment. I can't say if there are any practical problems until I try implementing it. But there might be difficulties that are not evident now. In general it's becoming a bit more complex than simply working with a self-assigned initial quota. With best regards, Arman From: Takeshi Yoshino [mailto:tyoshino@google.com] Sent: Thursday, June 21, 2012 3:27 PM To: Arman Djusupov Cc: Jamie Lokier; hybi@ietf.org Subject: Re: [hybi] Multiplexing: Pre-AddChannelResponse quota On Tue, Jun 19, 2012 at 4:06 PM, Arman Djusupov wrote: For reasons of simplicity and API limitations, browsers may simply always level the quota along the channels, or they might prefer to slightly delay sending the AddChannelRequest to check what is the size of the first message being sent so that the AddChannelRequest with IQ_X = message size is sent along with the first message, to avoid an extra roundtrip. Considering the concern Jamie showed, how about sending some FlowControl frame variant indicating the end of pre-handshake data after pre-handshake frames? The client consumes total pre-handshake data quota it has for the new channel as it like. And then, sends the end-of-pre-handshake-data frame. It can be after or before receiving AddChannelResponse for the request. The server knows how much pre-handshake data quota has been spent for the new channel attempt by summing the data size of frames before the end-of-pre-handshake-data frame. Delaying AddChannelRequest is fine but not so flexible enough to address the concern Jamie showed. ------=_NextPart_000_0004_01CD5056.304CC700 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello Takeshi,

 

This will result in the protocol having two different stages of = communication. One stage before the handshake during which flow control = should be based on the common quota, and a second stage after the = end-of-pre-handshake-data frame is received during which flow control is = based on the logical channel quota. I'm ok with this solution, but I = have the impression that this is a bit of = overkill.

 

It will be difficult to implement in a high concurrency multithreaded = environment. I can't say if there are any practical problems until I try = implementing it. But there might be difficulties that are not evident = now. In general it's becoming a bit more complex than simply working = with a self-assigned initial quota.

 

With best regards,

Arman

 

From:= = Takeshi Yoshino [mailto:tyoshino@google.com]
Sent: Thursday, = June 21, 2012 3:27 PM
To: Arman Djusupov
Cc: Jamie = Lokier; hybi@ietf.org
Subject: Re: [hybi] Multiplexing: = Pre-AddChannelResponse quota

 

On = Tue, Jun 19, 2012 at 4:06 PM, Arman Djusupov <arman@noemax.com> = wrote:

For reasons of simplicity and API limitations, = browsers may simply always level the quota along the channels, or they = might prefer to slightly delay sending the AddChannelRequest to check = what is the size of the first message being sent so that the = AddChannelRequest with IQ_X =3D message size is sent along with the = first message, to avoid an extra = roundtrip.

 

Considering the concern Jamie = showed, how about sending some FlowControl frame variant indicating the = end of pre-handshake data after pre-handshake frames? The client = consumes total pre-handshake data quota it has for the new = channel as it like. And then, sends the end-of-pre-handshake-data = frame. It can be after or before receiving AddChannelResponse for the = request. The server knows how much pre-handshake data quota has been = spent for the new channel attempt by summing the data size of frames = before the end-of-pre-handshake-data frame. Delaying AddChannelRequest = is fine but not so flexible enough to address the concern Jamie = showed.

------=_NextPart_000_0004_01CD5056.304CC700-- From tyoshino@google.com Thu Jun 21 23:18:51 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 B4B4021F85C9 for ; Thu, 21 Jun 2012 23:18:51 -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=[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 qdPtQgkAfyyk for ; Thu, 21 Jun 2012 23:18:51 -0700 (PDT) Received: from mail-gg0-f172.google.com (mail-gg0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id B51D021F85C4 for ; Thu, 21 Jun 2012 23:18:50 -0700 (PDT) Received: by ggnc4 with SMTP id c4so1378737ggn.31 for ; Thu, 21 Jun 2012 23:18:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=KFbuIu9MA1DZoqJP6zc06eBC8TFFxRAjVM4FDt+z6a4=; b=pN/i24Lb9ONODaOLx457bOCaDp7J6w/Jf2I3GhO4GqyAjum9/8w4b0c+2CKgAk14dE x/4TvPVEKfkqMpOUNDdeHRGkSO4Ehz/CpaAl1EAJbHLkmOuIx5Tu8nvCVN8Q1brfNxwT zHB5m+rBmHFfAkrHyt2FM3JFMpjj6NyheS9pk4CPeWkRypxe/O9T1eA18qR0kr344t9W DiAiLkaJUVORIvj1WCyXUweiET6liRrdIXSZPn9r/RsWbp1E+Taa3Qdl7yOPd61P+E5C a58MGc05lYEOp9d06AGhDivF2/UG2fXMJNgAoh+NWLhQsntVuwZZkt4W4I5aAHo3WfHq ZHyw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=KFbuIu9MA1DZoqJP6zc06eBC8TFFxRAjVM4FDt+z6a4=; b=O+Cd0L9lC+AJ+xqlGhSerPGQ2E1D5CJ/qCCAIh6HFthCdQcu6W3kJzHf88jUYF03M+ jB9gpYWcXeYKd1ogWCVmlJXksE8JoQLvpeelFN2B3mIQGJ7oC4jHONNxlf2yZb0RQm4k zzAsX0RzUbuj9tnzuHf/nW5h5W8cUCeuh6ZQNziBHoDylETtoaH8F9YbNqxjfxQgQk0J eyMpI2l/MevEL2AUeOpRxw0ZOdTe3BN4l4gmzArV2A56e1t1lTlQLEMXRZHPnSl1SV4i qnIXvh37WjxaL+otqneTINASxrFLAAAS7kcxsN7a47QOWO4WDr+ZEA5+gsvhpLCE9ViP nb+Q== Received: by 10.50.187.228 with SMTP id fv4mr544969igc.10.1340345929703; Thu, 21 Jun 2012 23:18:49 -0700 (PDT) Received: by 10.50.187.228 with SMTP id fv4mr544958igc.10.1340345929578; Thu, 21 Jun 2012 23:18:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.66.7 with HTTP; Thu, 21 Jun 2012 23:18:29 -0700 (PDT) In-Reply-To: <000301cd503d$0aff8f00$20fead00$@noemax.com> References: <002f01cd3cc4$4791b380$d6b51a80$@noemax.com> <20120607034440.GD26406@jl-vm1.vm.bytemark.co.uk> <002001cd4a14$53eb66f0$fbc234d0$@noemax.com> <001301cd4acf$d8c5cda0$8a5168e0$@noemax.com> <6A3569A8-C253-4363-B00C-F336B0CA3128@noemax.com> <000301cd503d$0aff8f00$20fead00$@noemax.com> From: Takeshi Yoshino Date: Fri, 22 Jun 2012 15:18:29 +0900 Message-ID: To: Arman Djusupov Content-Type: multipart/alternative; boundary=14dae9340a6b02380204c3099b30 X-System-Of-Record: true X-Gm-Message-State: ALoCoQnB3Hu+R8h6NupLZ8SkZHq2LGwBKW7bkjJdDhuK2skigh1fvbkHeJF2mkPZgiCJVM9nnsz0FmuqJIIKR3x6yJi/HzVyIZCiqOM6gvB85U1byTmztwuMcMAypDWvkaY6jQ3CGvEfiLYVmfjmTqY/A5MOADcvZyiuWgpytzoo0wTCd11kzq0= Cc: hybi@ietf.org Subject: Re: [hybi] Multiplexing: Pre-AddChannelResponse quota 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, 22 Jun 2012 06:18:51 -0000 --14dae9340a6b02380204c3099b30 Content-Type: text/plain; charset=ISO-8859-1 As we're going to add, say, NewChannelQuotaUpdate command which replenishes new channel quota, another idea is assigning a channel ID by the server on NewChannelQuotaUpdate. This way, the server can give pre-handshake quota to each potential channel slot by the same manner as post-handshake quota assignment. Pre-handshake quota can be carried over seamlessly. Takeshi On Fri, Jun 22, 2012 at 3:05 PM, Arman Djusupov wrote: > Hello Takeshi,**** > > ** ** > > This will result in the protocol having two different stages of > communication. One stage before the handshake during which flow control > should be based on the common quota, and a second stage after the > end-of-pre-handshake-data frame is received during which flow control is > based on the logical channel quota. I'm ok with this solution, but I have > the impression that this is a bit of overkill.**** > > ** ** > > It will be difficult to implement in a high concurrency multithreaded > environment. I can't say if there are any practical problems until I try > implementing it. But there might be difficulties that are not evident now. > In general it's becoming a bit more complex than simply working with a > self-assigned initial quota. **** > > ** ** > > With best regards,**** > > Arman**** > > ** ** > > *From:* Takeshi Yoshino [mailto:tyoshino@google.com] > *Sent:* Thursday, June 21, 2012 3:27 PM > > *To:* Arman Djusupov > *Cc:* Jamie Lokier; hybi@ietf.org > *Subject:* Re: [hybi] Multiplexing: Pre-AddChannelResponse quota**** > > ** ** > > On Tue, Jun 19, 2012 at 4:06 PM, Arman Djusupov wrote:* > *** > > For reasons of simplicity and API limitations, browsers may simply always > level the quota along the channels, or they might prefer to slightly delay > sending the AddChannelRequest to check what is the size of the first > message being sent so that the AddChannelRequest with IQ_X = message size > is sent along with the first message, to avoid an extra roundtrip.**** > > ** ** > > Considering the concern Jamie showed, how about sending some FlowControl > frame variant indicating the end of pre-handshake data after pre-handshake > frames? The client consumes total pre-handshake data quota it has for the > new channel as it like. And then, sends the end-of-pre-handshake-data > frame. It can be after or before receiving AddChannelResponse for the > request. The server knows how much pre-handshake data quota has been spent > for the new channel attempt by summing the data size of frames before the > end-of-pre-handshake-data frame. Delaying AddChannelRequest is fine but not > so flexible enough to address the concern Jamie showed.**** > --14dae9340a6b02380204c3099b30 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
As we're go= ing to add, say, NewChannelQuotaUpdate command which replenishes new channe= l quota, another idea is assigning a channel ID by the server on NewChannel= QuotaUpdate. This way, the server can give pre-handshake quota to each pote= ntial channel slot by the same manner as post-handshake quota assignment. P= re-handshake quota can be carried over seamlessly.

Takeshi


On Fri, Jun 22, 2012 at 3:05 PM, Arman D= jusupov <arman@noemax.com> wrote:

Hello Takeshi,

=A0

This will result in the protocol having two d= ifferent stages of communication. One stage before the handshake during whi= ch flow control should be based on the common quota, and a second stage aft= er the end-of-pre-handshake-data frame is received during which flow contro= l is based on the logical channel quota. I'm ok with this solution, but= I have the impression that this is a bit of overkill.=

=A0<= /p>

It will be difficult t= o implement in a high concurrency multithreaded environment. I can't sa= y if there are any practical problems until I try implementing it. But ther= e might be difficulties that are not evident now. In general it's becom= ing a bit more complex than simply working with a self-assigned initial quo= ta.

=A0<= /p>

With best regards,<= /u>

Arman

=A0

From: Takeshi = Yoshino [mailto:ty= oshino@google.com]
Sent: Thursday, June 21, 2012 3:27 PM

To: Arman Djusupov
Cc: Jamie Lokier; hybi@ietf.org
Subject: Re: [h= ybi] Multiplexing: Pre-AddChannelResponse quota

=A0

On Tue, Jun 19, 2012 at 4:06 PM, Arman Djusupov <arman@noemax.com> wrote:=

For reasons of simplicity and API limitations, browsers may simply al= ways level the quota along the channels, or they might prefer to slightly d= elay sending the AddChannelRequest to check what is the size of the first m= essage being sent so that the AddChannelRequest with IQ_X =3D message size = is sent along with the first message, to avoid an extra roundtrip.

=A0

Considering the concern Jamie showed, how about sending some= FlowControl frame variant indicating the end of pre-handshake data after p= re-handshake frames? The client consumes total pre-handshake data quota it = has for the new channel=A0as it like. And then, sends the end-of-pre-handsh= ake-data frame. It can be after or before receiving AddChannelResponse for = the request. The server knows how much pre-handshake data quota has been sp= ent for the new channel attempt by summing the data size of frames before t= he end-of-pre-handshake-data frame. Delaying AddChannelRequest is fine but = not so flexible enough to address the concern Jamie showed.


 --14dae9340a6b02380204c3099b30-- From tyoshino@google.com Fri Jun 22 01:20:04 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 8AABC21F85EA for ; Fri, 22 Jun 2012 01:20:04 -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=[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 SwCfw7-Dh6UU for ; Fri, 22 Jun 2012 01:20:03 -0700 (PDT) Received: from mail-gg0-f172.google.com (mail-gg0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4770B21F85E0 for ; Fri, 22 Jun 2012 01:20:03 -0700 (PDT) Received: by ggnc4 with SMTP id c4so1435644ggn.31 for ; Fri, 22 Jun 2012 01:20:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=yo6uls8ihstNUd1JtJAvACa9pEdnp6J/MPO63ktfJgk=; b=QTQTb0SPii6jCaqVfG38uWMNxFrzfhgaeB0lhJTH4OvaHlDaUEeJnFgG+C49cuuZsD D3OQQKJjMyzIVESE2QSwB2Q+ubAZrGc1qbPgTR7ptcho+WWQDIY6uPvvn3d3+u/KOzyT g6f58NMn78L1ETCETS/DDR+8vqJ7MXtNZZz675gNiAQDl0m8THkPWn5zOts7s12esTi0 ADxcJMMMFESJFxc31lXWAoOpDpeSBCeUj6bm8viRgd5A59oXTmCtIQjtP+cPCZQjm9t6 k40+RQTnP+ii+QSYP4FZarhEHV0lRPZo6PT5qfHyauCRxGLNcPFz+RoAWNtz5ZwU/sIq mvag== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=yo6uls8ihstNUd1JtJAvACa9pEdnp6J/MPO63ktfJgk=; b=frrjrZ/csNjFSKtlkJ6FfAjSj/AYBObEClG6Y3cjHKoAy0o02IUoaGvlHB3qrJYYcx wooVn8XuojVO4cUm61eEnztR1wXfBSTk9OqNkI4udeMBfv9j/qAS3lF8FsYVStJ+tNmJ 1VzzMgJxI+nf4Ke/wgSnbzeBSlygjWThPpHGBeIAkNgtLYvraPZv+baQvo86mRoVmaw1 H9goHu4q7CbwJ76uT1wLUgzqR8ziWJ1gzXybr8atTsC8C8tWC21dwHxu9+24pQbBB94F 8Wbidc0b3T05vuFMZwhFTZdzn4nr36JDYCyt00mr1h6j0qxx6L273ONVjvVMo5eqNRzF N57g== Received: by 10.50.179.74 with SMTP id de10mr682916igc.61.1340353201441; Fri, 22 Jun 2012 01:20:01 -0700 (PDT) Received: by 10.50.179.74 with SMTP id de10mr682909igc.61.1340353201322; Fri, 22 Jun 2012 01:20:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.66.7 with HTTP; Fri, 22 Jun 2012 01:19:41 -0700 (PDT) In-Reply-To: <000c01cd495e$751e5cd0$5f5b1670$@noemax.com> References: <001a01cd3e69$4a221c10$de665430$@noemax.com> <4FC732DC.3000308@250bpm.com> <000e01cd3f1c$af15ad40$0d4107c0$@noemax.com> <4FC880A7.9070007@250bpm.com> <001001cd4000$fe2c82c0$fa858840$@noemax.com> <4FCCAE6B.1010306@250bpm.com> <002d01cd4262$747957b0$5d6c0710$@noemax.com> <20120607022312.GA26406@jl-vm1.vm.bytemark.co.uk> <000e01cd449d$1c0ed220$542c7660$@noemax.com> <000401cd4566$d5f6bb70$81e43250$@noemax.com> <4FD85D7C.3000902@250bpm.com> <000c01cd495e$751e5cd0$5f5b1670$@noemax.com> From: Takeshi Yoshino Date: Fri, 22 Jun 2012 17:19:41 +0900 Message-ID: To: Arman Djusupov Content-Type: multipart/alternative; boundary=14dae934041b703a4604c30b4cc5 X-System-Of-Record: true X-Gm-Message-State: ALoCoQnmDsiurA5lBFnyxe5jlLS9gelx4qevAHdfQCTUzCAPgG+QYsrGTiRycnLOqxM30PV3/VCWv8ElU31S/z6UPLzZ+DKX+enodv7mS5BeWOhwPqYHKQWFojezcWQg+ZZcL0RyqPNsWkMobfeF0U+6c03wzerkJ15E0CXjUaGCmrFe3S5xWnk= Cc: hybi@ietf.org Subject: Re: [hybi] Flow control quota 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, 22 Jun 2012 08:20:05 -0000 --14dae934041b703a4604c30b4cc5 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Jun 13, 2012 at 9:17 PM, Arman Djusupov wrote: > But by doing so we dodge the problem with non fragmentable frames that > might > be produced by any future extension that is unknown to the intermediary. > For > example we may need a reliable streaming extension that numbers all the > frames and adds the frame number in the extension data so that it can > resume > sending the message if the connection fails. Such an extension would not > This implies that frame boundary is preserved end-to-end (or we may say it's preserved extension-to-extension). Some extensions may just require per-message signaling. Some may require signaling not aligned to message boundary. Your example might be in the latter group. Boundaries each extension want to place and use may differ. Now I think that sharing WebSocket fragmentation defined in RFC 6455 between such extensions is not realistic. But we do have it. For what we can utilize it? - partial flush or - partial flush and multiplexing Regardless if we use fragmentation for mux or not, I'd suggest that we stop using the frame boundary signal for compression, and refrain from using the boundary of fragmentation and RSV bits and extension data field as per-frame (per-processing-unit) signaling for future extensions, too. Extension data is not the only place extensions may touch. Extensions may transform application data. Per-frame compression does it. No worry. "reliable streaming extension" may embed sequence and the size of the chunk in application data. We tend to miss the frame boundary information, but let's accept new overhead for extensions to represent their processing unit. > support fragmentation so it would set the RSV bit of each frame to prevent > it from being fragmented by intermediaries. As long as the parent > specification allows extensions to place their data at the beginning of the > frame payload, this extension's data would not be recoverable if the frame > is fragmented, so such an extensions would be incompatible with mux. > > It's ok if some extensions are not compatible with mux intermediaries, > since > the WebSocket specification allows intermediaries to refuse extensions that > are not known to them. But ideally mux should be transparent to all > extensions, so that mux intermediaries can be unobtrusively introduced at > any point of the communication path without placing any restrictions on the > extensions that may be used and the type of payload being exchanged. > The ideal mux does require encapsulation (#2). As John said, it was hard to sell. Maybe, we can call for opinions again. I'm ok with full encapsulation though I doubt refragmentability (without parsing mux) after mux is really important. > > So I think we should take a bit more time to think on how we can resolve > the > problem with mux without changing per-frame compression. The second problem > is that changing per-frame compression so that it is applied on the message > boundaries would create an issue if it is applied after mux. Since after > mux > there are no message boundaries any more as message frames are intermixed, > the compression would have to be applied on each frame separately. So > effectively per-frame compression extensions would have two modes of > operation, which would be very hard to define in a specification. It would > practically make it a requirement that this per-frame compression extension > be aware that mux is being used. IMO having such coupling between > extensions > would be a bad design. > Hmm... --14dae934041b703a4604c30b4cc5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed, Jun 13, 2012 at 9:17 PM, Arman Djusupov <arman@noemax.c= om> wrote:
But by doing so we dodge the problem with non fragmentable frames that migh= t
be produced by any future extension that is unknown to the intermediary. Fo= r
example we may need a reliable streaming extension that numbers all the
frames and adds the frame number in the extension data so that it can resum= e
sending the message if the connection fails. Such an extension would not

This implies that frame boundary is prese= rved end-to-end (or we may say it's preserved extension-to-extension).<= /div>

Some extensions may just require per-message signaling.= Some may require signaling not aligned to message boundary. Your example m= ight be in the latter group. Boundaries each extension want to place and us= e may differ. Now I think that sharing WebSocket fragmentation defined in R= FC 6455 between such extensions is not realistic. But we do have it. For wh= at we can utilize it?
- partial flush
or
-=A0partial flush and multiplex= ing

Regardless if we use fragmentation for mux or = not, I'd suggest that we stop using the frame boundary signal for compr= ession, and refrain from using the boundary of fragmentation and RSV bits a= nd extension data field as per-frame (per-processing-unit) signaling for fu= ture extensions, too.

Extension data is not the only place extensions may tou= ch. Extensions may transform application data. Per-frame compression does i= t. No worry. "reliable streaming extension" may embed sequence an= d the size of the chunk in application data. We tend to miss the frame boun= dary information, but let's accept new overhead for extensions to repre= sent their processing unit.
=A0
support fragmentation so it would set the RSV bit of each frame to prevent<= br> it from being fragmented by intermediaries. As long as the parent
specification allows extensions to place their data at the beginning of the=
frame payload, this extension's data would not be recoverable if the fr= ame
is fragmented, so such an extensions would be incompatible with mux.

It's ok if some extensions are not compatible with mux intermediaries, = since
the WebSocket specification allows intermediaries to refuse extensions that=
are not known to them. But ideally mux should be transparent to all
extensions, so that mux intermediaries can be unobtrusively introduced at any point of the communication path without placing any restrictions on the=
extensions that may be used and the type of payload being exchanged.

The ideal mux does require encapsulation (#2)= . As John said, it was hard to sell. Maybe, we can call for opinions again.=

I'm ok with full encapsulation though I doubt refra= gmentability (without parsing mux) after mux is really important.
=A0

So I think we should take a bit more time to think on how we can resolve th= e
problem with mux without changing per-frame compression. The second problem=
is that changing per-frame compression so that it is applied on the message=
boundaries would create an issue if it is applied after mux. Since after mu= x
there are no message boundaries any more as message frames are intermixed,<= br> the compression would have to be applied on each frame separately. So
effectively per-frame compression= extensions would have two modes of
operation, which would be very hard to define in a specification. It would<= br> practically make it a requirement that this per-frame compression extension=
be aware that mux is being used. IMO having such coupling between extension= s
would be a bad design.

Hmm...

--14dae934041b703a4604c30b4cc5-- From arman@noemax.com Fri Jun 22 01:20:26 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 C803621F85E0 for ; Fri, 22 Jun 2012 01:20:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.426 X-Spam-Level: X-Spam-Status: No, score=-2.426 tagged_above=-999 required=5 tests=[AWL=0.172, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 TVxbbDMcJpXq for ; Fri, 22 Jun 2012 01:20:22 -0700 (PDT) Received: from mail.noemax.com (mail.noemax.com [64.34.201.8]) by ietfa.amsl.com (Postfix) with ESMTP id 414FB21F8675 for ; Fri, 22 Jun 2012 01:20:22 -0700 (PDT) DKIM-Signature: a=rsa-sha1; t=1340353226; x=1340958026; s=m1024; d=noemax.com; c=relaxed/relaxed; v=1; bh=K7AJNy4v11be2EDZcMO4IWZAHX8=; h=From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:In-Reply-To:References; b=sK7//Z3aP1imi3D/Ka34lhD22hg9VfLARTCmF//CsQUXWoilAKHFTPg/ViQTmjXRBgfXBB8oDo6Qv6/9gYHC/hULo1pgzsr4ytlwqmG1mR0W10kjyku+vZKlb+bdMpnO/XDQovx7xCTQA1Gt6xhAFK2iiZ8dumIElPDg7V0lBQs= Received: from mail.noemax.com by mail.noemax.com (IceWarp 10.4.1) with ASMTP (SSL) id GOQ42024; Fri, 22 Jun 2012 11:20:24 +0300 From: "Arman Djusupov" To: "'Takeshi Yoshino'" References: <002f01cd3cc4$4791b380$d6b51a80$@noemax.com> <20120607034440.GD26406@jl-vm1.vm.bytemark.co.uk> <002001cd4a14$53eb66f0$fbc234d0$@noemax.com> <001301cd4acf$d8c5cda0$8a5168e0$@noemax.com> <6A3569A8-C253-4363-B00C-F336B0CA3128@noemax.com> <000301cd503d$0aff8f00$20fead00$@noemax.com> In-Reply-To: Date: Fri, 22 Jun 2012 11:20:05 +0300 Message-ID: <002101cd504f$d8a20e30$89e62a90$@noemax.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0022_01CD5068.FDEF4630" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHbEEjWH8q2xL+U7IgUz4ieagM0MAIpCHL8APvLbp8B3rSIHAHfCnvqAiE9EN8B8r7HPACD0WVjAIKfMBgB696tEgIeY34vAi4tHFcCuqrLZJZC/LbQ Content-Language: en-us Cc: hybi@ietf.org Subject: Re: [hybi] Multiplexing: Pre-AddChannelResponse quota 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, 22 Jun 2012 08:20:26 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0022_01CD5068.FDEF4630 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Good idea. Hmm, actually this model can also work without the server assigning channel IDs. The server simply needs to provide an initial quota to the slot and then we have to allow the server to send FC frames to the client's logical channel before the handshake is complete. So as soon as server receives an AddChannelRequest and learns the channel ID, it would be sending normal FC frames to the client. This way the FC would also work as usual both before and after the handshake. The only difference from the current spec is that the channel should be considered as established once an AddChannelRequest received by the server. FC for the logical channel should start from the moment when the server learns channel ID. If the server sends a FC frame as soon as it receives an AddChannelRequest, it should arrive to the client before the client uses all initial quota, so the transmission should not stop. If there is a delay in communication it would happen only due to the initial quota being too small for the transmission rate. But such delays are inevitable both before and after handshake. It depends entirely on the link speed and amount of quota granted. This way the client would be able to transmit as much as the server can receive without waiting for an AddChannelResponse. I like this idea, it is simple and would work fine. With best regards, Arman From: Takeshi Yoshino [mailto:tyoshino@google.com] Sent: Friday, June 22, 2012 9:18 AM To: Arman Djusupov Cc: Jamie Lokier; hybi@ietf.org Subject: Re: [hybi] Multiplexing: Pre-AddChannelResponse quota As we're going to add, say, NewChannelQuotaUpdate command which replenishes new channel quota, another idea is assigning a channel ID by the server on NewChannelQuotaUpdate. This way, the server can give pre-handshake quota to each potential channel slot by the same manner as post-handshake quota assignment. Pre-handshake quota can be carried over seamlessly. Takeshi On Fri, Jun 22, 2012 at 3:05 PM, Arman Djusupov wrote: Hello Takeshi, This will result in the protocol having two different stages of communication. One stage before the handshake during which flow control should be based on the common quota, and a second stage after the end-of-pre-handshake-data frame is received during which flow control is based on the logical channel quota. I'm ok with this solution, but I have the impression that this is a bit of overkill. It will be difficult to implement in a high concurrency multithreaded environment. I can't say if there are any practical problems until I try implementing it. But there might be difficulties that are not evident now. In general it's becoming a bit more complex than simply working with a self-assigned initial quota. With best regards, Arman From: Takeshi Yoshino [mailto:tyoshino@google.com] Sent: Thursday, June 21, 2012 3:27 PM To: Arman Djusupov Cc: Jamie Lokier; hybi@ietf.org Subject: Re: [hybi] Multiplexing: Pre-AddChannelResponse quota On Tue, Jun 19, 2012 at 4:06 PM, Arman Djusupov wrote: For reasons of simplicity and API limitations, browsers may simply always level the quota along the channels, or they might prefer to slightly delay sending the AddChannelRequest to check what is the size of the first message being sent so that the AddChannelRequest with IQ_X = message size is sent along with the first message, to avoid an extra roundtrip. Considering the concern Jamie showed, how about sending some FlowControl frame variant indicating the end of pre-handshake data after pre-handshake frames? The client consumes total pre-handshake data quota it has for the new channel as it like. And then, sends the end-of-pre-handshake-data frame. It can be after or before receiving AddChannelResponse for the request. The server knows how much pre-handshake data quota has been spent for the new channel attempt by summing the data size of frames before the end-of-pre-handshake-data frame. Delaying AddChannelRequest is fine but not so flexible enough to address the concern Jamie showed. ------=_NextPart_000_0022_01CD5068.FDEF4630 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Good idea.

 

Hmm, actually this model can also work without the server assigning = channel IDs. The server simply needs to provide an initial quota to the = slot and then we have to allow the server to send FC frames to the = client’s logical channel before the handshake is complete. So as = soon as server receives an AddChannelRequest and learns the channel ID, = it would be sending normal FC frames to the client. This way the FC = would also work as usual both before and after the handshake. The only = difference from the current spec is that the channel should be = considered as established once an AddChannelRequest received by the = server. FC for the logical channel should start from the moment when the = server learns channel ID.

 

If the server sends a FC frame as soon as it receives an = AddChannelRequest, it should arrive to the client before the client uses = all initial quota, so the transmission should not stop. If there is a = delay in communication it would happen only due to the initial quota = being too small for the transmission rate. But such delays are = inevitable both before and after handshake. It depends entirely on the = link speed and amount of quota granted.

 

This way the client would be able to transmit as much as the server = can receive without waiting for an AddChannelResponse. I like this idea, = it is simple and would work fine.

 

With best regards,

Arman

 

 

From:= = Takeshi Yoshino [mailto:tyoshino@google.com]
Sent: Friday, = June 22, 2012 9:18 AM
To: Arman Djusupov
Cc: Jamie = Lokier; hybi@ietf.org
Subject: Re: [hybi] Multiplexing: = Pre-AddChannelResponse quota

 

As we're going to add, say, = NewChannelQuotaUpdate command which replenishes new channel quota, = another idea is assigning a channel ID by the server on = NewChannelQuotaUpdate. This way, the server can give pre-handshake quota = to each potential channel slot by the same manner as post-handshake = quota assignment. Pre-handshake quota can be carried over = seamlessly.


Takeshi

On = Fri, Jun 22, 2012 at 3:05 PM, Arman Djusupov <arman@noemax.com> = wrote:

Hello Takeshi,

 

This will result in the protocol having two different stages of = communication. One stage before the handshake during which flow control = should be based on the common quota, and a second stage after the = end-of-pre-handshake-data frame is received during which flow control is = based on the logical channel quota. I'm ok with this solution, but I = have the impression that this is a bit of = overkill.

 

It will be difficult to implement in a high concurrency multithreaded = environment. I can't say if there are any practical problems until I try = implementing it. But there might be difficulties that are not evident = now. In general it's becoming a bit more complex than simply working = with a self-assigned initial quota.

 

With best regards,

Arman

 

From:= = Takeshi Yoshino [mailto:tyoshino@google.com]
Sent: Thursday, = June 21, 2012 3:27 PM


To: Arman = Djusupov
Cc: Jamie Lokier; hybi@ietf.org
Subject: Re: [hybi] = Multiplexing: Pre-AddChannelResponse quota

 <= /o:p>

On Tue, Jun 19, 2012 at 4:06 = PM, Arman Djusupov <arman@noemax.com> = wrote:

For reasons of simplicity and API limitations, = browsers may simply always level the quota along the channels, or they = might prefer to slightly delay sending the AddChannelRequest to check = what is the size of the first message being sent so that the = AddChannelRequest with IQ_X =3D message size is sent along with the = first message, to avoid an extra = roundtrip.

 

Considering the concern Jamie = showed, how about sending some FlowControl frame variant indicating the = end of pre-handshake data after pre-handshake frames? The client = consumes total pre-handshake data quota it has for the new = channel as it like. And then, sends the end-of-pre-handshake-data = frame. It can be after or before receiving AddChannelResponse for the = request. The server knows how much pre-handshake data quota has been = spent for the new channel attempt by summing the data size of frames = before the end-of-pre-handshake-data frame. Delaying AddChannelRequest = is fine but not so flexible enough to address the concern Jamie = showed.

 

------=_NextPart_000_0022_01CD5068.FDEF4630-- From jamie@shareable.org Fri Jun 22 03:19:59 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 0DFE521F84D5 for ; Fri, 22 Jun 2012 03:19:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 7k5ZIfuL2oKu for ; Fri, 22 Jun 2012 03:19:58 -0700 (PDT) Received: from mail2.shareable.org (mail2.shareable.org [80.68.89.115]) by ietfa.amsl.com (Postfix) with ESMTP id 6EA5D21F8622 for ; Fri, 22 Jun 2012 03:19:58 -0700 (PDT) Received: from jamie by mail2.shareable.org with local (Exim 4.63) (envelope-from ) id 1Si0y2-0003JM-Qs; Fri, 22 Jun 2012 11:19:54 +0100 Date: Fri, 22 Jun 2012 11:19:54 +0100 From: Jamie Lokier To: Arman Djusupov Message-ID: <20120622101954.GQ5812@jl-vm1.vm.bytemark.co.uk> References: <002001cd4a14$53eb66f0$fbc234d0$@noemax.com> <001301cd4acf$d8c5cda0$8a5168e0$@noemax.com> <6A3569A8-C253-4363-B00C-F336B0CA3128@noemax.com> <000301cd503d$0aff8f00$20fead00$@noemax.com> <002101cd504f$d8a20e30$89e62a90$@noemax.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <002101cd504f$d8a20e30$89e62a90$@noemax.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: hybi@ietf.org Subject: Re: [hybi] Multiplexing: Pre-AddChannelResponse quota 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, 22 Jun 2012 10:19:59 -0000 Arman Djusupov wrote: > Good idea. > > Hmm, actually this model can also work without the server assigning > channel IDs. Yes, that's very useful in making the protocol simple without blocking at any point. As a general principle: "Initiator chooses id" removes delays in all sorts of patterns, such as muxing, request-response, remote object allocation, etc. In this case the client is the initiator, however if there will ever be channels initiated from the server side, the server should choose channel id in that case. > The server simply needs to provide an initial quota to the > slot and then we have to allow the server to send FC frames to the > client’s logical channel before the handshake is complete. So as soon > as server receives an AddChannelRequest and learns the channel ID, it > would be sending normal FC frames to the client. This way the FC would > also work as usual both before and after the handshake. The only > difference from the current spec is that the channel should be > considered as established once an AddChannelRequest received by the > server. FC for the logical channel should start from the moment when > the server learns channel ID. > > If the server sends a FC frame as soon as it receives an > AddChannelRequest, it should arrive to the client before the > client uses all initial quota, so the transmission should not > stop. If there is a delay in communication it would happen only > due to the initial quota being too small for the transmission > rate. But such delays are inevitable both before and after > handshake. It depends entirely on the link speed and amount of > quota granted. > > This way the client would be able to transmit as much as the server can > receive without waiting for an AddChannelResponse. I like this idea, it > is simple and would work fine. Looks very good to me :-) Using elements of the established-channel protocol as much as possible is key to a simple handshake and minimal delays. It's also shorter to describe in specs, and shorter code. Anything which improves the performance of established channels (such as expanding the flow control window heuristically for link bandwidth (like recent TCP does), choosing good windows, sharing memory among channels etc.) will also improve the performance at the early stage. Similar principles apply pre-handshake to the channel assignment itself, which is why using the same kind of control for *number* of channels assignable works quite well, and it also benefits from similar heuristics. (In principle round-trip delay elimination can go further up the chain through WS, HTTP, TLS and even TCP setup, but various aspects of specification make it difficult.) -- Jamie From tyoshino@google.com Fri Jun 22 03:54:36 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 A750721F8646 for ; Fri, 22 Jun 2012 03:54:36 -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=[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 sXwHHg5EMS0r for ; Fri, 22 Jun 2012 03:54:36 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9368A21F8484 for ; Fri, 22 Jun 2012 03:54:35 -0700 (PDT) Received: by lbbgo11 with SMTP id go11so3739471lbb.31 for ; Fri, 22 Jun 2012 03:54:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=eQioOzQmwScakxeAX1k8j3wh22g0PwXlnlBswHp4IzY=; b=XBuEQrkYAEPsYD9zWvRkS0/EIJEAgCNbR6Gx6YTA9l2lyu4/QvgP4plVfXutjApZii fQh0kWBnJGQByW3uHflvudG7NN6UK29Mr7Qvw/NB3eVP7GxUYhDfnLYwaZnsdZQd8JGO oErvolwV0sQO37BR2Nmi6RKSIhUOuZzT/JUdepu9d/QkLORyzEugjTqWAJEAZqDme7Ay JAkUs2DGByjpTPwyRxtnvpRuu4Gho++tZewSyUzJ6a5joKEkK8kD7kLBZpNPadmpTmpU mI6wOgUCNqoX58zw73LvgKIXmI/Fzy/Y09SLlE30/ubWyMSh0jv7UWrNSrNhmhVZHsq3 C++A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=eQioOzQmwScakxeAX1k8j3wh22g0PwXlnlBswHp4IzY=; b=Qi/HzR4ggxprB1IwByuEg8pjlZQRLUmh3Rr36MezhhFvdsIZ90ga8GOfMu4xj3n0vO soWioe/xk2fm2+VN18jjNqtVF0+UafHDVvhL/BdsVFnbd/Q8nEozlhKz77Rx0Kfm0kK3 9G2C/UiJzD3RFiB1jFq5YA1WA5E/s5JDxccktZ3/Vsu4HTpk8Zt97HQ6YemGLnOGuPz5 pPQ0GrjPAhqza7qHT/GSiACbiSZLzCWv2Pzo6jO2D2+yM7za/IHKrNuPXi9bbgF2HBpK bZM+e2fdfHqM+6jSJYb46AvBYq8BUdgwkqHPLXKwHjwQPGi3E2RYjljpc3oQGAWCm/f0 n0Iw== Received: by 10.112.82.197 with SMTP id k5mr1232294lby.98.1340362474424; Fri, 22 Jun 2012 03:54:34 -0700 (PDT) Received: by 10.112.82.197 with SMTP id k5mr1232284lby.98.1340362474282; Fri, 22 Jun 2012 03:54:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.112.7.105 with HTTP; Fri, 22 Jun 2012 03:54:13 -0700 (PDT) In-Reply-To: <002101cd504f$d8a20e30$89e62a90$@noemax.com> References: <002f01cd3cc4$4791b380$d6b51a80$@noemax.com> <20120607034440.GD26406@jl-vm1.vm.bytemark.co.uk> <002001cd4a14$53eb66f0$fbc234d0$@noemax.com> <001301cd4acf$d8c5cda0$8a5168e0$@noemax.com> <6A3569A8-C253-4363-B00C-F336B0CA3128@noemax.com> <000301cd503d$0aff8f00$20fead00$@noemax.com> <002101cd504f$d8a20e30$89e62a90$@noemax.com> From: Takeshi Yoshino Date: Fri, 22 Jun 2012 19:54:13 +0900 Message-ID: To: Arman Djusupov Content-Type: multipart/alternative; boundary=f46d04016c1b265fe804c30d7572 X-System-Of-Record: true X-Gm-Message-State: ALoCoQn0Q3mI1gV+mc51pf+jX/gDumZlLjojm3YxkyACj3z9f8sgU36+VhmQ+NF3TX9dVdTdI7oId6ob4tBKLfHQv87M1NCPb6Wfkiu8lo+RHmek4J5xS3WwMyOA9/hLFdaBmQjEQ0ceMbhNLiprLPjIJfQw44SN0L99OmbItkL8Jb3moWqC468= Cc: hybi@ietf.org Subject: Re: [hybi] Multiplexing: Pre-AddChannelResponse quota 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, 22 Jun 2012 10:54:36 -0000 --f46d04016c1b265fe804c30d7572 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Fri, Jun 22, 2012 at 5:20 PM, Arman Djusupov wrote: > Hmm, actually this model can also work without the server assigning > channel IDs. The server simply needs to provide an initial quota to the > slot and then we have to allow the server to send FC frames to the client= =92s > logical channel before the handshake is complete. > Without the server assigning some identifier for the new slot (doesn't need to be the channel ID to be used after channel open, but some identifier), we cannot match the slot and the pre-handshake FC frames. Sorry but could you elaborate your idea? Maybe, you said here that we'll be able to send FC after receiving AddChannelRequest and before sending back AddChannelResponse? What I had in my mind is like this: (C) receives Physical channel server's opening handshake (C) receives NewChannelSlot[ID=3D1] (C) receives NewChannelSlot[ID=3D2] (C) receives NewChannelSlot[ID=3D3] Now (C) can issue three AddChannelRequests but may not send any pre-handshake data. (C) receives FlowControl[ID=3D1, quota=3D1024] (C) receives FlowControl[ID=3D2, quota=3D1024] (C) receives FlowControl[ID=3D3, quota=3D1024] Now (C) is allowed to send pre-handshake data up to 1024 for each of allocated slots. Here, the client attempts to open a new logical channel using the first allocated slot. (C) sends AddChannelRequest[ID=3D1] (C) sends TextData[len=3D512] (C) receives AddChannelResponse[ID=3D1, success] (C) receives NewChannelSlot[ID=3D4] (C) receives FlowControl[ID=3D1, quota=3D1024] Now channel 1 is open and its quota is 1536. --f46d04016c1b265fe804c30d7572 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
On Fri, Jun 22, 2012 at 5:20 PM, Arman Djusupov <arman@noemax.c= om> wrote:

Hmm, actually this model can also wor= k without the server assigning channel IDs. The server simply needs to prov= ide an initial quota to the slot and then we have to allow the server to se= nd FC frames to the client=92s logical channel before the handshake is comp= lete.


Without the server assigning some id= entifier for the new slot (doesn't need to be the channel ID to be used= after channel open, but some identifier), we cannot match the slot and the= pre-handshake FC frames.

Sorry but could you elaborate your idea? Maybe, you sai= d here that we'll be able to send FC after receiving AddChannelRequest = and before sending back AddChannelResponse?

What I= had in my mind is like this:

(C) receives Physical channel server's opening hand= shake
(C) receives NewChannelSlot[ID=3D1]
(C) rece= ives NewChannelSlot[ID=3D2]
(C) receives NewChannelSlot[ID=3D3]

Now (C) can issue three AddChannelRequests but may not = send any pre-handshake data.

(C) receives FlowControl[I= D=3D1, quota=3D1024]
(C) receives Fl= owControl[ID=3D2, quota=3D1024]
(C) receives FlowControl[ID=3D3, quota=3D1024]

Now (C) is allowed to send pre-handsha= ke data up to 1024 for each of allocated slots.
Here, the client = attempts to open a new logical channel using the first allocated slot.

(C) sends AddChannelRequest[ID=3D1]
(C) sends TextData[len=3D512]
(C) receives Ad= dChannelResponse[ID=3D1, success]
(C) receives NewChannelSlot[ID= =3D4]
(C) receives FlowControl[ID=3D1, quota=3D1024]

Now channel 1 is open and its quota =A0is 1536.

--f46d04016c1b265fe804c30d7572-- From jamie@shareable.org Fri Jun 22 05:17: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 0034321F85CC for ; Fri, 22 Jun 2012 05:17:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] 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 CgFYE-hoKE5V for ; Fri, 22 Jun 2012 05:17:41 -0700 (PDT) Received: from mail2.shareable.org (mail2.shareable.org [80.68.89.115]) by ietfa.amsl.com (Postfix) with ESMTP id 459AA21F85C0 for ; Fri, 22 Jun 2012 05:17:41 -0700 (PDT) Received: from jamie by mail2.shareable.org with local (Exim 4.63) (envelope-from ) id 1Si2ny-0003q3-C1; Fri, 22 Jun 2012 13:17:38 +0100 Date: Fri, 22 Jun 2012 13:17:38 +0100 From: Jamie Lokier To: Takeshi Yoshino Message-ID: <20120622121738.GR5812@jl-vm1.vm.bytemark.co.uk> References: <002001cd4a14$53eb66f0$fbc234d0$@noemax.com> <001301cd4acf$d8c5cda0$8a5168e0$@noemax.com> <6A3569A8-C253-4363-B00C-F336B0CA3128@noemax.com> <000301cd503d$0aff8f00$20fead00$@noemax.com> <002101cd504f$d8a20e30$89e62a90$@noemax.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: hybi@ietf.org Subject: Re: [hybi] Multiplexing: Pre-AddChannelResponse quota 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, 22 Jun 2012 12:17:42 -0000 Takeshi Yoshino wrote: > Without the server assigning some identifier for the new slot (doesn't > need to be the channel ID to be used after channel open, but some > identifier), we cannot match the slot and the pre-handshake FC frames. > Sorry but could you elaborate your idea? Maybe, you said here that > we'll be able to send FC after receiving AddChannelRequest and before > sending back AddChannelResponse? > What I had in my mind is like this: > (C) receives Physical channel server's opening handshake > (C) receives NewChannelSlot[ID=1] > (C) receives NewChannelSlot[ID=2] > (C) receives NewChannelSlot[ID=3] > Now (C) can issue three AddChannelRequests but may not send any > pre-handshake data. Why not just send NewChannelSlots[ADD=3], instead of 3 NewChannelSlot messages? The slot messages are wasteful if the server is happy to accept 1000 low-usage slots from the beginning. > (C) receives FlowControl[ID=1, quota=1024] > (C) receives FlowControl[ID=2, quota=1024] > (C) receives FlowControl[ID=3, quota=1024] > Now (C) is allowed to send pre-handshake data up to 1024 for each of > allocated slots. Why not just send NewChannelSlots[ADD=3,PER_CHANNEL_QUOTA=1024]? (Or SHARED_QUOTA, whatever seems to work best.) > Here, the client attempts to open a new logical channel using the first > allocated slot. > (C) sends AddChannelRequest[ID=1] Replace with: (C) sends AddChannelRequest[CLIENT_ASSIGNED_ID=1] (where the ID is whatever the client says it should be - or it might follow some rule such as incrementing from 1 each new one). > (C) sends TextData[len=512] Yes. The channel data quota on the client is now 512. > (C) receives AddChannelResponse[ID=1, success] Yes. But the ID is what the client assigned. The server can also send response data immediately after this, if it has some very quickly. > (C) receives NewChannelSlot[ID=4] Replace with: (C) receives NewChannelSlots[ADD=1,PER_CHANNEL_QUOTA=1024]. (Or it can be a flag in the AddChannelResponse parameters in the common case where it's COUNT=1 and the data quotas haven't changed, but that's just a special case to compress a message.) This is the same method as flow control for bytes in a channel, but for new channel counts. Send out messages granting more room. > (C) receives FlowControl[ID=1, quota=1024] > Now channel 1 is open and its quota is 1536. Yes. So the main differences between your and my scheme here is: - the client assigns IDs - the server sends one count update, not a message for each slot In both schemes, new channel assignment is "pessimistic" in the sense that channel requests can't block the socket or get rejected at the mux level. If it turns out to that network scaling behaviour improves with "optimistic" requests that can fail and be retried, it can be built on top of this in various ways, such as NewChannelSlotsAck for when slots are reduced (negative ADD, round trip before server is allowed to block) or AddChannelDropped (client must retry, here or elsewhere, and it's guaranteed the server did not act on the data sent; allows server to remove quota immediately instead of round-trip). However TCP works fine without this sort of "quota retraction", using gradually increasing window if needed to share memory, so I don't know that it's useful and I would bet on low-quality clients reacting buggily to it. -- Jamie From arman@noemax.com Fri Jun 22 05:19:11 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 9E50721F8600 for ; Fri, 22 Jun 2012 05:19:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[AWL=0.151, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 nnQmbkVGnL8x for ; Fri, 22 Jun 2012 05:19:08 -0700 (PDT) Received: from mail.noemax.com (mail.noemax.com [64.34.201.8]) by ietfa.amsl.com (Postfix) with ESMTP id 312BC21F85C0 for ; Fri, 22 Jun 2012 05:19:08 -0700 (PDT) DKIM-Signature: a=rsa-sha1; t=1340367553; x=1340972353; s=m1024; d=noemax.com; c=relaxed/relaxed; v=1; bh=lKqfKml6vsiXpIf8xL2k+LKS65E=; h=From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:In-Reply-To:References; b=22zsziU9NyFm7Bt4eE6tQLwPXzbKSdInxrvWC9xF/GuAE7MYuJfLv6L6U5DNYQwmcvwQD8Di1J5Xd0DIUWCxYeuKq8wufINNgAZhSMHsNDiYDZldiLIttmmVcrPlrMG/TgjP8CWFsQRjDP+I5R+WkUzAG5A0BWzOyo15oENaavQ= Received: from mail.noemax.com by mail.noemax.com (IceWarp 10.4.1) with ASMTP (SSL) id GSP30111; Fri, 22 Jun 2012 15:19:11 +0300 From: "Arman Djusupov" To: "'Takeshi Yoshino'" References: <002f01cd3cc4$4791b380$d6b51a80$@noemax.com> <20120607034440.GD26406@jl-vm1.vm.bytemark.co.uk> <002001cd4a14$53eb66f0$fbc234d0$@noemax.com> <001301cd4acf$d8c5cda0$8a5168e0$@noemax.com> <6A3569A8-C253-4363-B00C-F336B0CA3128@noemax.com> <000301cd503d$0aff8f00$20fead00$@noemax.com> <002101cd504f$d8a20e30$89e62a90$@noemax.com> In-Reply-To: Date: Fri, 22 Jun 2012 15:18:47 +0300 Message-ID: <004901cd5071$30fa9ef0$92efdcd0$@noemax.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_004A_01CD508A.564ABD20" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHbEEjWH8q2xL+U7IgUz4ieagM0MAIpCHL8APvLbp8B3rSIHAHfCnvqAiE9EN8B8r7HPACD0WVjAIKfMBgB696tEgIeY34vAi4tHFcCuqrLZAFq3anoAdNpLTmWKU2d4A== Content-Language: en-us Cc: hybi@ietf.org Subject: Re: [hybi] Multiplexing: Pre-AddChannelResponse quota 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, 22 Jun 2012 12:19:11 -0000 This is a multipart message in MIME format. ------=_NextPart_000_004A_01CD508A.564ABD20 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit My idea was that the server can deliver the pre-handshake quotas using the NewChannelSlot frame and update it only once it has received the AddChannelRequest with the channel ID assigned by the client. The server does not need to update this value often anyway, it is best to update it once a new channel has been created. If the server sends the additional quota using the FC frame as soon as it has received the AddChannelRequest, then there will be no delay, granted that the pre-handshake-quota quota was large enough. So it would look like this: (C) receives Physical channel server's opening handshake (C) receives NewChannelSlot[pre-handshake-quota=1024] (C) receives NewChannelSlot[pre-handshake-quota =1024] (C) receives NewChannelSlot[pre-handshake-quota =1024] Now (C) can issue three AddChannelRequests and may send some pre-handshake data. (C) sends AddChannelRequests(channelID = 2), AddChannelRequests(channelID = 3), AddChannelRequests(channelID = 4) // server may assume the slots are used in the queue order As soon as the server receives the AddChannelRequests it sends a FC frame for each channel without any delay and before even evaluating those requests. (C) receives FlowControl[ID=2, quota=2048] (C) receives FlowControl[ID=3, quota=2048] (C) receives FlowControl[ID=4, quota=2048] Now (C) adds 2048 quota to each allocated logical channel while already sending data so that it can send more data without delay. As long as the server can receive more data it will be sending more FC frames with more quota. Here is an example that shows how the client attempts to open a new logical channel using the first allocated slot. --- Physical Channel Handshake- (C) receives NewChannelSlot[pre-handshake-quota=1024] // slot for a new channel (C) receives FlowControl[ID=1, quota=1024] // quota for first channel (irrelevant to the sample, but has to be there) -- Second Logical Channel (C) sends AddChannelRequest[ID=2] (C) sends TextData[len=512] (C) receives FlowControl[ID=2, quota=1024] // channel#2 quota now equal to 1536 (C) receives AddChannelResponse[ID=2, success] (C) receives FlowControl[ID=2, quota=1024] // channel#2 quota now equal to 2560 We simply eliminate the pre-handshake quota and post-handshake quota. Flow control starts from the first byte sent after sending the AddChannelRequest irrespective of when or whether the AddChannelResponse is received. The initial quota value is defined by the NewChannelSlot message and is supplemented by normal FC frames with a channel ID that is equal to the one specified by the AddChannelRequest. In this case we don't need slot IDs. The next slot will always be the next slot in the queue. I don't think we need to update a slot quota before it is used, because in order to use this functionality the server would have to broadcast new quotas every time some buffer space is released. This will make it a real-time "quota feed", I really don't think any server would spend resources on keeping the client slot quotas up to date with the server capacity. It's more reasonable to give a slot some nice initial quota value and then update it as soon as possible once the client has used the slot. With best regards, Arman From: Takeshi Yoshino [mailto:tyoshino@google.com] Sent: Friday, June 22, 2012 1:54 PM To: Arman Djusupov Cc: Jamie Lokier; hybi@ietf.org Subject: Re: [hybi] Multiplexing: Pre-AddChannelResponse quota On Fri, Jun 22, 2012 at 5:20 PM, Arman Djusupov wrote: Hmm, actually this model can also work without the server assigning channel IDs. The server simply needs to provide an initial quota to the slot and then we have to allow the server to send FC frames to the client's logical channel before the handshake is complete. Without the server assigning some identifier for the new slot (doesn't need to be the channel ID to be used after channel open, but some identifier), we cannot match the slot and the pre-handshake FC frames. Sorry but could you elaborate your idea? Maybe, you said here that we'll be able to send FC after receiving AddChannelRequest and before sending back AddChannelResponse? What I had in my mind is like this: (C) receives Physical channel server's opening handshake (C) receives NewChannelSlot[ID=1] (C) receives NewChannelSlot[ID=2] (C) receives NewChannelSlot[ID=3] Now (C) can issue three AddChannelRequests but may not send any pre-handshake data. (C) receives FlowControl[ID=1, quota=1024] (C) receives FlowControl[ID=2, quota=1024] (C) receives FlowControl[ID=3, quota=1024] Now (C) is allowed to send pre-handshake data up to 1024 for each of allocated slots. Here, the client attempts to open a new logical channel using the first allocated slot. (C) sends AddChannelRequest[ID=1] (C) sends TextData[len=512] (C) receives AddChannelResponse[ID=1, success] (C) receives NewChannelSlot[ID=4] (C) receives FlowControl[ID=1, quota=1024] Now channel 1 is open and its quota is 1536. ------=_NextPart_000_004A_01CD508A.564ABD20 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

My idea was that the server can deliver the pre-handshake quotas = using the NewChannelSlot frame and update it only once it has = received the AddChannelRequest with the channel ID assigned by the = client. The server does not need to update this value often anyway, it = is best to update it once a new channel has been created. If the server = sends the additional quota using the FC frame as soon as it has received = the AddChannelRequest, then there will be no delay, granted that the = pre-handshake-quota quota was large enough.

 

So it would look like this:

 

(C) receives Physical channel server's opening = handshake

(C) receives = NewChannelSlot[pre-handshake-quota=3D1024]

(C) receives NewChannelSlot[pre-handshake-quota = =3D1024]

(C) receives NewChannelSlot[pre-handshake-quota = =3D1024]

 

Now (C) can issue three AddChannelRequests and may send some = pre-handshake data.

 

(C) sends AddChannelRequests(channelID =3D 2), = AddChannelRequests(channelID =3D 3), AddChannelRequests(channelID =3D = 4)  // server may assume the slots are used in the queue = order

 

As soon as the server receives the AddChannelRequests it sends a FC = frame for each channel without any delay and before even evaluating = those requests.

 

(C) receives FlowControl[ID=3D2, = quota=3D2048]

(C) receives FlowControl[ID=3D3, = quota=3D2048]

(C) receives FlowControl[ID=3D4, = quota=3D2048]

 

Now (C) adds 2048 quota to each allocated logical channel while = already sending data so that it can send more data without delay. As = long as the server can receive more data it will be sending more FC = frames with more quota.

 

Here is an example that shows how the client attempts to open a new = logical channel using the first allocated slot.

 

--- Physical Channel Handshake—

(C) receives = NewChannelSlot[pre-handshake-quota=3D1024]     &= nbsp;            =             /= / slot for a new channel

(C) receives FlowControl[ID=3D1, = quota=3D1024]          =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p; // quota for first channel (irrelevant to  the sample, but has = to be there)

 

-- Second Logical Channel

(C) sends AddChannelRequest[ID=3D2]

(C) sends TextData[len=3D512]

(C) receives FlowControl[ID=3D2, quota=3D1024] =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;          // = channel#2 quota now equal to 1536

(C) receives AddChannelResponse[ID=3D2, = success]

(C) receives FlowControl[ID=3D2, = quota=3D1024]          =             &= nbsp;           &n= bsp;    =             &= nbsp;        // channel#2 quota now = equal to 2560

 

 

We simply eliminate the pre-handshake quota and post-handshake quota. = Flow control starts from the first byte sent after sending the = AddChannelRequest irrespective of when or whether the AddChannelResponse = is received. The initial quota value is defined by the NewChannelSlot = message and is supplemented by normal FC frames with a channel ID that = is equal to the one specified by the = AddChannelRequest.

 

In this case we don’t need slot IDs. The next slot will always = be the next slot in the queue.

 

I don’t think we need to update a slot quota before it is used, = because in order to use this functionality the server would have to = broadcast new quotas every time some buffer space is released. This will = make it a real-time “quota feed”, I really don’t think = any server would spend resources on keeping the client slot quotas = up to date with the server capacity. It’s more reasonable to give = a slot some nice initial quota value and then update it as soon as = possible once the client has used the slot.

 

With best regards,

Arman

 

 

From:= = Takeshi Yoshino [mailto:tyoshino@google.com]
Sent: Friday, = June 22, 2012 1:54 PM
To: Arman Djusupov
Cc: Jamie = Lokier; hybi@ietf.org
Subject: Re: [hybi] Multiplexing: = Pre-AddChannelResponse quota

 

On = Fri, Jun 22, 2012 at 5:20 PM, Arman Djusupov <arman@noemax.com> = wrote:

Hmm, actually this model can also work without the server assigning = channel IDs. The server simply needs to provide an initial quota to the = slot and then we have to allow the server to send FC frames to the = client’s logical channel before the handshake is = complete.

 

Without the server assigning = some identifier for the new slot (doesn't need to be the channel ID to = be used after channel open, but some identifier), we cannot match the = slot and the pre-handshake FC frames.

 

Sorry but could you elaborate = your idea? Maybe, you said here that we'll be able to send FC after = receiving AddChannelRequest and before sending back = AddChannelResponse?

 

What I had in my mind is like = this:

 

(C) receives Physical channel = server's opening handshake

(C) = receives NewChannelSlot[ID=3D1]

(C) = receives NewChannelSlot[ID=3D2]

(C) = receives NewChannelSlot[ID=3D3]

 

Now (C) can issue three = AddChannelRequests but may not send any pre-handshake = data.

 

(C) receives = FlowControl[ID=3D1, quota=3D1024]
(C) receives FlowControl[ID=3D2, = quota=3D1024]
(C) receives FlowControl[ID=3D3, = quota=3D1024]

 

Now (C) is allowed to send = pre-handshake data up to 1024 for each of allocated = slots.

Here, the client attempts to = open a new logical channel using the first allocated = slot.

 

(C) sends = AddChannelRequest[ID=3D1]
(C) sends = TextData[len=3D512]

(C) = receives AddChannelResponse[ID=3D1, = success]

(C) receives = NewChannelSlot[ID=3D4]

(C) = receives FlowControl[ID=3D1, = quota=3D1024]

 

Now channel 1 is open and its = quota  is 1536.

 

------=_NextPart_000_004A_01CD508A.564ABD20-- From jamie@shareable.org Fri Jun 22 19:39:19 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 5EC4B21F849B for ; Fri, 22 Jun 2012 19:39:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 V+YUMll59Dey for ; Fri, 22 Jun 2012 19:39:19 -0700 (PDT) Received: from mail2.shareable.org (mail2.shareable.org [80.68.89.115]) by ietfa.amsl.com (Postfix) with ESMTP id C890521F849A for ; Fri, 22 Jun 2012 19:39:18 -0700 (PDT) Received: from jamie by mail2.shareable.org with local (Exim 4.63) (envelope-from ) id 1SiGFn-0003Us-Ig; Sat, 23 Jun 2012 03:39:15 +0100 Date: Sat, 23 Jun 2012 03:39:15 +0100 From: Jamie Lokier To: Martin Sustrik Message-ID: <20120623023915.GT5812@jl-vm1.vm.bytemark.co.uk> References: <001001cd4000$fe2c82c0$fa858840$@noemax.com> <4FCCAE6B.1010306@250bpm.com> <002d01cd4262$747957b0$5d6c0710$@noemax.com> <20120607022312.GA26406@jl-vm1.vm.bytemark.co.uk> <000e01cd449d$1c0ed220$542c7660$@noemax.com> <000401cd4566$d5f6bb70$81e43250$@noemax.com> <4FD85D7C.3000902@250bpm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4FD85D7C.3000902@250bpm.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: hybi@ietf.org Subject: Re: [hybi] Flow control quota 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: Sat, 23 Jun 2012 02:39:19 -0000 Martin Sustrik wrote: > On 13/06/12 08:50, Takeshi Yoshino wrote: > > >It's also an option that we give up frame-level extensions other than mux. > > That makes sense IMO. Fragmentation is an integral part of > multiplexing. Using it for other purposes is just asking for > trouble. Without fragmentation, that means a non-multiplexing proxy can't send a control message to say why it's dropping the connection, in the middle of a large message. E.g. to distinguish between connection-reset (RST), connection-closed (FIN), and connection TCP keepalive timeout; something which the receiver can distinguish when there's no proxy. Connections with a proxy in the way should be able to relay the same error conditions as without one, but they can't forward those "direct" over TCP, they have to be converted to control messages. I'm not saying that's important, just that it's an effect of fragmentation that doesn't depend on mux. -- Jamie From tyoshino@google.com Sun Jun 24 19:19:41 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 3EC9021F85F6 for ; Sun, 24 Jun 2012 19:19:41 -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=[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 nkDIN3F6e+3l for ; Sun, 24 Jun 2012 19:19:40 -0700 (PDT) Received: from mail-gg0-f172.google.com (mail-gg0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8F2AD21F858A for ; Sun, 24 Jun 2012 19:19:40 -0700 (PDT) Received: by ggnc4 with SMTP id c4so2730484ggn.31 for ; Sun, 24 Jun 2012 19:19:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=xMgi/HZIO6o/b7z7+p97LMTE+Osho9ZMcKpCTImp9Ps=; b=dA7dM9aU6pX8ycyDKnPJT+lROeoF5/PHePLMYPiOQALabT/DCUNb9mYJJ/ieWPgOCv 0tpjhVkBduHZCmcvF/sCvXAenC5R0GzCgOcCij0aaiMAAWTmfGwRHP5Cnulv/ugoSXIc LzE1QgK2fIu5C+zfdWPrmF/AJGUNTmpcpIx9X4PMCY0vXrfh3i/eueaeAuVEM7DWhqtw 7MLI9/Rno7VQgzYPXPiVlm5O7vOwCdpn5QaWqxl3MXkj7TtpB9fApz75Xg+MhiD8xekp rMY6qAwr7PjrRSCXzwLBc7Ukeygerm79Al/2OcW4FjiJ9ZsAO60p3Gu0J9Nh+8tSJMlZ uw8Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=xMgi/HZIO6o/b7z7+p97LMTE+Osho9ZMcKpCTImp9Ps=; b=kvVqVxW2m5a/pGumvm1sGH3rviL2/J6seegRTSjMB3MQdn/0qz8zBWQvI1OfgFI8Cz pKLLC8hwUz5DnHTZ5p1uPSraioaI2r/oWukVwHqmp0b0OaikLKcTkeyUgnLBG4D9Gu6M We1wlHiphfycZYvFoCvK8oom2L9KwjqNwjqhbbr2XZf6tiVbBHMltbqdshGa8gVXbqOx vu8FNLqjv+QsdJmYQXDQtbxVyorr5S3j45SecQmr/aN43gVIB6o9AJgiYA4fKVCg33S/ MCIjEFUNwcQ0BuygM2ShcIBTILDfn5kvPJ/wAnD3jNBqJl7mk+Iv4WK+qwurovp3L1Jq wr2g== Received: by 10.50.160.234 with SMTP id xn10mr6832617igb.61.1340590779493; Sun, 24 Jun 2012 19:19:39 -0700 (PDT) Received: by 10.50.160.234 with SMTP id xn10mr6832609igb.61.1340590779405; Sun, 24 Jun 2012 19:19:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.66.7 with HTTP; Sun, 24 Jun 2012 19:19:18 -0700 (PDT) In-Reply-To: <20120622121738.GR5812@jl-vm1.vm.bytemark.co.uk> References: <002001cd4a14$53eb66f0$fbc234d0$@noemax.com> <001301cd4acf$d8c5cda0$8a5168e0$@noemax.com> <6A3569A8-C253-4363-B00C-F336B0CA3128@noemax.com> <000301cd503d$0aff8f00$20fead00$@noemax.com> <002101cd504f$d8a20e30$89e62a90$@noemax.com> <20120622121738.GR5812@jl-vm1.vm.bytemark.co.uk> From: Takeshi Yoshino Date: Mon, 25 Jun 2012 11:19:18 +0900 Message-ID: To: Jamie Lokier Content-Type: multipart/alternative; boundary=14dae934030332158904c3429d36 X-System-Of-Record: true X-Gm-Message-State: ALoCoQn3/pkPg7NRZ2fd6iRhIR+/6vKxHTzBXBC9k54e/IhhSWCCsVQyLPZIXlS6tDT7zZZw9HbCOWCI4caEm8ZWWT9IjwCwF898Tw7s6I+V1BcLfSzM5O9VSDiBxqGuQTM6wM5Apikf6Z4BEehk4cTJjODt6hB4nidhyn5/DD7+jYRvfLZf42E= Cc: hybi@ietf.org Subject: Re: [hybi] Multiplexing: Pre-AddChannelResponse quota 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, 25 Jun 2012 02:19:41 -0000 --14dae934030332158904c3429d36 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Jun 22, 2012 at 9:17 PM, Jamie Lokier wrote: > Why not just send NewChannelSlots[ADD=3], instead of 3 > NewChannelSlot messages? > > The slot messages are wasteful if the server is happy to accept 1000 > low-usage slots from the beginning. > > > (C) receives FlowControl[ID=1, quota=1024] > > (C) receives FlowControl[ID=2, quota=1024] > > (C) receives FlowControl[ID=3, quota=1024] > > Now (C) is allowed to send pre-handshake data up to 1024 for each of > > allocated slots. > > Why not just send NewChannelSlots[ADD=3,PER_CHANNEL_QUOTA=1024]? > > This is fine if we don't need a way to increase pre-handshake quota for the slots after allocating them e.g. when the server gets more room for processing after the allocation. (C) receives NewChannelSlots[ADD=1,PER_CHANNEL_QUOTA=1024]. > > (Or it can be a flag in the AddChannelResponse parameters in the > common case where it's COUNT=1 and the data quotas haven't changed, > but that's just a special case to compress a message.) > Yes. --14dae934030332158904c3429d36 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Fri, Jun 22, 2012 at 9:17 PM, Jamie Lokier <jamie@shareab= le.org> wrote:
Why not just send NewChann= elSlots[ADD=3D3], instead of 3
NewChannelSlot messages?

The slot messages are wasteful if the server is happy to accept 1000
low-usage slots from the beginning.

> =A0 =A0(C) receives FlowControl[ID=3D1, quota=3D1024]
> =A0 =A0(C) receives FlowControl[ID=3D2, quota=3D1024]
> =A0 =A0(C) receives FlowControl[ID=3D3, quota=3D1024]
> =A0 =A0Now (C) is allowed to send pre-handshake data up to 1024 for ea= ch of
> =A0 =A0allocated slots.

Why not just send NewChannelSlots[ADD=3D3,PER_CHANNEL_QUOTA=3D1024]?<= br>

This is fine if we don't need a wa= y to increase pre-handshake quota for the slots after allocating them e.g. = when the server gets more room for processing after the allocation.

=A0 =A0(C) receives New= ChannelSlots[ADD=3D1,PER_CHANNEL_QUOTA=3D1024].

(Or it can be a flag in the AddChannelResponse parameters in the
common case where it's COUNT=3D1 and the data quotas haven't change= d,
but that's just a special case to compress a message.)
=

Yes.
--14dae934030332158904c3429d36-- From tyoshino@google.com Sun Jun 24 19:29:56 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 538C111E8073 for ; Sun, 24 Jun 2012 19:29:56 -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 vHZMJkqQGNw8 for ; Sun, 24 Jun 2012 19:29:55 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id B7C8E21F858F for ; Sun, 24 Jun 2012 19:29:55 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so6667786obb.31 for ; Sun, 24 Jun 2012 19:29:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=pP9Hf4NkAa5prTfnxmM05M0OIGYm7dvDI2r7X1pp8b0=; b=ANs3fCRmY3OKaI1NMSbQb+ljYBrnRNVd7xFFduk5BlZY3QuY1hTAM4kt46Ay5VAv9o wDzqTZzJWTSE1G/hJjLqzUtMReV3naHiZsN2cBK0aHXEX9pQprg+1prkL/yt5IMuKC3P luniTfOahAkR0p9dAKuY0JrsxExWjqAnw8YlBFMmNSgCNA4r2xE3sLGXONpq9juNnraR gcJ8J7lMVnGsgdCjVH3RK6g3zYVGT5mlqq1zJT1o42CiPmaH/1CluxvJKL/qPSCaviD9 VnY6F7cblk/Ovxzx7v+IR58jsDEEjZTKj6U1ZJ/zxcfjozyCN3I5X7Zc0wyhNNILkj9K +QUQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=pP9Hf4NkAa5prTfnxmM05M0OIGYm7dvDI2r7X1pp8b0=; b=PvhNRxoxdAKSvilNTOcuyu3ACWHNeFsIhI9FFWSfB1tHknI4GuMETBcsE5pI121GKz +IYXMt/0yC5tinsWC/pLIG5oHFTGO0K76h/Xht3JdgfQnqplkMoTWPdlLCBX5f0LBhDV P/Q2iXbQ3DTecWripoPrBV7ut1eBewlTlFmn1a28qbchSoLUc5qHpOXn9l6pujd5e3PW kadZn4h/BOPZ3htgFILTA8wlwgLsO3zEV9o7/MtPOPJjY13yVjdfIkK2wL1SBHcIDpOm bcMoUtFCrvZNe6dSyHsys9saDGZoXg0ufMLbBN2Iqh+vX4sKBJ9c8Evvn/Ph9Uxh6//3 L9kQ== Received: by 10.50.160.234 with SMTP id xn10mr6843647igb.61.1340591395275; Sun, 24 Jun 2012 19:29:55 -0700 (PDT) Received: by 10.50.160.234 with SMTP id xn10mr6843642igb.61.1340591395076; Sun, 24 Jun 2012 19:29:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.66.7 with HTTP; Sun, 24 Jun 2012 19:29:34 -0700 (PDT) In-Reply-To: <004901cd5071$30fa9ef0$92efdcd0$@noemax.com> References: <002f01cd3cc4$4791b380$d6b51a80$@noemax.com> <20120607034440.GD26406@jl-vm1.vm.bytemark.co.uk> <002001cd4a14$53eb66f0$fbc234d0$@noemax.com> <001301cd4acf$d8c5cda0$8a5168e0$@noemax.com> <6A3569A8-C253-4363-B00C-F336B0CA3128@noemax.com> <000301cd503d$0aff8f00$20fead00$@noemax.com> <002101cd504f$d8a20e30$89e62a90$@noemax.com> <004901cd5071$30fa9ef0$92efdcd0$@noemax.com> From: Takeshi Yoshino Date: Mon, 25 Jun 2012 11:29:34 +0900 Message-ID: To: Arman Djusupov Content-Type: multipart/alternative; boundary=14dae9340303e47c0a04c342c109 X-System-Of-Record: true X-Gm-Message-State: ALoCoQnhI+0kj3teXNHxe5Dofp/U0RRr7jkcrzMEi5MhpOyczZlKA4I7bZjeQvV+5Vht2D7OsS9Xv53sh1XzGMqcw2Sj/VqR+hvPF1LNhONS7Xe+84eky5Rck2lrDCA2a0YxUNJYK3VvA5QrcqMhvZI7TRFORPeuu/J+dL31DHEDsThJ/r526wk= Cc: hybi@ietf.org Subject: Re: [hybi] Multiplexing: Pre-AddChannelResponse quota 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, 25 Jun 2012 02:29:56 -0000 --14dae9340303e47c0a04c342c109 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable OK, I understood your thoughts, Jamie, Arman. I'll take in your idea. On Fri, Jun 22, 2012 at 9:18 PM, Arman Djusupov wrote: > I don=92t think we need to update a slot quota before it is used, because= in > order to use this functionality the server would have to broadcast new > quotas every time some buffer space is released. This will make it a > real-time =93quota feed=94, I really don=92t think any server would spend > resources on keeping the client slot quotas up to date with the server > capacity. It=92s more reasonable to give a slot some nice initial quota v= alue > and then update it as soon as possible once the client has used the slot. > --14dae9340303e47c0a04c342c109 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
OK, I understood your thoughts, Jamie, Arman.

I'll take in your= idea.

On Fri, Jun= 22, 2012 at 9:18 PM, Arman Djusupov <arman@noemax.com> wrote= :

<= span style=3D"color:rgb(31,73,125);font-family:Calibri,sans-serif;font-size= :11pt">I don=92t think we need to update a slot quota before it is used, be= cause in order to use this functionality the server would have to broadcast= new quotas every time some buffer space is released. This will make it a r= eal-time =93quota feed=94, I really don=92t think any server would spend re= sources on=A0keeping the client slot quotas up to date with the server capa= city. It=92s more reasonable to give a slot some nice initial quota value a= nd then update it as soon as possible once the client has used the slot.

--14dae9340303e47c0a04c342c109-- From tyoshino@google.com Mon Jun 25 01:46:29 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 1E69021F84CE for ; 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 ; 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 ; Mon, 25 Jun 2012 01:46:24 -0700 (PDT) Received: by yenq13 with SMTP id q13so2875207yen.31 for ; 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 Date: Mon, 25 Jun 2012 17:46:03 +0900 Message-ID: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jun 2012 08:46:29 -0000 --e89a8f3bad134a18d304c3480441 Content-Type: text/plain; charset=ISO-8859-1 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 --e89a8f3bad134a18d304c3480441 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Recently s= ome issue with integration between compression and multiplexing was pointed= out on the list.


In summary,

a) current per-fra= me compression locks down fragmentation since it flips RSV1 for each frame = and it requires frame boundary unchanged to apply decompression algorithm c= orrectly
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 implem= entation, 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 mes= sage). But then, the changed compression cannot be applied to the stream af= ter 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. T= his idea got lots of objection due to it's extra overhead when the base= framing was discussed. Taking into account the issue, and possible layerin= g problems in the future, how about revisiting multiplex layering now?

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

Takeshi
--e89a8f3bad134a18d304c3480441-- From tyoshino@google.com Mon Jun 25 01:46:30 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 CE43F21F84CE for ; Mon, 25 Jun 2012 01:46:30 -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=[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 62-Wmzjt4TCg for ; Mon, 25 Jun 2012 01:46:30 -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 3034321F848A for ; Mon, 25 Jun 2012 01:46:30 -0700 (PDT) Received: by mail-yx0-f172.google.com with SMTP id q13so2875207yen.31 for ; Mon, 25 Jun 2012 01:46:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=bDDctrhfRLDo6F/OL4RrtAJg49BJgHMhPT6ZGQG6p3M=; b=HEyv5yR6pwCCVugH+3j6FQ9AkmICoOuGX8oFVUQ+lCpljepKcbK7lhLRxuK6S19x9g znwmk9Y0Hdgb3WAHBzE2dxIEGidKmCmOlw3uhivv+HaEWxWFRVt+t02cZLWHpLeXM9P1 QC2JeAS2JKMPcDXgJrHsHY+9DuRUGgqo/WvGnwNhryfgxkTBCB3vELNxNrcCAiFPt3+d 9CDONOMEGhgYqBBe4bTRFoOWIZIq635S4QFp6GFOk9oTqHmhSS1bg1P0juxjlL9pgRZJ mx8Pf6sHz4YHblbWbyfgLn+WEiH+Ubh/J4KiIzAi7KCF9mU1WkuyZ4PUpOa3CrbQ1P/d ykbg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=bDDctrhfRLDo6F/OL4RrtAJg49BJgHMhPT6ZGQG6p3M=; b=GGpSbx2FlL5ip0jen47grvr1QcCZD7OyjciJlmD+8uHwo38EvKMRd5Fjb0oZknAc3n 5900/AJqp2diRg/177HsheAdGzhp+tVtaZrloRnROAclWQDtVmIMR/klfNv3NDbGgVHO tOOmDVW8xr/ZSbPByFDAeIfvkoWEFNZ5H/bRyXGQ7ShhBagqa116VxwaDbgDleiykcSF sxOFlwhQDw5UJhX/wva6oVQ5ZoLP9ihyh3gmpIoxoigJdj8+ZiWHtkYxRVfRnZg3XDps yC8fFW+IVq2eLI2OvGKDOZr+LjkB1Vt6YlxGypxjaVCMSIVX8zmJLuo/q3KFWzB1Fb7O f+7Q== Received: by 10.50.160.202 with SMTP id xm10mr7555912igb.10.1340613989808; Mon, 25 Jun 2012 01:46:29 -0700 (PDT) Received: by 10.50.160.202 with SMTP id xm10mr7555899igb.10.1340613989653; Mon, 25 Jun 2012 01:46:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.66.7 with HTTP; Mon, 25 Jun 2012 01:46:09 -0700 (PDT) In-Reply-To: <000401cd4566$d5f6bb70$81e43250$@noemax.com> References: <001a01cd3e69$4a221c10$de665430$@noemax.com> <4FC732DC.3000308@250bpm.com> <000e01cd3f1c$af15ad40$0d4107c0$@noemax.com> <4FC880A7.9070007@250bpm.com> <001001cd4000$fe2c82c0$fa858840$@noemax.com> <4FCCAE6B.1010306@250bpm.com> <002d01cd4262$747957b0$5d6c0710$@noemax.com> <20120607022312.GA26406@jl-vm1.vm.bytemark.co.uk> <000e01cd449d$1c0ed220$542c7660$@noemax.com> <000401cd4566$d5f6bb70$81e43250$@noemax.com> From: Takeshi Yoshino Date: Mon, 25 Jun 2012 17:46:09 +0900 Message-ID: To: Arman Djusupov Content-Type: multipart/alternative; boundary=14dae9340eb7a25e3f04c3480495 X-System-Of-Record: true X-Gm-Message-State: ALoCoQl7xuk3FqqhlJSEghtg3+7UgX0x9umKCV6wjoA2ha1JRsXz8x86wUXzU2xte0njVJhtzOKCjSLvQ4SXsZr1CVxEZXhrdFeBYCMJiheuytKVYuuZA9JSZpw311MI/u7lLzuuypRi2RciBHGGfAFS5MRWrs7p02/AeT/38DqmCajpuN0H5vI= Cc: hybi@ietf.org Subject: Re: [hybi] Flow control quota 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, 25 Jun 2012 08:46:30 -0000 --14dae9340eb7a25e3f04c3480495 Content-Type: text/plain; charset=ISO-8859-1 I think use of "message" boundary is safe. So, I'd 1. remove MASK bit, (extended) payload length, masking-key (if any) from the original frame 2. put the remaining bytes into one WebSocket message (opcode=2 as you said) together with channel ID On Fri, Jun 8, 2012 at 8:06 PM, Arman Djusupov wrote: > A solution for the 2nd option: > We need to encapsulate frame fragments into a mux message. In this case all > mux frames would have their FIN bit set to 1 and opCode set to 2 (binary), > so the payload of a mux frame will be transparent to all intermediaries > that > do not support mux. still true > Mux frames would retain the current format and would > have channelID in their extension data. Moved to the top of the encapsulating message. > In addition to that each mux message that corresponds to the first fragment of the original frame would include > the frame length, Replaced with the encapsulating message's message length information. > opCode, FIN flag and RSV bits of the original frame; > still true. > subsequent mux frames would include only the payload of the fragment. > > This format would introduce an additional overhead of 16 to 72 bits per > original frame. > Additional overhead will be 1 octet per original frame. --14dae9340eb7a25e3f04c3480495 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I think use of "message" boundary is safe. So, I'= d

1. remove MASK bit, (extended) payload length, masking-key (if any) from th= e original frame
2. put the remaining bytes= into one WebSocket message (opcode=3D2 as you said) together with channel = ID

On Fri, Jun= 8, 2012 at 8:06 PM, Arman Djusupov <arman@noemax.com> wrote:=
A solution for the 2nd option:
We need to encapsulate frame fragments into a mux message. In this case all=
mux frames would have their FIN bit set to 1 and opCode set to 2 (binary),<= br> so the payload of a mux frame will be transparent to all intermediaries tha= t
do not support mux.

still true
= =A0
Mux frames would retain the curren= t format and would
have channelID in their extension data.

Mov= ed to the top of the encapsulating message.
=A0
=A0In addition to that each mux message
that corresponds to the first fragment of the original frame would include<= br> the frame length,

Replaced with the encapsu= lating message's message length information.
=A0
opCode, FIN flag and RSV bits of the original frame;
=
still true.
=A0
Date: Mon, 25 Jun 2012 02:08:33 -0700 Cc: hybi@ietf.org Subject: [hybi] I-D Action: draft-ietf-hybi-websocket-multiplexing-02.txt 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, 25 Jun 2012 09:09:03 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the BiDirectional or Server-Initiated HTTP Wo= rking Group of the IETF. Title : A Multiplexing Extension for WebSockets Author(s) : John A. Tamplin Takeshi Yoshino Filename : draft-ietf-hybi-websocket-multiplexing-02.txt Pages : 35 Date : 2012-06-25 Abstract: The WebSocket Protocol [RFC6455] requires a new transport connection for every WebSocket connection. This presents a scalability problem when many clients connect to the same server, and is made worse by having multiple clients running in different tabs of the same user agent. This extension provides a way for separate logical WebSocket connections to share an underlying transport connection. Please send feedback to the hybi@ietf.org mailing list. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-hybi-websocket-multiplexing There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-hybi-websocket-multiplexing-02 A diff from previous version is available at: http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-hybi-websocket-multiplexing= -02 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From tyoshino@google.com Mon Jun 25 02:13:26 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 962F521F84DD for ; Mon, 25 Jun 2012 02:13:26 -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=[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 DQ3tvVKlb836 for ; Mon, 25 Jun 2012 02:13:22 -0700 (PDT) Received: from mail-gh0-f172.google.com (mail-gh0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5C52321F847E for ; Mon, 25 Jun 2012 02:13:22 -0700 (PDT) Received: by ghbg16 with SMTP id g16so2902185ghb.31 for ; Mon, 25 Jun 2012 02:13:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type:x-system-of-record; bh=gkzmefqoJO2yXtoRnRetDInU7DrPma8uv1CI4QrTVfY=; b=A3HIoZZgZvhedYjKYc5D8AL8AWXoa1p7CzCy8hKcq84MvZZ0Hv76GbYLaIKFQOlp/9 3WVvyGYyiIK01HskY8ydBMF2HhSXaPGS/hDIlFQjfsx1IsgtlZvyvjisuhWx41VZCcWt eYr65fQuhT2iKirFnpZQMOXR8oXK0cOQuHkXzxucfC/oePzUYvAgxWZ1+FVAQkYf0bjm PSt5y0+QWlshYa/wOAFsu/EMUuXLw1qKxHrhvfvRMOWi6IrY2T6UbOBnRAZO1S6Grufg WIrxmfm7cLEJgDsetf/EnfOQIOArH05Rwag9bkRdx2CvfQoNEuAFMCKUKGQwvBtomY5U E+Rg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type:x-system-of-record:x-gm-message-state; bh=gkzmefqoJO2yXtoRnRetDInU7DrPma8uv1CI4QrTVfY=; b=eJcN+Yyj9SbmmvLt676xxmP4m9Z31JA9ZSZecG1eor2J2TlBpMQH9mZcw3590rPwhc xDfKP6qHrKxtbumNuiM9TIe1AttH4huQVVoGAExYwkBV4EuolLuAPfPpA3njpGYWChG/ KIuLcOqWfbMHhmT4wuzDt/NDWZgl7N+tkFKB1OBM0+zsZEbsnTEOJ1ekns55o7ECCbpI vaWljnpgcRt71wtM02oKGr+sDJ5A/wrqLb4yGOmS58rjwO8h3Nsy7n3PCZNqJnunYRZs fY8mFyh1rfuTEofuHVX4e2nP5D68UG3Kmv7SLoO7HB0FWqaSpCM0lMahwejE1MkrENpL CKuA== Received: by 10.50.173.65 with SMTP id bi1mr7479026igc.10.1340615601695; Mon, 25 Jun 2012 02:13:21 -0700 (PDT) Received: by 10.50.173.65 with SMTP id bi1mr7479016igc.10.1340615601455; Mon, 25 Jun 2012 02:13:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.66.7 with HTTP; Mon, 25 Jun 2012 02:13:01 -0700 (PDT) In-Reply-To: <20120625090833.31471.45078.idtracker@ietfa.amsl.com> References: <20120625090833.31471.45078.idtracker@ietfa.amsl.com> From: Takeshi Yoshino Date: Mon, 25 Jun 2012 18:13:01 +0900 Message-ID: To: hybi@ietf.org Content-Type: multipart/alternative; boundary=e89a8f6430e0b4827504c348648e X-System-Of-Record: true X-Gm-Message-State: ALoCoQkQrVYtgyk49+Zm6+U38yWeVDpoNSkm0x4wXwKeHr3Hm/+vPSYJdGylCfJd//DcNP9885IrDZzu68niPPMZyhPSSxZ7WxEE3hmgCluMaSnsrtj/GiX3O1TbMg2fZNW0IWxmZ5IGHjORSiETYGkqHspE90GfdSgUZbj8WWFUnv0dWfdRiH0= Subject: Re: [hybi] I-D Action: draft-ietf-hybi-websocket-multiplexing-02.txt 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, 25 Jun 2012 09:13:26 -0000 --e89a8f6430e0b4827504c348648e Content-Type: text/plain; charset=ISO-8859-1 Added NewChannelSlot command which allows the server side to regulate the rate of new channel creation attempt and to provide pre-handshake quota (client-to-server data flowing after AddChannelRequest without waiting for AddChannelResponse) See the discussion here: http://www.ietf.org/mail-archive/web/hybi/current/msg09676.html --e89a8f6430e0b4827504c348648e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Added NewChanne= lSlot command which allows the server side to regulate the rate of new chan= nel creation attempt and to provide pre-handshake quota (client-to-server d= ata flowing after AddChannelRequest without waiting for AddChannelResponse)=

See the discussion here:=A0
--e89a8f6430e0b4827504c348648e-- From tyoshino@google.com Mon Jun 25 02:29:03 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 C957B21F8473 for ; Mon, 25 Jun 2012 02:29:03 -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=[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 4Bnt-pflh0ol for ; Mon, 25 Jun 2012 02:29:03 -0700 (PDT) Received: from mail-yw0-f53.google.com (mail-yw0-f53.google.com [209.85.213.53]) by ietfa.amsl.com (Postfix) with ESMTP id D2D5F21F8466 for ; Mon, 25 Jun 2012 02:29:02 -0700 (PDT) Received: by mail-yw0-f53.google.com with SMTP id 26so4322983yhp.26 for ; Mon, 25 Jun 2012 02:29:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=7T8EMJmc5mJOsoKNBXQ0dxZAFla/wMhEvq687AD5OHo=; b=TnooJC0Y8EQ40dSyhB0hA1JvYDrRVe37AoF+fn8+Nijadr3WeTM5ywGYYi82LsiXo9 gkLrwxCYJqaT84j8k+XLi84biS9bfBndXNtZtSzZGIz9SkAeHE8tp9sr1UZOnBCcZZ9B be5hfWXcxiXH2jyOolJ5cQWxCRRqi0az2trs0sqvYe+ZuQ64e8GCGlngOlHJw5AGvDtm KlJkpBf4XKYjcy7JnBFq0TtuXQ2xhBZkhNpNa5eenCmQxukuegxbihsM/qJEbODAb0af WLCopUOJLM8/MeKkXW5Fbnz4JFeGJqJr6yDBKeAI9ndqmOoXSYHPOCSO7/n2eFVWKarX 3ctg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=7T8EMJmc5mJOsoKNBXQ0dxZAFla/wMhEvq687AD5OHo=; b=bDvggCawAL3sQ0VzHqSZFisleDc1w1qgqIoorcihVusGciwAndvzivF2x3tqsBAIPa MNbU9bLU68WGpPGr7gdGsztEOFsjc7ESVSMYPaR08tjyjPVO07xDP6mC26aQ4upOKxXn LLx0Y9PKllBlYbwc0wxovSNvQnNz5rhALG89ir9sHZD08ylA4qXJh/8oF+flAQcTzM4O MBidN2k+3W9a8qcdpBqpLHKF7vT681eE7XHavoy70yyGsdGj4QDhv56QRumeHA1Phv6k FWddi4qbvBYRMmZ4pQjh/U7Z5GrJ4KpOLV4fJJwOZBrw+VPsKVCuDPRa/Azc4drkR8xq TUaw== Received: by 10.50.156.194 with SMTP id wg2mr7457111igb.46.1340616542259; Mon, 25 Jun 2012 02:29:02 -0700 (PDT) Received: by 10.50.156.194 with SMTP id wg2mr7457098igb.46.1340616542077; Mon, 25 Jun 2012 02:29:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.66.7 with HTTP; Mon, 25 Jun 2012 02:28:41 -0700 (PDT) In-Reply-To: <20120623023915.GT5812@jl-vm1.vm.bytemark.co.uk> References: <001001cd4000$fe2c82c0$fa858840$@noemax.com> <4FCCAE6B.1010306@250bpm.com> <002d01cd4262$747957b0$5d6c0710$@noemax.com> <20120607022312.GA26406@jl-vm1.vm.bytemark.co.uk> <000e01cd449d$1c0ed220$542c7660$@noemax.com> <000401cd4566$d5f6bb70$81e43250$@noemax.com> <4FD85D7C.3000902@250bpm.com> <20120623023915.GT5812@jl-vm1.vm.bytemark.co.uk> From: Takeshi Yoshino Date: Mon, 25 Jun 2012 18:28:41 +0900 Message-ID: To: Jamie Lokier Content-Type: multipart/alternative; boundary=e89a8f3bafd5c543c104c3489cb9 X-System-Of-Record: true X-Gm-Message-State: ALoCoQnIMTUQooqeukGKDJ56awGQSY4pWly9fVTo3GbbWFdjhgXytTA8DEtenRWNpQdgNyalEoRnZNiI3BC+WUJkKzLIjlTbWUnAAbZKYFa7c6j5K6L73ixeuYX4JAxVbDda9t3sVtPE4D1LagWmFZX4sPyNWGwitwF2Zg0bewh8FhYuBQ5tNxU= Cc: hybi@ietf.org Subject: Re: [hybi] Flow control quota 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, 25 Jun 2012 09:29:03 -0000 --e89a8f3bafd5c543c104c3489cb9 Content-Type: text/plain; charset=ISO-8859-1 On Sat, Jun 23, 2012 at 11:39 AM, Jamie Lokier wrote: > Martin Sustrik wrote: > > On 13/06/12 08:50, Takeshi Yoshino wrote: > > > > >It's also an option that we give up frame-level extensions other than > mux. > > > > That makes sense IMO. Fragmentation is an integral part of > > multiplexing. Using it for other purposes is just asking for > > trouble. > Based on the context, I think that Martin just agreed with me in terms of avoiding use of fragmentation for other extensions such as compression but didn't mean that fragmentation should be exclusive for multiplexing. > Without fragmentation, that means a non-multiplexing proxy can't send > a control message to say why it's dropping the connection, in the > middle of a large message. E.g. to distinguish between > connection-reset (RST), connection-closed (FIN), and connection TCP > keepalive timeout; something which the receiver can distinguish when > there's no proxy. > Thanks. The fact that multiplexing itself locks fragmentation is sometimes problematic. This is one example for that. --e89a8f3bafd5c543c104c3489cb9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Sat, Jun 23, 2012 at 11:39 AM, Jamie Lokier <jamie@sharea= ble.org> wrote:
Mart= in Sustrik wrote:
> On 13/06/12 08:50, Takeshi Yoshino wrote:
>
> >It's also an option that we give up frame-level extensions oth= er than mux.
>
> That makes sense IMO. Fragmentation is an integral part of
> multiplexing. Using it for other purposes is just asking for
> trouble.

Based on= the context, I think that Martin just agreed with me in terms of avoiding = use of fragmentation for other extensions such as compression but didn'= t mean that fragmentation should be exclusive for multiplexing.
=A0
Without fragmentation, that means a non-multiplexing proxy can&= #39;t send
a control message to say why it's dropping the connection, in the
middle of a large message. =A0E.g. to distinguish between
connection-reset (RST), connection-closed (FIN), and connection TCP
keepalive timeout; something which the receiver can distinguish when
there's no proxy.

Thanks. The fact = that multiplexing itself locks fragmentation is sometimes problematic. This= is one example for that.

--e89a8f3bafd5c543c104c3489cb9-- From sustrik@250bpm.com Mon Jun 25 02:39:56 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 59BD921F8494 for ; Mon, 25 Jun 2012 02:39:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.694 X-Spam-Level: X-Spam-Status: No, score=-0.694 tagged_above=-999 required=5 tests=[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 E6OT8QBCPGYj for ; Mon, 25 Jun 2012 02:39:55 -0700 (PDT) Received: from mail.moloch.sk (chrocht.moloch.sk [62.176.169.44]) by ietfa.amsl.com (Postfix) with ESMTP id B815121F8474 for ; Mon, 25 Jun 2012 02:39:55 -0700 (PDT) Received: from [89.173.20.49] (chello089173020049.chello.sk [89.173.20.49]) by mail.moloch.sk (Postfix) with ESMTPSA id 03F99182BCCB; Mon, 25 Jun 2012 11:39:52 +0200 (CEST) Message-ID: <4FE831E8.90207@250bpm.com> Date: Mon, 25 Jun 2012 11:39:52 +0200 From: Martin Sustrik User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.24) Gecko/20111109 Thunderbird/3.1.16 MIME-Version: 1.0 To: Takeshi Yoshino References: <001001cd4000$fe2c82c0$fa858840$@noemax.com> <4FCCAE6B.1010306@250bpm.com> <002d01cd4262$747957b0$5d6c0710$@noemax.com> <20120607022312.GA26406@jl-vm1.vm.bytemark.co.uk> <000e01cd449d$1c0ed220$542c7660$@noemax.com> <000401cd4566$d5f6bb70$81e43250$@noemax.com> <4FD85D7C.3000902@250bpm.com> <20120623023915.GT5812@jl-vm1.vm.bytemark.co.uk> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: hybi@ietf.org Subject: Re: [hybi] Flow control quota 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, 25 Jun 2012 09:39:56 -0000 On 25/06/12 11:28, Takeshi Yoshino wrote: > On Sat, Jun 23, 2012 at 11:39 AM, Jamie Lokier > wrote: > > Martin Sustrik wrote: > > On 13/06/12 08:50, Takeshi Yoshino wrote: > > > > >It's also an option that we give up frame-level extensions other > than mux. > > > > That makes sense IMO. Fragmentation is an integral part of > > multiplexing. Using it for other purposes is just asking for > > trouble. > > > Based on the context, I think that Martin just agreed with me in terms > of avoiding use of fragmentation for other extensions such as > compression but didn't mean that fragmentation should be exclusive for > multiplexing. Yes. Exactly. Fragments can be used by layers below (WS protocol as such) but not by the layers above (other extensions, applications etc.) Compare that to TCP/IP: Packets are defined at IP level and used for control messages (SYN, RST, ...) by TCP. They are also used for transporting fragmented data. However, no layer on top (compression on top of TCP, application using TCP) can mess with the fragmentation. Martin From metajack@gmail.com Mon Jun 25 14:55:07 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 295C611E80C0; Mon, 25 Jun 2012 14:55:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 WQOnI5PYihwa; Mon, 25 Jun 2012 14:55:06 -0700 (PDT) Received: from mail-qa0-f44.google.com (mail-qa0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6455511E808C; Mon, 25 Jun 2012 14:55:06 -0700 (PDT) Received: by qadz3 with SMTP id z3so1616388qad.10 for ; Mon, 25 Jun 2012 14:55:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type :content-transfer-encoding; bh=uMIkcTPNZNIMRXfM2GQAh7zFVoh/H/Pb13J/0uLn7i4=; b=ShdmzzOgEskLZxFcA/tRsXkOxJHU+yhw6evB5pUsbmFzRrUHTEk1MBenpmRsEedYgq EY2pFSOiAU/Sc5yVFBMRZFcUDAxdJJQj9POJPi7/e1eV8sOyDNPiobxPw1j3QiJosJ08 Wenm2C3K8RuKL7dC9niJdXccER6slMeCDfHMKYlPUEN04Nt8cTnwlr1PJxNFhEInKzyW rkkJA15KBsC0Ei0eBbN/+vPDj4ysWcnJEr9JJWx2WexJNHVSTxh8LN7oM2hEfv0vjAFT 7Hs3/I0iTvrz3dEL/X0rwW7HtxgOARm3zr9AYUkhNXxtFPmVHXTk+hCI2eGIG+BUU91z pygw== MIME-Version: 1.0 Received: by 10.224.40.2 with SMTP id i2mr22420149qae.62.1340661305735; Mon, 25 Jun 2012 14:55:05 -0700 (PDT) Sender: metajack@gmail.com Received: by 10.229.246.7 with HTTP; Mon, 25 Jun 2012 14:55:05 -0700 (PDT) In-Reply-To: <20120625215354.8426.66267.idtracker@ietfa.amsl.com> References: <20120625215354.8426.66267.idtracker@ietfa.amsl.com> Date: Mon, 25 Jun 2012 15:55:05 -0600 X-Google-Sender-Auth: dQdcJvxoBVOUzXq6_4C2dCOgS3U Message-ID: From: Jack Moffitt To: XMPP , Hybi , "Jabber/XMPP software development list" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Mon, 25 Jun 2012 16:03:50 -0700 Subject: [hybi] Fwd: New Version Notification for draft-moffitt-xmpp-over-websocket-01.txt 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, 25 Jun 2012 21:55:07 -0000 I've just updated and submitted a new draft. The changes are fairly minor, mostly clarification of a few things that were pointed out in the last draft and updated references. Please let me know if you have any comments. jack. ---------- Forwarded message ---------- From: Date: Mon, Jun 25, 2012 at 3:53 PM Subject: New Version Notification for draft-moffitt-xmpp-over-websocket-01.= txt To: jack@metajack.im Cc: ecestari@process-one.com A new version of I-D, draft-moffitt-xmpp-over-websocket-01.txt has been successfully submitted by Jack Moffitt and posted to the IETF repository. Filename: =A0 =A0 =A0 =A0draft-moffitt-xmpp-over-websocket Revision: =A0 =A0 =A0 =A001 Title: =A0 =A0 =A0 =A0 =A0 An XMPP Sub-protocol for WebSocket Creation date: =A0 2012-06-25 WG ID: =A0 =A0 =A0 =A0 =A0 Individual Submission Number of pages: 12 URL: http://www.ietf.org/internet-drafts/draft-moffitt-xmpp-over-websocket-01.tx= t Status: http://datatracker.ietf.org/doc/draft-moffitt-xmpp-over-websocket Htmlized: =A0 =A0 =A0 =A0http://tools.ietf.org/html/draft-moffitt-xmpp-over= -websocket-01 Diff: http://tools.ietf.org/rfcdiff?url2=3Ddraft-moffitt-xmpp-over-websocket-01 Abstract: =A0 This document defines a binding for the XMPP protocol over a =A0 WebSocket transport layer. =A0A WebSocket binding for XMPP provides =A0 higher performance than the current HTTP binding for XMPP. The IETF Secretariat From vk.86.811@gmail.com Tue Jun 26 02:35:26 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 5EB9721F85A8 for ; Tue, 26 Jun 2012 02:35:26 -0700 (PDT) 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 3Yp1AhYRXW1h for ; Tue, 26 Jun 2012 02:35:26 -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 D599E21F8570 for ; Tue, 26 Jun 2012 02:35:25 -0700 (PDT) Received: by yenq13 with SMTP id q13so3979530yen.31 for ; Tue, 26 Jun 2012 02:35:25 -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 :content-type; bh=BCbjGdDJl+8PgchO9skzhuH4sC7Gbw2P7LwO32JqqMA=; b=N/cLB94I2od76inm9QFDDldmn9B5gNZUZDcPfqyDCbSncC2+GjeDWPzZaHx9LuIt4A /glx1CzUIcO6FpEBDN8MC6ry+vaEEAwaTLqcbS8Rzd/1RsLnS2qLefaO08D4K6Lk5mfm c+TJxsaVjEiLYcUk+weZJN4jwu+16tHfqlWzZBdpiD0VZwclv9NPXgG/mJirDHrK1ZJx 3gL1/WTLBtOwRsBSKrXtmYPx7VlzYyKj4EQxTiPjmrf8CZ+FoPpi/areCd04CCrli8xY k9RtBRJipcdeVqnh2fvtgczNIq60OpD/2g0zwa0V2MYLTAREOLvjEoVYK2arWc/Siyyd tqbg== MIME-Version: 1.0 Received: by 10.50.183.228 with SMTP id ep4mr10534606igc.74.1340703325110; Tue, 26 Jun 2012 02:35:25 -0700 (PDT) Received: by 10.50.242.39 with HTTP; Tue, 26 Jun 2012 02:35:25 -0700 (PDT) In-Reply-To: References: Date: Tue, 26 Jun 2012 11:35:25 +0200 Message-ID: From: vinod kumar To: hybi@ietf.org Content-Type: multipart/alternative; boundary=14dae934064f71420904c35cd100 Subject: [hybi] XMLRPC Server - websocket 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, 26 Jun 2012 09:40:31 -0000 --14dae934064f71420904c35cd100 Content-Type: text/plain; charset=ISO-8859-1 Hi All, Can you please help me out how to connect a websocket to xmlrpc server ? I have my xmlrpc server running. I made a client code for websocket too. But I'm not able to connect the websocket to my server . Thanks, Vinodh --14dae934064f71420904c35cd100 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi All,

=A0 =A0 Can you pleas= e help me out how to connect a websocket to xmlrpc server ? =A0I have my xm= lrpc server running. I made a client code for websocket too. But I'm no= t able to connect the websocket to my server .

Thanks,
Vinodh

--14dae934064f71420904c35cd100-- From vk.86.811@gmail.com Tue Jun 26 03:23:58 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 69FF121F85D8 for ; Tue, 26 Jun 2012 03:23:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.414 X-Spam-Level: * X-Spam-Status: No, score=1.414 tagged_above=-999 required=5 tests=[AWL=-3.751, BAYES_05=-1.11, FRT_STOCK2=3.988, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, J_CHICKENPOX_16=0.6, J_CHICKENPOX_17=0.6, J_CHICKENPOX_19=0.6, J_CHICKENPOX_66=0.6, NORMAL_HTTP_TO_IP=0.001, RCVD_IN_DNSWL_LOW=-1, WEIRD_PORT=0.001] 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 rJCordoVANmM for ; Tue, 26 Jun 2012 03:23:57 -0700 (PDT) Received: from mail-gh0-f172.google.com (mail-gh0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 99A5E21F85CC for ; Tue, 26 Jun 2012 03:23:57 -0700 (PDT) Received: by ghbg16 with SMTP id g16so4021260ghb.31 for ; Tue, 26 Jun 2012 03:23:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=taWm/MQwKk5e0uTt3cmMLU1yAHZYU2aMgclPrZkOv/I=; b=bkTAk6HRsbzm4fGJ/gcfVcTKYKbY7Sbi1HX4tjLrDHXzpVGIujDWAMG4bwXl4modbq LhyaeST1MYQ3Q3cppRumfC0CoUrJ0l+w1LB6TnzPXuo6sY7HjSp18hVtaKJRvAwirdNM y4/sRxyROhXyneDSU2BYqqmf39mcUU4no/KjSQuHlOk1+6/keRj2aFB4l7sv9/E9r7em XSePy1ED7Z1o8/CEBPvh468KKZYoosAxb5i9DuwYmx9C8PaMfwQfgDCUVFjdibcKkNNq n/b09b4OdRHT9N11ZNhOa0cO01b0YNsgKvaDzunUSPszGwcmptYPCOruJ2pQfcL8D1rU EvKQ== MIME-Version: 1.0 Received: by 10.43.104.202 with SMTP id dn10mr8469694icc.29.1340706237076; Tue, 26 Jun 2012 03:23:57 -0700 (PDT) Received: by 10.50.242.39 with HTTP; Tue, 26 Jun 2012 03:23:57 -0700 (PDT) Date: Tue, 26 Jun 2012 12:23:57 +0200 Message-ID: From: vinod kumar To: hybi@ietf.org Content-Type: multipart/alternative; boundary=bcaec5171af502551e04c35d7f18 Subject: [hybi] Error in testing websockets !!! 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, 26 Jun 2012 10:23:58 -0000 --bcaec5171af502551e04c35d7f18 Content-Type: text/plain; charset=ISO-8859-1 Hi, I tried running a sample model. I started the server listening on a port. I have a client in html file which connects to the websocket. But when I start the client, it's giving me the following error. Someone, please help me out. --------------------------------------- 'GET / HTTP/1.1\r\nUpgrade: websocket\r\nConnection: Upgrade\r\nHost: 192.168.100.10:9997\r\nOrigin: null\r\nSec-WebSocket-Key: 95WQxAdZ0POM9hU6gR0oHQ==\r\nSec-WebSocket-Version: 13\r\n\r\n' Exception in thread Thread-1: Traceback (most recent call last): File "/usr/lib/python2.7/threading.py", line 551, in __bootstrap_inner self.run() File "/usr/lib/python2.7/threading.py", line 504, in run self.__target(*self.__args, **self.__kwargs) File "server.py", line 17, in handle s.send('\x00world\xff') error: [Errno 32] Broken pipe -------------------------------------- The comments on the website say : The server is using the outdated draft-74 protocol, whereas your version of Chrome is using probably draft-76 What does this mean? what exactly should I change in server and client codes to make them work? My server code is this : -------------------------------------------------------- #!/usr/bin/env python import socket, threading, time def handle(s): print repr(s.recv(9998)) s.send(''' HTTP/1.1 101 Web Socket Protocol Handshake\r Upgrade: WebSocket\r WebSocket-Origin: file:///home/vinodh/Desktop/homematic/e_notif/hws/\r WebSocket-Location: ws://localhost:9876/\r WebSocket-Protocol: sample '''.strip() + '\r\n\r\n') time.sleep(1) s.send('\x00hello\xff') time.sleep(1) s.send('\x00world\xff') s.close() s = socket.socket() s.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1) s.bind(('192.168.100.10', 9997)); print 'binding done ' s.listen(1); print 'listening ' while 1: t,_ = s.accept(); print 'something got accepted ' threading.Thread(target = handle, args = (t,)).start() --------------------------------------------------- My Client code is this : --------------------------------------------------- Web Socket Example
-------------------------------------------------------------- Thanks, Vinodh --bcaec5171af502551e04c35d7f18 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi,

=A0 =A0I tried running a sample model. I started the= server listening on a port. I have a client in html file which connects to= the websocket. But when I start the client, it's giving me the followi= ng error. Someone, please help me out.=A0
---------------------------------------


<= /div>

The comments on the website say :=A0=A0= The server is using the outdated draft-74 protocol, = whereas your version of Chrome is using probably draft-76=A0
What does this mean? what exactly should I change in s= erver and client codes to make them work?=A0

My server code i= s this :
---------= -----------------------------------------------
#!/usr/bin/env python

import socket, threading, ti= me

def handle(s):
=A0 print repr(s.recv(= 9998))
=A0 s.send('''
HTTP/1.1 101 Web Sock= et Protocol Handshake\r
Upgrade: WebSocket\r
WebSocket-Origin: file:///home/vinodh/D= esktop/homematic/e_notif/hws/\r
WebSocket-Location: ws://localhos= t:9876/\r
WebSocket-Protocol: sample
=A0 '''= ;.strip() + '\r\n\r\n')
=A0 time.sleep(1)
=A0 s.send('\x00hello\xff')
<= div>=A0 time.sleep(1)
=A0 s.send('\x00world\xff')
=A0 s.close()

s.bind(('192.168.100.10', 9997));
print 'binding= done '
s.listen(1);
print 'listening '
while 1:
=A0 t,_ =3D s.accept();
=A0 print '= something got accepted '
=A0 threading.Thread(target =3D handle, args =3D (t,)).start()
---------------------------------------------------
My Client = code is this :
--------------------------------------------------= -
<!DOCTYPE html>
<html xmlns=3D"http://www.w3.org/1999/xhtml">
=A0 <head>
=A0 =A0 <title>Web Socket Example= </title>
=A0 =A0 <meta charset=3D"UTF-8">
=A0 =A0 <= ;script>
=A0 =A0 =A0 window.onload =3D function() {
= =A0 =A0 =A0 =A0 var s =3D new WebSocket("ws://192.168.100.10:9997/");
=A0 =A0 =A0 =A0 s.onopen =3D function(e) { alert("opened"); = }
=A0 =A0 =A0 =A0 s.onclose =3D function(e) { alert("closed&= quot;); }
=A0 =A0 =A0 =A0 s.onmessage =3D function(e) { alert(&qu= ot;got: " + e.data); }
=A0 =A0 =A0 };
=A0 =A0 </script>
=A0 </he= ad>
=A0 =A0 <body>
=A0 =A0 =A0 <div id=3D&q= uot;holder" style=3D"width:600px; height:300px"></div&= gt;
=A0 =A0 </body>
</html>
----------------------------------------= ----------------------

Thanks,
Vinodh
--bcaec5171af502551e04c35d7f18-- From vk.86.811@gmail.com Tue Jun 26 03:25:24 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 50C2421F85F0 for ; Tue, 26 Jun 2012 03:25:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.717 X-Spam-Level: X-Spam-Status: No, score=-1.717 tagged_above=-999 required=5 tests=[AWL=1.881, 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 uuL+YElhbs+g for ; Tue, 26 Jun 2012 03:25:23 -0700 (PDT) Received: from mail-yw0-f53.google.com (mail-yw0-f53.google.com [209.85.213.53]) by ietfa.amsl.com (Postfix) with ESMTP id BFD9721F85EF for ; Tue, 26 Jun 2012 03:25:23 -0700 (PDT) Received: by yhp26 with SMTP id 26so5952488yhp.26 for ; Tue, 26 Jun 2012 03:25:23 -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 :content-type; bh=ITe9YDaOj8igiXDOgFZm7LY59S4n8vHBCCGK1XhICA0=; b=HSC3T8VkOJ4pmhkgnmMYlj/TS9YCrZzIhJ4/d9I744/XsXaEqYETynyHP+nXgNP2Yt qL/6WL8L4CezPbc2qrOn+kWdvGce7TdCVYOsarmkts5BAwDMla2RU800EckioGBlt0lG rSAffPPWywZM+DcvNdc5D9V4Vmimd+CSqT26hw9VhhqPumxK6dFG/BHDKlBulJahze5D rjtb6ovpPcLh/oNSOFjh75xQzMpMUjohc3bBfxix8C6gWXADu9aFE9mUo+iUVIz/Y7ph 99vhNq+JIZqvjZpLatK2W8IVjEa8XPIKk3uMy1S5aBs/GfVwqJue+hlitfU15kBhixEU 1uog== MIME-Version: 1.0 Received: by 10.50.188.131 with SMTP id ga3mr10616586igc.54.1340706323023; Tue, 26 Jun 2012 03:25:23 -0700 (PDT) Received: by 10.50.242.39 with HTTP; Tue, 26 Jun 2012 03:25:22 -0700 (PDT) In-Reply-To: References: Date: Tue, 26 Jun 2012 12:25:22 +0200 Message-ID: From: vinod kumar To: hybi@ietf.org Content-Type: multipart/alternative; boundary=14dae934115721c6ff04c35d84e7 Subject: Re: [hybi] Error in testing websockets !!! 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, 26 Jun 2012 10:25:24 -0000 --14dae934115721c6ff04c35d84e7 Content-Type: text/plain; charset=ISO-8859-1 And sorry, both are on localhost! The client code shows an ip. I edited it. --14dae934115721c6ff04c35d84e7 Content-Type: text/html; charset=ISO-8859-1 And sorry, both are on localhost! The client code shows an ip. I edited it. --14dae934115721c6ff04c35d84e7-- From jat@google.com Tue Jun 26 12:00:53 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 3E83111E80E7 for ; Tue, 26 Jun 2012 12:00:53 -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=[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 NprNESInzvrh for ; Tue, 26 Jun 2012 12:00:52 -0700 (PDT) Received: from mail-gh0-f172.google.com (mail-gh0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id D6E5811E8112 for ; Tue, 26 Jun 2012 12:00:49 -0700 (PDT) Received: by ghbg16 with SMTP id g16so288529ghb.31 for ; Tue, 26 Jun 2012 12:00:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=hgfycH472Q/bS+K5HjgKAAU/tGxWj3AEqT48+hacZJI=; b=F1eywW2BRx8dr0cJJpTZVxmKadH1as1NCLRPtIDYv7m/9qtFo3jLlOPYJiRGqVAT4p FSNnZ/rtCJuq0XD/p7IIezt4+becrpw2tyQ5CEzwrMQEzbkU7I1Sg7+imT+MTsuw1MVj aL+ajI17f94f5Q+IOOgemmmTO7Y2gjD/Sz+oHgCgr48yeRG6zebSkRCrfrrV8+fDlotf fh+NMVGBxorvDAkPWt7XrZDmRMDPptot3FznpOxaQC1izRqQLQ0SW4PJtLlQuH48ZGeb KRyvf8rQgGADi2C/BHccWG6kuX3lur6NyDgF4Nng2XJ7d6hFb5rIjt9VbBzu5yLLK8uw qSfQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=hgfycH472Q/bS+K5HjgKAAU/tGxWj3AEqT48+hacZJI=; b=U6O0islJQHZMz6eWk6WG3PVVRJ12QlChIkX6aw596RqA2TpgC6FI3RASRwGdAQV119 fXxJkIJWcQd81GbKaQ2676BqbpShontWcnJdPbnbg860DV8Ea/vYG6K5KuXaBXHeHm7k BH2lfnYVpDFFhxxIZCCcS9Q1b+VapWnen9eWEqXu4IPtR0Ciz4Yqcmq46KmlDlElICl2 Zv+PtGVJ2qLJFOdaH8eJM/oFdioLhlOQh0CX7w2nxEYaJEV/DQS3H8ZAOxRXvGlJsOoD rQfmLVbw1pOxLtjraTT4QFR5bB0V9dyk7yAbVes2BlpIGYo9eFT45o6N4q+ZahsXKcnf jzkw== Received: by 10.42.155.73 with SMTP id t9mr9035875icw.48.1340737249262; Tue, 26 Jun 2012 12:00:49 -0700 (PDT) Received: by 10.42.155.73 with SMTP id t9mr9035865icw.48.1340737249163; Tue, 26 Jun 2012 12:00:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.50.46.99 with HTTP; Tue, 26 Jun 2012 12:00:28 -0700 (PDT) In-Reply-To: References: From: John Tamplin Date: Tue, 26 Jun 2012 15:00:28 -0400 Message-ID: To: vinod kumar Content-Type: multipart/alternative; boundary=90e6ba61358a79389d04c364b731 X-System-Of-Record: true X-Gm-Message-State: ALoCoQld2BCKgRuRH+IwEsetek9RS/AhqcrD0O8yNdZjjChJGbrbDHgHy+hW2d7LIAUh7s3nd9a366XuuS0C3Djl9dGXdn6Vq1M4jPRAzlT/5u8d/BejRZkeg0ZlNl24ivQ29z2hUV2A4+qaPQO7qyhsksTPam48v3kojkWWQTPPHk3ZK6UZBko= Cc: hybi@ietf.org Subject: Re: [hybi] XMLRPC Server - websocket 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, 26 Jun 2012 19:00:53 -0000 --90e6ba61358a79389d04c364b731 Content-Type: text/plain; charset=UTF-8 On Tue, Jun 26, 2012 at 5:35 AM, vinod kumar wrote: > Can you please help me out how to connect a websocket to xmlrpc server > ? I have my xmlrpc server running. I made a client code for websocket too. > But I'm not able to connect the websocket to my server . > Your server has to implement the WebSocket protocol. -- John A. Tamplin Software Engineer (GWT), Google --90e6ba61358a79389d04c364b731 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Tue, Jun 26, 2012 at 5:35 AM, vinod kumar = <vk.86.811@gmai= l.com> wrote:
=C2=A0 =C2= =A0 Can you please help me out how to connect a websocket to xmlrpc server = ? =C2=A0I have my xmlrpc server running. I made a client code for websocket= too. But I'm not able to connect the websocket to my server .

Your server has to implement t= he WebSocket protocol.

--
John A. Tamplin
Softwa= re Engineer (GWT), Google
--90e6ba61358a79389d04c364b731-- From jamie@shareable.org Tue Jun 26 15:28: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 C510F11E808E for ; Tue, 26 Jun 2012 15:28:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] 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 fNI1paOgeh0n for ; Tue, 26 Jun 2012 15:28:37 -0700 (PDT) Received: from mail2.shareable.org (mail2.shareable.org [80.68.89.115]) by ietfa.amsl.com (Postfix) with ESMTP id 37BE811E8087 for ; Tue, 26 Jun 2012 15:28:37 -0700 (PDT) Received: from jamie by mail2.shareable.org with local (Exim 4.63) (envelope-from ) id 1SjeFK-0006y4-Cp; Tue, 26 Jun 2012 23:28:30 +0100 Date: Tue, 26 Jun 2012 23:28:30 +0100 From: Jamie Lokier To: Takeshi Yoshino Message-ID: <20120626222830.GV5812@jl-vm1.vm.bytemark.co.uk> References: <001301cd4acf$d8c5cda0$8a5168e0$@noemax.com> <6A3569A8-C253-4363-B00C-F336B0CA3128@noemax.com> <000301cd503d$0aff8f00$20fead00$@noemax.com> <002101cd504f$d8a20e30$89e62a90$@noemax.com> <20120622121738.GR5812@jl-vm1.vm.bytemark.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: hybi@ietf.org Subject: Re: [hybi] Multiplexing: Pre-AddChannelResponse quota 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, 26 Jun 2012 22:28:37 -0000 Takeshi Yoshino wrote: > On Fri, Jun 22, 2012 at 9:17 PM, Jamie Lokier <[1]jamie@shareable.org> > wrote: > > Why not just send NewChannelSlots[ADD=3], instead of 3 > > NewChannelSlot messages? > The slot messages are wasteful if the server is happy to accept 1000 > low-usage slots from the beginning. > > > (C) receives FlowControl[ID=1, quota=1024] > > (C) receives FlowControl[ID=2, quota=1024] > > (C) receives FlowControl[ID=3, quota=1024] > > Now (C) is allowed to send pre-handshake data up to 1024 for each > of > > allocated slots. > > Why not just send NewChannelSlots[ADD=3,PER_CHANNEL_QUOTA=1024]? > > This is fine if we don't need a way to increase pre-handshake quota for > the slots after allocating them e.g. when the server gets more room for > processing after the allocation. So how do you do it in your scheme - resend FlowControl for each slot? In that case, do this: NewChannelSlots[ADD=0,PER_CHANNEL_QUOTA=2048] I suggest the per-channel quota, is a single value available to all new channels, not a different value per channel. Does it make sense to have different new-channel "sizes"? ADD increments the available quota for new channels, while PER_CHANNEL_QUOTA sets that, I guess. It's not allowed to reduce the data quota, unless we have an "optimistic" mechanism for retracting flow control in other ways as well, which a hop-by-hop extension might do. The message is, in effect, a flow control allocation to each new channel that hasn't been created yet. However, I wonder, if it decides to have more memory, why would the server increase the per-channel data quota instead of increasing the number of available slots? Is there a reason for one over the other? There may still a case for a shared pool of pre-handshake data quota instead, but it would need to be carefully done because memory can't be carved up arbitrarily; a per-channel overhead factor would be needed. -- Jamie From ferg@caucho.com Tue Jun 26 15:41:31 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 182CC21F84FE for ; Tue, 26 Jun 2012 15:41:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 ZV94CYmENCie for ; Tue, 26 Jun 2012 15:41:30 -0700 (PDT) Received: from nm12-vm0.access.bullet.mail.mud.yahoo.com (nm12-vm0.access.bullet.mail.mud.yahoo.com [66.94.236.11]) by ietfa.amsl.com (Postfix) with SMTP id AC75F21F8504 for ; Tue, 26 Jun 2012 15:41:28 -0700 (PDT) Received: from [66.94.237.200] by nm12.access.bullet.mail.mud.yahoo.com with NNFMP; 26 Jun 2012 22:41:28 -0000 Received: from [98.138.206.46] by tm11.access.bullet.mail.mud.yahoo.com with NNFMP; 26 Jun 2012 22:41:28 -0000 Received: from [127.0.0.1] by smtp109.biz.mail.ne1.yahoo.com with NNFMP; 26 Jun 2012 22:41:28 -0000 X-Yahoo-Newman-Id: 105826.84097.bm@smtp109.biz.mail.ne1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: cjdttdYVM1kNucq1MQIX.VlK_ZXv6DCSBBwp7nxQKe4XJhi B82AQruIzVCNmwPJXZDWSXTOHZrYMrPFwfX6DavrCFV2rrxmJcmTtSNv9D4Q 2.bud.5U0CQwu9dClmU9RrlGaaltMgWmvzTJJzrbqGF.0RtazrpKcG2koopc gWTQZ8biGNhWrbi1oaPCWVZ74H_8LXWoobpcAEG0KGW84L.jE_vZydjIgwCV fj4HAC.1Bamrmq0QNCqwnwsegpAfwNMXs.uBzE84DUtRmYI3LLDJiSCwIJHp .ViwddtXPppUFN16FBv9ep8ErXyfFikt1m_aMHjs2Xd1hI6fmEHlKxK3pITD K86e_LeqasP76fZogwu2AOxST_MjOKjwBRVnt7ABPgkK806WKpjxC06_._iI OHrGEWEvJhJKxG.xWqNij6IHBoBs- X-Yahoo-SMTP: L1_TBRiswBB5.MuzAo8Yf89wczFo0A2C Received: from [192.168.1.11] (ferg@66.92.8.203 with plain) by smtp109.biz.mail.ne1.yahoo.com with SMTP; 26 Jun 2012 15:41:27 -0700 PDT Message-ID: <4FEA3A97.5030301@caucho.com> Date: Tue, 26 Jun 2012 15:41:27 -0700 From: Scott Ferguson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: "hybi@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [hybi] Multiplexing: even/odd client/server channel open X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ferg@caucho.com List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jun 2012 22:41:31 -0000 In the current draft, only the client can open channels and it can open any channel id. In http-ng (and spdy, I believe), half the channel ids (even) are reserved to the client and half the channel ids (odd) are reserved to the server. This splitting of the channel space allows either end to open a new channel without collision. Since spdy is already experimenting with the use of server-initiated channels, it's not unreasonable to suppose that some websocket applications may want similar capabilities. (Presumably non-browser apps or spdy-over-websocket.) Alternatively, the odd channels could be reserved for future expansion without adding server-initiated channels now, allowing a later version of mux to add server-initiated channels. I didn't see a previous discussion on this topic, but I skimmed fairly quickly, so disregard if it's been discussed already. I'd think reserving odd channel ids would be a straightforward improvement to avoid locking in the client-only limitation of the current draft, even if it was decided that server initiated channels should be avoided for the current spec. -- Scott From tyoshino@google.com Tue Jun 26 20:16:29 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 D438D11E80EA for ; Tue, 26 Jun 2012 20:16: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=[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 eJa3YDdrR1dX for ; Tue, 26 Jun 2012 20:16:28 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 49E7A21F8505 for ; Tue, 26 Jun 2012 20:16:28 -0700 (PDT) Received: by lbbgo11 with SMTP id go11so989166lbb.31 for ; Tue, 26 Jun 2012 20:16:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=ljR63M6A+NTxDihLdr29JR8GbRuRV5zMILgmhjqmxbg=; b=hfTKT3uemLRFL3awx3e0jifUBm9WzaoDxFOCr4jvGv1jaZEaBBliSZTIFIiMLe00cW 25iE0zBo82+XdgDBCSLG52/uBgy7HlnMfJGO47QDdJcR2tl+HUNoYnqY9XiGazfhVk4u T+cXmzidKYt0HjR1abKmoBV+gTjYG9mf97gJLwjKrHsfDY1N+6ecKEt2WPYbrbU3y+1e 23eIdf3FBAzHqLM/91gtNB6jBc+Js1x5U6WeSpIVAoLi7TDkHB9YFWJKgMkn6edDbRgt gbbif28FTWxAEbaPZNqSO52q+5aUFDEbe0wnCNaaqPRixqdlOPzY4D1t6dbd/uzVIzU/ rkoA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=ljR63M6A+NTxDihLdr29JR8GbRuRV5zMILgmhjqmxbg=; b=jRDilj3iO8VFtq6/0492uoOkiVBDaYEODx36lLfhhxhZRIDPEc3IyZ9tUhvrNApLgV wYY/1cFOqYYE2EIPXE4JBodPQKLXranENyIlkx93tVJSjbMQZM1MtYgoR5LZ8hmfzQld GNsPF50gMqR/3cs9VimLHh5+P6e2OtRsdoGbKWYmBs5d4qryJntped6I4VUM1qcXzKp2 l2nZ+MtITioBC0tdJPwLK5Ji4+Tnx72tpot24PgZnRT3YqujlWpjMEaXEhGHmrqkcB47 OT9tYYLTwvJ+LcDTX2wPll5U8R23lGHO9BnV1/163eQVeFz0mq9sZ4f45v9/1daZj5YT ia0Q== Received: by 10.152.148.199 with SMTP id tu7mr18755256lab.43.1340766987225; Tue, 26 Jun 2012 20:16:27 -0700 (PDT) Received: by 10.152.148.199 with SMTP id tu7mr18755248lab.43.1340766987106; Tue, 26 Jun 2012 20:16:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.112.48.202 with HTTP; Tue, 26 Jun 2012 20:16:06 -0700 (PDT) In-Reply-To: <20120626222830.GV5812@jl-vm1.vm.bytemark.co.uk> References: <001301cd4acf$d8c5cda0$8a5168e0$@noemax.com> <6A3569A8-C253-4363-B00C-F336B0CA3128@noemax.com> <000301cd503d$0aff8f00$20fead00$@noemax.com> <002101cd504f$d8a20e30$89e62a90$@noemax.com> <20120622121738.GR5812@jl-vm1.vm.bytemark.co.uk> <20120626222830.GV5812@jl-vm1.vm.bytemark.co.uk> From: Takeshi Yoshino Date: Wed, 27 Jun 2012 12:16:06 +0900 Message-ID: To: Jamie Lokier Content-Type: multipart/alternative; boundary=e89a8f2353bbfe398904c36ba39a X-System-Of-Record: true X-Gm-Message-State: ALoCoQmVzxMiRz9cN7ZOeUAnB8ODuHb/nuXM7TOf8u/L/qtWqh0ADj6ae60/mxWOtDa542D+wVmJ8gSwbyfuWLPEv+Lf3teVjTBaBZo85JK+DI/pgGTQPwr6ZRpbD468LRJvsmnabR6KdtZK4jXZM6S4OJsgTjW3DughQLOCptVzRwgwwL2Udv0= Cc: hybi@ietf.org Subject: Re: [hybi] Multiplexing: Pre-AddChannelResponse quota 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, 27 Jun 2012 03:16:30 -0000 --e89a8f2353bbfe398904c36ba39a Content-Type: text/plain; charset=ISO-8859-1 On Wed, Jun 27, 2012 at 7:28 AM, Jamie Lokier wrote: > Takeshi Yoshino wrote: > > This is fine if we don't need a way to increase pre-handshake quota > for > > the slots after allocating them e.g. when the server gets more room > for > > processing after the allocation. > > So how do you do it in your scheme - resend FlowControl for each slot? > Yes > In that case, do this: > > NewChannelSlots[ADD=0,PER_CHANNEL_QUOTA=2048] > > I suggest the per-channel quota, is a single value available to all > new channels, not a different value per channel. This also works. > Does it make sense > to have different new-channel "sizes"? > No. I don't think it makes sense. I suggested that for leveling imbalanced quotas. Imbalance of quotas happens when the server replenishes new channel slots but with smaller quota due to temporary decrease of processing capacity. After some seconds, the capacity may recover. Then, such a flexible pre-handshake quota replenishing method allows for leveling them (remaining old slots and the newly allocated slots with smaller quota) again. That's the reason I've put the idea on the table, but I can live without this functionality. > ADD increments the available quota for new channels, while > PER_CHANNEL_QUOTA sets that, I guess. Yes. > It's not allowed to reduce the > data quota, unless we have an "optimistic" mechanism for retracting > flow control in other ways as well, which a hop-by-hop extension might > do. The message is, in effect, a flow control allocation to each new > channel that hasn't been created yet. > Yes. I'd clarify "hasn't been created yet" by "has not sent AddChannelResponse" for server-side and "has not received AddChannelResponse" for client-side. > However, I wonder, if it decides to have more memory, why would the > server increase the per-channel data quota instead of increasing the > number of available slots? Is there a reason for one over the other? > I have no idea. It should depend on the app's requirements. --e89a8f2353bbfe398904c36ba39a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed, Jun 27, 2012 at 7:28 AM, Jam= ie Lokier <jamie@shareable.org> wrote:
Takeshi Yoshino wrote:
= > =A0 =A0This is fine if we don't need a way to increase pre-handsha= ke quota for
> =A0 =A0the slots after allocating them e.g. when the server gets more = room for
> =A0 =A0processing after the allocation.

So how do you do it in your scheme - resend FlowControl for each slot= ?

Yes
=A0
In that case, do this:

=A0 NewChannelSlots[ADD=3D0,PER_CHANNEL_QUOTA=3D2048]

I suggest the per-channel quota, is a single value available to all
new channels, not a different value per channel.

This also works.
=A0
= =A0Does it make sense
to have different new-channel "sizes"?

<= /div>
No. I don't think it makes sense.

I = suggested that for leveling imbalanced quotas. Imbalance of quotas happens = when the server replenishes new channel slots but with smaller quota due to= temporary decrease of processing capacity. After some seconds, the capacit= y may recover. Then, such a flexible pre-handshake quota replenishing metho= d allows for leveling them (remaining old slots and the newly allocated slo= ts with smaller quota) again.

That's the reason I've put the idea on the tabl= e, but=A0I can live without this functionality.
=A0
ADD increments the available quota for new channels, while
PER_CHANNEL_QUOTA sets that, I guess.

Yes.<= /div>
=A0
=A0It's not allowed = to reduce the
data quota, unless we have an "optimistic" mechanism for retracti= ng
flow control in other ways as well, which a hop-by-hop extension might
do. =A0The message is, in effect, a flow control allocation to each new
channel that hasn't been created yet.

Yes. I'd clarify "hasn't been created yet" by "ha= s not sent AddChannelResponse" for=A0server-side=A0and "has not r= eceived AddChannelResponse" for=A0client-side.
=A0
However, I wonder, if it decides to have more memory, why would the
server increase the per-channel data quota instead of increasing the
number of available slots? =A0Is there a reason for one over the other?
=

I have no idea. It should depend on the ap= p's requirements.
=A0
--e89a8f2353bbfe398904c36ba39a-- From tyoshino@google.com Wed Jun 27 00:44:41 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 1314021F85FC for ; Wed, 27 Jun 2012 00:44:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.676 X-Spam-Level: X-Spam-Status: No, score=-102.676 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_52=0.6, 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 nfxYtIjYAn7e for ; Wed, 27 Jun 2012 00:44:40 -0700 (PDT) Received: from mail-gh0-f172.google.com (mail-gh0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 66EF521F85EA for ; Wed, 27 Jun 2012 00:44:40 -0700 (PDT) Received: by ghbg16 with SMTP id g16so730903ghb.31 for ; Wed, 27 Jun 2012 00:44:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=220k6+Sg2TA32o62K3mlSlf1fBr4+8QSBLLBruuV4OM=; b=SUZuQd2hZDrwbQUPvDRSlDLVC61EBN9GHKxTjV6/khJZObtMMENTF+0p5WRADLxtrZ ZOwNlWPFNtD0FObjUPuBJGcPOg/d+odjbjAVVpeusRbHedmDv6vRZ+lMkM8lLaMboL9y sKSus0kjCoVQ4uGTqW+thdwHZhQsfAH9RtggJ0I5R0cCbKBAp+8ywLDB1kzZTZOdlQwd wXN39iw5CbqtORUv413K2uyoCM66nHn5wEh94nVRYVVHrwFMOCQ/Id3WBNjgNbBq+tNK U8zJLGG48vDcbj5X1gAD1zwzg2bsBMOb1cIKNj9uAvt7SYSYVS8DC2qTqqORQ5WblIs4 AzZA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=220k6+Sg2TA32o62K3mlSlf1fBr4+8QSBLLBruuV4OM=; b=Na3Q/CFn9oxhaDa0llq6UvKDaxab6RCnBXjxmkajq2FptDmBelJ9x8JV84RzTYZOMS Q68FepCrjoR/KtjDQwyO2nx91899XNximl9rj8v6XJ1dQ49Ekmumq7MiOJ/eOPLPOg+J e2xkm+ZbSgzjoLjxnFowc7XlKh8/UCk4zwDJaCpURLAskh0EKZW4VQhUTu5YW1iKTn+x IVduVnsuGNKUplun09uBKuEAvMGEbbxUI/pudYOGOBu/LKJEDnEcisA0Tf3/5m9T5uuD 2HidF0z01rzGs729O9UrO8yYyDgWCuTrtVDKU8tt1wsCC9NFzJeldFI6s5yHU+w+jq7V 46NQ== Received: by 10.50.160.202 with SMTP id xm10mr639384igb.10.1340783079537; Wed, 27 Jun 2012 00:44:39 -0700 (PDT) Received: by 10.50.160.202 with SMTP id xm10mr639375igb.10.1340783079416; Wed, 27 Jun 2012 00:44:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.66.7 with HTTP; Wed, 27 Jun 2012 00:44:19 -0700 (PDT) In-Reply-To: References: <001a01cd3e69$4a221c10$de665430$@noemax.com> <4FC732DC.3000308@250bpm.com> <000e01cd3f1c$af15ad40$0d4107c0$@noemax.com> <4FC880A7.9070007@250bpm.com> <001001cd4000$fe2c82c0$fa858840$@noemax.com> <4FCCAE6B.1010306@250bpm.com> <002d01cd4262$747957b0$5d6c0710$@noemax.com> <20120607022312.GA26406@jl-vm1.vm.bytemark.co.uk> <000e01cd449d$1c0ed220$542c7660$@noemax.com> <000401cd4566$d5f6bb70$81e43250$@noemax.com> From: Takeshi Yoshino Date: Wed, 27 Jun 2012 16:44:19 +0900 Message-ID: To: Arman Djusupov Content-Type: multipart/alternative; boundary=14dae9340eb72b613804c36f6346 X-System-Of-Record: true X-Gm-Message-State: ALoCoQkJekFyLyfwBYYyuT4mvwQZg7iAN8gqAuYzAS/NEgvSdW08+jyki74LY2NeatrV4WtO2hbwQX1X6GRHrVjh0Z+ky3CMVqrPyP+mPuFnEIHvohj+5EMn+m6amic94N0GohKumxFBv2BfZLFC9qnnHYFaQJQg+kqQVKJ5Eg9GVZwfOre9gng= Cc: hybi@ietf.org Subject: Re: [hybi] Flow control quota 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, 27 Jun 2012 07:44:41 -0000 --14dae9340eb72b613804c36f6346 Content-Type: text/plain; charset=ISO-8859-1 Here's the text for the proposed scheme. ==== 6. Framing This extension encapsulates each frame of a multiplexed connection into a binary message with Payload Data obtained by concatenating the following data in the order they are listed: 1. The logical channel ID for the multiplexed connection. 2. FIN, RSV1, RSV2, RSV3 and opcode of the original frame. 3. Unmasked "Payload Data" of the original frame. ==== 8. Examples 0x82 0x0d 0x01 0x81 "Hello world" This is a non-fragmented text message of "Hello world" on channel 1 encapsulated into a non-fragmented message. 0x02 0x07 0x01 0x81 "Hello" 0x80 0x06 " world" This is a fragmented encapsulating message converying a non- fragmented text frame "Hello world" on channel 1. 0x82 0x07 0x01 0x01 "Hello" 0x82 0x05 0x02 0x81 "bye" 0x82 0x08 0x01 0x80 " world" This example shows how data for two channels are interleaved. There're three non-fragmented encapsulating messages. The first and third one convey each of two frames of a fragmented text message of "Hello world" on channel 1. The second one conveys a non-fragmented text message of "bye" on channel 2. --14dae9340eb72b613804c36f6346 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Here's the text for the proposed= scheme.

=3D=3D=3D=3D

6. =A0Framing

=A0 =A0This extension encapsulates each frame of a multipl= exed connection
=A0 =A0into a binary message with Payload Data o= btained by concatenating the
=A0 =A0followi= ng data in the order they are listed:

<= /div>
=A0 =A01. =A0The logical channel ID for the multiplexed connection.

=A0 =A02. =A0= FIN, RSV1, RSV2, RSV3 and opcode of the original frame.

=A0 =A03. =A0Unmasked "Payload Data&q= uot; of the original frame.

=3D=3D=3D=3D

8. =A0Examples

=A0 =A00x82 0x= 0d 0x01 0x81 "Hello world"

=A0 =A0 =A0 This is a non-fragmented text message= of "Hello world" on channel
=A0 =A0 =A0 1 encapsulated= into a non-fragmented message.

=A0 =A00x02 0x07 0= x01 0x81 "Hello" 0x80 0x06 " world"

=A0 =A0 =A0 This is a fragmented encapsulating message = converying a non-
=A0 =A0 =A0 fragmented text frame "Hello w= orld" on channel 1.

=A0 =A00x82 0x07 0x01 0x0= 1 "Hello" 0x82 0x05 0x02 0x81 "bye" 0x82 0x08 0x01
=A0 =A00x80 " world"

=A0 =A0 =A0 Th= is example shows how data for two channels are interleaved.
=A0 = =A0 =A0 There're three non-fragmented encapsulating messages. =A0The fi= rst
=A0 =A0 =A0 and third one convey each of two frames of a fragmented text
=A0 =A0 =A0 message of "Hello world" on channel 1. =A0The se= cond one conveys a
=A0 =A0 =A0 non-fragmented text message of &qu= ot;bye" on channel 2.

--14dae9340eb72b613804c36f6346-- From vk.86.811@gmail.com Wed Jun 27 00:48:56 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 DE0CB21F8643 for ; Wed, 27 Jun 2012 00:48:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.008 X-Spam-Level: * X-Spam-Status: No, score=1.008 tagged_above=-999 required=5 tests=[AWL=-1.784, BAYES_00=-2.599, FRT_STOCK2=3.988, HTML_MESSAGE=0.001, J_CHICKENPOX_16=0.6, J_CHICKENPOX_17=0.6, J_CHICKENPOX_19=0.6, J_CHICKENPOX_66=0.6, NORMAL_HTTP_TO_IP=0.001, RCVD_IN_DNSWL_LOW=-1, WEIRD_PORT=0.001] 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 vQXnvlekEvYR for ; Wed, 27 Jun 2012 00:48:56 -0700 (PDT) Received: from mail-yw0-f53.google.com (mail-yw0-f53.google.com [209.85.213.53]) by ietfa.amsl.com (Postfix) with ESMTP id 0A4A721F863E for ; Wed, 27 Jun 2012 00:48:55 -0700 (PDT) Received: by yhp26 with SMTP id 26so1049342yhp.26 for ; Wed, 27 Jun 2012 00:48:55 -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 :content-type; bh=IZBzEI5XYw80eVjk99Chj8ZsqtjTiR/ykL40cDlNZs8=; b=DieBwVdqIr5S3if7NGQvexLlcaKqFUjC3dOBbYRxlYyvHjnst135dnsh42qMVduRlE rQv2pdvzOziy6dPrM8Vn1ztaIpvxVmOFufp4SNGVDRMeXM3Ofwi9DDwYVjjZvkN3LMfY U7/sx7IyRZwIhZdww5J/cYDRMmnR7JtyqsBa1Qkz0kXPkLgc7dTcwDkary++a4LVjUfv kawBd7ZdY02KrJ31odKWRynOib1h8B/JsL93+AG9dkPf23bG4m9LobmxaBYySUsfJ28j PQoWjITdtrFApqrZuUCK1RomsMK3Vo8V237wauyPAUZ+H96D7j+8eTSRxtE/YlJcf9QH euWA== MIME-Version: 1.0 Received: by 10.43.49.67 with SMTP id uz3mr10183494icb.47.1340783335400; Wed, 27 Jun 2012 00:48:55 -0700 (PDT) Received: by 10.50.242.39 with HTTP; Wed, 27 Jun 2012 00:48:55 -0700 (PDT) In-Reply-To: References: Date: Wed, 27 Jun 2012 09:48:55 +0200 Message-ID: From: vinod kumar To: John Tamplin , hybi@ietf.org Content-Type: multipart/alternative; boundary=bcaec5299f696d65d204c36f7268 Subject: Re: [hybi] XMLRPC Server - websocket 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, 27 Jun 2012 07:48:57 -0000 --bcaec5299f696d65d204c36f7268 Content-Type: text/plain; charset=ISO-8859-1 Hi John, Thanks for your reply. I have implemented the websocket. Still facing some trouble. The event onopen is not happening. When I send something from my server, it occurs. But nothing like onmessage event happens. Hi, I'm not sure whether the connection is established or not. The things which I kept in onopen event are not getting alerted. Please have a look at the codes below: ------ Server ------ #!/usr/bin/env python import socket, threading, time, string import hashlib import base64 def get_response_handshake_key(s): hs_lines = s.split() part1 = "" parse_position = hs_lines[7].index('\\r') half1 = hs_lines[7][:parse_position] half2 = "258EAFA5-E914-47DA-95CA-C5AB0DC85B11" raw_key = half1+half2 sha1_object = hashlib.sha1() sha1_object.update(raw_key) half_encoded = sha1_object.digest() encoded_key = base64.b64encode(half_encoded) return encoded_key def handle(s): key_half1 = repr(s.recv(4443)) encoded_key = get_response_handshake_key(key_half1) hand_shake_response = "'HTTP/1.1 101 Switching Protocols \r\nUpgrade: websocket \r\nConnection: Upgrade \r\nSec-WebSocket-Accept: %s\r\n'"%(encoded_key) s.send(hand_shake_response) print 'response sent vinod' time.sleep(1) print 'message1 sent ' s.send('\x00hello\xff') time.sleep(1) s.send('\x00world\xff') print 'message2 sent' s.close() s = socket.socket() s.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1) s.bind(('ip_address', 4443)); print 'binding done ' s.listen(1); print 'listening ' while 1: t,_ = s.accept(); print 'something got accepted ' threading.Thread(target = handle, args = (t,)).start() ---------------------------------------------------------------------------------------------------------- Client --------- Web Socket Example
------------------------------------------------------------------------------- OUTPUT on console at server : binding done listening something got accepted 'GET / HTTP/1.1\r\nUpgrade: websocket\r\nConnection: Upgrade\r\nHost: ip_address:4443\r\nOrigin:http://192.168.0.101:8888\r\nSec-WebSocket-Key: JTsXI9vB6e/psrPTasC4zw==\r\nSec-WebSocket-Version: 13\r\n\r\n' response sent vinod message1 sent message2 sent --------------------------------------------------------------------------------- It's showing message sent here. But I'm not receiving any messages on browser. Now even the "alert open" is happening for onopen event. I have "s.close()" at the end because of which the only thing happening on browser is : an alert with "closed" Please help me out. The protocol is implemented all fine. I checked with the encoders too. They are fine. There could be a small thing I'm missing. Thanks, Vinodh --bcaec5299f696d65d204c36f7268 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi John,

Thanks for your reply. I have implemented the websocket= . Still facing some trouble. The event onopen is not happening. When I send= something from my server, it occurs. But nothing like onmessage event happ= ens.
Hi,

=A0I'm not sure whether= the connection is established or not. The things which I kept in onopen ev= ent are not getting alerted. Please have a look at the codes below:
------
Server
------
#!/usr/bin/env python

import socket, threadin= g, time, string
import hashlib
import base64
=
def get_response_handshake_key(s):
=A0 hs_lines = =3D s.split()
=A0 part1 =3D ""
=A0 parse_position =3D hs_lines[7= ].index('\\r')
=A0 half1 =3D hs_lines[7][:parse_position]=
=A0 half2 =3D "258EAFA5-E914-47DA-95CA-C5AB0DC85B11"
=A0 raw_key =3D half1+half2
=A0 sha1_object =3D hashlib.sha1()
=A0 sha1_object.update(ra= w_key)
=A0 half_encoded =3D sha1_object.digest()
=A0 en= coded_key =3D base64.b64encode(half_encoded)
=A0 return encoded_k= ey
=A0=A0
def handle(s):
=A0 key_half1 =3D repr(s.recv(444= 3))
=A0 encoded_key =3D get_response_handshake_key(key_half1)
=A0 hand_shake_response =3D "'HTTP/1.1 101 Switching Protoc= ols \r\nUpgrade: websocket \r\nConnection: Upgrade \r\nSec-WebSocket-Accept= : %s\r\n'"%(encoded_key)
=A0 s.send(hand_shake_response)
=A0 print 'response sent= vinod'
=A0 time.sleep(1)
=A0 print 'message1 s= ent '
=A0 s.se= nd('\x00hello\xff')
=A0 time.sleep(1)
=A0 s.send('\x00world\xff')
<= /div>
=A0 print 'message2 sent'
=A0 s.close()

s =3D sock= et.socket()
s.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1)
s.bind(('ip_address', 4443));
print 'binding done '
s.listen(1);<= /div>
print 'listening '
while 1:
=A0 t,_ =3D s.= accept();
=A0 print 'something got accepted '
= =A0 threading.Thread(target =3D handle, args =3D (t,)).start()
<= /div>
---------------------------------------------------------------------------= -------------------------------
Client=A0
---------
<!DOCTYPE html>
=A0 <head>
=A0 =A0 <title>Web Socket Example<= /title>
=A0 =A0 <meta charset=3D"UTF-8">
=
=A0 =A0 <script>
=A0 =A0 =A0 window.onload =3D functio= n() {
=A0 =A0 =A0 =A0 var s =3D new WebSocket("ws://ip_address:4443/");=
=A0 =A0 =A0 =A0 s.onop= en =3D function(e) { alert("opened"); }
=A0 =A0 =A0 =A0= s.onclose =3D function(e) { alert(e);alert("closed"); }
=A0 =A0 =A0 =A0 s.onmes= sage =3D function(e) { alert("got: " + e.data); }
=A0 = =A0 =A0 };
=A0 =A0 </script>
=A0 </head>
=A0 =A0 <body>
=A0 =A0 =A0 <div id=3D"holder" style=3D"width:600px;= height:300px"></div>
=A0 =A0 </body>
</html>
---------------------------------------------------------------------------= ----
OUTPUT on console at server= :
binding done=A0
listen= ing=A0
something got accepted=A0
'GET / HTTP/1.1\r\= nUpgrade: websocket\r\nConnection: Upgrade\r\nHost: ip_address:4443\r\nOrig= in:http://192.168.0.101:8888\r\nSec-WebSocket-Key: JTsXI9v= B6e/psrPTasC4zw=3D=3D\r\nSec-WebSocket-Version: 13\r\n\r\n'

response sent vinod
message1 sent=A0
message2 sent
----------= -----------------------------------------------------------------------
It's showing message sent here. B= ut I'm not receiving any messages on browser. Now even the "alert = open" is happening for onopen event. I have "s.close()" at t= he end because of which the only thing happening on browser is : an alert w= ith "closed"

Please help me out. The protocol is implemented all fine. I checked with th= e encoders too. They are fine. There could be a small thing I'm missing= .

Thanks,
Vinodh
--bcaec5299f696d65d204c36f7268-- From li.yin@intel.com Wed Jun 27 01:46:30 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 4844021F85FB for ; Wed, 27 Jun 2012 01:46:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.891 X-Spam-Level: * X-Spam-Status: No, score=1.891 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FRT_STOCK2=3.988, HTML_MESSAGE=0.001, J_CHICKENPOX_16=0.6, J_CHICKENPOX_17=0.6, J_CHICKENPOX_19=0.6, J_CHICKENPOX_66=0.6, NORMAL_HTTP_TO_IP=0.001, RCVD_IN_DNSWL_HI=-8, WEIRD_PORT=0.001] 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 Ty9FZj0X2kmI for ; Wed, 27 Jun 2012 01:46:29 -0700 (PDT) Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by ietfa.amsl.com (Postfix) with ESMTP id 3872A21F85F2 for ; Wed, 27 Jun 2012 01:46:29 -0700 (PDT) Received: from orsmga002.jf.intel.com ([10.7.209.21]) by orsmga101.jf.intel.com with ESMTP; 27 Jun 2012 01:46:22 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.67,351,1309762800"; d="scan'208,217";a="163306941" Received: from fmsmsx106.amr.corp.intel.com ([10.19.9.37]) by orsmga002.jf.intel.com with ESMTP; 27 Jun 2012 01:46:21 -0700 Received: from fmsmsx102.amr.corp.intel.com (10.19.9.53) by FMSMSX106.amr.corp.intel.com (10.19.9.37) with Microsoft SMTP Server (TLS) id 14.1.355.2; Wed, 27 Jun 2012 01:46:21 -0700 Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by FMSMSX102.amr.corp.intel.com (10.19.9.53) with Microsoft SMTP Server (TLS) id 14.1.355.2; Wed, 27 Jun 2012 01:46:21 -0700 Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.87]) by SHSMSX102.ccr.corp.intel.com ([169.254.2.47]) with mapi id 14.01.0355.002; Wed, 27 Jun 2012 16:46:18 +0800 From: "Yin, Li" To: vinod kumar Thread-Topic: [hybi] XMLRPC Server - websocket Thread-Index: AQHNU3/Pl8xClzWrJUqtzDIyBK830JcMbsoAgADWtICAAJPiUA== Date: Wed, 27 Jun 2012 08:46:18 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.239.127.40] Content-Type: multipart/alternative; boundary="_000_F70A8AEBE518884ABEC998529DD9D15E0D52ACSHSMSX101ccrcorpi_" MIME-Version: 1.0 Cc: "hybi@ietf.org" Subject: Re: [hybi] XMLRPC Server - websocket 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, 27 Jun 2012 08:46:30 -0000 --_000_F70A8AEBE518884ABEC998529DD9D15E0D52ACSHSMSX101ccrcorpi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 aGFuZF9zaGFrZV9yZXNwb25zZSBzaG91bGQgZW5kIG9mIOKAnFxyXG5cclxu4oCdLCB5b3UgY2Fu IGhhdmUgYSB0cnkgYWdhaW4uDQoNCkJ5IHRoZSB3YXksIHdoaWNoIGJyb3dzZXIgYXJlIHlvdSB1 c2luZz8gSWYgdGhlIFdlYlNvY2tldCBjb25uZWN0aW9uIGNhbuKAmXQgYmUgY3JlYXRlZCwgdGhl IGZhaWxlZCByZWFzb24gc2hvdWxkIGJlIHByaW50ZWQgb24gY29uc29sZSBvZiBicm93c2VyLA0K YXMgZmFyIGFzIEkga25vdywgY2hyb21pdW0gY2FuIGRvIHRoYXQuDQpJZiB0aGUgZXJyb3Igc3Rp bGwgb2NjdXJzLCBwbGVhc2UgcHJvdmlkZSBjb25zb2xlIG1lc3NhZ2UgZnJvbSBicm93c2VyLg0K DQpSZWdhcmRzLA0KTGkgWWluDQoNCkZyb206IGh5YmktYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRv Omh5YmktYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIHZpbm9kIGt1bWFyDQpTZW50OiBX ZWRuZXNkYXksIEp1bmUgMjcsIDIwMTIgMzo0OSBQTQ0KVG86IEpvaG4gVGFtcGxpbjsgaHliaUBp ZXRmLm9yZw0KU3ViamVjdDogUmU6IFtoeWJpXSBYTUxSUEMgU2VydmVyIC0gd2Vic29ja2V0DQoN CkhpIEpvaG4sDQoNClRoYW5rcyBmb3IgeW91ciByZXBseS4gSSBoYXZlIGltcGxlbWVudGVkIHRo ZSB3ZWJzb2NrZXQuIFN0aWxsIGZhY2luZyBzb21lIHRyb3VibGUuIFRoZSBldmVudCBvbm9wZW4g aXMgbm90IGhhcHBlbmluZy4gV2hlbiBJIHNlbmQgc29tZXRoaW5nIGZyb20gbXkgc2VydmVyLCBp dCBvY2N1cnMuIEJ1dCBub3RoaW5nIGxpa2Ugb25tZXNzYWdlIGV2ZW50IGhhcHBlbnMuDQpIaSwN Cg0KIEknbSBub3Qgc3VyZSB3aGV0aGVyIHRoZSBjb25uZWN0aW9uIGlzIGVzdGFibGlzaGVkIG9y IG5vdC4gVGhlIHRoaW5ncyB3aGljaCBJIGtlcHQgaW4gb25vcGVuIGV2ZW50IGFyZSBub3QgZ2V0 dGluZyBhbGVydGVkLiBQbGVhc2UgaGF2ZSBhIGxvb2sgYXQgdGhlIGNvZGVzIGJlbG93Og0KLS0t LS0tDQpTZXJ2ZXINCi0tLS0tLQ0KIyEvdXNyL2Jpbi9lbnYgcHl0aG9uDQoNCmltcG9ydCBzb2Nr ZXQsIHRocmVhZGluZywgdGltZSwgc3RyaW5nDQppbXBvcnQgaGFzaGxpYg0KaW1wb3J0IGJhc2U2 NA0KDQpkZWYgZ2V0X3Jlc3BvbnNlX2hhbmRzaGFrZV9rZXkocyk6DQogIGhzX2xpbmVzID0gcy5z cGxpdCgpDQogIHBhcnQxID0gIiINCiAgcGFyc2VfcG9zaXRpb24gPSBoc19saW5lc1s3XS5pbmRl eCgnXFxyJykNCiAgaGFsZjEgPSBoc19saW5lc1s3XVs6cGFyc2VfcG9zaXRpb25dDQogIGhhbGYy ID0gIjI1OEVBRkE1LUU5MTQtNDdEQS05NUNBLUM1QUIwREM4NUIxMSINCiAgcmF3X2tleSA9IGhh bGYxK2hhbGYyDQogIHNoYTFfb2JqZWN0ID0gaGFzaGxpYi5zaGExKCkNCiAgc2hhMV9vYmplY3Qu dXBkYXRlKHJhd19rZXkpDQogIGhhbGZfZW5jb2RlZCA9IHNoYTFfb2JqZWN0LmRpZ2VzdCgpDQog IGVuY29kZWRfa2V5ID0gYmFzZTY0LmI2NGVuY29kZShoYWxmX2VuY29kZWQpDQogIHJldHVybiBl bmNvZGVkX2tleQ0KDQpkZWYgaGFuZGxlKHMpOg0KICBrZXlfaGFsZjEgPSByZXByKHMucmVjdig0 NDQzKSkNCiAgZW5jb2RlZF9rZXkgPSBnZXRfcmVzcG9uc2VfaGFuZHNoYWtlX2tleShrZXlfaGFs ZjEpDQogIGhhbmRfc2hha2VfcmVzcG9uc2UgPSAiJ0hUVFAvMS4xIDEwMSBTd2l0Y2hpbmcgUHJv dG9jb2xzIFxyXG5VcGdyYWRlOiB3ZWJzb2NrZXQgXHJcbkNvbm5lY3Rpb246IFVwZ3JhZGUgXHJc blNlYy1XZWJTb2NrZXQtQWNjZXB0OiAlc1xyXG4nIiUoZW5jb2RlZF9rZXkpDQogIHMuc2VuZCho YW5kX3NoYWtlX3Jlc3BvbnNlKQ0KICBwcmludCAncmVzcG9uc2Ugc2VudCB2aW5vZCcNCiAgdGlt ZS5zbGVlcCgxKQ0KICBwcmludCAnbWVzc2FnZTEgc2VudCAnDQogIHMuc2VuZCgnXHgwMGhlbGxv XHhmZicpDQogIHRpbWUuc2xlZXAoMSkNCiAgcy5zZW5kKCdceDAwd29ybGRceGZmJykNCiAgcHJp bnQgJ21lc3NhZ2UyIHNlbnQnDQogIHMuY2xvc2UoKQ0KDQpzID0gc29ja2V0LnNvY2tldCgpDQpz LnNldHNvY2tvcHQoc29ja2V0LlNPTF9TT0NLRVQsIHNvY2tldC5TT19SRVVTRUFERFIsIDEpDQpz LmJpbmQoKCdpcF9hZGRyZXNzJywgNDQ0MykpOw0KcHJpbnQgJ2JpbmRpbmcgZG9uZSAnDQpzLmxp c3RlbigxKTsNCnByaW50ICdsaXN0ZW5pbmcgJw0Kd2hpbGUgMToNCiAgdCxfID0gcy5hY2NlcHQo KTsNCiAgcHJpbnQgJ3NvbWV0aGluZyBnb3QgYWNjZXB0ZWQgJw0KICB0aHJlYWRpbmcuVGhyZWFk KHRhcmdldCA9IGhhbmRsZSwgYXJncyA9ICh0LCkpLnN0YXJ0KCkNCi0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCkNsaWVudA0KLS0tLS0tLS0tDQo8IURP Q1RZUEUgaHRtbD4NCjxodG1sIHhtbG5zPSJodHRwOi8vd3d3LnczLm9yZy8xOTk5L3hodG1sIj4N CiAgPGhlYWQ+DQogICAgPHRpdGxlPldlYiBTb2NrZXQgRXhhbXBsZTwvdGl0bGU+DQogICAgPG1l dGEgY2hhcnNldD0iVVRGLTgiPg0KICAgIDxzY3JpcHQ+DQogICAgICB3aW5kb3cub25sb2FkID0g ZnVuY3Rpb24oKSB7DQogICAgICAgIHZhciBzID0gbmV3IFdlYlNvY2tldCgid3M6Ly9pcF9hZGRy ZXNzOjQ0NDMvIik7DQogICAgICAgIHMub25vcGVuID0gZnVuY3Rpb24oZSkgeyBhbGVydCgib3Bl bmVkIik7IH0NCiAgICAgICAgcy5vbmNsb3NlID0gZnVuY3Rpb24oZSkgeyBhbGVydChlKTthbGVy dCgiY2xvc2VkIik7IH0NCiAgICAgICAgcy5vbm1lc3NhZ2UgPSBmdW5jdGlvbihlKSB7IGFsZXJ0 KCJnb3Q6ICIgKyBlLmRhdGEpOyB9DQogICAgICB9Ow0KICAgIDwvc2NyaXB0Pg0KICA8L2hlYWQ+ DQogICAgPGJvZHk+DQogICAgICA8ZGl2IGlkPSJob2xkZXIiIHN0eWxlPSJ3aWR0aDo2MDBweDsg aGVpZ2h0OjMwMHB4Ij48L2Rpdj4NCiAgICA8L2JvZHk+DQo8L2h0bWw+DQotLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tDQpPVVRQVVQgb24gY29uc29sZSBhdCBzZXJ2ZXIgOg0KYmluZGluZyBkb25lDQps aXN0ZW5pbmcNCnNvbWV0aGluZyBnb3QgYWNjZXB0ZWQNCidHRVQgLyBIVFRQLzEuMVxyXG5VcGdy YWRlOiB3ZWJzb2NrZXRcclxuQ29ubmVjdGlvbjogVXBncmFkZVxyXG5Ib3N0OiBpcF9hZGRyZXNz OjQ0NDNcclxuT3JpZ2luOmh0dHA6Ly8xOTIuMTY4LjAuMTAxOjg4ODg8aHR0cDovLzE5Mi4xNjgu MC4xMDE6ODg4OC8+XHJcblNlYy1XZWJTb2NrZXQtS2V5OiBKVHNYSTl2QjZlL3BzclBUYXNDNHp3 PT1cclxuU2VjLVdlYlNvY2tldC1WZXJzaW9uOiAxM1xyXG5cclxuJw0KDQpyZXNwb25zZSBzZW50 IHZpbm9kDQptZXNzYWdlMSBzZW50DQptZXNzYWdlMiBzZW50DQotLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0NCkl0J3Mgc2hvd2luZyBtZXNzYWdlIHNlbnQgaGVyZS4gQnV0IEknbSBub3QgcmVjZWl2 aW5nIGFueSBtZXNzYWdlcyBvbiBicm93c2VyLiBOb3cgZXZlbiB0aGUgImFsZXJ0IG9wZW4iIGlz IGhhcHBlbmluZyBmb3Igb25vcGVuIGV2ZW50LiBJIGhhdmUgInMuY2xvc2UoKSIgYXQgdGhlIGVu ZCBiZWNhdXNlIG9mIHdoaWNoIHRoZSBvbmx5IHRoaW5nIGhhcHBlbmluZyBvbiBicm93c2VyIGlz IDogYW4gYWxlcnQgd2l0aCAiY2xvc2VkIg0KDQpQbGVhc2UgaGVscCBtZSBvdXQuIFRoZSBwcm90 b2NvbCBpcyBpbXBsZW1lbnRlZCBhbGwgZmluZS4gSSBjaGVja2VkIHdpdGggdGhlIGVuY29kZXJz IHRvby4gVGhleSBhcmUgZmluZS4gVGhlcmUgY291bGQgYmUgYSBzbWFsbCB0aGluZyBJJ20gbWlz c2luZy4NCg0KVGhhbmtzLA0KVmlub2RoDQo= --_000_F70A8AEBE518884ABEC998529DD9D15E0D52ACSHSMSX101ccrcorpi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 U2ltU3VuOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5v c2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJc QFNpbVN1biI7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQovKiBTdHlsZSBEZWZp bml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXtt YXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1z b0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0 LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xs b3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVj b3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6 cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCglj b2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1v bmx5O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46 MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRT ZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVk ZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0t PjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0K PG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+ PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxp bms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5oYW5kX3NoYWtlX3Jlc3BvbnNlIHNo b3VsZCBlbmQgb2Yg4oCcXHJcblxyXG7igJ0sIHlvdSBjYW4gaGF2ZSBhIHRyeSBhZ2Fpbi48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+QnkgdGhlIHdheSwgd2hpY2ggYnJv d3NlciBhcmUgeW91IHVzaW5nPyBJZiB0aGUgV2ViU29ja2V0IGNvbm5lY3Rpb24gY2Fu4oCZdCBi ZSBjcmVhdGVkLCB0aGUgZmFpbGVkIHJlYXNvbiBzaG91bGQgYmUgcHJpbnRlZCBvbiBjb25zb2xl IG9mIGJyb3dzZXIsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5hcyBmYXIgYXMgSSBrbm93LCBjaHJvbWl1bSBj YW4gZG8gdGhhdC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPklmIHRoZSBlcnJvciBzdGlsbCBvY2N1cnMsIHBs ZWFzZSBwcm92aWRlIGNvbnNvbGUgbWVzc2FnZSBmcm9tIGJyb3dzZXIuPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPlJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5MaSBZaW48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0 O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90OyI+IGh5YmktYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmh5YmktYm91bmNlc0Bp ZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+dmlub2Qga3VtYXI8YnI+DQo8Yj5TZW50Ojwv Yj4gV2VkbmVzZGF5LCBKdW5lIDI3LCAyMDEyIDM6NDkgUE08YnI+DQo8Yj5Ubzo8L2I+IEpvaG4g VGFtcGxpbjsgaHliaUBpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW2h5YmldIFhN TFJQQyBTZXJ2ZXIgLSB3ZWJzb2NrZXQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+SGkgSm9obiwgPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5UaGFua3MgZm9yIHlvdXIgcmVwbHkuIEkgaGF2ZSBpbXBsZW1lbnRlZCB0aGUgd2Vic29j a2V0LiBTdGlsbCBmYWNpbmcgc29tZSB0cm91YmxlLiBUaGUgZXZlbnQgb25vcGVuIGlzIG5vdCBo YXBwZW5pbmcuIFdoZW4gSSBzZW5kIHNvbWV0aGluZyBmcm9tIG15IHNlcnZlciwgaXQgb2NjdXJz LiBCdXQgbm90aGluZyBsaWtlIG9ubWVzc2FnZSBldmVudCBoYXBwZW5zLjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMyMjIyMjI7YmFja2dyb3VuZDp3aGl0ZSI+SGksPC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndo aXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFs JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzIyMjIyMiI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMjIy MjIyIj4mbmJzcDtJJ20gbm90IHN1cmUgd2hldGhlciB0aGUgY29ubmVjdGlvbiBpcyBlc3RhYmxp c2hlZCBvciBub3QuIFRoZSB0aGluZ3Mgd2hpY2ggSSBrZXB0IGluIG9ub3BlbiBldmVudCBhcmUg bm90IGdldHRpbmcgYWxlcnRlZC4gUGxlYXNlIGhhdmUNCiBhIGxvb2sgYXQgdGhlIGNvZGVzIGJl bG93OjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjgu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzIyMjIyMiI+LS0tLS0tPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMjIyMjIyIj5TZXJ2ZXI8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3Vu ZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtB cmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMyMjIyMjIiPi0tLS0tLTxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4 LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMyMjIyMjIiPiMhL3Vzci9iaW4vZW52IHB5dGhvbjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5k OndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Fy aWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzIyMjIyMiI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MjIyMjIyIj5pbXBvcnQgc29ja2V0LCB0aHJlYWRpbmcsIHRpbWUsIHN0cmluZzxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJi YWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzIyMjIyMiI+ aW1wb3J0IGhhc2hsaWI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMyMjIyMjIiPmltcG9ydCBiYXNlNjQ8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3Vu ZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtB cmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMyMjIyMjIiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzIyMjIyMiI+ZGVmIGdldF9yZXNwb25zZV9oYW5kc2hha2Vfa2V5KHMpOjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNr Z3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzIyMjIyMiI+Jm5i c3A7IGhzX2xpbmVzID0gcy5zcGxpdCgpPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMjIyMjIyIj4mbmJzcDsgcGFydDEgPSAmcXVvdDsm cXVvdDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4 LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMyMjIyMjIiPiZuYnNwOyBwYXJzZV9wb3NpdGlvbiA9IGhzX2xpbmVzWzddLmluZGV4 KCdcXHInKTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzIyMjIyMiI+Jm5ic3A7IGhhbGYxID0gaHNfbGluZXNbN11bOnBhcnNlX3Bvc2l0 aW9uXTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjgu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzIyMjIyMiI+Jm5ic3A7IGhhbGYyID0gJnF1b3Q7MjU4RUFGQTUtRTkxNC00N0RBLTk1 Q0EtQzVBQjBEQzg1QjExJnF1b3Q7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMjIyMjIyIj4mbmJzcDsgcmF3X2tleSA9IGhhbGYxJiM0 MztoYWxmMjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzIyMjIyMiI+Jm5ic3A7IHNoYTFfb2JqZWN0ID0gaGFzaGxpYi5zaGExKCk8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250 LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMy MjIyMjIiPiZuYnNwOyBzaGExX29iamVjdC51cGRhdGUocmF3X2tleSk8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dy b3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVv dDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMyMjIyMjIiPiZuYnNw OyBoYWxmX2VuY29kZWQgPSBzaGExX29iamVjdC5kaWdlc3QoKTxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5k OndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Fy aWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzIyMjIyMiI+Jm5ic3A7IGVu Y29kZWRfa2V5ID0gYmFzZTY0LmI2NGVuY29kZShoYWxmX2VuY29kZWQpPG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tn cm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMjIyMjIyIj4mbmJz cDsgcmV0dXJuIGVuY29kZWRfa2V5PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMjIyMjIyIj4mbmJzcDsmbmJzcDs8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFj a2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTom cXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMyMjIyMjIiPmRl ZiBoYW5kbGUocyk6PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMjIyMjIyIj4mbmJzcDsga2V5X2hhbGYxID0gcmVwcihzLnJlY3YoNDQ0 MykpPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMjIyMjIyIj4mbmJzcDsgZW5jb2RlZF9rZXkgPSBnZXRfcmVzcG9uc2VfaGFuZHNoYWtl X2tleShrZXlfaGFsZjEpPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMjIyMjIyIj4mbmJzcDsgaGFuZF9zaGFrZV9yZXNwb25zZSA9ICZx dW90OydIVFRQLzEuMSAxMDEgU3dpdGNoaW5nIFByb3RvY29scyBcclxuVXBncmFkZTogd2Vic29j a2V0IFxyXG5Db25uZWN0aW9uOiBVcGdyYWRlIFxyXG5TZWMtV2ViU29ja2V0LUFjY2VwdDogJXNc clxuJyZxdW90OyUoZW5jb2RlZF9rZXkpPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMjIyMjIyIj4mbmJzcDsgcy5zZW5kKGhhbmRfc2hh a2VfcmVzcG9uc2UpPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMjIyMjIyIj4mbmJzcDsgcHJpbnQgJ3Jlc3BvbnNlIHNlbnQgdmlub2Qn PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMjIyMjIyIj4mbmJzcDsgdGltZS5zbGVlcCgxKTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRl Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzIyMjIyMiI+Jm5ic3A7IHByaW50ICdt ZXNzYWdlMSBzZW50ICc8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojNTAwMDUwIj4mbmJzcDsgcy5zZW5kKCdceDAwaGVsbG9c eGZmJyk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4 LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiM1MDAwNTAiPiZuYnNwOyB0aW1lLnNsZWVwKDEpPG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6 d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJp YWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojNTAwMDUwIj4mbmJzcDsgcy5z ZW5kKCdceDAwd29ybGRceGZmJyk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzIyMjIyMiI+Jm5ic3A7IHByaW50ICdtZXNz YWdlMiBzZW50JzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiM1MDAwNTAiPiZuYnNwOyBzLmNsb3NlKCk8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFj a2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTom cXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiM1MDAwNTAiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjgu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzUwMDA1MCI+cyA9IHNvY2tldC5zb2NrZXQoKTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndo aXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFs JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzUwMDA1MCI+cy5zZXRzb2Nrb3B0 KHNvY2tldC5TT0xfU09DS0VULCBzb2NrZXQuU09fUkVVU0VBRERSLCAxKTxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMjIy MjIyIj5zLmJpbmQoKCdpcF9hZGRyZXNzJywgNDQ0MykpOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dy b3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVv dDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiM1MDAwNTAiPnByaW50 ICdiaW5kaW5nIGRvbmUgJzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzUwMDA1MCI+cy5saXN0ZW4oMSk7PG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91 bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojNTAwMDUwIj5wcmludCAn bGlzdGVuaW5nICc8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiM1MDAwNTAiPndoaWxlIDE6PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojNTAwMDUwIj4mbmJzcDsgdCxfID0gcy5h Y2NlcHQoKTs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiM1MDAwNTAiPiZuYnNwOyBwcmludCAnc29tZXRoaW5nIGdvdCBhY2NlcHRlZCAn PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojNTAwMDUwIj4mbmJzcDsgdGhyZWFkaW5nLlRocmVhZCh0YXJnZXQgPSBoYW5kbGUsIGFyZ3Mg PSAodCwpKS5zdGFydCgpPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRl Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzIyMjIyMiI+LS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndo aXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFs JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzIyMjIyMiI+Q2xpZW50Jm5ic3A7 PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMjIyMjIyIj4tLS0tLS0tLS08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndo aXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFs JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzUwMDA1MCI+Jmx0OyFET0NUWVBF IGh0bWwmZ3Q7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojNTAwMDUwIj4mbHQ7aHRtbCB4bWxucz0mcXVvdDs8YSBocmVmPSJodHRwOi8v d3d3LnczLm9yZy8xOTk5L3hodG1sIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9y OiMxMTU1Q0MiPmh0dHA6Ly93d3cudzMub3JnLzE5OTkveGh0bWw8L3NwYW4+PC9hPiZxdW90OyZn dDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjBw dDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiM1MDAwNTAiPiZuYnNwOyAmbHQ7aGVhZCZndDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0 ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiM1MDAwNTAiPiZuYnNwOyAmbmJzcDsg Jmx0O3RpdGxlJmd0O1dlYiBTb2NrZXQgRXhhbXBsZSZsdDsvdGl0bGUmZ3Q7PG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJh Y2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojNTAwMDUwIj4m bmJzcDsgJm5ic3A7ICZsdDttZXRhIGNoYXJzZXQ9JnF1b3Q7VVRGLTgmcXVvdDsmZ3Q7PG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojNTAw MDUwIj4mbmJzcDsgJm5ic3A7ICZsdDtzY3JpcHQmZ3Q7PG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hp dGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojNTAwMDUwIj4mbmJzcDsgJm5ic3A7 ICZuYnNwOyB3aW5kb3cub25sb2FkID0gZnVuY3Rpb24oKSB7PG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFj a2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTom cXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMyMjIyMjIiPiZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB2YXIgcyA9IG5ldyBXZWJTb2NrZXQoJnF1b3Q7d3M6 Ly9pcF9hZGRyZXNzOjQ0NDMvJnF1b3Q7KTs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiM1MDAwNTAiPiZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyBzLm9ub3BlbiA9IGZ1bmN0aW9uKGUpIHsgYWxlcnQoJnF1b3Q7b3BlbmVkJnF1b3Q7 KTsgfTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjgu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzIyMjIyMiI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHMub25jbG9zZSA9IGZ1 bmN0aW9uKGUpIHsgYWxlcnQoZSk7YWxlcnQoJnF1b3Q7Y2xvc2VkJnF1b3Q7KTsgfTxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtm b250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiM1MDAwNTAiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBzLm9ubWVzc2FnZSA9IGZ1bmN0 aW9uKGUpIHsgYWxlcnQoJnF1b3Q7Z290OiAmcXVvdDsgJiM0MzsgZS5kYXRhKTsgfTxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzUwMDA1 MCI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgfTs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiM1MDAwNTAiPiZuYnNwOyAmbmJzcDsgJmx0Oy9z Y3JpcHQmZ3Q7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojNTAwMDUwIj4mbmJzcDsgJmx0Oy9oZWFkJmd0OzxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3Jv dW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzUwMDA1MCI+Jm5ic3A7 ICZuYnNwOyAmbHQ7Ym9keSZndDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiM1MDAwNTAiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZsdDtk aXYgaWQ9JnF1b3Q7aG9sZGVyJnF1b3Q7IHN0eWxlPSZxdW90O3dpZHRoOjYwMHB4OyBoZWlnaHQ6 MzAwcHgmcXVvdDsmZ3Q7Jmx0Oy9kaXYmZ3Q7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojNTAwMDUwIj4mbmJzcDsgJm5ic3A7ICZsdDsv Ym9keSZndDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiM1MDAwNTAiPiZsdDsvaHRtbCZndDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMjIyMjIy Ij4tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMjIyMjIyIj5PVVRQVVQgb24gY29uc29sZSBhdCBz ZXJ2ZXIgOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMyMjIyMjIiPmJpbmRpbmcgZG9uZSZuYnNwOzxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNr Z3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzIyMjIyMiI+bGlz dGVuaW5nJm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMjIyMjIyIj5zb21ldGhpbmcgZ290IGFjY2VwdGVkJm5ic3A7PG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMjIy MjIyIj4nR0VUIC8gSFRUUC8xLjFcclxuVXBncmFkZTogd2Vic29ja2V0XHJcbkNvbm5lY3Rpb246 IFVwZ3JhZGVcclxuSG9zdDogaXBfYWRkcmVzczo0NDQzXHJcbk9yaWdpbjo8YSBocmVmPSJodHRw Oi8vMTkyLjE2OC4wLjEwMTo4ODg4LyIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xv cjojMTE1NUNDIj5odHRwOi8vMTkyLjE2OC4wLjEwMTo4ODg4PC9zcGFuPjwvYT5cclxuU2VjLVdl YlNvY2tldC1LZXk6DQogSlRzWEk5dkI2ZS9wc3JQVGFzQzR6dz09XHJcblNlYy1XZWJTb2NrZXQt VmVyc2lvbjogMTNcclxuXHJcbic8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMyMjIyMjIiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5k OndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Fy aWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzIyMjIyMiI+cmVzcG9uc2Ug c2VudCB2aW5vZDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzIyMjIyMiI+bWVzc2FnZTEgc2VudCZuYnNwOzxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3Jv dW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzIyMjIyMiI+bWVzc2Fn ZTIgc2VudDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMjIyMjIyIj4tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZh bWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMyMjIy MjIiPkl0J3Mgc2hvd2luZyBtZXNzYWdlIHNlbnQgaGVyZS4gQnV0IEknbSBub3QgcmVjZWl2aW5n IGFueSBtZXNzYWdlcyBvbiBicm93c2VyLiBOb3cgZXZlbiB0aGUgJnF1b3Q7YWxlcnQgb3BlbiZx dW90OyBpcyBoYXBwZW5pbmcgZm9yIG9ub3BlbiBldmVudC4NCiBJIGhhdmUgJnF1b3Q7cy5jbG9z ZSgpJnF1b3Q7IGF0IHRoZSBlbmQgYmVjYXVzZSBvZiB3aGljaCB0aGUgb25seSB0aGluZyBoYXBw ZW5pbmcgb24gYnJvd3NlciBpcyA6IGFuIGFsZXJ0IHdpdGggJnF1b3Q7Y2xvc2VkJnF1b3Q7PG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MjIyMjIyIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMyMjIyMjIiPlBsZWFzZSBoZWxwIG1lIG91dC4gVGhlIHByb3RvY29s IGlzIGltcGxlbWVudGVkIGFsbCBmaW5lLiBJIGNoZWNrZWQgd2l0aCB0aGUgZW5jb2RlcnMgdG9v LiBUaGV5IGFyZSBmaW5lLiBUaGVyZSBjb3VsZCBiZSBhIHNtYWxsIHRoaW5nDQogSSdtIG1pc3Np bmcuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMjIyMjIyIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMyMjIyMjIiPlRoYW5rcyw8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3Vu ZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtB cmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMyMjIyMjIiPlZpbm9kaDxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwv aHRtbD4NCg== --_000_F70A8AEBE518884ABEC998529DD9D15E0D52ACSHSMSX101ccrcorpi_-- From vk.86.811@gmail.com Wed Jun 27 01:53:28 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 0E07621F8658 for ; Wed, 27 Jun 2012 01:53:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.414 X-Spam-Level: **** X-Spam-Status: No, score=4.414 tagged_above=-999 required=5 tests=[AWL=-4.477, BAYES_99=3.5, FRT_STOCK2=3.988, HTML_MESSAGE=0.001, J_CHICKENPOX_16=0.6, J_CHICKENPOX_17=0.6, J_CHICKENPOX_19=0.6, J_CHICKENPOX_66=0.6, NORMAL_HTTP_TO_IP=0.001, RCVD_IN_DNSWL_LOW=-1, WEIRD_PORT=0.001] 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 r6RW5cIHFdIO for ; Wed, 27 Jun 2012 01:53:27 -0700 (PDT) Received: from mail-yw0-f53.google.com (mail-yw0-f53.google.com [209.85.213.53]) by ietfa.amsl.com (Postfix) with ESMTP id D651A21F8648 for ; Wed, 27 Jun 2012 01:53:26 -0700 (PDT) Received: by yhp26 with SMTP id 26so1104951yhp.26 for ; Wed, 27 Jun 2012 01:53:26 -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 :content-type; bh=o8MP8VjuQPGtr3+uKkDTtpOXX3aNgqxughxFr2pmLrU=; b=FynF3NzykjU3uJhedAhLaL4nf4vx4p/YPUURweHQq4m7Icg0mrKT1xmHuuNjt23317 /L1MWwDTCuREv+3FepU6w47L3JJPQ3bIPIYrVWssNwtIPaYQQV8a3ljVuvv4F0/0WgUI N3ymTMiG0JuGOnIhuDfg2UfZel27qSAm14nbcDri7/FuOMRliihaaBzGelPtgOxsXAoh XwsflEjRZZaDXQx3yc8+kOZA9TpmPpuUrJfUmJuupBlb60xQvE0TglgqY+rik/5+zwFr 21fEqMc9oxs3R2+MZMYKaotX2vxdxm2T7BHiY4918SaahZaJMt28fnmfrKvydliqUK4U Cc5Q== MIME-Version: 1.0 Received: by 10.50.190.163 with SMTP id gr3mr707594igc.74.1340787206159; Wed, 27 Jun 2012 01:53:26 -0700 (PDT) Received: by 10.50.242.39 with HTTP; Wed, 27 Jun 2012 01:53:26 -0700 (PDT) In-Reply-To: References: Date: Wed, 27 Jun 2012 10:53:26 +0200 Message-ID: From: vinod kumar To: "Yin, Li" , hybi@ietf.org Content-Type: multipart/alternative; boundary=f46d04478817247e7f04c3705903 Subject: Re: [hybi] XMLRPC Server - websocket 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, 27 Jun 2012 08:53:28 -0000 --f46d04478817247e7f04c3705903 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Li Yin, Thanks a lot. The "\r\n" is the mistake. Now, it shows me the alert "opened". So, connection is established. But when I try sending something as it's shown in code, the other event "onmessage" is not getting triggered. And browser console is empty now. Thanks, Vinodh On Wed, Jun 27, 2012 at 10:46 AM, Yin, Li wrote: > hand_shake_response should end of =93\r\n\r\n=94, you can have a try aga= in.** > ** > > ** ** > > By the way, which browser are you using? If the WebSocket connection can= =92t > be created, the failed reason should be printed on console of browser,***= * > > as far as I know, chromium can do that.**** > > If the error still occurs, please provide console message from browser.**= * > * > > ** ** > > Regards,**** > > Li Yin**** > > ** ** > > *From:* hybi-bounces@ietf.org [mailto:hybi-bounces@ietf.org] *On Behalf > Of *vinod kumar > *Sent:* Wednesday, June 27, 2012 3:49 PM > *To:* John Tamplin; hybi@ietf.org > *Subject:* Re: [hybi] XMLRPC Server - websocket**** > > ** ** > > Hi John, **** > > ** ** > > Thanks for your reply. I have implemented the websocket. Still facing som= e > trouble. The event onopen is not happening. When I send something from my > server, it occurs. But nothing like onmessage event happens.**** > > Hi,**** > > ** ** > > I'm not sure whether the connection is established or not. The things > which I kept in onopen event are not getting alerted. Please have a look = at > the codes below:**** > > ------**** > > Server**** > > ------**** > > #!/usr/bin/env python**** > > ** ** > > import socket, threading, time, string**** > > import hashlib**** > > import base64**** > > ** ** > > def get_response_handshake_key(s):**** > > hs_lines =3D s.split()**** > > part1 =3D ""**** > > parse_position =3D hs_lines[7].index('\\r')**** > > half1 =3D hs_lines[7][:parse_position]**** > > half2 =3D "258EAFA5-E914-47DA-95CA-C5AB0DC85B11"**** > > raw_key =3D half1+half2**** > > sha1_object =3D hashlib.sha1()**** > > sha1_object.update(raw_key)**** > > half_encoded =3D sha1_object.digest()**** > > encoded_key =3D base64.b64encode(half_encoded)**** > > return encoded_key**** > > **** > > def handle(s):**** > > key_half1 =3D repr(s.recv(4443))**** > > encoded_key =3D get_response_handshake_key(key_half1)**** > > hand_shake_response =3D "'HTTP/1.1 101 Switching Protocols \r\nUpgrade: > websocket \r\nConnection: Upgrade \r\nSec-WebSocket-Accept: > %s\r\n'"%(encoded_key)**** > > s.send(hand_shake_response)**** > > print 'response sent vinod'**** > > time.sleep(1)**** > > print 'message1 sent '**** > > s.send('\x00hello\xff')**** > > time.sleep(1)**** > > s.send('\x00world\xff')**** > > print 'message2 sent'**** > > s.close()**** > > ** ** > > s =3D socket.socket()**** > > s.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1)**** > > s.bind(('ip_address', 4443));**** > > print 'binding done '**** > > s.listen(1);**** > > print 'listening '**** > > while 1:**** > > t,_ =3D s.accept();**** > > print 'something got accepted '**** > > threading.Thread(target =3D handle, args =3D (t,)).start()**** > > > -------------------------------------------------------------------------= --------------------------------- > **** > > Client **** > > ---------**** > > **** > > **** > > **** > > Web Socket Example**** > > **** > > **** > > **** > > **** > >
**** > > **** > > **** > > > -------------------------------------------------------------------------= ------ > **** > > OUTPUT on console at server :**** > > binding done **** > > listening **** > > something got accepted **** > > 'GET / HTTP/1.1\r\nUpgrade: websocket\r\nConnection: Upgrade\r\nHost: > ip_address:4443\r\nOrigin:http://192.168.0.101:8888\r\nSec-WebSocket-Key: > JTsXI9vB6e/psrPTasC4zw=3D=3D\r\nSec-WebSocket-Version: 13\r\n\r\n'**** > > ** ** > > response sent vinod**** > > message1 sent **** > > message2 sent**** > > > -------------------------------------------------------------------------= -------- > **** > > It's showing message sent here. But I'm not receiving any messages on > browser. Now even the "alert open" is happening for onopen event. I have > "s.close()" at the end because of which the only thing happening on brows= er > is : an alert with "closed"**** > > ** ** > > Please help me out. The protocol is implemented all fine. I checked with > the encoders too. They are fine. There could be a small thing I'm missing= . > **** > > ** ** > > Thanks,**** > > Vinodh**** > --f46d04478817247e7f04c3705903 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Li Yin,

Thanks a lot. The "\r\n" is the mis= take. Now, it shows me the alert "opened". So, connection is esta= blished. But when I try sending something as it's shown in code, the ot= her event "onmessage" is not getting triggered. And browser conso= le is empty now.=A0

Thanks,
Vinodh

On Wed, Jun 27, 2012 at 10:46 AM, Yin, Li <li.yin@intel.com> wrote:

hand_shake_response should end of =93\r= \n\r\n=94, you can have a try again.

=A0

By the way, which browser are you using= ? If the WebSocket connection can=92t be created, the failed reason should = be printed on console of browser,

as far as I know, chromium can do that.=

If the error still occurs, please provi= de console message from browser.

=A0

Regards,

Li Yin

=A0<= /p>

From: hybi-bounces@ietf.org [mailto:hybi-= bounces@ietf.org] On Behalf Of vinod kumar
Sent: Wednesday, June 27, 2012 3:49 PM
To: John Tamplin; hybi@ietf.org
Subject: Re: [hybi] XMLRPC Server - websocket

=A0

Hi John,

=A0

Thanks for your reply. I have implemented the websoc= ket. Still facing some trouble. The event onopen is not happening. When I s= end something from my server, it occurs. But nothing like onmessage event h= appens.

Hi,<= u>

<= u>=A0

= =A0I'm not sure whether the connection is established or not. The thing= s which I kept in onopen event are not getting alerted. Please have a look at the codes below:

-= -----

S= erver

-= -----

#= !/usr/bin/env python

<= u>=A0

i= mport socket, threading, time, string

i= mport hashlib

i= mport base64

<= u>=A0

d= ef get_response_handshake_key(s):

= =A0 hs_lines =3D s.split()

= =A0 part1 =3D ""

= =A0 parse_position =3D hs_lines[7].index('\\r')

= =A0 half1 =3D hs_lines[7][:parse_position]

= =A0 half2 =3D "258EAFA5-E914-47DA-95CA-C5AB0DC85B11"

= =A0 raw_key =3D half1+half2

= =A0 sha1_object =3D hashlib.sha1()

= =A0 sha1_object.update(raw_key)

= =A0 half_encoded =3D sha1_object.digest()

= =A0 encoded_key =3D base64.b64encode(half_encoded)

= =A0 return encoded_key

= =A0=A0

d= ef handle(s):

= =A0 key_half1 =3D repr(s.recv(4443))

= =A0 encoded_key =3D get_response_handshake_key(key_half1)

= =A0 hand_shake_response =3D "'HTTP/1.1 101 Switching Protocols \r\= nUpgrade: websocket \r\nConnection: Upgrade \r\nSec-WebSocket-Accept: %s\r\= n'"%(encoded_key)

= =A0 s.send(hand_shake_response)

= =A0 print 'response sent vinod'

= =A0 time.sleep(1)

= =A0 print 'message1 sent '

= =A0 s.send('\x00hello\xff')

= =A0 time.sleep(1)

= =A0 s.send('\x00world\xff')

= =A0 print 'message2 sent'

= =A0 s.close()

<= u>=A0

s= =3D socket.socket()

s= .setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1)=

s= .bind(('ip_address', 4443));

p= rint 'binding done '

s= .listen(1);

p= rint 'listening '

w= hile 1:

= =A0 t,_ =3D s.accept();

= =A0 print 'something got accepted '

= =A0 threading.Thread(target =3D handle, args =3D (t,)).start()

-= ---------------------------------------------------------------------------= ------------------------------

C= lient=A0

-= --------

&= lt;!DOCTYPE html>

&= lt;html xmlns=3D"http://www.w3.org/1999/xhtml= ">

= =A0 <head>

= =A0 =A0 <title>Web Socket Example</title><= /p>

= =A0 =A0 <meta charset=3D"UTF-8">

= =A0 =A0 <script>

= =A0 =A0 =A0 window.onload =3D function() {

= =A0 =A0 =A0 =A0 var s =3D new WebSocket("ws://ip_address:4443/");=

= =A0 =A0 =A0 =A0 s.onopen =3D function(e) { alert("opened"); }<= /u>

= =A0 =A0 =A0 =A0 s.onclose =3D function(e) { alert(e);alert("closed&quo= t;); }

= =A0 =A0 =A0 =A0 s.onmessage =3D function(e) { alert("got: " + e.d= ata); }

= =A0 =A0 =A0 };

= =A0 =A0 </script>

= =A0 </head>

= =A0 =A0 <body>

= =A0 =A0 =A0 <div id=3D"holder" style=3D"width:600px; heig= ht:300px"></div>

= =A0 =A0 </body>

&= lt;/html>

-= ---------------------------------------------------------------------------= ---

O= UTPUT on console at server :

b= inding done=A0

l= istening=A0

s= omething got accepted=A0

&= #39;GET / HTTP/1.1\r\nUpgrade: websocket\r\nConnection: Upgrade\r\nHost: ip= _address:4443\r\nOrigin:http://192.168.0.101:8888\r\= nSec-WebSocket-Key: JTsXI9vB6e/psrPTasC4zw=3D=3D\r\nSec-WebSocket-Version: 13\r\n\r\n'<= /u>

<= u>=A0

r= esponse sent vinod

m= essage1 sent=A0

m= essage2 sent

-= ---------------------------------------------------------------------------= -----

I= t's showing message sent here. But I'm not receiving any messages o= n browser. Now even the "alert open" is happening for onopen even= t. I have "s.close()" at the end because of which the only thing ha= ppening on browser is : an alert with "closed"

<= u>=A0

P= lease help me out. The protocol is implemented all fine. I checked with the= encoders too. They are fine. There could be a small thing I'm missing.

<= u>=A0

T= hanks,

V= inodh


--f46d04478817247e7f04c3705903-- From arman@noemax.com Wed Jun 27 01:57:08 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 5A40321F84E1 for ; Wed, 27 Jun 2012 01:57:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.164 X-Spam-Level: X-Spam-Status: No, score=-2.164 tagged_above=-999 required=5 tests=[AWL=-0.166, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_52=0.6] 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 bgYu4hRqbLuX for ; Wed, 27 Jun 2012 01:57:07 -0700 (PDT) Received: from mail.noemax.com (mail.noemax.com [64.34.201.8]) by ietfa.amsl.com (Postfix) with ESMTP id AD1A821F849A for ; Wed, 27 Jun 2012 01:57:06 -0700 (PDT) DKIM-Signature: a=rsa-sha1; t=1340787427; x=1341392227; s=m1024; d=noemax.com; c=relaxed/relaxed; v=1; bh=P//4Zog7qUHWFRfERZbhBG23RdI=; h=From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:In-Reply-To:References; b=482RJbdczbJ/phzOC1kjxF9eIz23sXbuiY3ilTLXlVD/VccZgW5k1zoTTdDe5NUNORsbrzNbf9sfisiho1diZZfJAhSx3xzyS6u7/9/yBZcylQrgt0+uvZI3HXwNqFHw4OrL/0cLVthxrQSf6tZhhmcf6VJlMHFET+q543nTwSc= Received: from mail.noemax.com by mail.noemax.com (IceWarp 10.4.1) with ASMTP (SSL) id LOG17105; Wed, 27 Jun 2012 11:57:05 +0300 From: "Arman Djusupov" To: "'Takeshi Yoshino'" References: <001a01cd3e69$4a221c10$de665430$@noemax.com> <4FC732DC.3000308@250bpm.com> <000e01cd3f1c$af15ad40$0d4107c0$@noemax.com> <4FC880A7.9070007@250bpm.com> <001001cd4000$fe2c82c0$fa858840$@noemax.com> <4FCCAE6B.1010306@250bpm.com> <002d01cd4262$747957b0$5d6c0710$@noemax.com> <20120607022312.GA26406@jl-vm1.vm.bytemark.co.uk> <000e01cd449d$1c0ed220$542c7660$@noemax.com> <000401cd4566$d5f6bb70$81e43250$@noemax.com> In-Reply-To: Date: Wed, 27 Jun 2012 11:56:24 +0300 Message-ID: <002f01cd5442$c0129370$4037ba50$@noemax.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0030_01CD545B.E56103F0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQDnHEYxNcL9Xb2UVJoRm1lbL/BkAQFoH3KRAV1ppa8CZ6BgXAIpbgj4AsMo47wDBdtyYwH7TrBAAdzt12oB94xqWAGEGWmHAlGfbXgBsAbLXwLdWUHul/+4P9A= Content-Language: en-us Cc: hybi@ietf.org Subject: Re: [hybi] Flow control quota 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, 27 Jun 2012 08:57:08 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0030_01CD545B.E56103F0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit This format will produce an overhead of just 1 byte per encapsulated frame. The only thing that worries me is that the mux extension produces opcode 2 frames, FIN frames and continuation frames in random order. For non-mux intermediaries this would look like mess, since it would be getting multiple subsequent frames with opcode 2 without FIN frames between them which is a violation of RFC 6455 (mux specification eliminate this requirement). But I'm still fine with this solution. A little inconvenience is small price to pay for better bandwidth utilization. With best regards, Arman From: Takeshi Yoshino [mailto:tyoshino@google.com] Sent: Wednesday, June 27, 2012 10:44 AM To: Arman Djusupov Cc: Greg Wilkins; hybi@ietf.org Subject: Re: [hybi] Flow control quota Here's the text for the proposed scheme. ==== 6. Framing This extension encapsulates each frame of a multiplexed connection into a binary message with Payload Data obtained by concatenating the following data in the order they are listed: 1. The logical channel ID for the multiplexed connection. 2. FIN, RSV1, RSV2, RSV3 and opcode of the original frame. 3. Unmasked "Payload Data" of the original frame. ==== 8. Examples 0x82 0x0d 0x01 0x81 "Hello world" This is a non-fragmented text message of "Hello world" on channel 1 encapsulated into a non-fragmented message. 0x02 0x07 0x01 0x81 "Hello" 0x80 0x06 " world" This is a fragmented encapsulating message converying a non- fragmented text frame "Hello world" on channel 1. 0x82 0x07 0x01 0x01 "Hello" 0x82 0x05 0x02 0x81 "bye" 0x82 0x08 0x01 0x80 " world" This example shows how data for two channels are interleaved. There're three non-fragmented encapsulating messages. The first and third one convey each of two frames of a fragmented text message of "Hello world" on channel 1. The second one conveys a non-fragmented text message of "bye" on channel 2. ------=_NextPart_000_0030_01CD545B.E56103F0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

This format will produce an overhead of just 1 byte per encapsulated = frame. The only thing that worries me is that the mux extension produces = opcode 2 frames, FIN frames and continuation frames in random order. For = non-mux intermediaries this would look like mess, since it would be = getting multiple subsequent frames with opcode 2 without FIN frames = between them which is a violation of RFC 6455 (mux specification = eliminate this requirement).

 

But I’m still fine with this solution. A little inconvenience = is small price to pay for better bandwidth = utilization.

 

With best regards,

Arman

 

 

From:= = Takeshi Yoshino [mailto:tyoshino@google.com]
Sent: Wednesday, = June 27, 2012 10:44 AM
To: Arman Djusupov
Cc: Greg = Wilkins; hybi@ietf.org
Subject: Re: [hybi] Flow control = quota

 

Here's the text for the = proposed scheme.

 

=3D=3D=3D=3D=

 

6. =  Framing

 

   This extension = encapsulates each frame of a multiplexed = connection

   into a binary = message with Payload Data obtained by concatenating = the

   following data = in the order they are listed:

 

   1.  The = logical channel ID for the multiplexed = connection.

 

   2.  FIN, = RSV1, RSV2, RSV3 and opcode of the original = frame.

 

   3. =  Unmasked "Payload Data" of the original = frame.

 

=3D=3D=3D=3D=

 

8. =  Examples

 

   0x82 0x0d 0x01 = 0x81 "Hello world"

 

      This is = a non-fragmented text message of "Hello world" on = channel

      1 = encapsulated into a non-fragmented = message.

 

   0x02 0x07 0x01 = 0x81 "Hello" 0x80 0x06 " = world"

 

      This is = a fragmented encapsulating message converying a = non-

      = fragmented text frame "Hello world" on channel = 1.

 

   0x82 0x07 0x01 = 0x01 "Hello" 0x82 0x05 0x02 0x81 "bye" 0x82 0x08 = 0x01

   0x80 " = world"

 

      This = example shows how data for two channels are = interleaved.

      There're = three non-fragmented encapsulating messages.  The = first

      and = third one convey each of two frames of a fragmented = text

      message = of "Hello world" on channel 1.  The second one conveys = a

      = non-fragmented text message of "bye" on channel = 2.

 

------=_NextPart_000_0030_01CD545B.E56103F0-- From zash@zash.se Tue Jun 26 18:27:27 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 EF5F311E8101; Tue, 26 Jun 2012 18:27:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35] 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 pTVYQ-PEDdsm; Tue, 26 Jun 2012 18:27:27 -0700 (PDT) Received: from mail.zash.se (ip66.hethane.riksnet.nu [85.11.25.66]) by ietfa.amsl.com (Postfix) with ESMTP id 6D55711E8085; Tue, 26 Jun 2012 18:27:27 -0700 (PDT) Received: from [77.110.10.237] (ip3-237.bon.riksnet.se [77.110.10.237]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) (Authenticated sender: zash) by mail.zash.se (Postfix) with ESMTPSA id AB37460EDC; Wed, 27 Jun 2012 03:27:23 +0200 (CEST) Message-ID: <4FEA616B.6040201@zash.se> Date: Wed, 27 Jun 2012 03:27:07 +0200 From: Kim Alvefur User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120615 Thunderbird/13.0.1 MIME-Version: 1.0 To: Jack Moffitt References: <20120625215354.8426.66267.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enig42AD266655FDDD60C69669DF" X-Mailman-Approved-At: Wed, 27 Jun 2012 02:03:30 -0700 Cc: Hybi , Jabber/XMPP software development list , XMPP Subject: Re: [hybi] [xmpp] Fwd: New Version Notification for draft-moffitt-xmpp-over-websocket-01.txt 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, 27 Jun 2012 01:27:28 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig42AD266655FDDD60C69669DF Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 2012-06-25T23:55:05 CEST, Jack Moffitt wrote: > I've just updated and submitted a new draft. > > The changes are fairly minor, mostly clarification of a few things > that were pointed out in the last draft and updated references. Great to see things moving again! > Please let me know if you have any comments. >TLS cannot be used in The XMPP sub-protocol because the sub-protocol > does not allow for raw binary data to be sent. This is no longer correct, you can now send binary data. Not that it=20 makes TLS over WS (over SSL) a good idea. I expected a pointer=20 towards wss instead. Also applies to Security Considerations. > Examples will be added as soon as the WebSocket protocol > specification is more stable. More stable than a published RFC? ;) > If a registry is created for WebSocket sub-protocols, the xmpp sub- > protocol will be registered. There was. --------------enig42AD266655FDDD60C69669DF Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBCgAGBQJP6mFrAAoJEK3tmne2etMpi0MP/1PCpgX79ynVLx+gsWsg3R4T sRF0G5dxlz776Dmue7Cs45kBNcj/4EuB1gBGsWH0WdlgNnLuc3LFOX2bPxwOTx+q 9EYhFOsO9SCkD4lFIoCJC36/CRgAR4S4z+FobZJJzi7nP4R2kmQo0iKKOWgXpEPq 5lOjoQ1YvIAffBR5ZdmDpQkZF0r2jaWzMAv6C5qmEHC2O1HyyIyzd4f6nN38hPqV oZARehIV8eiEjfwlsW2lspMv+1xLvSiNWSVFbmi6+0yC04Uz4ZlHFtSl2nOm5ruW 7UJSXBOhXtVirjoXxYF32yJtmJKWC5VWKNykyPdYD8LniBZ2g19Xp+7RPFKVxyXN TotV/C75lVpRe2Z8oRKA98u9zUXo6XTaAP9mzLhIht/FLHDjOyLlCae0pN4miIYC PnRYLNR3b+ds0d93zawz8TsBCnI77MGl8lZEu6qq2z9lEOlkzmq169SPpGs3MC66 N5q6VRa1z2Dk25KfSEVpefuH46Z1Bq45WFvoOFEtdURtEJ+w+FmOo90qKvCeZFOL EEP9mERPfBeSOl1nibTIJDBGRgtQXPrP0f+nxV+iKQsecueom9gx6fZOeDN+cxH7 OOBWL6c739WlaUwe5db4J83DwA454LX3OYSEHpMBnMB9UKJRxmCLsnatjVLCCj3g aZQc1oiEeXYdrxlshu5r =Ny0a -----END PGP SIGNATURE----- --------------enig42AD266655FDDD60C69669DF-- From tyoshino@google.com Wed Jun 27 02:31:59 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 9A04521F85CF for ; Wed, 27 Jun 2012 02:31:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.959 X-Spam-Level: X-Spam-Status: No, score=-102.959 tagged_above=-999 required=5 tests=[AWL=0.017, 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 sddJRerqP4Ws for ; Wed, 27 Jun 2012 02:31:59 -0700 (PDT) Received: from mail-yw0-f53.google.com (mail-yw0-f53.google.com [209.85.213.53]) by ietfa.amsl.com (Postfix) with ESMTP id 174DF21F849A for ; Wed, 27 Jun 2012 02:31:58 -0700 (PDT) Received: by yhp26 with SMTP id 26so1142204yhp.26 for ; Wed, 27 Jun 2012 02:31:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=jFW9qfaK9iCy781vgx9GhPlfUutK8UeZM9xMTsV5loo=; b=dfhRfsj+Cyn/7S+w6u1+PsEyFghGMLFrEQmRrQLMT2bqgREm2lgc62TA5Xm77/BjyP t4mb3J03FgRdkPggw9fWj6l050LdFjvY1/KpTB+ccfaTfyffbLwm9BP9bjyReNValbPP esdM/SgcxK8+0SNWOp+6uzqloSCeXu/HLvPqjMyYOkOSTGVc43WlXZ4KO4XFEKUBOLyU BF40qcx/iZSjH8Mp8eoqKpO7uw7ZgwoHXcWd+RP418bdSwnq8Ox8w+Djm5u4g+qnsjsg gj88w70w1RMz24/ES3gRoT7h2inZNM+5Dp6Be7bXovRcP+vB86LQ/RejMIwxvKvK1m03 ataA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=jFW9qfaK9iCy781vgx9GhPlfUutK8UeZM9xMTsV5loo=; b=bGZIu+/lTWcZcP/mmg6DhaMnGVjVp4YAweZV4P6IB49Yjg3Zjsc5HRuE7zpUsxx+xX +bOBZPdJMostugM5yhqsaqYKJwx0uvER92wmWtM+2s1vufuaQrh6R3kokLlUjsXEi75e baDnQsptjYjjZuSDZrj+iVnswbxsOWMfgn68E5mPvfY6wnroFIN1o+IPx6KxVaAke5+H sDGTKTMxUkhopz8T/RssSe106L6rJshhNvZQIp9djuMyEzQ2JFQPXf5rStkE0RAmkpIZ t84ydpAh314NkDFWY4k/6scOMBg1wE0Z9xPIadHv5oElpVjwayDjE8k7LzGZb2zPTrCT ehmA== Received: by 10.50.222.162 with SMTP id qn2mr820454igc.46.1340789517494; Wed, 27 Jun 2012 02:31:57 -0700 (PDT) Received: by 10.50.222.162 with SMTP id qn2mr820448igc.46.1340789517399; Wed, 27 Jun 2012 02:31:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.66.7 with HTTP; Wed, 27 Jun 2012 02:31:36 -0700 (PDT) In-Reply-To: <002f01cd5442$c0129370$4037ba50$@noemax.com> References: <001a01cd3e69$4a221c10$de665430$@noemax.com> <4FC732DC.3000308@250bpm.com> <000e01cd3f1c$af15ad40$0d4107c0$@noemax.com> <4FC880A7.9070007@250bpm.com> <001001cd4000$fe2c82c0$fa858840$@noemax.com> <4FCCAE6B.1010306@250bpm.com> <002d01cd4262$747957b0$5d6c0710$@noemax.com> <20120607022312.GA26406@jl-vm1.vm.bytemark.co.uk> <000e01cd449d$1c0ed220$542c7660$@noemax.com> <000401cd4566$d5f6bb70$81e43250$@noemax.com> <002f01cd5442$c0129370$4037ba50$@noemax.com> From: Takeshi Yoshino Date: Wed, 27 Jun 2012 18:31:36 +0900 Message-ID: To: Arman Djusupov Content-Type: multipart/alternative; boundary=14dae9340fbfe7383704c370e2e1 X-System-Of-Record: true X-Gm-Message-State: ALoCoQmBtwHaJaiF1U47PjMYIXi1azKyOfAbHFLD6HcMDOtr+I7B6iJsyXG7dg7TuGMRZk8WsN9vVgafMz0SwIaigpnlaNM5oEXzETrkvKC5o+JCSlYfyWRTkGPUf04d2a2ZvMMeUH3f3uItffms3m6lv4iIE8TAdiF1SEKJ+yx/Q+Ih2uU1u0U= Cc: hybi@ietf.org Subject: Re: [hybi] Flow control quota 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, 27 Jun 2012 09:31:59 -0000 --14dae9340fbfe7383704c370e2e1 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Jun 27, 2012 at 5:56 PM, Arman Djusupov wrote: > This format will produce an overhead of just 1 byte per encapsulated > frame. The only thing that worries me is that the mux extension produces > opcode 2 frames, FIN frames and continuation frames in random order. For > non-mux intermediaries this would look like mess, since it would be getting > multiple subsequent frames with opcode 2 without FIN frames between them > which is a violation of RFC 6455 (mux specification eliminate this > requirement). > Ah, no. This format doesn't violate it. The extension 1. receives messages (maybe already fragmented) from multiplexed virtual connections 2. adjusts fragmentation by re/de-fragment them and interleaves them considering quota, fairness, position to insert multiplex control blocks etc. 3. inserts multiplex control blocks between them 4. tag them with channel ID 5. build an encapsulating message for each of them 6. the resulting messages may also be fragmented if necessary Each of interleaved data finally forms a message (a regular (non-interleaved) sequence of fragments) which looks normal for non-mux-capable intermediaries. --14dae9340fbfe7383704c370e2e1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed, Jun 27, 2012 at 5:56 PM, Arm= an Djusupov <arman@noemax.com> wrote:

This format w= ill produce an overhead of just 1 byte per encapsulated frame. The only thi= ng that worries me is that the mux extension produces opcode 2 frames, FIN = frames and continuation frames in random order. For non-mux intermediaries = this would look like mess, since it would be getting multiple subsequent fr= ames with opcode 2 without FIN frames between them which is a violation of = RFC 6455 (mux specification eliminate this requirement).


Ah, no. This format doesn'= t violate it.

The extension
1. receives = messages (maybe already fragmented) from multiplexed virtual connections
2. adjusts fragmentation by re/de-fragment them and interleaves them c= onsidering quota, fairness, position to insert multiplex control blocks etc= .
3. inserts multiplex control blocks between them
4. tag them with channel ID
5. build an encapsulating message= for each of them
6. the resulting messages may also be fragmente= d if necessary

Each of interleaved data finally fo= rms a message (a regular (non-interleaved) sequence of fragments) which loo= ks normal for non-mux-capable intermediaries.

--14dae9340fbfe7383704c370e2e1-- From arman@noemax.com Wed Jun 27 05:05: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 1B7D121F863E for ; Wed, 27 Jun 2012 05:05:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[AWL=0.151, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 oGxjWSRmSq69 for ; Wed, 27 Jun 2012 05:05:21 -0700 (PDT) Received: from mail.noemax.com (mail.noemax.com [64.34.201.8]) by ietfa.amsl.com (Postfix) with ESMTP id 403C221F8661 for ; Wed, 27 Jun 2012 05:05:21 -0700 (PDT) DKIM-Signature: a=rsa-sha1; t=1340798721; x=1341403521; s=m1024; d=noemax.com; c=relaxed/relaxed; v=1; bh=TfyfO6aH9s9NuWvPUKMgWTdezeY=; h=From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:In-Reply-To:References; b=OoF7quFOvPW461OSyzKSZ5c1WDnvIcG2OSUH9GsbvXtYshoB2fcUdzNCBN0ZnYNAheLNYuGyt7EtrAzkL5OddMyUSSRqLeEefnYKljVMR33nPG0mVgKmSTQIdhvRnG2mNDGGPqGRw5y/CNSwmAJLc+cws9wbTW7dI1Bj6Rmer54= Received: from mail.noemax.com by mail.noemax.com (IceWarp 10.4.1) with ASMTP (SSL) id LSG85919; Wed, 27 Jun 2012 15:05:19 +0300 From: "Arman Djusupov" To: "'Takeshi Yoshino'" References: <001a01cd3e69$4a221c10$de665430$@noemax.com> <4FC732DC.3000308@250bpm.com> <000e01cd3f1c$af15ad40$0d4107c0$@noemax.com> <4FC880A7.9070007@250bpm.com> <001001cd4000$fe2c82c0$fa858840$@noemax.com> <4FCCAE6B.1010306@250bpm.com> <002d01cd4262$747957b0$5d6c0710$@noemax.com> <20120607022312.GA26406@jl-vm1.vm.bytemark.co.uk> <000e01cd449d$1c0ed220$542c7660$@noemax.com> <000401cd4566$d5f6bb70$81e43250$@noemax.com> <002f01cd5442$c0129370$4037ba50$@noemax.com> In-Reply-To: Date: Wed, 27 Jun 2012 15:04:35 +0300 Message-ID: <005301cd545d$0a329030$1e97b090$@noemax.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0054_01CD5476.2F821220" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQDnHEYxNcL9Xb2UVJoRm1lbL/BkAQFoH3KRAV1ppa8CZ6BgXAIpbgj4AsMo47wDBdtyYwH7TrBAAdzt12oB94xqWAGEGWmHAlGfbXgBsAbLXwLdWUHuAf+8S9ECjfJZgJfbfz7Q Content-Language: en-us Cc: hybi@ietf.org Subject: Re: [hybi] Flow control quota 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, 27 Jun 2012 12:05:23 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0054_01CD5476.2F821220 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit This encapsulation would allow a muxed message to be further fragmented by an intermediary and so resolves the per-frame compression issue when it is used after mux since it would be able to sync on proper message boundaries. But it doesn't seem that the original frame boundaries can be recovered after de-multiplexing as the frame is getting encapsulated after re-fragmentation. So we completely abandon the idea to preserve the original frames boundaries? (I don't mind, I just want to clarify). With best regards, Arman From: Takeshi Yoshino [mailto:tyoshino@google.com] Sent: Wednesday, June 27, 2012 12:32 PM To: Arman Djusupov Cc: Greg Wilkins; hybi@ietf.org Subject: Re: [hybi] Flow control quota On Wed, Jun 27, 2012 at 5:56 PM, Arman Djusupov wrote: This format will produce an overhead of just 1 byte per encapsulated frame. The only thing that worries me is that the mux extension produces opcode 2 frames, FIN frames and continuation frames in random order. For non-mux intermediaries this would look like mess, since it would be getting multiple subsequent frames with opcode 2 without FIN frames between them which is a violation of RFC 6455 (mux specification eliminate this requirement). Ah, no. This format doesn't violate it. The extension 1. receives messages (maybe already fragmented) from multiplexed virtual connections 2. adjusts fragmentation by re/de-fragment them and interleaves them considering quota, fairness, position to insert multiplex control blocks etc. 3. inserts multiplex control blocks between them 4. tag them with channel ID 5. build an encapsulating message for each of them 6. the resulting messages may also be fragmented if necessary Each of interleaved data finally forms a message (a regular (non-interleaved) sequence of fragments) which looks normal for non-mux-capable intermediaries. ------=_NextPart_000_0054_01CD5476.2F821220 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

This encapsulation would allow a muxed message to be further = fragmented by an intermediary and so resolves the per-frame compression = issue when it is used after mux since it would be able to sync on proper = message boundaries.

 

But it doesn’t seem that the original frame boundaries can be = recovered after de-multiplexing as the frame is getting encapsulated = after re-fragmentation. So we completely abandon the idea to preserve = the original frames boundaries? (I don’t mind, I just want to = clarify).

 

With best regards,

Arman

 

 

From:= = Takeshi Yoshino [mailto:tyoshino@google.com]
Sent: Wednesday, = June 27, 2012 12:32 PM
To: Arman Djusupov
Cc: Greg = Wilkins; hybi@ietf.org
Subject: Re: [hybi] Flow control = quota

 

On = Wed, Jun 27, 2012 at 5:56 PM, Arman Djusupov <arman@noemax.com> = wrote:

This format will produce an overhead of just 1 byte per encapsulated = frame. The only thing that worries me is that the mux extension produces = opcode 2 frames, FIN frames and continuation frames in random order. For = non-mux intermediaries this would look like mess, since it would be = getting multiple subsequent frames with opcode 2 without FIN frames = between them which is a violation of RFC 6455 (mux specification = eliminate this requirement).

 

Ah, no. This format doesn't = violate it.

 

The = extension

1. receives messages (maybe = already fragmented) from multiplexed virtual = connections

2. adjusts fragmentation by = re/de-fragment them and interleaves them considering quota, fairness, = position to insert multiplex control blocks = etc.

3. inserts multiplex control = blocks between them

4. = tag them with channel ID

5. = build an encapsulating message for each of = them

6. the resulting messages may = also be fragmented if necessary

 

Each of interleaved data = finally forms a message (a regular (non-interleaved) sequence of = fragments) which looks normal for non-mux-capable = intermediaries.

 

------=_NextPart_000_0054_01CD5476.2F821220-- From li.yin@intel.com Wed Jun 27 07:08:56 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 629FA21F876F for ; Wed, 27 Jun 2012 07:08:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.891 X-Spam-Level: * X-Spam-Status: No, score=1.891 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FRT_STOCK2=3.988, HTML_MESSAGE=0.001, J_CHICKENPOX_16=0.6, J_CHICKENPOX_17=0.6, J_CHICKENPOX_19=0.6, J_CHICKENPOX_66=0.6, NORMAL_HTTP_TO_IP=0.001, RCVD_IN_DNSWL_HI=-8, WEIRD_PORT=0.001] 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 8utss1rgLnIM for ; Wed, 27 Jun 2012 07:08:55 -0700 (PDT) Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by ietfa.amsl.com (Postfix) with ESMTP id 354A621F876E for ; Wed, 27 Jun 2012 07:08:55 -0700 (PDT) Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by fmsmga102.fm.intel.com with ESMTP; 27 Jun 2012 07:08:54 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208,217";a="170651824" Received: from fmsmsx104.amr.corp.intel.com ([10.19.9.35]) by fmsmga001.fm.intel.com with ESMTP; 27 Jun 2012 07:08:50 -0700 Received: from fmsmsx101.amr.corp.intel.com (10.19.9.52) by FMSMSX104.amr.corp.intel.com (10.19.9.35) with Microsoft SMTP Server (TLS) id 14.1.355.2; Wed, 27 Jun 2012 07:08:50 -0700 Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by FMSMSX101.amr.corp.intel.com (10.19.9.52) with Microsoft SMTP Server (TLS) id 14.1.355.2; Wed, 27 Jun 2012 07:08:49 -0700 Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.87]) by SHSMSX151.ccr.corp.intel.com ([169.254.3.126]) with mapi id 14.01.0355.002; Wed, 27 Jun 2012 22:08:47 +0800 From: "Yin, Li" To: vinod kumar , "hybi@ietf.org" Thread-Topic: [hybi] XMLRPC Server - websocket Thread-Index: AQHNU3/Pl8xClzWrJUqtzDIyBK830JcMbsoAgADWtICAAJPiUP//fiUAgADddBA= Date: Wed, 27 Jun 2012 14:08:47 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.239.127.40] Content-Type: multipart/alternative; boundary="_000_F70A8AEBE518884ABEC998529DD9D15E0D5379SHSMSX101ccrcorpi_" MIME-Version: 1.0 Subject: Re: [hybi] XMLRPC Server - websocket 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, 27 Jun 2012 14:08:56 -0000 --_000_F70A8AEBE518884ABEC998529DD9D15E0D5379SHSMSX101ccrcorpi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhlIGRhdGEgZm9ybWF0IHlvdSBzZW50IGlzIGluY29ycmVjdC4NCk1vcmUgZGV0YWlsZWQgaW5m b3JtYXRpb24sIHlvdSBjYW4gcmVhZCB0aGUgUkZDNjQ1NQ0KaHR0cDovL3Rvb2xzLmlldGYub3Jn L2h0bWwvcmZjNjQ1NSNzZWN0aW9uLTUuMQ0KDQpGcm9tOiB2aW5vZCBrdW1hciBbbWFpbHRvOnZr Ljg2LjgxMUBnbWFpbC5jb21dDQpTZW50OiBXZWRuZXNkYXksIEp1bmUgMjcsIDIwMTIgNDo1MyBQ TQ0KVG86IFlpbiwgTGk7IGh5YmlAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbaHliaV0gWE1MUlBD IFNlcnZlciAtIHdlYnNvY2tldA0KDQpIaSBMaSBZaW4sDQoNClRoYW5rcyBhIGxvdC4gVGhlICJc clxuIiBpcyB0aGUgbWlzdGFrZS4gTm93LCBpdCBzaG93cyBtZSB0aGUgYWxlcnQgIm9wZW5lZCIu IFNvLCBjb25uZWN0aW9uIGlzIGVzdGFibGlzaGVkLiBCdXQgd2hlbiBJIHRyeSBzZW5kaW5nIHNv bWV0aGluZyBhcyBpdCdzIHNob3duIGluIGNvZGUsIHRoZSBvdGhlciBldmVudCAib25tZXNzYWdl IiBpcyBub3QgZ2V0dGluZyB0cmlnZ2VyZWQuIEFuZCBicm93c2VyIGNvbnNvbGUgaXMgZW1wdHkg bm93Lg0KDQpUaGFua3MsDQpWaW5vZGgNCk9uIFdlZCwgSnVuIDI3LCAyMDEyIGF0IDEwOjQ2IEFN LCBZaW4sIExpIDxsaS55aW5AaW50ZWwuY29tPG1haWx0bzpsaS55aW5AaW50ZWwuY29tPj4gd3Jv dGU6DQpoYW5kX3NoYWtlX3Jlc3BvbnNlIHNob3VsZCBlbmQgb2Yg4oCcXHJcblxyXG7igJ0sIHlv dSBjYW4gaGF2ZSBhIHRyeSBhZ2Fpbi4NCg0KQnkgdGhlIHdheSwgd2hpY2ggYnJvd3NlciBhcmUg eW91IHVzaW5nPyBJZiB0aGUgV2ViU29ja2V0IGNvbm5lY3Rpb24gY2Fu4oCZdCBiZSBjcmVhdGVk LCB0aGUgZmFpbGVkIHJlYXNvbiBzaG91bGQgYmUgcHJpbnRlZCBvbiBjb25zb2xlIG9mIGJyb3dz ZXIsDQphcyBmYXIgYXMgSSBrbm93LCBjaHJvbWl1bSBjYW4gZG8gdGhhdC4NCklmIHRoZSBlcnJv ciBzdGlsbCBvY2N1cnMsIHBsZWFzZSBwcm92aWRlIGNvbnNvbGUgbWVzc2FnZSBmcm9tIGJyb3dz ZXIuDQoNClJlZ2FyZHMsDQpMaSBZaW4NCg0KRnJvbTogaHliaS1ib3VuY2VzQGlldGYub3JnPG1h aWx0bzpoeWJpLWJvdW5jZXNAaWV0Zi5vcmc+IFttYWlsdG86aHliaS1ib3VuY2VzQGlldGYub3Jn PG1haWx0bzpoeWJpLWJvdW5jZXNAaWV0Zi5vcmc+XSBPbiBCZWhhbGYgT2Ygdmlub2Qga3VtYXIN ClNlbnQ6IFdlZG5lc2RheSwgSnVuZSAyNywgMjAxMiAzOjQ5IFBNDQpUbzogSm9obiBUYW1wbGlu OyBoeWJpQGlldGYub3JnPG1haWx0bzpoeWJpQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtoeWJp XSBYTUxSUEMgU2VydmVyIC0gd2Vic29ja2V0DQoNCkhpIEpvaG4sDQoNClRoYW5rcyBmb3IgeW91 ciByZXBseS4gSSBoYXZlIGltcGxlbWVudGVkIHRoZSB3ZWJzb2NrZXQuIFN0aWxsIGZhY2luZyBz b21lIHRyb3VibGUuIFRoZSBldmVudCBvbm9wZW4gaXMgbm90IGhhcHBlbmluZy4gV2hlbiBJIHNl bmQgc29tZXRoaW5nIGZyb20gbXkgc2VydmVyLCBpdCBvY2N1cnMuIEJ1dCBub3RoaW5nIGxpa2Ug b25tZXNzYWdlIGV2ZW50IGhhcHBlbnMuDQpIaSwNCg0KIEknbSBub3Qgc3VyZSB3aGV0aGVyIHRo ZSBjb25uZWN0aW9uIGlzIGVzdGFibGlzaGVkIG9yIG5vdC4gVGhlIHRoaW5ncyB3aGljaCBJIGtl cHQgaW4gb25vcGVuIGV2ZW50IGFyZSBub3QgZ2V0dGluZyBhbGVydGVkLiBQbGVhc2UgaGF2ZSBh IGxvb2sgYXQgdGhlIGNvZGVzIGJlbG93Og0KLS0tLS0tDQpTZXJ2ZXINCi0tLS0tLQ0KIyEvdXNy L2Jpbi9lbnYgcHl0aG9uDQoNCmltcG9ydCBzb2NrZXQsIHRocmVhZGluZywgdGltZSwgc3RyaW5n DQppbXBvcnQgaGFzaGxpYg0KaW1wb3J0IGJhc2U2NA0KDQpkZWYgZ2V0X3Jlc3BvbnNlX2hhbmRz aGFrZV9rZXkocyk6DQogIGhzX2xpbmVzID0gcy5zcGxpdCgpDQogIHBhcnQxID0gIiINCiAgcGFy c2VfcG9zaXRpb24gPSBoc19saW5lc1s3XS5pbmRleCgnXFxyJykNCiAgaGFsZjEgPSBoc19saW5l c1s3XVs6cGFyc2VfcG9zaXRpb25dDQogIGhhbGYyID0gIjI1OEVBRkE1LUU5MTQtNDdEQS05NUNB LUM1QUIwREM4NUIxMSINCiAgcmF3X2tleSA9IGhhbGYxK2hhbGYyDQogIHNoYTFfb2JqZWN0ID0g aGFzaGxpYi5zaGExKCkNCiAgc2hhMV9vYmplY3QudXBkYXRlKHJhd19rZXkpDQogIGhhbGZfZW5j b2RlZCA9IHNoYTFfb2JqZWN0LmRpZ2VzdCgpDQogIGVuY29kZWRfa2V5ID0gYmFzZTY0LmI2NGVu Y29kZShoYWxmX2VuY29kZWQpDQogIHJldHVybiBlbmNvZGVkX2tleQ0KDQpkZWYgaGFuZGxlKHMp Og0KICBrZXlfaGFsZjEgPSByZXByKHMucmVjdig0NDQzKSkNCiAgZW5jb2RlZF9rZXkgPSBnZXRf cmVzcG9uc2VfaGFuZHNoYWtlX2tleShrZXlfaGFsZjEpDQogIGhhbmRfc2hha2VfcmVzcG9uc2Ug PSAiJ0hUVFAvMS4xIDEwMSBTd2l0Y2hpbmcgUHJvdG9jb2xzIFxyXG5VcGdyYWRlOiB3ZWJzb2Nr ZXQgXHJcbkNvbm5lY3Rpb246IFVwZ3JhZGUgXHJcblNlYy1XZWJTb2NrZXQtQWNjZXB0OiAlc1xy XG4nIiUoZW5jb2RlZF9rZXkpDQogIHMuc2VuZChoYW5kX3NoYWtlX3Jlc3BvbnNlKQ0KICBwcmlu dCAncmVzcG9uc2Ugc2VudCB2aW5vZCcNCiAgdGltZS5zbGVlcCgxKQ0KICBwcmludCAnbWVzc2Fn ZTEgc2VudCAnDQogIHMuc2VuZCgnXHgwMGhlbGxvXHhmZicpDQogIHRpbWUuc2xlZXAoMSkNCiAg cy5zZW5kKCdceDAwd29ybGRceGZmJykNCiAgcHJpbnQgJ21lc3NhZ2UyIHNlbnQnDQogIHMuY2xv c2UoKQ0KDQpzID0gc29ja2V0LnNvY2tldCgpDQpzLnNldHNvY2tvcHQoc29ja2V0LlNPTF9TT0NL RVQsIHNvY2tldC5TT19SRVVTRUFERFIsIDEpDQpzLmJpbmQoKCdpcF9hZGRyZXNzJywgNDQ0Mykp Ow0KcHJpbnQgJ2JpbmRpbmcgZG9uZSAnDQpzLmxpc3RlbigxKTsNCnByaW50ICdsaXN0ZW5pbmcg Jw0Kd2hpbGUgMToNCiAgdCxfID0gcy5hY2NlcHQoKTsNCiAgcHJpbnQgJ3NvbWV0aGluZyBnb3Qg YWNjZXB0ZWQgJw0KICB0aHJlYWRpbmcuVGhyZWFkKHRhcmdldCA9IGhhbmRsZSwgYXJncyA9ICh0 LCkpLnN0YXJ0KCkNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0NCkNsaWVudA0KLS0tLS0tLS0tDQo8IURPQ1RZUEUgaHRtbD4NCjxodG1sIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy8xOTk5L3hodG1sIj4NCiAgPGhlYWQ+DQogICAgPHRpdGxlPldlYiBT b2NrZXQgRXhhbXBsZTwvdGl0bGU+DQogICAgPG1ldGEgY2hhcnNldD0iVVRGLTgiPg0KICAgIDxz Y3JpcHQ+DQogICAgICB3aW5kb3cub25sb2FkID0gZnVuY3Rpb24oKSB7DQogICAgICAgIHZhciBz ID0gbmV3IFdlYlNvY2tldCgid3M6Ly9pcF9hZGRyZXNzOjQ0NDMvIik7DQogICAgICAgIHMub25v cGVuID0gZnVuY3Rpb24oZSkgeyBhbGVydCgib3BlbmVkIik7IH0NCiAgICAgICAgcy5vbmNsb3Nl ID0gZnVuY3Rpb24oZSkgeyBhbGVydChlKTthbGVydCgiY2xvc2VkIik7IH0NCiAgICAgICAgcy5v bm1lc3NhZ2UgPSBmdW5jdGlvbihlKSB7IGFsZXJ0KCJnb3Q6ICIgKyBlLmRhdGEpOyB9DQogICAg ICB9Ow0KICAgIDwvc2NyaXB0Pg0KICA8L2hlYWQ+DQogICAgPGJvZHk+DQogICAgICA8ZGl2IGlk PSJob2xkZXIiIHN0eWxlPSJ3aWR0aDo2MDBweDsgaGVpZ2h0OjMwMHB4Ij48L2Rpdj4NCiAgICA8 L2JvZHk+DQo8L2h0bWw+DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpPVVRQVVQgb24gY29uc29s ZSBhdCBzZXJ2ZXIgOg0KYmluZGluZyBkb25lDQpsaXN0ZW5pbmcNCnNvbWV0aGluZyBnb3QgYWNj ZXB0ZWQNCidHRVQgLyBIVFRQLzEuMVxyXG5VcGdyYWRlOiB3ZWJzb2NrZXRcclxuQ29ubmVjdGlv bjogVXBncmFkZVxyXG5Ib3N0OiBpcF9hZGRyZXNzOjQ0NDNcclxuT3JpZ2luOmh0dHA6Ly8xOTIu MTY4LjAuMTAxOjg4ODg8aHR0cDovLzE5Mi4xNjguMC4xMDE6ODg4OC8+XHJcblNlYy1XZWJTb2Nr ZXQtS2V5OiBKVHNYSTl2QjZlL3BzclBUYXNDNHp3PT1cclxuU2VjLVdlYlNvY2tldC1WZXJzaW9u OiAxM1xyXG5cclxuJw0KDQpyZXNwb25zZSBzZW50IHZpbm9kDQptZXNzYWdlMSBzZW50DQptZXNz YWdlMiBzZW50DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCkl0J3Mgc2hvd2luZyBtZXNzYWdl IHNlbnQgaGVyZS4gQnV0IEknbSBub3QgcmVjZWl2aW5nIGFueSBtZXNzYWdlcyBvbiBicm93c2Vy LiBOb3cgZXZlbiB0aGUgImFsZXJ0IG9wZW4iIGlzIGhhcHBlbmluZyBmb3Igb25vcGVuIGV2ZW50 LiBJIGhhdmUgInMuY2xvc2UoKSIgYXQgdGhlIGVuZCBiZWNhdXNlIG9mIHdoaWNoIHRoZSBvbmx5 IHRoaW5nIGhhcHBlbmluZyBvbiBicm93c2VyIGlzIDogYW4gYWxlcnQgd2l0aCAiY2xvc2VkIg0K DQpQbGVhc2UgaGVscCBtZSBvdXQuIFRoZSBwcm90b2NvbCBpcyBpbXBsZW1lbnRlZCBhbGwgZmlu ZS4gSSBjaGVja2VkIHdpdGggdGhlIGVuY29kZXJzIHRvby4gVGhleSBhcmUgZmluZS4gVGhlcmUg Y291bGQgYmUgYSBzbWFsbCB0aGluZyBJJ20gbWlzc2luZy4NCg0KVGhhbmtzLA0KVmlub2RoDQoN Cg== --_000_F70A8AEBE518884ABEC998529DD9D15E0D5379SHSMSX101ccrcorpi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 U2ltU3VuOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5v c2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJc QFNpbVN1biI7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQovKiBTdHlsZSBEZWZp bml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXtt YXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1z b0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0 LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xs b3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVj b3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0YXRlLCBkaXYuTXNv QWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxv b24gVGV4dCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglm b250LXNpemU6OC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO30NCnNw YW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQt ZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkJh bGxvb25UZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1z by1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IjsNCglm b250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNv LXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41 aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNl Y3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNv IDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAv Pg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxh eW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwv bzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVO LVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9u MSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+VGhlIGRhdGEgZm9ybWF0IHlvdSBzZW50IGlzIGluY29ycmVjdC48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+TW9yZSBkZXRhaWxlZCBpbmZvcm1hdGlvbiwgeW91IGNh biByZWFkIHRoZSBSRkM2NDU1PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PGEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNjQ1NSNzZWN0aW9u LTUuMSI+aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNjQ1NSNzZWN0aW9uLTUuMTwvYT48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9 ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0 IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiB2 aW5vZCBrdW1hciBbbWFpbHRvOnZrLjg2LjgxMUBnbWFpbC5jb21dDQo8YnI+DQo8Yj5TZW50Ojwv Yj4gV2VkbmVzZGF5LCBKdW5lIDI3LCAyMDEyIDQ6NTMgUE08YnI+DQo8Yj5Ubzo8L2I+IFlpbiwg TGk7IGh5YmlAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtoeWJpXSBYTUxSUEMg U2VydmVyIC0gd2Vic29ja2V0PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PkhpIExpIFlpbiw8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PlRoYW5rcyBhIGxvdC4gVGhlICZxdW90O1xyXG4mcXVvdDsgaXMgdGhlIG1pc3Rha2UuIE5vdywg aXQgc2hvd3MgbWUgdGhlIGFsZXJ0ICZxdW90O29wZW5lZCZxdW90Oy4gU28sIGNvbm5lY3Rpb24g aXMgZXN0YWJsaXNoZWQuIEJ1dCB3aGVuIEkgdHJ5IHNlbmRpbmcgc29tZXRoaW5nIGFzIGl0J3Mg c2hvd24gaW4gY29kZSwgdGhlIG90aGVyIGV2ZW50ICZxdW90O29ubWVzc2FnZSZxdW90OyBpcyBu b3QgZ2V0dGluZyB0cmlnZ2VyZWQuIEFuZCBicm93c2VyIGNvbnNvbGUNCiBpcyBlbXB0eSBub3cu Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPlRoYW5rcyw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+Vmlub2RoPG86cD48L286cD48L3A+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gV2VkLCBKdW4gMjcsIDIwMTIgYXQgMTA6 NDYgQU0sIFlpbiwgTGkgJmx0OzxhIGhyZWY9Im1haWx0bzpsaS55aW5AaW50ZWwuY29tIiB0YXJn ZXQ9Il9ibGFuayI+bGkueWluQGludGVsLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9w Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90OyI+aGFuZF9zaGFrZV9yZXNwb25zZSBzaG91bGQgZW5kIG9mIOKAnFxyXG5cclxu 4oCdLCB5b3UgY2FuIGhhdmUgYSB0cnkgYWdhaW4uPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNwOzwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7Ij5CeSB0aGUgd2F5LCB3aGljaCBicm93c2VyIGFyZSB5b3UgdXNpbmc/ IElmIHRoZSBXZWJTb2NrZXQgY29ubmVjdGlvbiBjYW7igJl0IGJlIGNyZWF0ZWQsIHRoZSBmYWls ZWQgcmVhc29uIHNob3VsZA0KIGJlIHByaW50ZWQgb24gY29uc29sZSBvZiBicm93c2VyLDwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7Ij5hcyBmYXIgYXMgSSBrbm93LCBjaHJvbWl1bSBjYW4gZG8gdGhhdC48L3Nw YW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90OyI+SWYgdGhlIGVycm9yIHN0aWxsIG9jY3VycywgcGxlYXNlIHByb3ZpZGUg Y29uc29sZSBtZXNzYWdlIGZyb20gYnJvd3Nlci48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7PC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDsiPlJlZ2FyZHMsPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkxpIFlpbjwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxk aXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRk aW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90OyI+DQo8YSBocmVmPSJtYWlsdG86aHliaS1ib3VuY2VzQGlldGYub3JnIiB0YXJnZXQ9 Il9ibGFuayI+aHliaS1ib3VuY2VzQGlldGYub3JnPC9hPiBbbWFpbHRvOjxhIGhyZWY9Im1haWx0 bzpoeWJpLWJvdW5jZXNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5oeWJpLWJvdW5jZXNAaWV0 Zi5vcmc8L2E+XQ0KPGI+T24gQmVoYWxmIE9mIDwvYj52aW5vZCBrdW1hcjxicj4NCjxiPlNlbnQ6 PC9iPiBXZWRuZXNkYXksIEp1bmUgMjcsIDIwMTIgMzo0OSBQTTxicj4NCjxiPlRvOjwvYj4gSm9o biBUYW1wbGluOyA8YSBocmVmPSJtYWlsdG86aHliaUBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsi Pmh5YmlAaWV0Zi5vcmc8L2E+PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbaHliaV0gWE1MUlBD IFNlcnZlciAtIHdlYnNvY2tldDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj5IaSBKb2huLA0KPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+VGhhbmtzIGZvciB5b3VyIHJlcGx5LiBJIGhhdmUgaW1w bGVtZW50ZWQgdGhlIHdlYnNvY2tldC4gU3RpbGwgZmFjaW5nIHNvbWUgdHJvdWJsZS4gVGhlIGV2 ZW50IG9ub3BlbiBpcyBub3QgaGFwcGVuaW5nLiBXaGVuIEkgc2VuZCBzb21ldGhpbmcgZnJvbSBt eSBzZXJ2ZXIsIGl0IG9jY3Vycy4gQnV0IG5vdGhpbmcNCiBsaWtlIG9ubWVzc2FnZSBldmVudCBo YXBwZW5zLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFs JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzIyMjIyMjtiYWNrZ3JvdW5kOndo aXRlIj5IaSw8L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvO2JhY2tncm91bmQ6d2hpdGUiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250 LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMy MjIyMjIiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0bztiYWNrZ3JvdW5kOndoaXRlIj4NCjxzcGFuIHN0eWxlPSJmb250LXNp emU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMjIyMjIyIj4mbmJzcDtJJ20gbm90IHN1cmUgd2hldGhlciB0aGUgY29ubmVj dGlvbiBpcyBlc3RhYmxpc2hlZCBvciBub3QuIFRoZSB0aGluZ3Mgd2hpY2ggSSBrZXB0IGluIG9u b3BlbiBldmVudCBhcmUgbm90IGdldHRpbmcgYWxlcnRlZC4gUGxlYXNlIGhhdmUgYSBsb29rIGF0 IHRoZSBjb2RlcyBiZWxvdzo8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG87YmFja2dyb3VuZDp3aGl0ZSI+DQo8c3BhbiBzdHlsZT0iZm9u dC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzIyMjIyMiI+LS0tLS0tPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO2JhY2tncm91bmQ6d2hpdGUiPg0KPHNw YW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMyMjIyMjIiPlNlcnZlcjwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztiYWNrZ3JvdW5k OndoaXRlIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMjIyMjIyIj4tLS0tLS08 L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvO2JhY2tncm91bmQ6d2hpdGUiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjBw dDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMyMjIyMjIiPiMhL3Vzci9iaW4vZW52IHB5dGhvbjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztiYWNrZ3JvdW5kOndoaXRlIj4N CjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMjIyMjIyIj4mbmJzcDs8L3NwYW4+PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87YmFja2dy b3VuZDp3aGl0ZSI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzIyMjIyMiI+aW1w b3J0IHNvY2tldCwgdGhyZWFkaW5nLCB0aW1lLCBzdHJpbmc8L3NwYW4+PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87YmFja2dyb3VuZDp3aGl0ZSI+ DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzIyMjIyMiI+aW1wb3J0IGhhc2hsaWI8 L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG87YmFja2dyb3VuZDp3aGl0ZSI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzIy MjIyMiI+aW1wb3J0IGJhc2U2NDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztiYWNrZ3JvdW5kOndoaXRlIj4NCjxzcGFuIHN0eWxlPSJm b250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMjIyMjIyIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87YmFja2dyb3VuZDp3aGl0ZSI+DQo8 c3BhbiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzIyMjIyMiI+ZGVmIGdldF9yZXNwb25zZV9o YW5kc2hha2Vfa2V5KHMpOjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0bztiYWNrZ3JvdW5kOndoaXRlIj4NCjxzcGFuIHN0eWxlPSJmb250 LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMjIyMjIyIj4mbmJzcDsgaHNfbGluZXMgPSBzLnNwbGl0KCk8L3NwYW4+ PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87YmFj a2dyb3VuZDp3aGl0ZSI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzIyMjIyMiI+ Jm5ic3A7IHBhcnQxID0gJnF1b3Q7JnF1b3Q7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO2JhY2tncm91bmQ6d2hpdGUiPg0KPHNwYW4g c3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMyMjIyMjIiPiZuYnNwOyBwYXJzZV9wb3NpdGlvbiA9 IGhzX2xpbmVzWzddLmluZGV4KCdcXHInKTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztiYWNrZ3JvdW5kOndoaXRlIj4NCjxzcGFuIHN0 eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMjIyMjIyIj4mbmJzcDsgaGFsZjEgPSBoc19saW5lc1s3 XVs6cGFyc2VfcG9zaXRpb25dPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvO2JhY2tncm91bmQ6d2hpdGUiPg0KPHNwYW4gc3R5bGU9ImZv bnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMyMjIyMjIiPiZuYnNwOyBoYWxmMiA9ICZxdW90OzI1OEVBRkE1LUU5 MTQtNDdEQS05NUNBLUM1QUIwREM4NUIxMSZxdW90Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztiYWNrZ3JvdW5kOndoaXRlIj4NCjxz cGFuIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMjIyMjIyIj4mbmJzcDsgcmF3X2tleSA9IGhh bGYxJiM0MztoYWxmMjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0bztiYWNrZ3JvdW5kOndoaXRlIj4NCjxzcGFuIHN0eWxlPSJmb250LXNp emU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMjIyMjIyIj4mbmJzcDsgc2hhMV9vYmplY3QgPSBoYXNobGliLnNoYTEoKTwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 bztiYWNrZ3JvdW5kOndoaXRlIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMjIy MjIyIj4mbmJzcDsgc2hhMV9vYmplY3QudXBkYXRlKHJhd19rZXkpPC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO2JhY2tncm91bmQ6d2hp dGUiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlh bCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMyMjIyMjIiPiZuYnNwOyBoYWxm X2VuY29kZWQgPSBzaGExX29iamVjdC5kaWdlc3QoKTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztiYWNrZ3JvdW5kOndoaXRlIj4NCjxz cGFuIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMjIyMjIyIj4mbmJzcDsgZW5jb2RlZF9rZXkg PSBiYXNlNjQuYjY0ZW5jb2RlKGhhbGZfZW5jb2RlZCk8L3NwYW4+PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87YmFja2dyb3VuZDp3aGl0ZSI+DQo8 c3BhbiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzIyMjIyMiI+Jm5ic3A7IHJldHVybiBlbmNv ZGVkX2tleTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0bztiYWNrZ3JvdW5kOndoaXRlIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMjIyMjIyIj4mbmJzcDsmbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87YmFja2dyb3VuZDp3aGl0ZSI+DQo8c3BhbiBz dHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzIyMjIyMiI+ZGVmIGhhbmRsZShzKTo8L3NwYW4+PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87YmFja2dy b3VuZDp3aGl0ZSI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzIyMjIyMiI+Jm5i c3A7IGtleV9oYWxmMSA9IHJlcHIocy5yZWN2KDQ0NDMpKTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztiYWNrZ3JvdW5kOndoaXRlIj4N CjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMjIyMjIyIj4mbmJzcDsgZW5jb2RlZF9r ZXkgPSBnZXRfcmVzcG9uc2VfaGFuZHNoYWtlX2tleShrZXlfaGFsZjEpPC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO2JhY2tncm91bmQ6 d2hpdGUiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtB cmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMyMjIyMjIiPiZuYnNwOyBo YW5kX3NoYWtlX3Jlc3BvbnNlID0gJnF1b3Q7J0hUVFAvMS4xIDEwMSBTd2l0Y2hpbmcgUHJvdG9j b2xzIFxyXG5VcGdyYWRlOiB3ZWJzb2NrZXQgXHJcbkNvbm5lY3Rpb246IFVwZ3JhZGUgXHJcblNl Yy1XZWJTb2NrZXQtQWNjZXB0OiAlc1xyXG4nJnF1b3Q7JShlbmNvZGVkX2tleSk8L3NwYW4+PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87YmFja2dy b3VuZDp3aGl0ZSI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzIyMjIyMiI+Jm5i c3A7IHMuc2VuZChoYW5kX3NoYWtlX3Jlc3BvbnNlKTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztiYWNrZ3JvdW5kOndoaXRlIj4NCjxz cGFuIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMjIyMjIyIj4mbmJzcDsgcHJpbnQgJ3Jlc3Bv bnNlIHNlbnQgdmlub2QnPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvO2JhY2tncm91bmQ6d2hpdGUiPg0KPHNwYW4gc3R5bGU9ImZvbnQt c2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMyMjIyMjIiPiZuYnNwOyB0aW1lLnNsZWVwKDEpPC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO2JhY2tncm91bmQ6 d2hpdGUiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtB cmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMyMjIyMjIiPiZuYnNwOyBw cmludCAnbWVzc2FnZTEgc2VudCAnPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztiYWNrZ3JvdW5kOndoaXRlIj4NCjxzcGFu IHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojNTAwMDUwIj4mbmJzcDsgcy5zZW5kKCdceDAwaGVs bG9ceGZmJyk8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG87YmFja2dyb3VuZDp3aGl0ZSI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjgu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzUwMDA1MCI+Jm5ic3A7IHRpbWUuc2xlZXAoMSk8L3NwYW4+PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87YmFja2dyb3VuZDp3aGl0ZSI+ DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzUwMDA1MCI+Jm5ic3A7IHMuc2VuZCgn XHgwMHdvcmxkXHhmZicpPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87YmFja2dyb3VuZDp3aGl0ZSI+DQo8c3BhbiBzdHls ZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzIyMjIyMiI+Jm5ic3A7IHByaW50ICdtZXNzYWdlMiBzZW50 Jzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG87YmFja2dyb3VuZDp3aGl0ZSI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjgu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzUwMDA1MCI+Jm5ic3A7IHMuY2xvc2UoKTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztiYWNrZ3JvdW5kOndoaXRlIj4NCjxz cGFuIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojNTAwMDUwIj4mbmJzcDs8L3NwYW4+PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87YmFja2dyb3Vu ZDp3aGl0ZSI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzUwMDA1MCI+cyA9IHNv Y2tldC5zb2NrZXQoKTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0bztiYWNrZ3JvdW5kOndoaXRlIj4NCjxzcGFuIHN0eWxlPSJmb250LXNp emU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojNTAwMDUwIj5zLnNldHNvY2tvcHQoc29ja2V0LlNPTF9TT0NLRVQsIHNvY2tl dC5TT19SRVVTRUFERFIsIDEpPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87YmFja2dyb3VuZDp3aGl0ZSI+DQo8c3BhbiBz dHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzIyMjIyMiI+cy5iaW5kKCgnaXBfYWRkcmVzcycsIDQ0 NDMpKTs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvO2JhY2tncm91bmQ6d2hpdGUiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiM1MDAwNTAiPnByaW50ICdiaW5kaW5nIGRvbmUgJzwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztiYWNrZ3JvdW5kOndo aXRlIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJp YWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojNTAwMDUwIj5zLmxpc3Rlbigx KTs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG87YmFja2dyb3VuZDp3aGl0ZSI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzUwMDA1MCI+cHJpbnQgJ2xpc3RlbmluZyAnPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO2JhY2tncm91bmQ6d2hpdGUiPg0KPHNwYW4g c3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiM1MDAwNTAiPndoaWxlIDE6PC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO2JhY2tncm91bmQ6 d2hpdGUiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtB cmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiM1MDAwNTAiPiZuYnNwOyB0 LF8gPSBzLmFjY2VwdCgpOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0bztiYWNrZ3JvdW5kOndoaXRlIj4NCjxzcGFuIHN0eWxlPSJmb250 LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojNTAwMDUwIj4mbmJzcDsgcHJpbnQgJ3NvbWV0aGluZyBnb3QgYWNjZXB0 ZWQgJzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0bztiYWNrZ3JvdW5kOndoaXRlIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojNTAwMDUwIj4mbmJzcDsgdGhyZWFkaW5nLlRocmVhZCh0YXJnZXQgPSBoYW5kbGUsIGFyZ3Mg PSAodCwpKS5zdGFydCgpPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztiYWNrZ3JvdW5kOndoaXRlIj4NCjxz cGFuIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMjIyMjIyIj4tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO2JhY2tncm91bmQ6d2hpdGUiPg0KPHNw YW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMyMjIyMjIiPkNsaWVudCZuYnNwOzwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztiYWNr Z3JvdW5kOndoaXRlIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMjIyMjIyIj4t LS0tLS0tLS08L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztiYWNrZ3JvdW5kOndoaXRlIj4NCjxzcGFuIHN0eWxl PSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojNTAwMDUwIj4mbHQ7IURPQ1RZUEUgaHRtbCZndDs8L3NwYW4+ PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87YmFj a2dyb3VuZDp3aGl0ZSI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzUwMDA1MCI+ Jmx0O2h0bWwgeG1sbnM9JnF1b3Q7PGEgaHJlZj0iaHR0cDovL3d3dy53My5vcmcvMTk5OS94aHRt bCIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjojMTE1NUNDIj5odHRwOi8vd3d3 LnczLm9yZy8xOTk5L3hodG1sPC9zcGFuPjwvYT4mcXVvdDsmZ3Q7PC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO2JhY2tncm91bmQ6d2hp dGUiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlh bCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiM1MDAwNTAiPiZuYnNwOyAmbHQ7 aGVhZCZndDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG87YmFja2dyb3VuZDp3aGl0ZSI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjgu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzUwMDA1MCI+Jm5ic3A7ICZuYnNwOyAmbHQ7dGl0bGUmZ3Q7V2ViIFNvY2tldCBFeGFt cGxlJmx0Oy90aXRsZSZndDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG87YmFja2dyb3VuZDp3aGl0ZSI+DQo8c3BhbiBzdHlsZT0iZm9u dC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzUwMDA1MCI+Jm5ic3A7ICZuYnNwOyAmbHQ7bWV0YSBjaGFyc2V0PSZx dW90O1VURi04JnF1b3Q7Jmd0Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztiYWNrZ3JvdW5kOndoaXRlIj4NCjxzcGFuIHN0eWxlPSJm b250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojNTAwMDUwIj4mbmJzcDsgJm5ic3A7ICZsdDtzY3JpcHQmZ3Q7PC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv O2JhY2tncm91bmQ6d2hpdGUiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZh bWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiM1MDAw NTAiPiZuYnNwOyAmbmJzcDsgJm5ic3A7IHdpbmRvdy5vbmxvYWQgPSBmdW5jdGlvbigpIHs8L3Nw YW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0bztiYWNrZ3JvdW5kOndoaXRlIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMjIyMjIyIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgdmFyIHMgPSBuZXcgV2ViU29j a2V0KCZxdW90O3dzOi8vaXBfYWRkcmVzczo0NDQzLyZxdW90Oyk7PC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO2JhY2tncm91bmQ6d2hp dGUiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlh bCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiM1MDAwNTAiPiZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyBzLm9ub3BlbiA9IGZ1bmN0aW9uKGUpIHsgYWxlcnQoJnF1b3Q7b3Bl bmVkJnF1b3Q7KTsgfTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0bztiYWNrZ3JvdW5kOndoaXRlIj4NCjxzcGFuIHN0eWxlPSJmb250LXNp emU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMjIyMjIyIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgcy5vbmNsb3Nl ID0gZnVuY3Rpb24oZSkgeyBhbGVydChlKTthbGVydCgmcXVvdDtjbG9zZWQmcXVvdDspOyB9PC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0bztiYWNrZ3JvdW5kOndoaXRlIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojNTAwMDUwIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgcy5vbm1lc3NhZ2UgPSBmdW5j dGlvbihlKSB7IGFsZXJ0KCZxdW90O2dvdDogJnF1b3Q7ICYjNDM7IGUuZGF0YSk7IH08L3NwYW4+ PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87YmFj a2dyb3VuZDp3aGl0ZSI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzUwMDA1MCI+ Jm5ic3A7ICZuYnNwOyAmbmJzcDsgfTs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87YmFja2dyb3VuZDp3aGl0ZSI+DQo8c3BhbiBzdHls ZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzUwMDA1MCI+Jm5ic3A7ICZuYnNwOyAmbHQ7L3NjcmlwdCZn dDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG87YmFja2dyb3VuZDp3aGl0ZSI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzUwMDA1MCI+Jm5ic3A7ICZsdDsvaGVhZCZndDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87YmFja2dyb3VuZDp3aGl0ZSI+DQo8c3Bh biBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzUwMDA1MCI+Jm5ic3A7ICZuYnNwOyAmbHQ7Ym9k eSZndDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG87YmFja2dyb3VuZDp3aGl0ZSI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjguMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzUwMDA1MCI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJmx0O2RpdiBpZD0mcXVvdDtob2xkZXIm cXVvdDsgc3R5bGU9JnF1b3Q7d2lkdGg6NjAwcHg7IGhlaWdodDozMDBweCZxdW90OyZndDsmbHQ7 L2RpdiZndDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG87YmFja2dyb3VuZDp3aGl0ZSI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjgu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzUwMDA1MCI+Jm5ic3A7ICZuYnNwOyAmbHQ7L2JvZHkmZ3Q7PC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO2JhY2tncm91bmQ6 d2hpdGUiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtB cmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiM1MDAwNTAiPiZsdDsvaHRt bCZndDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvO2JhY2tncm91bmQ6d2hpdGUiPg0KPHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMyMjIyMjIiPi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08L3NwYW4+ PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87YmFj a2dyb3VuZDp3aGl0ZSI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzIyMjIyMiI+ T1VUUFVUIG9uIGNvbnNvbGUgYXQgc2VydmVyIDo8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO2JhY2tncm91bmQ6d2hpdGUi Pg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMyMjIyMjIiPmJpbmRpbmcgZG9uZSZu YnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0bztiYWNrZ3JvdW5kOndoaXRlIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMjIyMjIyIj5saXN0ZW5pbmcmbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87YmFja2dyb3VuZDp3aGl0ZSI+DQo8c3BhbiBz dHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzIyMjIyMiI+c29tZXRoaW5nIGdvdCBhY2NlcHRlZCZu YnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0bztiYWNrZ3JvdW5kOndoaXRlIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMjIyMjIyIj4nR0VUIC8gSFRUUC8xLjFcclxuVXBncmFkZTogd2Vic29ja2V0XHJcbkNvbm5l Y3Rpb246IFVwZ3JhZGVcclxuSG9zdDogaXBfYWRkcmVzczo0NDQzXHJcbk9yaWdpbjo8YSBocmVm PSJodHRwOi8vMTkyLjE2OC4wLjEwMTo4ODg4LyIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxl PSJjb2xvcjojMTE1NUNDIj5odHRwOi8vMTkyLjE2OC4wLjEwMTo4ODg4PC9zcGFuPjwvYT5cclxu U2VjLVdlYlNvY2tldC1LZXk6DQogSlRzWEk5dkI2ZS9wc3JQVGFzQzR6dz09XHJcblNlYy1XZWJT b2NrZXQtVmVyc2lvbjogMTNcclxuXHJcbic8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87YmFja2dyb3VuZDp3aGl0ZSI+DQo8c3BhbiBz dHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzIyMjIyMiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO2JhY2tncm91bmQ6d2hp dGUiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlh bCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMyMjIyMjIiPnJlc3BvbnNlIHNl bnQgdmlub2Q8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG87YmFja2dyb3VuZDp3aGl0ZSI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjgu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzIyMjIyMiI+bWVzc2FnZTEgc2VudCZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztiYWNrZ3JvdW5kOndoaXRlIj4N CjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMjIyMjIyIj5tZXNzYWdlMiBzZW50PC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG87YmFja2dyb3VuZDp3aGl0ZSI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjguMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzIyMjIyMiI+LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO2JhY2tncm91bmQ6d2hpdGUi Pg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMyMjIyMjIiPkl0J3Mgc2hvd2luZyBt ZXNzYWdlIHNlbnQgaGVyZS4gQnV0IEknbSBub3QgcmVjZWl2aW5nIGFueSBtZXNzYWdlcyBvbiBi cm93c2VyLiBOb3cgZXZlbiB0aGUgJnF1b3Q7YWxlcnQgb3BlbiZxdW90OyBpcyBoYXBwZW5pbmcg Zm9yIG9ub3BlbiBldmVudC4gSSBoYXZlICZxdW90O3MuY2xvc2UoKSZxdW90OyBhdCB0aGUgZW5k IGJlY2F1c2Ugb2Ygd2hpY2gNCiB0aGUgb25seSB0aGluZyBoYXBwZW5pbmcgb24gYnJvd3NlciBp cyA6IGFuIGFsZXJ0IHdpdGggJnF1b3Q7Y2xvc2VkJnF1b3Q7PC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO2JhY2tncm91bmQ6d2hpdGUi Pg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMyMjIyMjIiPiZuYnNwOzwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztiYWNr Z3JvdW5kOndoaXRlIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMjIyMjIyIj5Q bGVhc2UgaGVscCBtZSBvdXQuIFRoZSBwcm90b2NvbCBpcyBpbXBsZW1lbnRlZCBhbGwgZmluZS4g SSBjaGVja2VkIHdpdGggdGhlIGVuY29kZXJzIHRvby4gVGhleSBhcmUgZmluZS4gVGhlcmUgY291 bGQgYmUgYSBzbWFsbCB0aGluZyBJJ20gbWlzc2luZy48L3NwYW4+PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87YmFja2dyb3VuZDp3aGl0ZSI+DQo8 c3BhbiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzIyMjIyMiI+Jm5ic3A7PC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO2JhY2tncm91 bmQ6d2hpdGUiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVv dDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMyMjIyMjIiPlRoYW5r cyw8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG87YmFja2dyb3VuZDp3aGl0ZSI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzIyMjIyMiI+Vmlub2RoPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+ DQo= --_000_F70A8AEBE518884ABEC998529DD9D15E0D5379SHSMSX101ccrcorpi_-- From tyoshino@google.com Wed Jun 27 22:07:32 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 E20E721F8535 for ; Wed, 27 Jun 2012 22:07:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.96 X-Spam-Level: X-Spam-Status: No, score=-102.96 tagged_above=-999 required=5 tests=[AWL=0.016, 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 3i7dCwPzhDtl for ; Wed, 27 Jun 2012 22:07:32 -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 C513B21F8528 for ; Wed, 27 Jun 2012 22:07:31 -0700 (PDT) Received: by yenq13 with SMTP id q13so1703382yen.31 for ; Wed, 27 Jun 2012 22:07:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=jT8Zw/NYs2TDeWXV0t8gTwSZcP5+HDDlQ6dC6CQEcks=; b=AZzEmwMtaabOa6gZsMSuVSq31SRGG1hP0jU9JZUNHxCxxDgYNR67qHKiqFxLaerlUI PdHUe0kzyDw/S2MnSNlKiNVRxuhJS9Hz+m+3iUXK3D7RQakDIu6Z+lkZRltjA6keIsM9 5u3WhfX2Eb2ubLUvqkWq9WMm8q0AsQQ0Pe2ymQ8izCNm7LP2iHoVm/aD+HO/zRU4lHgz oNQk4iqxpbQMb1Ry0AXMd7QyesL2PJxhHPtwAek4TpLoYuFx9M3hebk58d3gLfG4/WJJ viUXcjBr9TrcLmVPF7dg3S9TRYCkFXP4M8bleEpPNN0PAB5YOK072mS0S33Du01+kCOk aSJg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=jT8Zw/NYs2TDeWXV0t8gTwSZcP5+HDDlQ6dC6CQEcks=; b=BajGmkbfYmTXkcP++YS91SBpcocW63qJXOWgv17MvlkRGgrbZeoxS46OZs+7Zmu0ko SoGR31sO3SaspO647Xk0GpelBdYVvuydJYS84mO9KUNOxU2VXJF340XbP6OQaIomVoRk PnzUPEeyuM03qptblHbDjKruGvL6odkr6nVa7Y6lhkkMxNevzGudvcDdshKeOjSosdwK MKN3IudBCd+EMcgSwJTNDdn+TGj7ylRL6gvcuM1ePnfAmIubSV/83AP7RfKGvFlj6zWT UaX2NuDYLQ9PTErQopCF10+9yJQEMmJpoIEn/2atH1XVuLIHDPboJyyK0g6k+9LqI4o7 JkPQ== Received: by 10.50.100.137 with SMTP id ey9mr114307igb.61.1340860050634; Wed, 27 Jun 2012 22:07:30 -0700 (PDT) Received: by 10.50.100.137 with SMTP id ey9mr114300igb.61.1340860050467; Wed, 27 Jun 2012 22:07:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.66.7 with HTTP; Wed, 27 Jun 2012 22:07:08 -0700 (PDT) In-Reply-To: <005301cd545d$0a329030$1e97b090$@noemax.com> References: <001a01cd3e69$4a221c10$de665430$@noemax.com> <4FC732DC.3000308@250bpm.com> <000e01cd3f1c$af15ad40$0d4107c0$@noemax.com> <4FC880A7.9070007@250bpm.com> <001001cd4000$fe2c82c0$fa858840$@noemax.com> <4FCCAE6B.1010306@250bpm.com> <002d01cd4262$747957b0$5d6c0710$@noemax.com> <20120607022312.GA26406@jl-vm1.vm.bytemark.co.uk> <000e01cd449d$1c0ed220$542c7660$@noemax.com> <000401cd4566$d5f6bb70$81e43250$@noemax.com> <002f01cd5442$c0129370$4037ba50$@noemax.com> <005301cd545d$0a329030$1e97b090$@noemax.com> From: Takeshi Yoshino Date: Thu, 28 Jun 2012 14:07:08 +0900 Message-ID: To: Arman Djusupov Content-Type: multipart/alternative; boundary=e89a8f23532b0069bf04c3814f41 X-System-Of-Record: true X-Gm-Message-State: ALoCoQlBTbz7AuguST29BbpUv2rPlhC0MY2IIVgLNXeOlXwAVDp6tWOKBx7iYXMBzIEU97nz7MOSHDjnoonnM3kq6q1XK4zEHfwd9+lrvC/BXBKb9zl4Q4au9VP9aGJ5kaysYaw+qqiyqGKnGO8KaSXJEAAnaiha84Vuu5Px1tAI+zLsH6Ktf5M= Cc: hybi@ietf.org Subject: Re: [hybi] Flow control quota 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: Thu, 28 Jun 2012 05:07:33 -0000 --e89a8f23532b0069bf04c3814f41 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Wed, Jun 27, 2012 at 9:04 PM, Arman Djusupov wrote: > This encapsulation would allow a muxed message to be further fragmented b= y > an intermediary > Yes > and so resolves the per-frame compression issue when it is used after mux > since it would be able to sync on proper message boundaries.**** > > ** > I have no idea why you connected the sentences with "so", but yes. There would be no problem with applying per-frame compression after this new mux. But after the per-frame compression, fragmentation will be locked. > But it doesn=92t seem that the original frame boundaries can be recovere= d > after de-multiplexing as the frame is getting encapsulated after > re-fragmentation. So we completely abandon the idea to preserve the > original frames boundaries? (I don=92t mind, I just want to clarify). > Yes. As I stated here http://www.ietf.org/mail-archive/web/hybi/current/msg09720.html, I'm going to also change the compression algorithm to per-message one. Then, there would be no fragmentation lock for any combination. We can - add per-message flag to encapsulating message that indicates it has the final chunk of the encapsulated frame - change the quota mechanism from per-frame basis to per-byte basis to make the mux to keep frame boundary. But I prefer the former. --e89a8f23532b0069bf04c3814f41 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
On Wed, Jun 27, 2012 = at 9:04 PM, Arman Djusupov <arman@noemax.com> wrote:

This encapsulation would allow a muxed message to be furth= er fragmented by an intermediary

Yes=A0

and so resolves the per-frame compression issue when it is us= ed after mux since it would be able to sync on proper message boundaries.

I have no idea why you connected the sentences with "so",= but yes. There would be no problem with applying per-frame compression aft= er this new mux.

But after the per-frame compression, fragmentation will= be locked.

=A0But it doesn=92t= seem that the original frame boundaries can be recovered after de-multiple= xing as the frame is getting encapsulated after re-fragmentation. So we com= pletely abandon the idea to preserve the original frames boundaries? (I don= =92t mind, I just want to clarify).

Yes. As I stated here=A0http://www.ietf.org/mail-a= rchive/web/hybi/current/msg09720.html, I'm going to also change the= compression algorithm to per-message one. Then, there would be no fragment= ation lock for any combination.

We can
- add per-message flag to encaps= ulating message that indicates it has the final chunk of the encapsulated f= rame
- change the quota mechanism from per-frame basis to per-byt= e basis
to make the mux to keep frame boundary.

But I= prefer the former.
=A0
--e89a8f23532b0069bf04c3814f41-- From arman@noemax.com Thu Jun 28 01:33:57 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 D70F721F88FE for ; Thu, 28 Jun 2012 01:33:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.461 X-Spam-Level: X-Spam-Status: No, score=-2.461 tagged_above=-999 required=5 tests=[AWL=0.137, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 rW5USUMJGkp3 for ; Thu, 28 Jun 2012 01:33:56 -0700 (PDT) Received: from mail.noemax.com (mail.noemax.com [64.34.201.8]) by ietfa.amsl.com (Postfix) with ESMTP id 8C46C21F890D for ; Thu, 28 Jun 2012 01:33:56 -0700 (PDT) DKIM-Signature: a=rsa-sha1; t=1340872436; x=1341477236; s=m1024; d=noemax.com; c=relaxed/relaxed; v=1; bh=HmRlkYoD7W6eWYZxXEQuoGC/6Yo=; h=From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:In-Reply-To:References; b=ruOCumjz6p4xzeDhjtUyLPQIT9scBNwKRz+F7rRQsJlcx1BrcnRoSSEeKT3Wfihwhqr2PD9+GHm/z5Gzsf73SuXZTuaoij1mE3MTo0vqSXOEQFsjnRfrSc01L8X5SGWTilaOiP2lgwvFgEW0fPXnYqi0vbWNFevyoQXuX/7Z3ro= Received: from mail.noemax.com by mail.noemax.com (IceWarp 10.4.1) with ASMTP (SSL) id MOJ45355; Thu, 28 Jun 2012 11:33:55 +0300 From: "Arman Djusupov" To: "'Takeshi Yoshino'" References: <001a01cd3e69$4a221c10$de665430$@noemax.com> <4FC732DC.3000308@250bpm.com> <000e01cd3f1c$af15ad40$0d4107c0$@noemax.com> <4FC880A7.9070007@250bpm.com> <001001cd4000$fe2c82c0$fa858840$@noemax.com> <4FCCAE6B.1010306@250bpm.com> <002d01cd4262$747957b0$5d6c0710$@noemax.com> <20120607022312.GA26406@jl-vm1.vm.bytemark.co.uk> <000e01cd449d$1c0ed220$542c7660$@noemax.com> <000401cd4566$d5f6bb70$81e43250$@noemax.com> <002f01cd5442$c0129370$4037ba50$@noemax.com> <005301cd545d$0a329030$1e97b090$@noemax.com> In-Reply-To: Date: Thu, 28 Jun 2012 11:33:11 +0300 Message-ID: <009c01cd5508$ab95e840$02c1b8c0$@noemax.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_009D_01CD5521.D0E56A30" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQDnHEYxNcL9Xb2UVJoRm1lbL/BkAQFoH3KRAV1ppa8CZ6BgXAIpbgj4AsMo47wDBdtyYwH7TrBAAdzt12oB94xqWAGEGWmHAlGfbXgBsAbLXwLdWUHuAf+8S9ECjfJZgAGqAOJEAslzr0OXuTsEgA== Content-Language: en-us Cc: hybi@ietf.org Subject: Re: [hybi] Flow control quota 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: Thu, 28 Jun 2012 08:33:58 -0000 This is a multipart message in MIME format. ------=_NextPart_000_009D_01CD5521.D0E56A30 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit > I have no idea why you connected the sentences with "so", but yes. There would be no problem with applying per-frame compression after this new mux. Sorry, I was just rephrasing the text and forgot the "so" in that place. > Yes. As I stated here http://www.ietf.org/mail-archive/web/hybi/current/msg09720.html, I'm going to also change the compression algorithm to per-message one. Then, there would be no fragmentation lock for any combination. Agree. > We can > - add per-message flag to encapsulating message that indicates it has the final chunk of the encapsulated frame > - change the quota mechanism from per-frame basis to per-byte basis > to make the mux to keep frame boundary. What do you mean by "per-byte" basis? Current flow control quota is already expressed in bytes. With best regards, Arman ------=_NextPart_000_009D_01CD5521.D0E56A30 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

> I have no idea why you connected the = sentences with "so", but yes. There would be no problem with = applying per-frame compression after this new mux.

 

Sorry, I was just rephrasing the text and forgot the “so” = in that place.

 

> Yes. As I = stated here = http://www.ietf.org/mail-archive/web/hybi/current/msg09720.html, I'm = going to also change the compression algorithm to per-message one. Then, = there would be no fragmentation lock for any = combination.

 

Agree.

 

> We can

> - add = per-message flag to encapsulating message that indicates it has the = final chunk of the encapsulated frame

> - change the = quota mechanism from per-frame basis to per-byte basis

> to make the = mux to keep frame boundary.

 

What do you mean by = “per-byte” basis? = Current flow control quota is already expressed in = bytes.

 

With best regards,

Arman

 

------=_NextPart_000_009D_01CD5521.D0E56A30-- From tyoshino@google.com Thu Jun 28 03:09:52 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 652FB21F84C9 for ; Thu, 28 Jun 2012 03:09:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.963 X-Spam-Level: X-Spam-Status: No, score=-102.963 tagged_above=-999 required=5 tests=[AWL=0.013, 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 t2mBNpQBvd5O for ; Thu, 28 Jun 2012 03:09:46 -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 74C8421F89E4 for ; Thu, 28 Jun 2012 02:14:08 -0700 (PDT) Received: by yenq13 with SMTP id q13so1824821yen.31 for ; Thu, 28 Jun 2012 02:14:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=joBFxeJHZQdHNER+8ZxU4+quOOWJq4ceGeMfUiJ169E=; b=bIoNqVKLBf02lLsnSfGVMsRW8JxvqmnhYcadfZ3Lf1WXJMnkt/S5yXwW7r111oeo8W IOeCn/IbZEim6jiXIwKqCYgOSPxc/Y/zTsMDQIaXp0HaRkHO211bdEAzxE2BcGxJr9lI KYz3c72l2VDz1YLR6x8xNEvzL9nFIO2BsEmEGB71biNQG6D2n3gP0NV6G4Fq8AdJo9Y3 gXgh2iuyI6gaj9Qtk6kBSr3We+YyI+QKmR0EkjkQz2QRTZQv17kTMR3+ZwfUsfXrbXCb 1LRpkw62VN40ZItDhJCmQoja1FsFIR9AuD5twX0/6XkePll7wLIrRwg+j/ey5+q5v2oj rMZA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=joBFxeJHZQdHNER+8ZxU4+quOOWJq4ceGeMfUiJ169E=; b=d4laN/02B3uPOjzEARsffrr0/9t3apHSRN07mQeWlnrn306rMWftiws6P9rbBByMH9 wcBTzDVeL+4hvFl+YSKGvNgyavK7skHDYsELd9p93RIdhwvCWb+VmUlA1Fls3XwjZ854 67y10ukgCvOXYtWywxZYp9xBv3o9It2JEy+wtBXp/mw+VIAXcSU5m63oFLiSoObLrzZt WaiuTj5pa2b4Non73CHpEXdqCXYS4xxbcWqcDRjsgffhdjuWLUNktb//5ArcEnhz3Gl4 +EF04bMFPtqOfCx91lMBgbThu60+E5PBNvG84ttAwcGYbrqURT5Mpdki6iPN0fKBV5Bg cFXw== Received: by 10.50.156.194 with SMTP id wg2mr308040igb.46.1340874847847; Thu, 28 Jun 2012 02:14:07 -0700 (PDT) Received: by 10.50.156.194 with SMTP id wg2mr308031igb.46.1340874847718; Thu, 28 Jun 2012 02:14:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.66.7 with HTTP; Thu, 28 Jun 2012 02:13:46 -0700 (PDT) In-Reply-To: <009c01cd5508$ab95e840$02c1b8c0$@noemax.com> References: <001a01cd3e69$4a221c10$de665430$@noemax.com> <4FC732DC.3000308@250bpm.com> <000e01cd3f1c$af15ad40$0d4107c0$@noemax.com> <4FC880A7.9070007@250bpm.com> <001001cd4000$fe2c82c0$fa858840$@noemax.com> <4FCCAE6B.1010306@250bpm.com> <002d01cd4262$747957b0$5d6c0710$@noemax.com> <20120607022312.GA26406@jl-vm1.vm.bytemark.co.uk> <000e01cd449d$1c0ed220$542c7660$@noemax.com> <000401cd4566$d5f6bb70$81e43250$@noemax.com> <002f01cd5442$c0129370$4037ba50$@noemax.com> <005301cd545d$0a329030$1e97b090$@noemax.com> <009c01cd5508$ab95e840$02c1b8c0$@noemax.com> From: Takeshi Yoshino Date: Thu, 28 Jun 2012 18:13:46 +0900 Message-ID: To: Arman Djusupov Content-Type: multipart/alternative; boundary=e89a8f3bafd5fc8e6604c384c0b8 X-System-Of-Record: true X-Gm-Message-State: ALoCoQmiJslUg1/uDKCsskwMzExR28Jh5z7ODu3HwfGjkkfCyUHPPF4B98GCM1z679VGf/PwS5WZ/9kayYujq0IfQxRNWLPl4BF/bylsGNDZqCcv4je+dkFsEiW7K1QI92OHDbxJuskZhWeKyA3OTRE7hMI/q8tq4aDXLuYrnmFv/8ezD5CZwoc= Cc: hybi@ietf.org Subject: Re: [hybi] Flow control quota 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: Thu, 28 Jun 2012 10:09:53 -0000 --e89a8f3bafd5fc8e6604c384c0b8 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Thu, Jun 28, 2012 at 5:33 PM, Arman Djusupov wrote: > > We can > ** > > > - add per-message flag to encapsulating message that indicates it has > the final chunk of the encapsulated frame**** > > > - change the quota mechanism from per-frame basis to per-byte basis**** > > > to make the mux to keep frame boundary.**** > > ** ** > > What do you mean by =93per-byte=94 basis? Current flow control quota is > already expressed in bytes. > Sorry. Now the text for quota is saying like "when the size of the frame is XX, don't send the frame otherwise it's ok to send the frame". I meant that with this change, the quota mechanism tells go/no-go for each byte, not for each frame. --e89a8f3bafd5fc8e6604c384c0b8 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
On Thu, Jun 28, 2012 = at 5:33 PM, Arman Djusupov <arman@noemax.com> wrote:
<= p class=3D"MsoNormal">> We c= an

> - add per-message flag to encapsulating message that indi= cates it has the final chunk of the encapsulated frame

> - change t= he quota mechanism from per-frame basis to per-byte basis

=

> to make th= e mux to keep frame boundary.

=A0

What do you mean by =93per-byte=94=A0basis? Current flow control quota is already exp= ressed in bytes.


Sorry. Now the text for quota is say= ing like "when the size of the frame is XX, don't send the frame o= therwise it's ok to send the frame". I meant that with this change= , the quota mechanism tells go/no-go for each byte, not for each frame.

--e89a8f3bafd5fc8e6604c384c0b8--