[alto] Adopting draft-kiesel-alto-xdom-disc as WG item?

Wendy Roome <wendy.roome@nokia-bell-labs.com> Tue, 12 July 2016 18:56 UTC

Return-Path: <wendy.roome@nokia-bell-labs.com>
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 0857212D5BD for <alto@ietfa.amsl.com>; Tue, 12 Jul 2016 11:56:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.902
X-Spam-Level:
X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 r7JO5PN0D0lf for <alto@ietfa.amsl.com>; Tue, 12 Jul 2016 11:55:59 -0700 (PDT)
Received: from smtp-us.alcatel-lucent.com (us-hpatc-esg-01.alcatel-lucent.com [135.245.18.27]) (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 24A2112B04E for <alto@ietf.org>; Tue, 12 Jul 2016 11:55:59 -0700 (PDT)
Received: from us70tumx1.dmz.alcatel-lucent.com (unknown [135.245.18.13]) by Websense Email Security Gateway with ESMTPS id 6C9796D6B5506 for <alto@ietf.org>; Tue, 12 Jul 2016 18:55:54 +0000 (GMT)
Received: from us70tusmtp1.zam.alcatel-lucent.com (us70tusmtp1.zam.alcatel-lucent.com [135.5.2.63]) by us70tumx1.dmz.alcatel-lucent.com (GMO) with ESMTP id u6CItvsE010516 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for <alto@ietf.org>; Tue, 12 Jul 2016 18:55:58 GMT
Received: from umail.lucent.com (umail.ndc.lucent.com [135.3.40.61]) by us70tusmtp1.zam.alcatel-lucent.com (GMO) with ESMTP id u6CItuYG002703 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <alto@ietf.org>; Tue, 12 Jul 2016 18:55:57 GMT
Received: from [135.222.152.71] (wdr-i7mbp2.mh.lucent.com [135.222.152.71]) by umail.lucent.com (8.13.8/TPES) with ESMTP id u6CItsAP025531 for <alto@ietf.org>; Tue, 12 Jul 2016 13:55:55 -0500 (CDT)
User-Agent: Microsoft-MacOutlook/14.6.5.160527
Date: Tue, 12 Jul 2016 14:55:52 -0400
From: Wendy Roome <wendy.roome@nokia-bell-labs.com>
To: IETF ALTO <alto@ietf.org>
Message-ID: <D3AAB578.7DF072%w.roome@alcatel-lucent.com>
Thread-Topic: Adopting draft-kiesel-alto-xdom-disc as WG item?
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/alto/o28sh-kwn-EIBbYODf9-VUXXkC4>
Subject: [alto] Adopting draft-kiesel-alto-xdom-disc as WG item?
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, 12 Jul 2016 18:56:01 -0000

My comments on draft-kiesel-alto-xdom-disc-02:

Section 1:

You might mention that yet another problem with the 1.? solutions is that
the values of ALTO cost metrics are not standardized. For example, there
is no standard definition of what "routingcost 10" means. Hence cost
metric values are not comparable between ALTO servers.

This is also a problem for 2.1, because the client cannot tell if the
returned costs are from the server it contacted directly, or from some
other server. 

Section 3.2:

If a client wants the cost from X => Y, why just do cross-domain discovery
on address X? Why not do it for Y instead? Or do it for both X & Y?

Section 3.3:

This also has the problem that cost metric values are not standardized,
which will make it very difficult to merge costs from multiple ALTO
servers into a single cost map.

Also, I think you mean "NxN cost map" rather than "NxN network map".

Section 4.2.1:

"or redirect the client to another ALTO server using mechanisms of the
ALTO protocol (see Sect. 9 of [RFC7285])."

Does that refer to a root IRD referencing a secondary IRD, as described in
Section 9.2.4? If so, I don't think of a secondary IRD as representing a
different ALTO server. Rather, I regard secondary IRDs as distributing the
resources of one ALTO server over several physical processors. I assumed
that the set of resources from the root IRD and secondary IRDs were
managed by the same entity, and used the same cost metric definitions, so
that cost metric values obtained from any of those resources could be
safely compared with each other.

	- Wendy Roome