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

xin wang <> Thu, 20 July 2017 17:55 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4AB42131D26; Thu, 20 Jul 2017 10:55:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.896
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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id OPlfCoWAj-L9; Thu, 20 Jul 2017 10:54:59 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3A79A12F3CB; Thu, 20 Jul 2017 10:54:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=EnK2xFmzxPFOwfg23STed805MNdKyvuRj4nXwsZJUSE=; b=SAcvcc4D/AuVgTlg0OJ+416FJJ482p2OmlC47d6qVuOu0e4ook5eo0oJQLO8YWHUY1QXMZ6F/VWQwm22BM1L51IcQfnP9S+Oc32umfxZJvSJhgHGEHPdu86dKeRm0NgXT0DUgoLFyXql/M5Q8Qw5ZN27DQfz0EL18KtDUyRgL0NDMOCUuv/qImkLcE15i6FrPugeRPFnfo0nyH2TqyrNEbNIoMwDvjDDLxdsGq7H4PV8Z4kc2DObcxv3s3n3m3/0KB19I/FA+4fvuo9FJYVe2lsGVQu4fGDzm30FI11qS4lAsP0zIq3Q1uYos4ucDj0UlZc6OC0xrlLo78lWs8GeqQ==
Received: from ( by ( 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 17:54:55 +0000
Received: from ( by ( 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 17:54:55 +0000
Received: from ([fe80::a082:6a22:1788:efa3]) by ([fe80::a082:6a22:1788:efa3%14]) with mapi id 15.01.1282.011; Thu, 20 Jul 2017 17:54:54 +0000
From: xin wang <>
To: "Y. Richard Yang" <>
CC: "" <>, IETF ALTO <>
Thread-Topic: Some comments on draft-ietf-alto-incr-update-sse-07
Thread-Index: AQHTAQZNT3v1xQpqqkijgfwBYOMc3aJcbiKAgACNO1w=
Date: Thu, 20 Jul 2017 17:54:53 +0000
Message-ID: <>
References: <>, <>
In-Reply-To: <>
Accept-Language: en-US, zh-CN
Content-Language: en-US
authentication-results:; dkim=none (message not signed) header.d=none;; dmarc=none action=none;
x-incomingtopheadermarker: OriginalChecksum:A5164BFA93ECBC7D6FAF4EA154E21383AA2CB474FE3614FCA05A23C8B38B8C59; UpperCasedChecksum:E2CBC239079E902B63A8F87C72605A8D20EBF8DB9DF29BC3C85D3A4DB5262862; SizeAsReceived:7501; Count:46
x-ms-exchange-messagesentrepresentingtype: 1
x-tmn: [mW+bpApm1/QDp93wMn86Kdp/4J1uIC18VJk+t5mhM6k=]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; HK2APC01HT193; 7:l/06Nwpm7BJQBslohER64d/lyEb+q2dwgPe/oSSsNpSizeCqQRnqlLzMfMbsR59sRvUNJmVbDTIpwS5lTkdPUQoijLt3cPA5I+XLye3Xcv9SW7zMLOYCJ/dbtr19fllZmmasJiF0HUh4lK0a84CmGTk3hOWofYdV4j9LxpfwdHyztlBWsvqgZ11eDiKBTE0aet3g/ydvnJZhw0sZa9rdy8icnLMv2hf0Bd/KazGMNVqAXzksyOO1yI895Zu7NGlxU4gSuT07vrYCUYePr+diR/bORB1qQez7x+Jobe2kVfBa3La46alqCT4/c3tsjy8j8GqubUs7AKaYxuaQpVPMolulyyJftds/aV0zku40f8axaUFmBvtf/mvZ3M0icEC37C5qaNrzvy0jnsk4aZhFw6bBPHvPccQgbhmvtMNRnGHWGiNtUHLGLo1saxPB0daydiS6DJJlP+OqvCVjeXNC8NDdupSZPRJ8W7AzLNg6CvYUwWVZtBIB1BcpWvMlvr/VTUm3iNxBeWPUbVcw+yrey0sHH1fKSas/lUkQ5ffx/Kzp1FTR9p9YkOGh6J/AWy9U0ycxlF93UR3w2PzNu7BSJMilJjMGA7o44MIXupj6kxWrtOAN3/rnFD+4CJOiDaNljn4UOC1UZKZLEz5xIA+oQl6aP6OrfLwn7YYBNf+qm9evXkyv4XcV+5g3zW06ZFQT3y7CFs7O4Pl4aLUbVxBLPMA6VFCeAVaZ/OP8U8z4KI6P1mRQ8K9aM9SeJx47TKI4VqxOt+b5JXOHPAMe3JjV0Q==
x-incomingheadercount: 46
x-eopattributedmessage: 0
x-forefront-antispam-report: EFV:NLI; SFV:NSPM; SFS:(7070007)(98901004); DIR:OUT; SFP:1901; SCL:1; SRVR:HK2APC01HT193;; FPR:; SPF:None; LANG:en;
x-ms-office365-filtering-correlation-id: 95a93920-6a0c-4126-7147-08d4cf986db0
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)(1603101448)(1601125374)(1701031045)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:HK2APC01HT193;
x-ms-traffictypediagnostic: HK2APC01HT193:
x-exchange-antispam-report-test: UriScan:(158342451672863)(133145235818549)(236129657087228)(788757137089)(48057245064654)(148574349560750)(194151415913766)(92977632026198)(167848164394848)(158140799945019);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(444000031); SRVR:HK2APC01HT193; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:HK2APC01HT193;
x-forefront-prvs: 0374433C81
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_KL1PR03MB1400C14171F4FD3F8A5B9B7EA8A70KL1PR03MB1400apcp_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Jul 2017 17:54:53.9303 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Internet
X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HK2APC01HT193
Archived-At: <>
Subject: Re: [alto] Some comments on draft-ietf-alto-incr-update-sse-07
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Application-Layer Traffic Optimization \(alto\) WG mailing list" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 20 Jul 2017 17:55:03 -0000

Dear Richard,

Thanks for the reply. Please see the comment below:

Dear Tony,

Thanks a lot for the review. Please see below for a quick response.

On Thu, Jul 20, 2017 at 5:14 AM, xin wang <<>> wrote:

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.

This is an interesting view: using an update stream resource to bring all ALTO resources together.

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.

The current draft has some dependency/consistency requirements:
- Sec. 7.6.2: Event sequence requirements, on updates of dependent resources
- Sec. 7.6.3 Cross-stream consistency requirements
- Sec. 10: Client processing when there are dependencies

My understanding is that you are suggesting a subsection (or two subsections) on
- IRD announcement, and one
- subscription

Do I understand you correctly?

>> I am suggesting to add a subsection to summarize the benefits of the proposed solution based on the requirements for the incremental updates or add some discussions to discuss how the proposed solution derived from the problem. Because people might quickly come up with their own solutions (like the simple one above) for the problem and they may want to know why yours is better.

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.

I believe that the media type in the "event" field can indicate whether this is a full or incremental (if so, which diff method). Does this address your issue or you are suggesting a more general solution?

>> Yes. This solves the issue.

X.Tony Wang


Also, there are some typos may be fixed:

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

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


X.Tony Wang

| Y. Richard Yang <<>>   |
| Professor of Computer Science       |
|        |