Re: [hybi] Flow control quota

"Arman Djusupov" <arman@noemax.com> Mon, 04 June 2012 15:54 UTC

Return-Path: <arman@noemax.com>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF01D21F88DA for <hybi@ietfa.amsl.com>; 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 <hybi@ietfa.amsl.com>; 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 <hybi@ietf.org>; 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 <arman@noemax.com>
To: 'Greg Wilkins' <gregw@intalio.com>
References: <001a01cd3e69$4a221c10$de665430$@noemax.com> <4FC732DC.3000308@250bpm.com> <000e01cd3f1c$af15ad40$0d4107c0$@noemax.com> <4FC880A7.9070007@250bpm.com> <CAH9hSJaWrUX6gFNLT4xkXLYKHSUH5+Y7AvqN9cD_CwekvsNu3A@mail.gmail.com> <001001cd4000$fe2c82c0$fa858840$@noemax.com> <CAH_y2NGFPHxBnSU-NmAFYLDxbt1LSaKtAoBFigC1vzvb=G3O0Q@mail.gmail.com>
In-Reply-To: <CAH_y2NGFPHxBnSU-NmAFYLDxbt1LSaKtAoBFigC1vzvb=G3O0Q@mail.gmail.com>
Date: Mon, 04 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 <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/hybi>, <mailto:hybi-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/hybi>
List-Post: <mailto:hybi@ietf.org>
List-Help: <mailto:hybi-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/hybi>, <mailto:hybi-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 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