Re: [MEXT] "buffer" action for flow binding

In general, it's enough to say that transports are robust to the temporary network hiccups you throw at them, and this applies not only to TCP, but SCTP, DCCP and other protocols as well.  These all contain their own mechanisms for estimating path properties and responding to changes in the path.  Yes, there may be a small performance dip, but the connections will live on and recover.  Hopefully you aren't handing over too frequently anyways ... and measurement data shows that many/most TCP connections are quite short (only a few segments) since webpages are only a small number of kB in size, on average.  Sometimes the buffering under discussion may be helpful; we can certainly tailor experiments and simulations that show that ... we can also tailor simulations and experiments to show that it's dangerous and can cause performance degradation instead of improvement under many conditions.  IP is assumed to be a best-effort service; no need to make it needlessly clever.

Don't assume that the upper layers are so simple and fragile that they need great amounts of help in order to perform, or you break them.  There are many papers on how link-layer ARQ leading to high jitter and delay spikes injures end-to-end transport performance.  RFC 3366 describes the danger in assuming that high-persistence of the lower layers should be used in delivering TCP segments and RFC 3481 documents a set of TCP extensions and tuning parameters designed for robustness to links with handovers.

There has also been an I-D discussed in TCPM several years ago about TCP-based response to connectivity changes if they are visible to the transport and not masked/hidden by the network layer:
http://tools.ietf.org/html/draft-schuetz-tcpm-tcp-rlci-03
The references in that I-D to [SHUETZ] and [EDDY] can be found on the web and contain simulation results showing performance issues that occur when the network layer tries to hide path changes from the transport.

________________________________________
From: Behcet Sarikaya [behcetsarikaya@yahoo.com]
Sent: Thursday, June 18, 2009 6:42 PM
To: Eddy, Wesley M. (GRC-MS00)[Verizon]
Cc: mext@ietf.org
Subject: Re: [MEXT] "buffer" action for flow binding

Hi Eddy,
  Thank you for your advice.
However, I would like to know if you have any experimental data, research, published papers, material to back it up. Please let us know. I know that TCP behaviour in wireless links has been studied in depth but I for one am not aware of any work on TCP and MIPv6 type of things, especially in this context.

Regards,

Behcet

----- Original Message ----
> From: "Eddy, Wesley M. (GRC-MS00)[Verizon]" <wesley.m.eddy@nasa.gov>
> To: Julien Laganier <julien.laganier.ietf@googlemail.com>; "w52006@huawei.com" <w52006@huawei.com>
> Cc: "mext@ietf.org" <mext@ietf.org>
> Sent: Thursday, June 18, 2009 12:15:32 PM
> Subject: Re: [MEXT] "buffer" action for flow binding
>
> I wouldn't advise trying to do too much optimization on behalf
> of TCP.  It depends on the length of time to perform the
> handover, but longish handovers can run near the RTO and the
> data needing buffering during bulk-transfer is limited by the
> ACKs already in-flight before handover due to the data segments
> being clocked out by ACKs.  For shorter handovers, TCP can
> handle the loss detection and recovery efficiently through the
> fast retransmission/recovery and SACK procedures.  There is
> also an argument some have made that TCP should be re-
> initiating slow-start from its initial window after handovers
> due to the fact that the path has completely changed and the
> state established on the old path (cwnd, ssthresh, RTT, PMTU)
> may be invalid.
>
> Just a bit of caution and skepticism that buffering at the HA
> will work exactly as intended in all cases ... even in the
> best case, the buffering will cause an RTT spike.
>
> ---------------------------
> Wes Eddy
> Network & Systems Architect
> Verizon FNS / NASA GRC
> Office: (216) 433-6682
> ---------------------------
>
>
> >-----Original Message-----
> >From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On Behalf Of
> >Julien Laganier
> >Sent: Thursday, June 18, 2009 8:07 AM
> >To: w52006@huawei.com
> >Cc: mext@ietf.org
> >Subject: Re: [MEXT] "buffer" action for flow binding
> >
> >Another potential usecase for buffering would be as follows:
> >
> >MN is receiving and/or sending bulk data transfer over TCP. Prior to
> >handover it requests HA to buffer downlink packets. After Handover it
> >requests HA to resume transmission of packets. In that way no TCP
> >packets are lost because sent at the old MN CoA, and TCP transmission
> >rate is less impacted or not impacted at all by the handover.
> >
> >--julien
> >
> >
> >On Thu, Jun 18, 2009 at 4:59 AM, Yungui Wang wrote:
> >
> >
> >    Hello
> >
> >    There is a scenario for the HA service provider.
> >
> >    One MN is watching a real-time TV service from internet. For
> >    mobile IP service,
> >    a video flow is created on HA. At the time, a video call is
> >    incoming, the MN
> >    decides to response the call and pause the TV service.  Due to
> >    lack of
> >    bandwidth he can't receive and buffer it locally. He may then ask
> >    the HA
> >    buffering the TV flow un-interruptted. Thus, new action "Buffer"
> >    may be
> >    needed for flow binding.
> >
> >    4 Buffer.  This value indicates a request to buffer all packets
> >        in the flow described by the option.  No BIDs are associated
> >    with
> >        this Action.
> >
> >    Does it make sense?
> >
> >
> >    B.R.
> >    Yungui
> >
> >
> >    _______________________________________________
> >    MEXT mailing list
> >    MEXT@ietf.org
> >    https://www.ietf.org/mailman/listinfo/mext
> >
> >
>
> _______________________________________________
> MEXT mailing list
> MEXT@ietf.org
> https://www.ietf.org/mailman/listinfo/mext