Re: [alto] Discussion II: Unifying cost-mode and cost-type to a single type

"Reinaldo Penno (repenno)" <repenno@cisco.com> Thu, 21 February 2013 17:16 UTC

Return-Path: <repenno@cisco.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 84B6E21F8EF9 for <alto@ietfa.amsl.com>; Thu, 21 Feb 2013 09:16:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.598
X-Spam-Level:
X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2GwKm9Jh+Jnu for <alto@ietfa.amsl.com>; Thu, 21 Feb 2013 09:16:41 -0800 (PST)
Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id D525721F8EF4 for <alto@ietf.org>; Thu, 21 Feb 2013 09:16:40 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10555; q=dns/txt; s=iport; t=1361467000; x=1362676600; h=from:to:subject:date:message-id:in-reply-to:mime-version; bh=jNiXWFsq35EmmoWgrxp0ECYfWA1zYRvm7KfmydTA1Mk=; b=alJWKEPpIEJV4xgZyaO6ODKrn/B/0u6kTipEZaVMUlkrlbT7jSfBXgnZ O5BcCeiQEuDr8yK7cydfvwCu5g6UGlEDm/o7/CANXEJZcoyl+CT7q7Yi6 0ohTYOssbJqOOZqx8Ds0WljL+zI7Wn9AkgOymiLp56sbE2R9rge4LFyOQ U=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgEFADZWJlGtJXG9/2dsb2JhbABFgkO+OYEEFnOCHwEBAQQBAQFrHQEIDgMDAQILHS4LFAkIAgQBEgiICgy/DASOXSAGBwsGgllhA6cUgweCJw
X-IronPort-AV: E=Sophos; i="4.84,710,1355097600"; d="scan'208,217"; a="179685456"
Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-2.cisco.com with ESMTP; 21 Feb 2013 17:16:36 +0000
Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id r1LHGZrE010672 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 21 Feb 2013 17:16:35 GMT
Received: from xmb-rcd-x04.cisco.com ([169.254.8.112]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.02.0318.004; Thu, 21 Feb 2013 11:16:35 -0600
From: "Reinaldo Penno (repenno)" <repenno@cisco.com>
To: Wendy Roome <w.roome@alcatel-lucent.com>, "alto@ietf.org" <alto@ietf.org>
Thread-Topic: [alto] Discussion II: Unifying cost-mode and cost-type to a single type
Thread-Index: AQHOEFD6VY+ntXZyY0eKp/DUkgLdjpiEwAyA
Date: Thu, 21 Feb 2013 17:16:34 +0000
Message-ID: <45A697A8FFD7CF48BCF2BE7E106F06040901008C@xmb-rcd-x04.cisco.com>
In-Reply-To: <CD4BB26C.35D3F%w.roome@alcatel-lucent.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.13.0.110805
x-originating-ip: [10.21.123.210]
Content-Type: multipart/alternative; boundary="_000_45A697A8FFD7CF48BCF2BE7E106F06040901008Cxmbrcdx04ciscoc_"
MIME-Version: 1.0
Subject: Re: [alto] Discussion II: Unifying cost-mode and cost-type to a single type
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, 21 Feb 2013 17:16:43 -0000

This is what you need. A private cost you can use within your ALTO servers and domain.

"Identifiers prefixed with ’priv:’ are reserved for Private Use"



From: Wendy Roome <w.roome@alcatel-lucent.com<mailto:w.roome@alcatel-lucent.com>>
Date: Thu, 21 Feb 2013 11:32:03 -0500
To: <alto@ietf.org<mailto:alto@ietf.org>>
Subject: Re: [alto] Discussion II: Unifying cost-mode and cost-type to a single type

Reinaldo,

I don't think the current ALTO draft is that permissive. Section 6.6.5 (Cost Types) seems to require that a server register any cost type that doesn't start with "exp:":

Identifiers prefixed with ’priv:’ are reserved for Private Use
[RFC5226]. Identifiers prefixed with ’exp:’ are reserved for
Experimental use. All other identifiers appearing in an HTTP request
or response with an ’application/alto-*’ media type MUST be
registered in the ALTO Cost Types registry Section 9.2.

Also, although we've registered "routingcost" with IANA, I don't consider that cost type is "interoperable." To me, "interoperable" means that "routingcost" values would be comparable between servers, so that a cost of (say) 40 means the same on all ALTO servers. That's clearly not the case. Nor should it be!

Perhaps I'm missing the point, but as long as an ALTO server has a standard way to describe its cost types, I don’t see any advantage to registering ALTO cost types with the IANA.

- Wendy


Date: Thu, 21 Feb 2013 16:00:30 +0000
From: "Reinaldo Penno (repenno)" <repenno@cisco.com<mailto:repenno@cisco.com>>

Hello,

Some comments inline...

From: Wendy Roome <w.roome@alcatel-lucent.com<mailto:w.roome@alcatel-lucent.com><mailto:w.roome@alcatel-lucent.com>>
Date: Wed, 20 Feb 2013 09:49:17 -0500

....

3. Your last point is about registering cost types. Yes, my proposal would make it harder to register new cost types with the IANA.

But I'll turn that around. Why do we need a central registry for cost types at all? Why does the IANA need to control them? Sorry if I'm stepping on someone's favorite idea here, but to me, a central registry seems totally unnecessary. Worse than that, it's harmful: it will stifle innovation, by making it much harder to create and experiment with new cost types.

[RP] You can always define a new cost type and experiment with it. IANA registered means standardization and interop are required.

Yes, that means that two independently implemented ALTO servers can each define a new cost type named "myExtendedCost", with completely different semantics. So what? What's the problem with that? Clients will know that "myExtendedCost" is only meaningful within the context of a specific ALTO server.

Note that the cost type extension I proposed takes over the descriptive features of the IANA registry, in that it provides all the information about this new cost type that a potential client needs to know. It doesn't allow the IANA to manage and control new cost types. But I think that's a good thing!

So in short, I suggest dropping the central "cost type registry" requirements completely (Section 9.2). Instead, the ALTO server provides a description of its cost types in its resource directory. ALTO servers are free to invent new cost types, to differentiate themselves and provide additional value.

[RP] ALTO servers can already do that today.  IANA registration does not preclude any of that, and as you say, within a domain you can define whatever cost mode you want. This is not new, IANA registers a few modes/message types/etc and reserves some for private use.


_______________________________________________ alto mailing list alto@ietf.org<mailto:alto@ietf.org> https://www.ietf.org/mailman/listinfo/alto