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

"Y. Richard Yang" <> Thu, 20 July 2017 09:11 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 453B0126B72; Thu, 20 Jul 2017 02:11:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.699
X-Spam-Status: No, score=-1.699 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_NONE=-0.0001, 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 dQuVTkStGhm9; Thu, 20 Jul 2017 02:10:58 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:400c:c0c::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A01B0127735; Thu, 20 Jul 2017 02:10:57 -0700 (PDT)
Received: by with SMTP id v105so37902193wrb.0; Thu, 20 Jul 2017 02:10:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=DKD4z9Hc4KxCvQKYNgoeg0kwk/R7Ag9cfPRgosZSfC4=; b=A33Bt21hzT5+p5LG+AUJpoRLGFb53G7tG+ZrB6PYe7pgSQEHh7m/sxr6/ZXLkh3Qg9 OMrx9vaovs8qR1XDHKE6zGvYfeS74DOzYQCVHEcy6qY6dzRoL34IkAQzQJyDKt+aLzTf 7WzmWeUhLQQise+IrfbJD0TYgrQNwsSEw886ys7tJ+rC4iqY195nGBOA3Ih+2IjeZ4cq PPeDX6BfrOBvZw8MOs57+A2jcpQ3DOhrEoCh0ErGrW180Hj79j/Xt5SCUjkqBvkCc/+Q 3EOp53CfdMQqkd4IB+B/EGFewAG7KIiNE97dkVrX1Hcic9y9tPMJoPkcMTpWti47YUNv vDWw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=DKD4z9Hc4KxCvQKYNgoeg0kwk/R7Ag9cfPRgosZSfC4=; b=D4E+d1bWWIt6IUiSWbVgVDAKImxT6cXHBgzfD8hpQLfSggiE1EIJJzF0gdfuXCp6Ts S2HyI+MHwjHxVZxYl8+2Uy7AkRQceKOhjIgcI+js3L1G0HR4/W9Y4nOozqmgPmSzIhz4 L7Wy4niGEZ+a03gAYkWujVE97oZPzffJyDMYyTJ2Kv+Q82DMZwUyiW16HMtcieDdJRX5 Y/jsPFGT2m9BNBH2Sl50xq0g0rsgOlud3cqs69f6ZYmlJI2DgPvlHAw4IOkayi/8GNCn 2d0UFdXHhaeS0g0yj1n9YQOHqQFYk2lph1qqzxkm3oHJnh8BQxqh3xMSAditH79P9ZnM 88Dg==
X-Gm-Message-State: AIVw113dThQWcCe9t59CgUf9O1HiVjpaCADOHcasPBu2DOH1v5VT7lqf hIHCyTgBphc+iHFv83rWnvbDD1mfklWZ
X-Received: by with SMTP id 93mr2264833wrr.225.1500541856219; Thu, 20 Jul 2017 02:10:56 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Thu, 20 Jul 2017 02:10:55 -0700 (PDT)
In-Reply-To: <>
References: <>
From: "Y. Richard Yang" <>
Date: Thu, 20 Jul 2017 11:10:55 +0200
X-Google-Sender-Auth: vj_mVM1GneHiQOVb4TfCien-ris
Message-ID: <>
To: Tony Wang <>
Cc: "" <>, IETF ALTO <>
Content-Type: multipart/alternative; boundary="94eb2c0d24704f87c30554bc20d9"
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 09:11:00 -0000

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?

> 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?


> 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

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