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

Yoshifumi Nishida <nishida@sfc.wide.ad.jp> Tue, 20 April 2010 10:09 UTC

Return-Path: <nishida@sfc.wide.ad.jp>
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 7E75328C278 for <tcpm@core3.amsl.com>; Tue, 20 Apr 2010 03:09:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.854
X-Spam-Level: **
X-Spam-Status: No, score=2.854 tagged_above=-999 required=5 tests=[AWL=-0.650, BAYES_50=0.001, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RELAY_IS_203=0.994]
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 FnnpzlE46CNH for <tcpm@core3.amsl.com>; Tue, 20 Apr 2010 03:09:01 -0700 (PDT)
Received: from mail.sfc.wide.ad.jp (mail.sfc.wide.ad.jp [203.178.142.146]) by core3.amsl.com (Postfix) with ESMTP id 19B263A6B96 for <tcpm@ietf.org>; Tue, 20 Apr 2010 02:58:23 -0700 (PDT)
Received: from localhost (cpu.sfc.wide.ad.jp [IPv6:2001:200:0:8803:203:178:142:143]) by mail.sfc.wide.ad.jp (Postfix) with ESMTP id 228D64C615; Tue, 20 Apr 2010 18:58:13 +0900 (JST)
Date: Tue, 20 Apr 2010 18:58:13 +0900 (JST)
Message-Id: <20100420.185813.30897748.nishida@sfc.wide.ad.jp>
To: Xiangsong.Cui@huawei.com
From: Yoshifumi Nishida <nishida@sfc.wide.ad.jp>
In-Reply-To: <00d601cae06c$5a4324c0$96106f0a@china.huawei.com>
References: <00d601cae06c$5a4324c0$96106f0a@china.huawei.com>
X-Mailer: Mew version 6.2 on Emacs 22.1 / Mule 5.0 (SAKAKI)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Cc: tcpm@ietf.org
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 10:09:02 -0000

Hi, My first impression is it looks like TCP needs to interact with other 
layers to know when to pasue/resume, which might be a bit tricky..
Also, is thre any reason not to use zero window advertisement?

Thanks,
--
Yoshifumi Nishida
nishida@sfc.wide.ad.jp

From: Xiangsong Cui <Xiangsong.Cui@huawei.com>
Subject: [tcpm] Discussion -- Pause/Resume mechanism on TCP ?
Date: Tue, 20 Apr 2010 17:32:10 +0800
Message-ID: <00d601cae06c$5a4324c0$96106f0a@china.huawei.com>

 > 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