Re: [DMM] draft-deng-mptcp-mobile-network-proxy-00
"Xiongchunshan (Sam)" <sam.xiongchunshan@huawei.com> Fri, 21 February 2014 09:03 UTC
Return-Path: <sam.xiongchunshan@huawei.com>
X-Original-To: dmm@ietfa.amsl.com
Delivered-To: dmm@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBCB21A000E for <dmm@ietfa.amsl.com>; Fri, 21 Feb 2014 01:03:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.748
X-Spam-Level:
X-Spam-Status: No, score=-4.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tXT45ptP0tok for <dmm@ietfa.amsl.com>; Fri, 21 Feb 2014 01:03:48 -0800 (PST)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id A05D31A004A for <dmm@ietf.org>; Fri, 21 Feb 2014 01:03:47 -0800 (PST)
Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BDU84566; Fri, 21 Feb 2014 09:03:43 +0000 (GMT)
Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 21 Feb 2014 09:03:06 +0000
Received: from nkgeml409-hub.china.huawei.com (10.98.56.40) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 21 Feb 2014 09:03:22 +0000
Received: from NKGEML507-MBS.china.huawei.com ([169.254.6.75]) by nkgeml409-hub.china.huawei.com ([10.98.56.40]) with mapi id 14.03.0158.001; Fri, 21 Feb 2014 17:03:17 +0800
From: "Xiongchunshan (Sam)" <sam.xiongchunshan@huawei.com>
To: "dmm@ietf.org" <dmm@ietf.org>, "pierrick.seite@orange.com" <pierrick.seite@orange.com>, Jouni Korhonen <jouni.nospam@gmail.com>
Thread-Topic: [DMM]draft-deng-mptcp-mobile-network-proxy-00
Thread-Index: AQHPLuPCRFzSCYYp4UuUV8TQvveq5A==
Date: Fri, 21 Feb 2014 09:03:17 +0000
Message-ID: <6B53974F43BA3C40A96CA7FDE0C9BBD0410FEF02@nkgeml507-mbs.china.huawei.com>
References: <6B53974F43BA3C40A96CA7FDE0C9BBD0410FEE49@nkgeml507-mbs.china.huawei.com> <25866_1392972844_5307142C_25866_5790_1_81C77F07008CA24F9783A98CFD706F71141F9C1E@PEXCVZYM12.corporate.adroot.infra.ftgroup>
In-Reply-To: <25866_1392972844_5307142C_25866_5790_1_81C77F07008CA24F9783A98CFD706F71141F9C1E@PEXCVZYM12.corporate.adroot.infra.ftgroup>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.111.64.75]
Content-Type: multipart/alternative; boundary="_000_6B53974F43BA3C40A96CA7FDE0C9BBD0410FEF02nkgeml507mbschi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/uJcLZlO12cper3l-A9vId_NvQU8
Subject: Re: [DMM] draft-deng-mptcp-mobile-network-proxy-00
X-BeenThere: dmm@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Distributed Mobility Management Working Group <dmm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dmm>, <mailto:dmm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dmm/>
List-Post: <mailto:dmm@ietf.org>
List-Help: <mailto:dmm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dmm>, <mailto:dmm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 21 Feb 2014 09:03:52 -0000
Hello Pierrick , Jouni, The comments are for the ID: draft-deng-mptcp-mobile-network-proxy-00.txt Thanks for the reminding and I change the title of the email. BRs Chunshan Xiong 熊春山 From: pierrick.seite@orange.com [mailto:pierrick.seite@orange.com] Sent: Friday, February 21, 2014 4:54 PM To: Xiongchunshan (Sam); dmm@ietf.org Subject: RE: [DMM] MPTCP Proxy for Mobile Networks Which document are you referring ? De : dmm [mailto:dmm-bounces@ietf.org] De la part de Xiongchunshan (Sam) Envoyé : vendredi 21 février 2014 08:19 À : dmm@ietf.org<mailto:dmm@ietf.org> Objet : [DMM] MPTCP Proxy for Mobile Networks Hello folks, Here I have some comments on this document: 1) 5.2 Traffic mediation (a) Anchoring of sub-flow traffic: On one hand, it is not always possible for a single GW be sitting on the path of every sub-flow from a MPTCP session, hence explicit traffic anchoring to enable a single point of general control over MPTCP sub-flows should be considered. (b) Mediation of sub-flow traffic: On the other hand, for fine- grained mediation of sub-flow traffic, both static and dynamic selection/offloading/pooling policies should be allowed. For instance, "always prefer Wi-Fi over 3GPP" could be a static policy for bulk data transfer services, while "use 3GPP only for backup unless Wi-Fi is congested" could be a dynamic offloading policy for a un-prioritized VoIP service. [xcs]Question for clarification: How does the MPTCP proxy know the binding information between the IP and RAT ? The mobile node knows which IP is allocated from which RAT, but it is very hard for the MPTCP Proxy in the core network to know these mapping information. One possible solution is the PCRF (defined in the 3GPP) to provide these binding information to the MPTCP proxy if the MPTCP proxy performance the traffic mediation or let the mobile to do the traffic mediation. Another question is how the rules (e.g. "always prefer Wi-Fi over 3GPP") are provided to the MPTCP Proxy or the mobile ? For the MPTCP proxy, it is again the PCRF; for the mobile , it is the ANDSF ? 2) 4.2 Resource pooling for reduced expense Due to its low construction and operation expenses, Wi-Fi has been adopted by mobile operators as a complementary RAT for their traditional 3GPP networks. However, different construction and operation expenses of various radio networks result in differences in charging rates/policies for different RATs. For instance, Wi-Fi access may be charged by the access duration, while the 3GPP access may be charged by the consumed data volume. Even if using the same policy, Wi-Fi service is expected to be much cheaper than 3GPP data service. Moreover, different subscription packages may offer various data plans for various RATs. For instance, a basic 4G package may contain free data volume as well free Wi-Fi access too. By enabling MPTCP session between UE and network proxy, via mediating sub-flow data traffic based on their Radio access types and the user’s subscription package, it is possible to further reduce the usage expenses from both sides of the network and user. [xcs] it will benefit the user if the user’s expense of data usage is reduced, if the WiFi connection is available and charging fee is very low, maybe all the traffic from the 4G are moved to the WiFi by the MPTCP proxy, and the mobility and QoS of the service maybe aren’t ensured, so it is proposed to adding the following sentence to the end of this chapter: The QoS/QoE/Service continuity of the current data services are still kept when the MPTCP proxy is used to reduce the user’s usage expenses. A assumption for reducing user expense is that the WiFi connection is activated beforehand, but sometimes the WiFi connection isn’t activated or a wrong WiFi AP is selected by the user( that MPTCP Proxy can’t access the WiFi IP flow), that is, one hand, the network need to control the MPTCP Proxy to mediate the IP flows, another hand, the network should tell the mobile to open which RAT/WiFi to make the MPTCP Proxy work. i.e. the network should provide some information to the UE , to guide the UE to select and open another RAT to enable the MPTCP. 3) 4.1 Dynamic traffic offloading based on network information For real-time interactive services with higher QoS requirements it is expected that 3GPP network can provide better guarantees on the average case. For bulk data transfer who is satisfied with best- effort delivery, Wi-Fi would be a great choice. But the vertical partition does not fit everywhere for the wireless condition itself is quite dynamic and hard to predict. It is important to implement adaptive offloading mechanisms in order to achieve higher resource utility with ever changing radio environment for a possibly moving terminal based on network status, e.g. cell load, AP’s signal intensity, user’s subscription type, etc. [xcs]The same question from 1): How does the MPTCP Proxy/UE know the network status ? The PCRF/ANDSF provides these information to the MPTCP Proxy/UE ? BRs Chunshan Xiong Huawei Technologies Co., Ltd. _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you.
- [DMM] MPTCP Proxy for Mobile Networks Xiongchunshan (Sam)
- Re: [DMM] MPTCP Proxy for Mobile Networks Jouni Korhonen
- Re: [DMM] MPTCP Proxy for Mobile Networks pierrick.seite
- Re: [DMM] draft-deng-mptcp-mobile-network-proxy-00 Xiongchunshan (Sam)
- Re: [DMM] MPTCP Proxy for Mobile Networks Hidetoshi Yokota
- Re: [DMM] MPTCP Proxy for Mobile Networks Xiongchunshan (Sam)