[alto] fci alto transport design discussion

"Y. Richard Yang" <yry@cs.yale.edu> Mon, 03 July 2017 11:59 UTC

Return-Path: <yang.r.yang@gmail.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 DC9AF1315F4; Mon, 3 Jul 2017 04:59:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.399
X-Spam-Level:
X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 CVlnIh6HLsKG; Mon, 3 Jul 2017 04:59:04 -0700 (PDT)
Received: from mail-wm0-x236.google.com (mail-wm0-x236.google.com [IPv6:2a00:1450:400c:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9709C1315F2; Mon, 3 Jul 2017 04:59:04 -0700 (PDT)
Received: by mail-wm0-x236.google.com with SMTP id f67so52359251wmh.1; Mon, 03 Jul 2017 04:59:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:from:date:message-id:subject:to; bh=n8JxPFWcOsu/+1jZr7vtmAjXfqsI903TM1bQI6u6VnE=; b=Nw6OA1kDtpDP1NHNQZ7YF0W4OZCwloR7SdIi4s1/oHK3VTgE66NWEcSZziK8g24IIK JJwxFGe9UFoA1cSWBsVLyVTOGPqJELO7YtyLeoO+ZAZaEHNKZ09vKuUWKbd0OoXzuPBc pKCsCZzdh6yNt5f/h+6QMVj4iTn8Gbl0qyTb9PXDsTUNUMkfDdpUC30A33j4KshYaVBb 9Xmg0+M9sh/+yKJ5g3/tMGTOiE/OeWwhPcAlPyqG/+354rFcb/LSLmTPjrM5Kqo/ZBM9 1MBegA2P4UrQtdXkFJyo748J0UORNEaeEgoIAy/lcYeAD5fG5ihkxloqKDZSI6FS4hyX EymQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:from:date:message-id:subject :to; bh=n8JxPFWcOsu/+1jZr7vtmAjXfqsI903TM1bQI6u6VnE=; b=EIKAYWZWqiJqGv90/u5CVjCE2VziSF/TUo+dryjva7qt8DYBe9Xz986VUz9s2zc8IK rHtAQD8vdE7CDjeWZyBpe/3DtfP1QNx5LtMfXZMQYD5WzGu6vx6b+lnzbdzCyFft8+FJ X5CleReWPX1wVB9CaxMML89nd1wo9rP4CGKmc8zYQ61YbuUz/1zn948ma1lPQohbJcRb Q3/b3r7Wkm/c0zVqbHOc5RV2eYenBqx837xm/5Z02f5N4udQfj97KHMnGXEbCL6U2SUJ jCgoTZ7BvIgbtdasD5Bz2DQSuYbNeWeYTerC0lXIxIivyywZAOgtG5/VVOc3BqvOwi/N pjjQ==
X-Gm-Message-State: AKS2vOwqTYB+Ax9Jji7/vMm8QumDhtvi8NH/RYU1bSPlfbsBK+5CrMPu JHWK/ds/NAmt4L1tWw1OgOlBQGb6JaK5
X-Received: by 10.28.127.21 with SMTP id a21mr22274601wmd.18.1499083143174; Mon, 03 Jul 2017 04:59:03 -0700 (PDT)
MIME-Version: 1.0
Sender: yang.r.yang@gmail.com
Received: by 10.28.71.89 with HTTP; Mon, 3 Jul 2017 04:59:02 -0700 (PDT)
From: "Y. Richard Yang" <yry@cs.yale.edu>
Date: Mon, 03 Jul 2017 19:59:02 +0800
X-Google-Sender-Auth: 3ivHpHAr004hC5k1DeLwxFfwFHM
Message-ID: <CANUuoLr3cXLe-27j11Be5amOcH7JjGrFTKa5PWBFaYJKV3sqbw@mail.gmail.com>
To: Jan Seedorf <jan.seedorf@hft-stuttgart.de>, Jon Peterson <jon.peterson@neustar.biz>, Kevin Ma J <kevin.j.ma@ericsson.com>, "cdni@ietf.org" <cdni@ietf.org>, IETF ALTO <alto@ietf.org>
Content-Type: multipart/alternative; boundary="001a1141fdce3cea330553687e42"
Archived-At: <https://mailarchive.ietf.org/arch/msg/alto/qiclc8r9B05bzIwT9JCkcP6Uh0U>
Subject: [alto] fci alto transport design discussion
X-BeenThere: alto@ietf.org
X-Mailman-Version: 2.1.22
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: Mon, 03 Jul 2017 11:59:07 -0000

Hi Jan, Jon, Kevin, all,

As we are working on the design, a key issue that we are trying to
understand is the conflict resolution of the capabilities in the
"capabilities" list [RFC8008]. Consider

   {
     "capabilities": [
       {
         "capability-type": "FCI.DeliveryProtocol",
         "capability-value": {
           "delivery-protocols": [
             "http/1.1",
           ]
         },
         "footprints": [
           <Footprint objects 1>
         ]
       },
       {
         "capability-type": "FCI.DeliveryProtocol",
         "capability-value": {
           "delivery-protocols": [
             "http/1.0",
           ]
         },
         "footprints": [
           <Footprint objects 2>
         ]
       }

     ]
   }

What if the footprints in the two entries have overlap? I see two options:
(1) Enforce that each capability-type has a single entry; that is, make
capability-type a key;
(2) Allow multiple entries with the same capability-type, and the search is
ordered by the array; that is, the result is the first matching footprints.

I assume that (2) is more flexible. An issue, however, is that it
makes incremental updates harder. In other words, this issue will determine
whether we should integrate JSON Patch. The current alto incremental
updates, based on SSE and JSON Merge Patch, is pretty useful. The FCI use
case may argue that we extend the incremental update w/ JSON Patch, to
better handle arrays, right away.

Any clarification, comments and suggestions will be great.

Richard