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

Xiangsong Cui <Xiangsong.Cui@huawei.com> Tue, 20 April 2010 09:34 UTC

Return-Path: <Xiangsong.Cui@huawei.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 7FB7C3A693B for <tcpm@core3.amsl.com>; Tue, 20 Apr 2010 02:34:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.146
X-Spam-Level:
X-Spam-Status: No, score=-0.146 tagged_above=-999 required=5 tests=[AWL=-0.148, BAYES_50=0.001, STOX_REPLY_TYPE=0.001]
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 PaxgwDn8zwAq for <tcpm@core3.amsl.com>; Tue, 20 Apr 2010 02:34:43 -0700 (PDT)
Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 41B323A6900 for <tcpm@ietf.org>; Tue, 20 Apr 2010 02:34:42 -0700 (PDT)
Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L1600EKY55MB1@szxga04-in.huawei.com> for tcpm@ietf.org; Tue, 20 Apr 2010 17:32:10 +0800 (CST)
Received: from c00111037 ([10.111.16.150]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0L160011R55MJ7@szxga04-in.huawei.com> for tcpm@ietf.org; Tue, 20 Apr 2010 17:32:10 +0800 (CST)
Date: Tue, 20 Apr 2010 17:32:10 +0800
From: Xiangsong Cui <Xiangsong.Cui@huawei.com>
To: tcpm@ietf.org
Message-id: <00d601cae06c$5a4324c0$96106f0a@china.huawei.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350
X-Mailer: Microsoft Outlook Express 6.00.2900.3598
Content-type: text/plain; format="flowed"; charset="gb2312"; reply-type="original"
Content-transfer-encoding: 7bit
X-Priority: 3
X-MSMail-priority: Normal
Subject: [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 09:34:44 -0000

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