[hybi] Flow control quota

"Arman Djusupov" <arman@noemax.com> Wed, 30 May 2012 13:37 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 1BD0D21F8736 for <hybi@ietfa.amsl.com>; Wed, 30 May 2012 06:37:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.148
X-Spam-Level:
X-Spam-Status: No, score=-1.148 tagged_above=-999 required=5 tests=[AWL=-1.150, BAYES_50=0.001, 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 5ReGjEG06zA5 for <hybi@ietfa.amsl.com>; Wed, 30 May 2012 06:37:02 -0700 (PDT)
Received: from mail.noemax.com (mail.noemax.com [64.34.201.8]) by ietfa.amsl.com (Postfix) with ESMTP id 719E921F8737 for <hybi@ietf.org>; Wed, 30 May 2012 06:37:02 -0700 (PDT)
DKIM-Signature: a=rsa-sha1; t=1338385021; x=1338989821; s=m1024; d=noemax.com; c=relaxed/relaxed; v=1; bh=1lwtlLVRxm1htJj6/cFiHrZQQrU=; h=From:Subject:Date:Message-ID:To:MIME-Version:Content-Type; b=mFI3pBY/SFIXgH6MnjLAEkQDndg3Crud7ebkl/phGP/aNt9An/dLKEfQ1tU6nIdYD/KUAJ1Ppe+L/k80BJ1BLUHNkmSITAtbOoVguHBNnGmwBZVn0mEfXvl4mvP66UsM+WT2rqZyXnZl8Yk7EAWwExh65vd+fT0E3kkPyWOyvKk=
Received: from mail.noemax.com by mail.noemax.com (IceWarp 10.4.0) with ASMTP (SSL) id OSP24900; Wed, 30 May 2012 16:37:00 +0300
From: Arman Djusupov <arman@noemax.com>
To: 'Takeshi Yoshino' <tyoshino@google.com>, hybi@ietf.org
Date: Wed, 30 May 2012 16:36:52 +0300
Message-ID: <001a01cd3e69$4a221c10$de665430$@noemax.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_001B_01CD3E82.6F703E70"
X-Mailer: Microsoft Outlook 14.0
thread-index: Ac0+aHlV710MsnfRTMiu0LvIyQHr3Q==
Content-Language: en-us
Subject: [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: Wed, 30 May 2012 13:37:04 -0000

Hello Takeshi,

 

Sometimes the sending side cannot fully utilize the remaining quota
available (a typical example is when the remaining quota is too small) and
has to wait for the receiving side to send a flow control frame (even though
the remaining quota is not yet equal to 0). If the receiving side’s mux
implementation sends flow control frames only when all the quota has been
fully consumed (remaining quota = 0), this can lead to a deadlock situation
in which the sending side waits for a FC frame before sending the next frame
while the receiving side waits for more bytes to be received before sending
a FC frame.

 

It would be good if the specification includes some general guidelines on
sending flow control quotas, e.g. “receiver MUST NOT wait for sending side
to use its full quota before sending a FC frame”. The specification could
even require that a FC frame is sent when half of the remaining quota is
used by the sending side. Otherwise one implementation may prefer to wait
for a FC frame when the frame size exceeds the remaining quota, while the
other may prefer to send a FC frame only when more than, say, ¾  of the
quota is used.

 

There are a variety of flow control strategies that can be used and each
implementation can have its own, what we need is to define some rules so
that all implementations are interoperable.

 

With best regards,

Arman