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

Hi Yoshifumi,

Thank you for your response!
One reason is that zero window advertisement can not stop the sender's RTX timer, in my understand, the zero window advertisement 
can only tell the sender not to send new traffic, but the sender will still keep the timer running, and when the timer expires, the 
cwind is reduced, and some packets are retransmitted unnecessary. When the receiver advertises the new receive window, maybe the 
sender has entered the slow start procedure, is that right?

Regards, Xiangsong

----- Original Message ----- 
From: "Yoshifumi Nishida" <nishida@sfc.wide.ad.jp>
To: <Xiangsong.Cui@huawei.com>
Cc: <tcpm@ietf.org>
Sent: Tuesday, April 20, 2010 5:58 PM
Subject: Re: [tcpm] Discussion -- Pause/Resume mechanism on TCP ?

>
> 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 