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

[Xiangsong Cui <[e-mail]>]

Hi Richard,

Thank you very much for your detailed explanation!

I found PILC, a concluded working group, ever studied on this area, and outputted many documents, but it seems that the RFCs are not 
used widely. maybe one reason is that the mechanism destroys the end-to-end principle of internet? I am wondering at this fact. 
Could you please tell me more information?

Another issue I am concerning is the buffer in the middle box. If there is a TCP proxy in the border and it splits the TCP 
connection into two parts, it has to buffer the TCP traffic? I am not sure about the influence.

Regards, Xiangsong

----- Original Message ----- 
From: "Scheffenegger, Richard" <[e-mail]>
To: "Xiangsong Cui" <[e-mail]>; <[e-mail]>
Sent: Wednesday, April 21, 2010 6:51 AM
Subject: RE: [tcpm] Discussion -- Pause/Resume mechanism on TCP ?



Hi,

I think it's well known (and well established), that middle-boxes which
intercept and "translate" TCP from wired to wireless give a big
performance boost; I've been involved in a PoC of such an architecture
for a cell provider some 10 years ago (when GPRS was in it's infancy).

Logically, the middlebox would terminate the tcp sessions from each end,
but appear transparent on the L3. Appropriate tunings to the tcp stack
depending on the type of connectivity were then made...

For the wired side, a zero window advertisement was used to throttle
incoming data when the wireless receiver were in a high BER area...

I would have thought, that such boxes are commercially available and
widely deployed these days. (Back then, it was an expirimental feature
of a Linux stack, I believe).

Besides, as others noted, some of the functionality described seems to
require some interaction between L4 and L1/L2; An application wishing to
do that, can already use zero window advertisements (indirectly, by not
fetching the data from the tcp receive buffer).

The only "enhancement" I see here is to now cut back cwnd - but without
an ack clock, you are asking for incast issues there...

Best regards

Richard Scheffenegger



> -----Original Message-----
> From: Xiangsong Cui [mailto:[e-mail]]
> Sent: Dienstag, 20. April 2010 11:32
> To: [e-mail]
> Subject: [tcpm] Discussion -- Pause/Resume mechanism on TCP ?
>
> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tcpm
>