[alto] Some comments on draft-ietf-alto-incr-update-sse-07

xin wang <xinwang2014@hotmail.com> Thu, 20 July 2017 03:14 UTC

Return-Path: <xinwang2014@hotmail.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 8277212EA52; Wed, 19 Jul 2017 20:14:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.896
X-Spam-Level:
X-Spam-Status: No, score=-0.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FORGED_HOTMAIL_RCVD2=0.874, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=hotmail.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 8bBNOeSkxg0X; Wed, 19 Jul 2017 20:14:35 -0700 (PDT)
Received: from APC01-PU1-obe.outbound.protection.outlook.com (mail-oln040092254062.outbound.protection.outlook.com [40.92.254.62]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C375C129A9C; Wed, 19 Jul 2017 20:14:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hotmail.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=WyGxFBoaJMEEArrR6oG7GtHVQiwumEpWFrATkNrYrco=; b=rsaaByihmmIEKGKR8kSzog1CvgWbkvef1wgeytr4JFq/YAdbLUpo2a8uwJN+CFGNk61XuWN7dhH9tkvM871ZBTERWChXEEJrL5gNHD9L6dFUr/8L/2Xn3k3DLW+GOCT4cmPEkGu2O0NMbqHVQTq6JSGXOkxK5p7oVnLl93i/eJKNg0F6oCe4GgPm0i975FUseL3XeyOh4rtOXSy9GD4OW0uEftpFfEjeepkpLX/O7Efunqi/R4Rq9RT9MuhFrkROQst8Ef7uGWiNU+RVbOCPpwhf9LyWbLquUJCmV9gQqgKsz7N2dEtcyd7+aenm/ZXgK/lSa8wPdKvnRfceauUOiw==
Received: from PU1APC01FT115.eop-APC01.prod.protection.outlook.com (10.152.252.52) by PU1APC01HT088.eop-APC01.prod.protection.outlook.com (10.152.253.110) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.1220.9; Thu, 20 Jul 2017 03:14:32 +0000
Received: from KL1PR03MB1400.apcprd03.prod.outlook.com (10.152.252.59) by PU1APC01FT115.mail.protection.outlook.com (10.152.252.208) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1220.9 via Frontend Transport; Thu, 20 Jul 2017 03:14:32 +0000
Received: from KL1PR03MB1400.apcprd03.prod.outlook.com ([fe80::a082:6a22:1788:efa3]) by KL1PR03MB1400.apcprd03.prod.outlook.com ([fe80::a082:6a22:1788:efa3%14]) with mapi id 15.01.1282.011; Thu, 20 Jul 2017 03:14:32 +0000
From: xin wang <xinwang2014@hotmail.com>
To: "draft-ietf-alto-incr-update-sse@ietf.org" <draft-ietf-alto-incr-update-sse@ietf.org>
CC: IETF ALTO <alto@ietf.org>
Thread-Topic: Some comments on draft-ietf-alto-incr-update-sse-07
Thread-Index: AQHTAQZNT3v1xQpqqkijgfwBYOMc3Q==
Date: Thu, 20 Jul 2017 03:14:31 +0000
Message-ID: <KL1PR03MB14003B3941862899BC6015DAA8A70@KL1PR03MB1400.apcprd03.prod.outlook.com>
Accept-Language: en-US, zh-CN
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=hotmail.com;
x-incomingtopheadermarker: OriginalChecksum:07EE57559DB14568245E3DB746057EF4A4B470947973A66FE23077F5FA2C9457; UpperCasedChecksum:D5B4651EB09B033290FDECCFB996834A3E552158F67F49A790C9E7B07AB0A65F; SizeAsReceived:7187; Count:44
x-ms-exchange-messagesentrepresentingtype: 1
x-tmn: [CAklVHHoI2dDl8WtR1RTlOmFQ9T2X8RJucE19Mr+XKE=]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; PU1APC01HT088; 7:Fzm3GXovV1shvWIkYSR6UzRlX/BGiNw0+pY9p0s47pEzDSBx+N+V5it3wfWTbno/GNjsRRcvjmpLO2g/OUSHedBN6ckNMVqdq5tUmLWMWlGK/Djxb4O72ZSXEw0OTmhKdI9h/hJjvMEDlnZi4YUsEv5FiLKgKieslQjvFzPPFX+3ZsJudi7Oib7Sa+P5WZFi2E0PpGzKNjKsDrA0sww4qZNoAZa3M3IrRl5PIJiIwNULi9srVyU69n08Lj+uqmBKF5JKkWkspAVFKvnRGCAAvtiD5Dld6Lu/YS3NB06dypfa9iw3ySWQBrQiP53LMCS2k3juYZ3pIeRvGRs43gzYGGjCcptiuHd+/Yk2Qwy8JAmg6SgNOD/VOcMjCPx4y130a4q/SrMofvhXKVLILgbZsqFuofcarj7tXU0pTmvHkppHlxxUyTQGJ+CI2c+M8geVo9Th3wvoP0jRwvm5GZ4Hr7N/u/F5YMiM9BZbHnazNSczayRJL8umZo1QYo6r80E31QWwQvKVlN0qbGexTE0lxjjQDb07wLHcL47AB59mFffdMd3hXXun1XStSjBAzjADfWuN7GefzUJaFiMDMpEr2ojWWkfrKXLQjyOE0L9oFkz88nX6BwUpq6lxcgKIM/WqSvIgk+Jur7duVw/d3LWI6CRn3VcOCybLuHIPhR5iYBzvRA1luEmjJEUbl/IQzfeptT/4YYRFcncG6hvwZFpG5oIYAUfdvZbBNCfs4VN9agzer5VDNwK0CvtPjscbJZm4VQJtgeiKWIZ78KGIrLKEQg==
x-incomingheadercount: 44
x-eopattributedmessage: 0
x-forefront-antispam-report: EFV:NLI; SFV:NSPM; SFS:(7070007)(98901004); DIR:OUT; SFP:1901; SCL:1; SRVR:PU1APC01HT088; H:KL1PR03MB1400.apcprd03.prod.outlook.com; FPR:; SPF:None; LANG:en;
x-ms-office365-filtering-correlation-id: f9004981-de6e-4ab4-e391-08d4cf1d70f8
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(300000503095)(300135400095)(201702061074)(5061506573)(5061507331)(1603103135)(2017031320274)(2017031324274)(2017031323274)(2017031322350)(1601125374)(1603101448)(1701031045)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:PU1APC01HT088;
x-ms-traffictypediagnostic: PU1APC01HT088:
x-exchange-antispam-report-test: UriScan:(158342451672863)(133145235818549)(236129657087228)(788757137089)(148574349560750)(92977632026198)(167848164394848)(158140799945019)(247924648384137);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(444000031); SRVR:PU1APC01HT088; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:PU1APC01HT088;
x-forefront-prvs: 0374433C81
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_KL1PR03MB14003B3941862899BC6015DAA8A70KL1PR03MB1400apcp_"
MIME-Version: 1.0
X-OriginatorOrg: hotmail.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Jul 2017 03:14:31.9474 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Internet
X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PU1APC01HT088
Archived-At: <https://mailarchive.ietf.org/arch/msg/alto/BsStn4T6rfmmP6hoLxrAHv_b-ic>
Subject: [alto] Some comments on draft-ietf-alto-incr-update-sse-07
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: Thu, 20 Jul 2017 03:14:36 -0000

Dear authors of ALTO Incremental Updates Using Server-Sent Events (SSE),


The draft about incremental updates by using Server-Sent Events (SSE) proposes a general framework for incremental updates of network information. The concept of update stream resource in the framework allows a unified interface to ALTO clients. The interface not only considers GET-mode ALTO services but also POST-mode services, which should support most future extensions of ALTO services. The following is my comments:


a. The benefits of the general framework


Besides of the extension-friendly design, I am thinking of other benefits of bringing all ALTO services together by using a new update stream resource. First, let me propose an alternative simple solution of incremental updates. The solution views each subscription independently, which means that each time a client calls an ALTO service (e.g., get network-map) to get incremental updating data, the server will establish a connection for the data. Then, by comparing with the simple solution, we can find an obvious benefit of the solution in the draft should be reducing redundant connections. Also, another benefit would be that it makes removing resources very easily. Though SSE itself supports disconnection API, it will add new APIs to the simple solution. Moreover, because one connection could manage multiple resources which may have overlapping (also dependencies) between each other, I am considering whether there exists an efficient way to make scheduling for updating these resources.


b. Full replacement or incremental updates


In the client side, if the data is updated in incremental ways, then there should be some algorithms to apply the updates like the algorithm in Section 4.2.1. However, if the data allows full replacement, then the client can easily replace the data with the new one instead of applying the algorithms. Also, the “incremental-updates” field is “true” indicates the server MAY send incremental update events, which means that the client may receive either a full replacement or incremental updates in each time (is this right?). My idea is that if the response from the server can indicate whether this update is a full replacement or incremental one, the client should benefit from that.


Also, there are some typos may be fixed:


Page 10: "we now gives" -> "we now give";

Page 13: missing “)” in "(see Section 6.3.”;


Best,

X.Tony Wang