Re: [rtcweb] #13: Transport of DATA_CHANNEL_OPEN

Bernard Aboba <bernard_aboba@hotmail.com> Wed, 24 April 2013 14:03 UTC

Return-Path: <bernard_aboba@hotmail.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B6A521F9305 for <rtcweb@ietfa.amsl.com>; Wed, 24 Apr 2013 07:03:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.507
X-Spam-Level:
X-Spam-Status: No, score=-102.507 tagged_above=-999 required=5 tests=[AWL=0.091, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 xbG1EKtaO9uj for <rtcweb@ietfa.amsl.com>; Wed, 24 Apr 2013 07:03:28 -0700 (PDT)
Received: from blu0-omc1-s31.blu0.hotmail.com (blu0-omc1-s31.blu0.hotmail.com [65.55.116.42]) by ietfa.amsl.com (Postfix) with ESMTP id B717221F92C5 for <rtcweb@ietf.org>; Wed, 24 Apr 2013 07:03:28 -0700 (PDT)
Received: from BLU169-W73 ([65.55.116.9]) by blu0-omc1-s31.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 24 Apr 2013 07:03:28 -0700
X-EIP: [v+Tf1JvP7Yze/hSafM8lhU8/VdlBfPll]
X-Originating-Email: [bernard_aboba@hotmail.com]
Message-ID: <BLU169-W7347A95F3FEFE5C7C9F86093B50@phx.gbl>
Content-Type: multipart/alternative; boundary="_3aabc3c5-82d2-40a5-bf31-11f1ed351705_"
From: Bernard Aboba <bernard_aboba@hotmail.com>
To: Michael Tuexen <michael.tuexen@lurchi.franken.de>
Date: Wed, 24 Apr 2013 07:03:28 -0700
Importance: Normal
In-Reply-To: <A012A773-415A-4C93-9D0C-D48590204A7C@lurchi.franken.de>
References: <066.3120a55540cacaa74ee5fda0b5273a48@trac.tools.ietf.org>, <516CE3EC.2050804@jesup.org>, <CABkgnnVaTOLa-hs7AtEgaTk7eq00bEkCY+_8L96Y8pooqybBxA@mail.gmail.com>, <CAJrXDUFgxLT3-1HehKbg5byzifFi4Obe3XW9G4sbWRbnU+Hi1A@mail.gmail.com>, <CABkgnnXr85LZyJiSF+ok2KMS_xQnS0CE4VBq4PvEhBBscn2QZQ@mail.gmail.com>, <516F1AF9.2080301@alvestrand.no>, <CABkgnnVtUjk4jSDVioxQnrt-b69Hx0nZLefs7tpEzETSmLXeNA@mail.gmail.com>, <516F9A5A.6080402@alvestrand.no>, <CABkgnnWrAMnm5fTWCNA1jqC_8Js0a6ewfSkvni4xg0E6rXdCtA@mail.gmail.com>, <5170247F.4090908@alvestrand.no>, <CABkgnnXU4HeJT-QwDcJ5NTvr72gZXxXi5zHFkQjJS__UXqzvtQ@mail.gmail.com>, <206CB075-6754-4578-B623-866E410DACCC@lurchi.franken.de>, <CABkgnnUCXUH+0a+F1LVQVrtL=Q65HGgsdT-oBBF++zSVR4OhWw@mail.gmail.com>, <5171734E.3050300@jesup.org>, <CABkgnnW0V7Sjx27Ff7CHANLqPifRLMDNatqD=VgPOB+d-iR+4A@mail.gmail.com>, <CAJrXDUGQyuKA_DxSOPfsWqCnkSRd=_Qzkir+r0-27oprCz6=sw@mail.gmail.com>, <CAJrXDUFpWHWN5AD7mP6G0y+gdeYc04WjK4ofLSgKG2MfZ16nvQ@mail.gmail.com> <BLU169, -W114DF9A01E2132B4B51167F93B50@phx.gbl>, <A012A773-415A-4C93-9D0C-D48590204A7C@lurchi.franken.de>
MIME-Version: 1.0
X-OriginalArrivalTime: 24 Apr 2013 14:03:28.0670 (UTC) FILETIME=[7EF7F3E0:01CE40F4]
Cc: Randell Jesup <randell-ietf@jesup.org>, "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] #13: Transport of DATA_CHANNEL_OPEN
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 24 Apr 2013 14:03:29 -0000

Michael said:
> I guess you are considering the case where the OPEN message was dropped by the network multiple times... [BA] Right.  That's the case in which the details of the OPEN transport makes a difference.
 
> The sender and receiver normally bound the memory for processing data (socket buffers). So
> your above only applies if the send buffer is larger than 9.6 MB.  [BA] The assumption is that the receiving application processes the incoming data, so that the RWIN does not decrease.  If the data is sent unordered and unreliable, and is acknowledged by SACK chunks (e.g. only the OPEN is lost), the sender can send this much data (assuming that it has that much to send).   > Often, the send and receiver buffer are the same and reflect the RWIN, so you are considering on the receiver side a 16 KB buffer, on the sender side a 10 MB buffer. [BA] No.  You can have 16 KB on both sides and the sender can end up sending this much, as long as the data isn't lost and the receiving application keeps processing it.  Because of that the RWIN does not limit the sender.