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

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

Yungui,

I'm entirely with you regarding 'Discard' action. I would add on top of it other specified actions as well. I do not see how these actions relate to mobility management. As you pointed out they are flow related and in my view should be handled by applications.
Moreover, specifically 'Discard' action, is quite usual firewall function but not in any way mobility support function.

And just one more time, the firewall function may be physically placed in the HA. However, why would one change firewall rules using mobility management protocol? I do not have any answer on that.

I think that the origin of the problem is binary format (really sorry for bringing it up again), where one cannot specify semantics of what can be done with flows, just flow IDs. Thus, it is necessary to have a number of options for delivering of such semantics. But not to forget about the purpose of the semnatics it should be (according to the charter) mobility management related. Using rules language would make things much more easier, just because the semantics is the part of the language description and parsing the language would produce unambiguios, correct, synchronized on both ends binding cashes.

Take again 'Discard' as an example. Semantically, one may come up with quite strange operations, which are sintactically correct: Add new flow binding and 'Discard' the flow. To avoid such things, the logic of mutual exclusiveness of various actions and options has to be introduced.
Parsing the language, on the other hand would remove both semantical and syntactical errors in operations, before producing meaningfull binding caches.

Regards
Yuri


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

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
> > 
>