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

[Yungui Wang <[e-mail]>]

Hello

Well, why is the action 'Discard' allowed?
They both are affecting the flow self, not influencing CoA
selection indeed. 
If 'buffer' disallowed, nor 'Discard' does.
Thanks.

B.R.
Yungui

> -----Original Message-----
> From: Yuri Ismailov [mailto:[e-mail]] 
> Sent: Monday, June 22, 2009 4:49 PM
> To: [e-mail]; Eddy, Wesley M. (GRC-MS00)[Verizon]; 
> Behcet Sarikaya
> Cc: [e-mail]
> Subject: RE: [MEXT] "buffer" action for flow binding
> 
> 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
> > 
>