[alto] Review on draft-randriamasy-alto-cost-context-01 by Geng

"Li, Geng" <geng.li@yale.edu> Wed, 28 June 2017 05:02 UTC

Return-Path: <geng.li@yale.edu>
X-Original-To: alto@ietfa.amsl.com
Delivered-To: alto@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D37AE12009C; Tue, 27 Jun 2017 22:02:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=yale.edu
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 9xyCrjcMyAwA; Tue, 27 Jun 2017 22:02:20 -0700 (PDT)
Received: from mx0a-00135301.pphosted.com (mx0a-00135301.pphosted.com [67.231.145.237]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F83E1275C5; Tue, 27 Jun 2017 22:02:17 -0700 (PDT)
Received: from pps.filterd (m0109485.ppops.net [127.0.0.1]) by mx0b-00135301.pphosted.com (8.16.0.20/8.16.0.20) with SMTP id v5S4x0V9011544; Wed, 28 Jun 2017 01:02:15 -0400
Authentication-Results: ppops.net; spf=pass smtp.mailfrom=geng.li@yale.edu
Received: from nam03-by2-obe.outbound.protection.outlook.com (mail-by2nam03lp0052.outbound.protection.outlook.com [216.32.180.52]) by mx0b-00135301.pphosted.com with ESMTP id 2bbsqd1e17-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 28 Jun 2017 01:02:15 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yale.edu; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=B/cLGO1XQItJvFILtcpGCq2GS9z5RUJHkt8hxjXTd6c=; b=F4UKqR5wK78qAcf9UJhkX1r6HyIYOn1Kl9NKhkgMnj0anHx+ZVhcjjAwG2qv95XLaQyxnvm/gU/x/CVQNbYU4Pw4Esnd9lQ3zuGectN/AUmU7hyOouRjPcAVfH9TncYXb8LbhNw2o/SQKhs275jd7x+CKluHTBZx/N2UumG2jjc=
Received: from DM5PR08MB3531.namprd08.prod.outlook.com (10.164.154.153) by DM5PR08MB3532.namprd08.prod.outlook.com (10.164.154.154) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1199.15; Wed, 28 Jun 2017 05:02:13 +0000
Received: from DM5PR08MB3531.namprd08.prod.outlook.com ([10.164.154.153]) by DM5PR08MB3531.namprd08.prod.outlook.com ([10.164.154.153]) with mapi id 15.01.1199.019; Wed, 28 Jun 2017 05:02:13 +0000
From: "Li, Geng" <geng.li@yale.edu>
To: "alto@ietf.org" <alto@ietf.org>, "draft-randriamasy-alto-cost-context@ietf.org" <draft-randriamasy-alto-cost-context@ietf.org>
Thread-Topic: Review on draft-randriamasy-alto-cost-context-01 by Geng
Thread-Index: AQHS78u03Vx/E/AmE0+5Ta1bITuj2g==
Date: Wed, 28 Jun 2017 05:02:13 +0000
Message-ID: <DM5PR08MB3531C6687BF468CD9F16939F91DD0@DM5PR08MB3531.namprd08.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=yale.edu;
x-originating-ip: [130.132.173.199]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; DM5PR08MB3532; 7:PsgxGUSZBC+AqcvSbk5RfJ4JccWVOwl3/q3wAlkYMAMt99X2iOa+Z1gasIdAONWZoWJAdPVJrdzwEE1hVWzVfd3TfYJMu0DlDdRXKpguzsHajbdpT0XINYI3F03DxRbGMmtID3B9p7yIOdFrKYhWz3hzulrzZk16tTyHNGww7IpQirBPykJ5zYQs4+1l78+i5+4Seb0figdbPl/o+0P2VfuEr37osFkWOrBfSOlX30zyqdH2E1Psmnu9CILia/mT96zyz7B15YAyw8j5MaXHk5406qdBwxR2oWxnP6jQmk/Ql1STc1fM5M8xlpZ3HUS5GCkH3yUBiJuclFBqgtsh7EPuDldzs1Um+/qflZzEdQogO5sA9m8nbIFCVqGeDsPHYBPddp9kt/7dqhsAWzumTSgRUFaygJgE7jpNNPMGnVJci/KOlgXNxP8VdbvGaZwFoyY6V82E6VRkSKUna/HgkJ3U+UnzV75DEgCwmSqE+gpXzPT1X/eUgr++et5GJXMmor8yucdhcoPMsekhnYiqdC05TNIy96xdoZzu8VWq/IAiPDfrQ8hp5BUHS22X8h7D8nYqYvEyf7gG3kJIdLRcpS54aCb7LmeSZzNYvFI1mrC08G8omn3xFRZmTbOWfGw65TH9k7+YYEa7Pos4TNjYdNT12SzITMczc+SnyyHbbnfkcRrAfl7OM4Cu/dvqlT+uNwZedga9fx/JcuNKSRp60cb7MVOPUt8SH3O7nmtXuHRG3ENVBvYtYvLeQJw9IQfdoWqDbjZ4hDiT19/+7UQD3se/vqdLejZhUwEHmwX9T44=
x-ms-office365-filtering-correlation-id: 07230546-17eb-4c0c-325d-08d4bde2d740
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254075)(300000503095)(300135400095)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095); SRVR:DM5PR08MB3532;
x-ms-traffictypediagnostic: DM5PR08MB3532:
x-microsoft-antispam-prvs: <DM5PR08MB35320658890BC4071F8F00C391DD0@DM5PR08MB3532.namprd08.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(158342451672863)(133145235818549)(236129657087228)(48057245064654)(92977632026198)(158140799945019)(247924648384137);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(5005006)(8121501046)(100000703101)(100105400095)(10201501046)(93006095)(93001095)(3002001)(6041248)(201703131423075)(201702281529075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(20161123564025)(20161123555025)(20161123562025)(20161123560025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DM5PR08MB3532; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DM5PR08MB3532;
x-forefront-prvs: 03524FBD26
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39410400002)(39830400002)(39450400003)(39400400002)(8676002)(6606003)(81166006)(54356999)(5660300001)(189998001)(478600001)(7736002)(74316002)(3280700002)(3660700001)(230783001)(8936002)(88552002)(86362001)(2906002)(33656002)(413944005)(7696004)(6116002)(102836003)(54896002)(55016002)(6506006)(9686003)(99286003)(2501003)(450100002)(38730400002)(66066001)(6436002)(3846002)(25786009)(50986999)(77096006)(19627405001)(2900100001)(53936002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM5PR08MB3532; H:DM5PR08MB3531.namprd08.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en;
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_DM5PR08MB3531C6687BF468CD9F16939F91DD0DM5PR08MB3531namp_"
MIME-Version: 1.0
X-OriginatorOrg: yale.edu
X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Jun 2017 05:02:13.6712 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: dd8cbebb-2139-4df8-b411-4e3e87abeb5c
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR08MB3532
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-06-28_02:, , signatures=0
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1706280081
Archived-At: <https://mailarchive.ietf.org/arch/msg/alto/jUyt3dC-yPyLGJGyeR20P7oAhHc>
Subject: [alto] Review on draft-randriamasy-alto-cost-context-01 by Geng
X-BeenThere: alto@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Application-Layer Traffic Optimization \(alto\) WG mailing list" <alto.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/alto>, <mailto:alto-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/alto/>
List-Post: <mailto:alto@ietf.org>
List-Help: <mailto:alto-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/alto>, <mailto:alto-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 28 Jun 2017 05:02:23 -0000

Dear authors,


Your work is excellent, and here are some comments I have.

In the draft, to extend ALTO in cellular networks to support context based service is innovative and significant. In my view, Use Case 1 may face several challenges before being applied, but Use Case 2 makes a lot of sense for the future mobile network.

In Use Case 1, the challenges to bring ALTO into wireless world can be concluded as following.
1. The RF cost is hard to be measured for real-time services because only considering the load is not enough. The wireless channel consists of larger scale fading and small scale fading, where the small scale fading (also called frequency-selective fading) is caused by multi-path effects and Doppler effects. The transmission performance at different frequency points varies, which is why cellular networks adopt per-RB scheduling. To transmit the delay sensitive data, the decisions for selecting cells by using the cost map may be not effective.
2. With regard to the “unattended data” (UD), my understanding is that they are tailed for the “context-aware” transmission, which is an important topic for the next generation of mobile network to realize “user centric” network. It is good, but I doubt that the amount of UD may be not as much as you think. And the data is not mandatory and is delay tolerant, therefore using another cell to transmit seems to be not that necessary.
3. The overhead of signaling to apply ALTO seems to be considerable. Such data should belong to the control plane and transmitted by the RRC (Radio Resource Control) container. Only the RRC establishment and re-configuration will trigger this transmission, and the control plane signals are designed to be as short and reliable as possible. But considering the data size for network map request/response and the interval for updating, the overhead may be relatively high.

In Use Case 2, the access-aware endpoint selection is more reasonable. The transportation (backbone) network and the Core Network (CN) are more stable compared with the Radio Access Network (RAN), and they are more likely to be the bottleneck in today’s mobile network. For example, for WiFi and LTE, when the conditions in RAN are similar, then the QoE is largely dependent on the selection of accessed gateway to PDN, especially for some video stream downloading service. The only challenge lies here is the technique for “Multi-RAT” coordination, which is also a big direction in 5G.

Issues:
1. In the 1st paragraph of section 2.1, when describing LAOC can be associated to several cells, it is needed to state that the control plane of LAOC is anchored at the serving cells, and all the signals are transmitted with the serving cells.
2. In the 1st paragraph of section 2.1, one can easily think of the “Duel Connectivity”, which is supported in 3GPP and described as a UE can transmit data with two cells at the same time, specifically with a macro cell and a small cell. But in this draft, it seems to be multi-connectivity, that I don’t think 3GPP supports.
3. In the 2nd paragraph of section 2.2, the words “serving PGW” may confuse the audience by another entity SGW. SGW (Serving Gateway) is the gateway which terminates the interface towards E-UTARN. For each UE associated with the EPS, at given point of time, there is a single Serving GW. The PGW is the gateway which terminates the SGi interface towards PDN. If UE is accessing multiple PDNs, there may be more than one PGW for that UE. I assume the authors wanted to say PGW, but the words “serving PGW” may bring misunderstanding.
4. In section 2.2, a UE can dynamically choose Wifi or LTE for transmission according to the endpoint cost. One important element that the author need to announce is the handover, i.e., how to execute the handover and how to make sure the data is not dropped when doing handover.
5. In the example of Use Case 1, I’m curious about the data size for the cost map, say how many bits it will be roughly.
6. In the example of Use Case 2, I’m curious about how to calculate the cost value of WiFi and LTE. They are two RATs, and they all include both RAN and backbone networks.

*Suggestion:
The concept of cost map continues to be used. However, according to the map, the decision is made by the base station or ALTO server instead of the UE.
In the draft, the procedure can be described as:
UE-->base station (query for the map)
base station-->UE (return the map)
UE-->base station (make the association decision)
base station-->UE (resource allocation signal for scheduling in PDCCH/PUCCH)
UE<-->base station (transmit data, both uplink or downlink)
My suggestion is to move the decider from UE to base station, and the station (or ALTO server) just return the final association result, then they can start to transmit data. The procedure becomes:
UE-->base station (query for the map)
base station-->UE (make decision according to the map, then resource allocation signal for scheduling in PDCCH/PUCCH)
UE<-->base station (transmit data, both uplink or downlink)
In that case, there are two advantages. First, it can reduce the overhead and signal transmitting to realize ALTO; second, it can reduce the processing load of UE.

Hope these are helpful.

Best, Geng
Computer Science, Yale