[alto] draft-marocco-alto-next-00

David Harrington <ietfdbh@comcast.net> Thu, 23 February 2012 16:09 UTC

Return-Path: <ietfdbh@comcast.net>
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 F38EC21F876A for <alto@ietfa.amsl.com>; Thu, 23 Feb 2012 08:09:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.806
X-Spam-Level:
X-Spam-Status: No, score=-100.806 tagged_above=-999 required=5 tests=[AWL=-1.093, BAYES_05=-1.11, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s2ukOsDBa7Z6 for <alto@ietfa.amsl.com>; Thu, 23 Feb 2012 08:09:50 -0800 (PST)
Received: from qmta10.westchester.pa.mail.comcast.net (qmta10.westchester.pa.mail.comcast.net [76.96.62.17]) by ietfa.amsl.com (Postfix) with ESMTP id EC8F121F8740 for <alto@ietf.org>; Thu, 23 Feb 2012 08:09:49 -0800 (PST)
Received: from omta21.westchester.pa.mail.comcast.net ([76.96.62.72]) by qmta10.westchester.pa.mail.comcast.net with comcast id dT911i0041ZXKqc5AU9qZg; Thu, 23 Feb 2012 16:09:50 +0000
Received: from [192.168.1.33] ([71.233.85.150]) by omta21.westchester.pa.mail.comcast.net with comcast id dU9j1i00F3Ecudz3hU9ofv; Thu, 23 Feb 2012 16:09:50 +0000
User-Agent: Microsoft-MacOutlook/14.14.0.111121
Date: Thu, 23 Feb 2012 11:09:40 -0500
From: David Harrington <ietfdbh@comcast.net>
To: alto@ietf.org, altoext@ietf.org
Message-ID: <CB6BCEF4.14D7E%ietfdbh@comcast.net>
Thread-Topic: draft-marocco-alto-next-00
Mime-version: 1.0
Content-type: multipart/alternative; boundary="B_3412840189_27381811"
Subject: [alto] draft-marocco-alto-next-00
X-BeenThere: alto@ietf.org
X-Mailman-Version: 2.1.12
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: <http://www.ietf.org/mail-archive/web/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: Thu, 23 Feb 2012 16:09:58 -0000

Hi,

AD-hat-off Š

I am not very convinced this is a set of problems that need ALTO solutions.

When dealing with P2P scenarios, ALTO is important because endpoints for a
large amount of P2P are "unmanaged" - they are typically home users sharing
files with other home users. Home users typically do not use/monitor
protocols such as BGP, ISIS, SNMP, Conex, ECN. Frequently consumer equipment
doesn't make these protocols available/accessible to end-users.

The information about the network, like server load, link status, bandwidth
availability, is not something the network providers necessarily want to
share. Network operators should be concerned about sharing with anonymous
users, who might well be interested in maliciously attacking the network
environment. 

Data centers and CDNs typically are "managed" environments, and the
file-sharing/load-balancing/congestion control protocols are for use within
the administrative domain by the operators of the data centers or CDNs (or
between "peered" environments, where there is a certain level of trust).
These environments typically have access to protocols such as SNMP and BGP,
and how the network is "tweaked" to accommodate dynamic traffics patterns is
the business of the network provider, using specialty applications to adapt
the network at the lower layers. Operators and their OAM protocols monitor
traffic load and can set policies to balance the load/adjust the forwarding
rules as needed to compensate for congestion, and so on. Applications
running on end-hosts do not have enough knowledge of the complete network
traffic, and are in a bad position to make policy decisions about load
balancing across servers based on bandwidth availability or server load or
memory usage.

I understand that there is a need for communications between layer 7
applications and the underlying layer 4,3,and 2 functionality.There are
already protocols available that allow applications to inform the lower
layers of the network what type of traffic they plan to introduce to the
network, and the qualities of the service they prefer for their traffic.
Applications can already make use of some of the existing standards for this
purpose. Users probably do not have authorization to affect the policy; they
can request QoS within the policies configured by the network operators.  I
do not see why, with few exceptions, the layer 7 application is better
positioned to be the policy decision point, especially for real-time
adjustments, than the OAM functionality already built into those lower
layers, and the network provider policy configurations. I also think that
real-time adjustments by ALTO don't seem called for, so a push model for
fast dynamic updates really isn't needed. If needed, existing push protocols
such as SNMP notifications, driven by an ALTO-SERVER-MIB,  could serve this
purpose just fine.

I have a concern about server-to-server sharing of information. I think the
network provider can decide which servers to share information with. If
server-to-server sharing eliminates the network provider from the decision
of whom to share data with, I consider that a problem. You, of course, do
not discuss how sharing would be done in this document, so maybe that issue
could be addressed.

Some of these ideas, such as server-to-server communications, might be
covered by a re-charter for the WG. However, developing a brand-new protocol
just for this purpose seems dubious when there are so many existing
protocols that can carry data between applications (which is what an alto
server is). I would expect that a better approach might be to have a server
and client co-resident, and using a (server-as-client)-to-server
communications.

I think you might have a hard time convincing the IESG to approve ALTO
extensions for data centers and CDNs that could already be handled by other
protocols in a managed environment.

My $.02
--
David Harrington