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

["Yuri Ismailov" <[e-mail]>]

Hi all,
I believe we should not mix too different things: (1) where to place functionality, and (2) which protocol to use to support this functionality.
Buffering, as a function may possibly placed in HA, but using of mobility protocol for triggering that function probably not the best choice.

/yuri


-----Original Message-----
From: Yungui Wang [mailto:[e-mail]] 
Sent: Monday, June 22, 2009 4:03 AM
To: 'Eddy, Wesley M. (GRC-MS00)[Verizon]'; 'Behcet Sarikaya'; Yuri Ismailov
Cc: [e-mail]
Subject: RE: [MEXT] "buffer" action for flow binding

Hello

Thanks for your clarification. 

My intent is an enhanced HA in which a ALG or backend server may be located as Yuri said could do more things. More conveniently, DPI-like technology (L3~L7) is more and more popular. I don't think it is very difficult to be done. Here, what we need is a simple request from MN. 
However, I am also not sure if the IP-layer request is appropriate.
But, as I know, there is a similar example that a server located in/side of a router (even side of AN) may buffer the multicast stream (a TV channel or the important frames of a channel) for fast channel switch in the fixed network. While, when a user sends a IP-layer request (IGMP) for a new channel, the router (/server) may firstly

push the buffered channel to the user, then do further works.

B.R.
Yungui

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf 
> Of Eddy, Wesley M. (GRC-MS00)[Verizon]
> Sent: Saturday, June 20, 2009 12:57 AM
> To: Behcet Sarikaya
> Cc: [e-mail]
> Subject: Re: [MEXT] "buffer" action for flow binding
> 
> 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
> >
> >
> >
> >
> 
> _______________________________________________
> MEXT mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mext
>