Re: [alto] Comments on draft-deng-alto-p2p-ext
Lingli Deng <lingli.deng@outlook.com> Tue, 08 September 2015 07:12 UTC
Return-Path: <lingli.deng@outlook.com>
X-Original-To: alto@ietfa.amsl.com
Delivered-To: alto@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD09E1ACD42 for <alto@ietfa.amsl.com>; Tue, 8 Sep 2015 00:12:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.7
X-Spam-Level:
X-Spam-Status: No, score=-0.7 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 v0-s0VDICO7F for <alto@ietfa.amsl.com>; Tue, 8 Sep 2015 00:11:58 -0700 (PDT)
Received: from BAY004-OMC1S25.hotmail.com (bay004-omc1s25.hotmail.com [65.54.190.36]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4760B1A90DC for <alto@ietf.org>; Tue, 8 Sep 2015 00:11:58 -0700 (PDT)
Received: from BAY167-W60 ([65.54.190.61]) by BAY004-OMC1S25.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.23008); Tue, 8 Sep 2015 00:11:57 -0700
X-TMN: [AGaGij0HK22svoMn/DhtGIpEbF1E/4L3iuY02EwQbQ4=]
X-Originating-Email: [lingli.deng@outlook.com]
Message-ID: <BAY167-W60AB04E0A352C31A9BF873F3530@phx.gbl>
Content-Type: multipart/alternative; boundary="_883c2b70-5eed-445a-a5dd-19658f9bb280_"
From: Lingli Deng <lingli.deng@outlook.com>
To: Gao Kai <gaok12@mails.tsinghua.edu.cn>, IETF ALTO <alto@ietf.org>
Date: Tue, 08 Sep 2015 07:11:57 +0000
Importance: Normal
In-Reply-To: <55ACEEC2.6040702@mails.tsinghua.edu.cn>
References: <55ACEEC2.6040702@mails.tsinghua.edu.cn>
MIME-Version: 1.0
X-OriginalArrivalTime: 08 Sep 2015 07:11:57.0830 (UTC) FILETIME=[A63A0260:01D0EA05]
Archived-At: <http://mailarchive.ietf.org/arch/msg/alto/n9krGB_ya1Da2-Ogmh-PctRASNE>
Subject: Re: [alto] Comments on draft-deng-alto-p2p-ext
X-BeenThere: alto@ietf.org
X-Mailman-Version: 2.1.15
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: Tue, 08 Sep 2015 07:12:01 -0000
Hi Kai, Thanks a lot for your review and comments. See my reply inline below. Regards, Lingli Date: Mon, 20 Jul 2015 20:51:14 +0800 From: gaok12@mails.tsinghua.edu.cn To: alto@ietf.org Subject: [alto] Comments on draft-deng-alto-p2p-ext Hi all, I found all these new endpoint properties very useful and I can't help notice many are specialized for mobile and data center scenarios. However I still have doubts on some issues and here are some comments: 1. I understand that the "precision" field is introduced to indicate the type of the content. However, in 5 cases out of 8 the field is left empty, in other 2 the only difference is between an exact value and the ranking. In the last case, "geolocation", the "precision" field can be chosen from four different values, but according to my understanding, an endpoint can have a geolocation for each one of them. What if the ALTO server wants to provide all kinds of them? Since they all share the property name "geolocation", it can lead to conflicts when the data are encapsulated in a JSON object. So instead of using "precision", I think it is better to provide 4 different geolocation properties. The same idea can apply to "network_access" and "provisioned_bandwidth": use "-rank" suffix in the name to indicate the value is a ranking. At the same time, introducing "geolocation-type"/"network-access-type"/"provisioned-bandwidth-type" to indicate what "precision"s are supported looks like a good idea to me.[dll] Sounds reasonable. 2. The names are using underscores instead of hyphens. However I think it is better to keep it compatible with RFC 7285 in which property names use hyphens to concatenate words.[dll] OK. We can work on that. 3. Why not use strings to represent the bandwidth? Such as "1 Gbps". It's more compact. I'd also like to know if there are some other considerations why the metric and value are separated.[dll] Simple strings could work to convey the information, but it could be helpful keeping them separate when the server is doing filtering based on the value of a given metric per client's request or ISP's policy. Does it make sense to you? ================== Regards, Kai _______________________________________________ alto mailing list alto@ietf.org https://www.ietf.org/mailman/listinfo/alto