Re: [tcpm] Discussion -- Pause/Resume mechanism on TCP ?

"Scheffenegger, Richard" <rs@netapp.com> Tue, 20 April 2010 22:52 UTC

Return-Path: <rs@netapp.com>
X-Original-To: tcpm@core3.amsl.com
Delivered-To: tcpm@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 533643A680A for <tcpm@core3.amsl.com>; Tue, 20 Apr 2010 15:52:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.999
X-Spam-Level:
X-Spam-Status: No, score=-3.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VANQJQO4K6GW for <tcpm@core3.amsl.com>; Tue, 20 Apr 2010 15:52:08 -0700 (PDT)
Received: from mx3.netapp.com (mx3.netapp.com [217.70.210.9]) by core3.amsl.com (Postfix) with ESMTP id DD0B13A659A for <tcpm@ietf.org>; Tue, 20 Apr 2010 15:52:07 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.52,245,1270450800"; d="scan'208";a="142513321"
Received: from smtp3.europe.netapp.com ([10.64.2.67]) by mx3-out.netapp.com with ESMTP; 20 Apr 2010 15:51:57 -0700
Received: from amsrsexc1-prd.hq.netapp.com (amsrsexc1-prd.hq.netapp.com [10.64.251.107]) by smtp3.europe.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id o3KMpuUE027601; Tue, 20 Apr 2010 15:51:56 -0700 (PDT)
Received: from LDCMVEXC1-PRD.hq.netapp.com ([10.65.251.107]) by amsrsexc1-prd.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 21 Apr 2010 00:51:56 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Tue, 20 Apr 2010 23:51:54 +0100
Message-ID: <5FDC413D5FA246468C200652D63E627A0852A5BC@LDCMVEXC1-PRD.hq.netapp.com>
In-Reply-To: <00d601cae06c$5a4324c0$96106f0a@china.huawei.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [tcpm] Discussion -- Pause/Resume mechanism on TCP ?
Thread-Index: AcrgbLQpJva8vyjMSpCGXf8hOszK/QAbbWRg
References: <00d601cae06c$5a4324c0$96106f0a@china.huawei.com>
From: "Scheffenegger, Richard" <rs@netapp.com>
To: "Xiangsong Cui" <Xiangsong.Cui@huawei.com>, <tcpm@ietf.org>
X-OriginalArrivalTime: 20 Apr 2010 22:51:56.0296 (UTC) FILETIME=[13CAB880:01CAE0DC]
Subject: Re: [tcpm] Discussion -- Pause/Resume mechanism on TCP ?
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 20 Apr 2010 22:52:09 -0000

Hi,

I think it's well known (and well established), that middle-boxes which
intercept and "translate" TCP from wired to wireless give a big
performance boost; I've been involved in a PoC of such an architecture
for a cell provider some 10 years ago (when GPRS was in it's infancy).

Logically, the middlebox would terminate the tcp sessions from each end,
but appear transparent on the L3. Appropriate tunings to the tcp stack
depending on the type of connectivity were then made...

For the wired side, a zero window advertisement was used to throttle
incoming data when the wireless receiver were in a high BER area...

I would have thought, that such boxes are commercially available and
widely deployed these days. (Back then, it was an expirimental feature
of a Linux stack, I believe).

Besides, as others noted, some of the functionality described seems to
require some interaction between L4 and L1/L2; An application wishing to
do that, can already use zero window advertisements (indirectly, by not
fetching the data from the tcp receive buffer).

The only "enhancement" I see here is to now cut back cwnd - but without
an ack clock, you are asking for incast issues there...

Best regards

Richard Scheffenegger

 

> -----Original Message-----
> From: Xiangsong Cui [mailto:Xiangsong.Cui@huawei.com] 
> Sent: Dienstag, 20. April 2010 11:32
> To: tcpm@ietf.org
> Subject: [tcpm] Discussion -- Pause/Resume mechanism on TCP ?
> 
> Hi folks,
> 
> I'm thinking such a question, can we, or should we add a 
> pause/resume mechanism on TCP?
> 
> Current TCP senders understand all packet losses as 
> indications of congestion, but this is not always true, 
> especially in the scenarios where wireless link is part of 
> the network. Compared with wire link, wireless link is less 
> stable, with higher bit error rate and more disconnection. 
> And additionally, packet error and link disconnection can not 
> be indicated by current TCP protocol and extensions, do I 
> miss anything?
> 
> 
> So I think maybe pause/resume mechanism is helpful to this 
> situation. The outline of pause/resume mechanism is as follows:
> 
> * Pause/Resume indication may be transmitted by the receiver 
> or the middle-box. Like ECN on TCP, middle-box may also send 
> Pause/Resume indication. The use cases may be (a) wireless 
> host moves to a tunnel or a shadow where the radio coverage 
> is lost, and later returns to the radio coverage; (b) the 
> router in the TCP path detects the next hop is invalid (by 
> BFD or other mechanism), and later detects the re-connection 
> to the next hop; (c) the wireless host (i.e. the receiver) 
> doesn't want to accept too many traffic. 
> A scenario for this use case is a user watches TCP video by 
> wireless device, the user/device doesn't want buffer too many 
> video stream because maybe the user only watch a little begin 
> part of the video, but the unwanted video would waste 
> wireless bandwidth and user's money. So the device does 
> receiving-buffering-pausing-resuming, following the user's schedule.
> 
> * Pause/Resume indication is directional, that means the 
> receiver of Pause should stop transmit traffic packets but 
> the sender of Pause may transmit traffic packets, unless the 
> peer host also transmits a Pause indication.
> 
> * When the TCP sender receives the Pause indication, it 
> should keep the cwind value, stop transmitting traffic 
> packets, and if the retransmission timer is running, the 
> sender should also stop the timer. The TCP sender should 
> accept received incoming TCP packet (both traffic packet and 
> control packet) as normal, that means the sender can adjust 
> the receive window, mark the transmitted packets as 
> acknowledged, and so on.
> Another consideration is the Pause timer, the TCP sender 
> should start the pause timer when it receives the Pause indication.
> 
> * After the TCP receiver transmits the Pause indication, it 
> may accept the received traffic packets or discard the 
> packets, but the receiver should accept TCP control packets.
> 
> * When the TCP sender receives the Resume indication, it 
> should begin to transmit traffic packets (if there are) as 
> normal, if there are transmitted packet(s) in the queue, it 
> should also restart the retransmission timer...
> If the Pause timer is running, the TCP sender should kill the 
> timer as soon as it receives the Resume indication.
> 
> * If the TCP sender doesn't receive the Resume indication 
> before the Pause timer expires, it should close the TCP connection.
> 
> 
> The intention of Pause/Resume is to avoid the violent change 
> on the TCP congestion window, does this idea make sense?
> If it builds interest, I am going to write a draft, anybody 
> who like to co-work on this topic?
> 
> Thanks and best regards
> 
> Xiangsong 
> 
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm
>