[alto] Reprise of REST comments

"Thomson, Martin" <Martin.Thomson@andrew.com> Wed, 10 November 2010 07:18 UTC

Return-Path: <Martin.Thomson@andrew.com>
X-Original-To: alto@core3.amsl.com
Delivered-To: alto@core3.amsl.com
Received: from localhost (localhost []) by core3.amsl.com (Postfix) with ESMTP id 1EDAD3A69A3 for <alto@core3.amsl.com>; Tue, 9 Nov 2010 23:18:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.026
X-Spam-Status: No, score=-3.026 tagged_above=-999 required=5 tests=[AWL=-0.427, BAYES_00=-2.599]
Received: from mail.ietf.org ([]) by localhost (core3.amsl.com []) (amavisd-new, port 10024) with ESMTP id hGCOPEj5F8a0 for <alto@core3.amsl.com>; Tue, 9 Nov 2010 23:18:19 -0800 (PST)
Received: from csmailgw2.commscope.com (csmailgw2.commscope.com []) by core3.amsl.com (Postfix) with ESMTP id 98E703A68D6 for <alto@ietf.org>; Tue, 9 Nov 2010 23:18:19 -0800 (PST)
Received: from [] ([]:38735 "EHLO ACDCE7HC2.commscope.com") by csmailgw2.commscope.com with ESMTP id S443398Ab0KJHSp (ORCPT <rfc822; alto@ietf.org>); Wed, 10 Nov 2010 01:18:45 -0600
Received: from SISPE7HC1.commscope.com ( by ACDCE7HC2.commscope.com ( with Microsoft SMTP Server (TLS) id 8.1.436.0; Wed, 10 Nov 2010 01:18:45 -0600
Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC1.commscope.com ([fe80::8a9:4724:f6bb:3cdf%10]) with mapi; Wed, 10 Nov 2010 15:18:41 +0800
From: "Thomson, Martin" <Martin.Thomson@andrew.com>
To: "alto@ietf.org" <alto@ietf.org>
Date: Wed, 10 Nov 2010 15:18:38 +0800
Thread-Topic: Reprise of REST comments
Thread-Index: AcuAp36i7OY3ugPTRmOqx69/eA26UA==
Message-ID: <8B0A9FCBB9832F43971E38010638454F03F336538D@SISPE7MB1.commscope.com>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-BCN: Meridius 1000 Version 3.4 on csmailgw2.commscope.com
X-BCN-Sender: Martin.Thomson@andrew.com
Subject: [alto] Reprise of REST comments
X-BeenThere: alto@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "Application-Layer Traffic Optimization \(alto\) WG mailing list" <alto.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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: Wed, 10 Nov 2010 07:18:21 -0000

I apologise for this being a reprise of previous comments, but I still feel like the current alto protocol is causing you a lot more work than you need.  

You really want to spend less time on dealing with protocol construction and more time on optimizing cost maps.  By building your own protocol, I don't think you get that.  

The delta between what you have and something that relies more heavily on existing protocol (i.e., HTTP) work is not that large.

There are two things that you should be doing:

 1. describe the data that you want a client to acquire (the fun stuff)
 2. describe how a client might find where information is (the dull and messy stuff)
 3. describe how a client might ask for information, if necessary (the yucky stuff)

If you define formats, and give them MIME types you get part 1.

If you then define meta-formats you get part 2.

If you define a query format for cost map filtering and anything that needs it, you get part 3.

Do it right and you don't have to worry about caching, or the sorts of issues that you are trying to re-invent the wheel for (for example: the ServerA ServerB load sharing example in Rich's presentation just now; load sharing does not need to be visible to clients.  There is lots of experience in building scalable HTTP infrastructure.).

That means that extensions the like of what we're seeing might be done without having to talk about protocols.  All you do is define the format and how that format is identified in the meta-format and discovery parts.

Something like:

 Server has document that lists 
   where a cost map is found
   Where a filtered cost map might be acquired by providing filtering criteria
   Where an endpoint map is found
   And so forth for each of the types you have, plus all the extensions that the server might support

    </alto/costmap>;title="Complete network cost map";type="application/alto-costmap"
    </alto/cost?{ip}>;title="Filtered cost map";type="application/alto-costmap"
    <http://other.server/alto/ep>;title="Complete endpoint map";type="application/alto-epmap"
  At the end of each of those links you either find a resource that contains the desired document.

  You use content negotiation and MIME for version negotiation (you don't need to specific versioning stuff that you have already)

  You can also use MIME for identifying the cost types to help a client in selecting the right URL: 


  Clients can share links (deep links might stop working occasionally, which would necessitate re-discovery, but that's not a big deal).

  HTTP caches (and CDNs...) can redistribute the data

Have a look at RFC 5988 and draft-core-linking for information on how you might provide a collection of links.