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

[Xiangsong Cui <[e-mail]>]

Hi Lars,

Thanks for your detailed explanation!

I can understand this item better now.

Regards, Xiangsong

----- Original Message ----- 
From: "Lars Eggert" <[e-mail]>
To: "Xiangsong Cui" <[e-mail]>
Cc: <[e-mail]>
Sent: Wednesday, April 21, 2010 6:00 PM
Subject: Re: [tcpm] Discussion -- Pause/Resume mechanism on TCP ?


Hi,

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.

Lars