Re: [MEXT] "buffer" action for flow binding
Yungui Wang <w52006@huawei.com> Mon, 22 June 2009 02:03 UTC
Return-Path: <w52006@huawei.com>
X-Original-To: mext@core3.amsl.com
Delivered-To: mext@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 89D0928C189 for <mext@core3.amsl.com>; Sun, 21 Jun 2009 19:03:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.261
X-Spam-Level:
X-Spam-Status: No, score=-0.261 tagged_above=-999 required=5 tests=[AWL=0.234, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mAXahQIoLULy for <mext@core3.amsl.com>; Sun, 21 Jun 2009 19:03:12 -0700 (PDT)
Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 097B428C108 for <mext@ietf.org>; Sun, 21 Jun 2009 19:03:12 -0700 (PDT)
Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KLM00LNFB1G17@szxga04-in.huawei.com> for mext@ietf.org; Mon, 22 Jun 2009 10:03:16 +0800 (CST)
Received: from huawei.com ([172.24.1.33]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KLM00CKNB1GD6@szxga04-in.huawei.com> for mext@ietf.org; Mon, 22 Jun 2009 10:03:16 +0800 (CST)
Received: from w52006d ([10.164.12.17]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KLM0000OB1FKH@szxml06-in.huawei.com> for mext@ietf.org; Mon, 22 Jun 2009 10:03:16 +0800 (CST)
Date: Mon, 22 Jun 2009 10:03:15 +0800
From: Yungui Wang <w52006@huawei.com>
In-reply-to: <C304DB494AC0C04C87C6A6E2FF5603DB2217AB6573@NDJSSCC01.ndc.nasa.gov>
To: "'Eddy, Wesley M. (GRC-MS00)[Verizon]'" <wesley.m.eddy@nasa.gov>, 'Behcet Sarikaya' <sarikaya@ieee.org>, 'Yuri Ismailov' <yuri.ismailov@ericsson.com>
Message-id: <002f01c9f2dd$9b186050$110ca40a@china.huawei.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350
X-Mailer: Microsoft Office Outlook 11
Content-type: text/plain; charset="iso-8859-1"
Content-transfer-encoding: quoted-printable
Thread-index: Acnw70i8LOXaXYxpTP6WFfdMp1IkhQADWyIwAHaVOiA=
Cc: mext@ietf.org
Subject: Re: [MEXT] "buffer" action for flow binding
X-BeenThere: mext@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: w52006@huawei.com
List-Id: Mobile IPv6 EXTensions WG <mext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/mext>, <mailto:mext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mext>
List-Post: <mailto:mext@ietf.org>
List-Help: <mailto:mext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mext>, <mailto:mext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 22 Jun 2009 02:03:13 -0000
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: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On > Behalf Of Eddy, Wesley M. (GRC-MS00)[Verizon] > Sent: Saturday, June 20, 2009 12:57 AM > To: Behcet Sarikaya > Cc: mext@ietf.org > 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: (216) 433-6682 > --------------------------- > > >-----Original Message----- > >From: Behcet Sarikaya [mailto:behcetsarikaya@yahoo.com] > >Sent: Friday, June 19, 2009 11:05 AM > >To: Eddy, Wesley M. (GRC-MS00)[Verizon] > >Cc: mext@ietf.org > >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]" > <wesley.m.eddy@nasa.gov> > >> To: Behcet Sarikaya <sarikaya@ieee.org> > >> Cc: "mext@ietf.org" <mext@ietf.org> > >> 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 [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]" > >> > To: Julien Laganier ; "w52006@huawei.com" > >> > >> > Cc: "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 > > > > > > > > > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext >
- Re: [MEXT] Important considerations for direction… Hesham Soliman
- [MEXT] Important considerations for directionalit… Hesham Soliman
- Re: [MEXT] Important considerations for direction… Behcet Sarikaya
- Re: [MEXT] Important considerations for direction… Yuri Ismailov
- Re: [MEXT] Important considerations for direction… Behcet Sarikaya
- Re: [MEXT] Important considerations for direction… Yuri Ismailov
- Re: [MEXT] Important considerations for direction… Hesham Soliman
- Re: [MEXT] Important considerations for direction… Yungui Wang
- Re: [MEXT] Important considerations for direction… Hesham Soliman
- Re: [MEXT] Important considerations for direction… Yungui Wang
- Re: [MEXT] Important considerations for direction… Hesham Soliman
- Re: [MEXT] Important considerations for direction… Yungui Wang
- Re: [MEXT] Important considerations for direction… Hesham Soliman
- Re: [MEXT] Important considerations for direction… Julien Laganier
- Re: [MEXT] Important considerations for direction… pierrick.seite
- Re: [MEXT] "buffer" action for flow binding Julien Laganier
- Re: [MEXT] Important considerations for direction… Behcet Sarikaya
- Re: [MEXT] Important considerations for direction… Yuri Ismailov
- Re: [MEXT] Important considerations for direction… Nicolas Montavont
- Re: [MEXT] Important considerations for direction… George Tsirtsis
- Re: [MEXT] Important considerations for direction… Behcet Sarikaya
- Re: [MEXT] Important considerations for direction… George Tsirtsis
- Re: [MEXT] Important considerations for direction… Frank Xia
- Re: [MEXT] Important considerations for direction… Behcet Sarikaya
- Re: [MEXT] Important considerations for direction… Hesham Soliman
- Re: [MEXT] Important considerations for direction… Yuri Ismailov
- Re: [MEXT] Important considerations for direction… Hesham Soliman
- Re: [MEXT] Important considerations for direction… pierrick.seite
- Re: [MEXT] Important considerations for direction… Hesham Soliman
- Re: [MEXT] Important considerations for direction… Yuri Ismailov
- Re: [MEXT] Important considerations for direction… Yuri Ismailov
- Re: [MEXT] Important considerations for direction… Hesham Soliman
- Re: [MEXT] Important considerations for direction… George Tsirtsis
- Re: [MEXT] Important considerations for direction… Yuri Ismailov
- Re: [MEXT] Important considerations for direction… Yuri Ismailov
- Re: [MEXT] Important considerations for direction… Hesham Soliman
- Re: [MEXT] Important considerations for direction… George Tsirtsis
- Re: [MEXT] Important considerations for direction… Yuri Ismailov
- Re: [MEXT] Important considerations for direction… Yuri Ismailov
- Re: [MEXT] Important considerations for direction… Hesham Soliman
- Re: [MEXT] Important considerations for direction… Yuri Ismailov
- Re: [MEXT] Important considerations for direction… Hesham Soliman
- Re: [MEXT] Important considerations for direction… Yuri Ismailov
- Re: [MEXT] Important considerations for direction… Hesham Soliman
- Re: [MEXT] Important considerations for direction… Yuri Ismailov
- Re: [MEXT] Important considerations for direction… Behcet Sarikaya
- Re: [MEXT] Important considerations for direction… Hesham Soliman
- Re: [MEXT] Important considerations for direction… w52006
- Re: [MEXT] Important considerations for direction… Hesham Soliman
- Re: [MEXT] Important considerations for direction… pierrick.seite
- Re: [MEXT] Important considerations for direction… Yuri Ismailov
- Re: [MEXT] Important considerations for direction… Hesham Soliman
- Re: [MEXT] Important considerations for direction… Behcet Sarikaya
- Re: [MEXT] Important considerations for direction… Yuri Ismailov
- Re: [MEXT] Important considerations for direction… Hesham Soliman
- Re: [MEXT] Important considerations for direction… Julien Laganier
- Re: [MEXT] Important considerations for direction… Yuri Ismailov
- Re: [MEXT] Important considerations for direction… Yuri Ismailov
- Re: [MEXT] Important considerations for direction… Hesham Soliman
- Re: [MEXT] Important considerations for direction… Behcet Sarikaya
- Re: [MEXT] Important considerations for direction… Yuri Ismailov
- Re: [MEXT] Important considerations for direction… Yuri Ismailov
- Re: [MEXT] Important considerations for direction… Hesham Soliman
- Re: [MEXT] Important considerations for direction… Yuri Ismailov
- Re: [MEXT] Important considerations for direction… Hesham Soliman
- Re: [MEXT] Important considerations for direction… Yuri Ismailov
- Re: [MEXT] Important considerations for direction… Hesham Soliman
- Re: [MEXT] Important considerations for direction… Yuri Ismailov
- Re: [MEXT] Important considerations for direction… Hesham Soliman
- Re: [MEXT] Important considerations for direction… Yuri Ismailov
- Re: [MEXT] Important considerations for direction… Hesham Soliman
- Re: [MEXT] Important considerations for direction… Yuri Ismailov
- Re: [MEXT] Important considerations for direction… Hesham Soliman
- Re: [MEXT] Important considerations for direction… Yuri Ismailov
- Re: [MEXT] Important considerations for direction… Hesham Soliman
- Re: [MEXT] Important considerations for direction… Yuri Ismailov
- Re: [MEXT] Important considerations for direction… Hesham Soliman
- Re: [MEXT] Important considerations for direction… Yuri Ismailov
- Re: [MEXT] Important considerations for direction… Hesham Soliman
- Re: [MEXT] Important considerations for direction… Yuri Ismailov
- Re: [MEXT] Important considerations for direction… Hesham Soliman
- Re: [MEXT] Important considerations for direction… Yuri Ismailov
- Re: [MEXT] Important considerations for direction… Hesham Soliman
- Re: [MEXT] Important considerations for direction… Yuri Ismailov
- [MEXT] "buffer" action for flow binding Yungui Wang
- Re: [MEXT] "buffer" action for flow binding Hesham Soliman
- Re: [MEXT] "buffer" action for flow binding Yungui Wang
- Re: [MEXT] "buffer" action for flow binding Yuri Ismailov
- Re: [MEXT] "buffer" action for flow binding Behcet Sarikaya
- Re: [MEXT] "buffer" action for flow binding Eddy, Wesley M. (GRC-MS00)[Verizon]
- Re: [MEXT] "buffer" action for flow binding George Tsirtsis
- Re: [MEXT] "buffer" action for flow binding Behcet Sarikaya
- Re: [MEXT] "buffer" action for flow binding Eddy, Wesley M. (GRC-MS00)[Verizon]
- Re: [MEXT] "buffer" action for flow binding Hesham Soliman
- Re: [MEXT] "buffer" action for flow binding Behcet Sarikaya
- Re: [MEXT] "buffer" action for flow binding Eddy, Wesley M. (GRC-MS00)[Verizon]
- Re: [MEXT] "buffer" action for flow binding Yungui Wang
- Re: [MEXT] "buffer" action for flow binding Yuri Ismailov
- Re: [MEXT] "buffer" action for flow binding Yungui Wang
- Re: [MEXT] "buffer" action for flow binding Yuri Ismailov