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