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

Xiangsong Cui <Xiangsong.Cui@huawei.com> Wed, 21 April 2010 08:36 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 B24573A6822 for <tcpm@core3.amsl.com>; Wed, 21 Apr 2010 01:36:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.516
X-Spam-Level:
X-Spam-Status: No, score=-1.516 tagged_above=-999 required=5 tests=[AWL=1.082, BAYES_00=-2.599, 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 CkqHL3kGvx2e for <tcpm@core3.amsl.com>; Wed, 21 Apr 2010 01:36:49 -0700 (PDT)
Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 39D623A6405 for <tcpm@ietf.org>; Wed, 21 Apr 2010 01:36:45 -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 <0L1700CE9X5YSA@szxga04-in.huawei.com> for tcpm@ietf.org; Wed, 21 Apr 2010 16:34:47 +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 <0L1700BD8X5X62@szxga04-in.huawei.com> for tcpm@ietf.org; Wed, 21 Apr 2010 16:34:45 +0800 (CST)
Date: Wed, 21 Apr 2010 16:34:49 +0800
From: Xiangsong Cui <Xiangsong.Cui@huawei.com>
To: Lars Eggert <lars.eggert@nokia.com>
Message-id: <01ac01cae12d$81d50640$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
References: <00d601cae06c$5a4324c0$96106f0a@china.huawei.com> <05F0AC17-703E-4F25-8730-A88ACA4D8E6B@nokia.com>
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: Wed, 21 Apr 2010 08:36:51 -0000

Hi Lars,

Many thanks for your showing me the excellent paper!

As stated in the paper: "the main advantage is that when the sender enters persist mode, it freezes all packet retransmit timers and 
does not drop the congestion window so that the idle time during the slow-start phase can be avoided", I am also in this way.

Some details I am considering now are: who send the indication, middle-box or the receiver? when does host/middle-box send the 
indication? sometimes it is difficult to forecast the disconnection.

I also read some other papers about TCP over wireless link and I am a little confused. It seems that there are many researches and 
energy on this topic for more than ten years, but it is not clear until now which solution is recommended by IETF, or I missed the 
proposal? Since the TCP protocol is product of IETF, should IETF give some official suggestion on the applicability of TCP 
extensions? So the mobile hosts and middle-boxes may follow that...

Thanks and regards
Xiangsong

----- Original Message ----- 
From: "Lars Eggert" <lars.eggert@nokia.com>
To: "Xiangsong Cui" <Xiangsong.Cui@huawei.com>
Cc: <tcpm@ietf.org>
Sent: Tuesday, April 20, 2010 6:09 PM
Subject: Re: [tcpm] Discussion -- Pause/Resume mechanism on TCP ?


Hi,

are you aware of the following research paper?

@inproceedings{DBLP
:conf/infocom/GoffMPG00,
  author    = {Tom Goff and
               James Moronski and
               Dhananjay S. Phatak and
               Vipul Gupta},
  title     = {Freeze-TCP: A True End-to-End TCP Enhancement Mechanism
               for Mobile Environments},
  booktitle = {INFOCOM},
  year      = {2000},
  pages     = {1537-1545},
  ee        = {http://www.ieee-infocom.org/2000/papers/501.pdf},
  bibsource = {DBLP, http://dblp.uni-trier.de}

Lars

On 2010-4-20, at 12:32, Xiangsong Cui wrote:

> 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