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

["Eddy, Wesley M. (GRC-MS00)[Verizon]" <[e-mail]>]

Yes, even for RTP it's very naive to assume that buffering in the
HA is productive, and even for RTP it can be counterproductive.
If the end host player uses short buffers to bound delay in the
application interactivity, the data you buffer in the HA will
likely be below the playback pointer by the time it arrives, and
simply be discarded.  You'll also be wasting time and bandwidth
transmitting this stale data across a possibly constrained link
only to have to tossed away by the application.  There are
certainly thresholds where HA buffering could be useful to an
A/V codec, but the time limits are quite heavily dependent on
the specific application software and its local configuration
which vary widely in the wild.  The limited potential for good
results combined with the definite possibility of bad results,
and the inherent additional complexity make this a non-starter
in my mind.

---------------------------
Wes Eddy
Network & Systems Architect
Verizon FNS / NASA GRC
Office: [phone]
---------------------------

>-----Original Message-----
>From: Behcet Sarikaya [mailto:[e-mail]]
>Sent: Friday, June 19, 2009 11:05 AM
>To: Eddy, Wesley M. (GRC-MS00)[Verizon]
>Cc: [e-mail]
>Subject: Re: [MEXT] "buffer" action for flow binding
>
>
>Hi Eddy,
>  You are talking about pilc work (RFC 3366, etc.). Admittedly one can
>show it either way.
>  The point here is that not all flows are over TCP. In fact the example
>given was a video call which will probably be RTP flow. RTP does not
>control the transmission as much as TCP does. So buffering at a point
>like HA could be useful, this seems intuitively correct..
>  Do you have any objection to that?
>
>Regards,
>
>Behcet
>
>
>
>----- Original Message ----
>> From: "Eddy, Wesley M. (GRC-MS00)[Verizon]" <[e-mail]>
>> To: Behcet Sarikaya <[e-mail]>
>> Cc: "[e-mail]" <[e-mail]>
>> Sent: Thursday, June 18, 2009 8:00:52 PM
>> Subject: 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 [[e-mail]]
>> Sent: Thursday, June 18, 2009 6:42 PM
>> To: Eddy, Wesley M. (GRC-MS00)[Verizon]
>> Cc: [e-mail]
>> 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]"
>> > To: Julien Laganier ; "[e-mail]"
>>
>> > Cc: "[e-mail]"
>> > 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: [phone]
>> > ---------------------------
>> >
>> >
>> > >-----Original Message-----
>> > >From: [e-mail] [mailto:[e-mail]] On
>Behalf Of
>> > >Julien Laganier
>> > >Sent: Thursday, June 18, 2009 8:07 AM
>> > >To: [e-mail]
>> > >Cc: [e-mail]
>> > >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
>> > >    [e-mail]
>> > >    https://www.ietf.org/mailman/listinfo/mext
>> > >
>> > >
>> >
>> > _______________________________________________
>> > MEXT mailing list
>> > [e-mail]
>> > https://www.ietf.org/mailman/listinfo/mext
>
>
>
>