[alto] review for draft-deng-alto-p2p-ext-07

Qiao Xiang <xiangq27@gmail.com> Tue, 08 March 2016 01:33 UTC

Return-Path: <xiangq27@gmail.com>
X-Original-To: alto@ietfc.amsl.com
Delivered-To: alto@ietfc.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 711B21CD7BF for <alto@ietfc.amsl.com>; Mon, 7 Mar 2016 17:33:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.449
X-Spam-Level:
X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfc.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.41]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mwtyq72_6rDw for <alto@ietfc.amsl.com>; Mon, 7 Mar 2016 17:33:24 -0800 (PST)
Received: from mail-io0-x230.google.com (mail-io0-x230.google.com [IPv6:2607:f8b0:4001:c06::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfc.amsl.com (Postfix) with ESMTPS id 49E781CD7A9 for <alto@ietf.org>; Mon, 7 Mar 2016 17:33:24 -0800 (PST)
Received: by mail-io0-x230.google.com with SMTP id g203so9017269iof.2 for <alto@ietf.org>; Mon, 07 Mar 2016 17:33:24 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=93maTWfHg7hiGIMQtpANszCQpYde06ShSH1HynH2P3M=; b=cE5+znlnKrykfYik8+dB1wb02Z1W1+LOTqQzycFPW4YvbJiXVFCFyEf8e55Ih6MymY BZu429eNnbe+m0tp8g2fikC+U3qvJf+iZmi/0RdzmD2vI6aGFlv7DhDm0ng+yh6rYeGm uJM7/w1Gm33e2wfQBbgM/N3uY6KRK2dErY9EAZeESuGoifxF5nGZF9eTqXJT75eodtVh i4R5U72S2xNP62cuJ5Ivr5eRrUyobgzYft7U8pqqlGx/ik8O+dioC+6RtN+mvM4sncqW jPxGbSj8rfuKNVr/b7fG5ABlXAIhDthiqWMS9EftbdEnSw2Oa3u0zroIGPsgomI0Tbox cu4Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=93maTWfHg7hiGIMQtpANszCQpYde06ShSH1HynH2P3M=; b=YnsuBWaGESflgv1GuebjgdzqR3bwqr0blZ0nmAO/JVSuSTuPdj+hDsZmvgow/YsKg5 pkhzqzC/9rVdzm089s3OviubndlgGWKmpJlI6s4XehPOhpv5BGVZfEcWb1WKWhS0Jl1D p80wcwIVdFcTwtS90c7E1PyrXfpz27agu5CtfIKMu0mhCyw2BcCvWtTpSCzi3Aa+tIgI tMTuxr7VLUGpnS/DAzzr7OkNZMSSq1dw4mVaMmtYN1htPv5bHfAITcXqRRvg+NghbHPk 7+4XI79MNdhmRJK0E193UDPfG6NrrTG3W/zBbhvQDxALWnH2D0uGa57TqSd2tLdkVhGk SSdg==
X-Gm-Message-State: AD7BkJLMdw7avEQKVan22S9xA87N7UmiPMDOiUszImALJF0n9kSA439v9TbYZOqGWWOKb98cos/93eEQU6No7A==
X-Received: by 10.107.12.207 with SMTP id 76mr4312967iom.70.1457400803609; Mon, 07 Mar 2016 17:33:23 -0800 (PST)
MIME-Version: 1.0
Received: by 10.79.79.83 with HTTP; Mon, 7 Mar 2016 17:33:04 -0800 (PST)
From: Qiao Xiang <xiangq27@gmail.com>
Date: Mon, 07 Mar 2016 20:33:04 -0500
Message-ID: <CAOB1xS_tPKbjR-7idQRLeQ0WU5DsidNPHS=78qi9ZcRFKzvwig@mail.gmail.com>
To: IETF ALTO <alto@ietf.org>
Content-Type: multipart/alternative; boundary="001a113eca0631d393052d7f91f0"
Archived-At: <http://mailarchive.ietf.org/arch/msg/alto/eONOUjn5i0yBArcKPM3WZZIvLGE>
Subject: [alto] review for draft-deng-alto-p2p-ext-07
X-BeenThere: alto@ietf.org
X-Mailman-Version: 2.1.17
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 Mar 2016 01:33:25 -0000

Hi All,

The following are my review for the draft-deng-alto-p2p-ext-07 drafts.

Sec 3, 3rd paragraph: "a end"->"an end"

Sec 3.1, the "Non-redundancy" guideline and the later-on "how to jutfity
non-redundancy" is not equivalent... I feel that the guideline is weaker
than the justification. I believe we should make them consistent/equivalent

Sec 3.3., 3rd paragraph: "the the"->"the"
Sec 4.1.1, the last paragraph, dc-location is a two-element object, not a
four-element object.
Sec 4.2.1, last sentence in paragraph 1: "it's"->it is.

Sec 4.2.2, I understand the need for differentiate electricity-supplied and
battery-supplied end point. In the meantime, I suggest we change the set
for content attribute to

"content": ["brown electricity", "renewable electricity", "batter"]

The reason is because nowadays more and more service providers are shifting
their workload to renewable-energy powered data centers, including Apple,
Google and etc. Compared with end points powered by brown energy, i.e.,
coal, the end points powered by renewable electricity may be more
economically efficient, and hence should be more preferable in supporting
more traffic.

Sec 4.4.1, regarding the "volume-limited" property, if we only use a
boolean value to indicate if an end point has such a limitation, how can
the server or the application decides how much traffic should be assigned
to this endpoint, 50MB, 500MB, 10GB or other values? Therefore we should
use a rank content for this property. Rank can be something like this:

1: 10-50MB, 2: 50-500MB, 3: 500-1000MB and etc.


Above is my current thought. I will review other drafts later. Thanks.


Best
Qiao













-- 
Qiao Xiang
Postdoctoral Fellow,
Department of Computer Science,
Yale University