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

Lars Eggert <> Wed, 21 April 2010 10:00 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7C6DA28C0F7 for <>; Wed, 21 Apr 2010 03:00:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.307
X-Spam-Status: No, score=-5.307 tagged_above=-999 required=5 tests=[AWL=-1.122, BAYES_40=-0.185, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id bfUS33zLJZdE for <>; Wed, 21 Apr 2010 03:00:47 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 7E1B828C0F2 for <>; Wed, 21 Apr 2010 03:00:44 -0700 (PDT)
Received: from ( []) by (Switch-3.3.3/Switch-3.3.3) with ESMTP id o3LA048v026759; Wed, 21 Apr 2010 13:00:27 +0300
Received: from ([]) by with Microsoft SMTPSVC(6.0.3790.3959); Wed, 21 Apr 2010 13:00:24 +0300
Received: from ([]) by over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Wed, 21 Apr 2010 13:00:23 +0300
Received: from ( []) by (Switch-3.3.3/Switch-3.3.3) with ESMTP id o3LA0MWA012378 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 21 Apr 2010 13:00:22 +0300
X-Virus-Status: Clean
X-Virus-Scanned: clamav-milter 0.96 at
Mime-Version: 1.0 (Apple Message framework v1078)
Content-Type: multipart/signed; boundary="Apple-Mail-12--668444118"; protocol="application/pkcs7-signature"; micalg="sha1"
From: Lars Eggert <>
In-Reply-To: <01ac01cae12d$81d50640$>
Date: Wed, 21 Apr 2010 13:00:15 +0300
Message-Id: <>
References: <00d601cae06c$5a4324c0$> <> <01ac01cae12d$81d50640$>
To: Xiangsong Cui <>
X-Mailer: Apple Mail (2.1078)
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.3 ( []); Wed, 21 Apr 2010 13:00:15 +0300 (EEST)
X-OriginalArrivalTime: 21 Apr 2010 10:00:23.0766 (UTC) FILETIME=[75B4F760:01CAE139]
X-Nokia-AV: Clean
Cc: "" <>
Subject: Re: [tcpm] Discussion -- Pause/Resume mechanism on TCP ?
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 21 Apr 2010 10:00:48 -0000


On 2010-4-21, at 11:34, Xiangsong Cui wrote:
> 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...

you're correct in that there is no IETF recommendation in this space, although there is a large body of research work. In my view, the reason for this is mainly that none of the researchers have had the energy to seriously continue their work so that it could be published as an IETF recommendation. This is to some degree understandable, because the effort it takes may need to be spent on something that may not be academically publishable.

For example, whereas it is sufficient for a research paper to show that benefits exists in some scenarios, for an IETF recommendation, we need to be sure that a proposal has no drawbacks, or at the very least that they are well-understood and easy to work around (e.g., by not using a proposed extension in those cases).

Also, TCP is a general-purpose protocol. Optimizing its operation for a specific link technology implicitly assumes that that link technology will be used on the bottleneck link that mostly defines the path characteristics. That's a pretty strong assumption in general. Many folks have shown that TCP can be tuned in this way; not many have tried to determine whether there are drawbacks when a tuned TCP runs over a path where a different link technology is the bottleneck.

Even proposals that are agnostic to link technology have issues, e.g., Freeze TCP, which I cited since it sounded similar to your proposal. For example, there is an implicit assumption that path characteristics (available bandwidth, RTT, etc.) do not change during the freeze period - when they do, the thawed connection can significantly overshoot along the new path, or it can underperform (and will take a long time to probe for extra capacity if it is in congestion avoidance mode). And obviously, there is an assumption that you somehow know when to freeze and thaw. 

In a nutshell, I believe there is no IETF recommendation in this space, because designing one that is often useful and overall not harmful and has sufficient benefits to offset the needed effort is harder than it first appears.