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

Lyle Bertz <> Mon, 24 July 2017 17:49 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6749A12EC1D; Mon, 24 Jul 2017 10:49:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.749
X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=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 K81qifYFtspt; Mon, 24 Jul 2017 10:49:25 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:400c:c0c::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 94FC3131ECC; Mon, 24 Jul 2017 10:49:24 -0700 (PDT)
Received: by with SMTP id y43so109228017wrd.3; Mon, 24 Jul 2017 10:49:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=qwzGuNxOkfiOkPmbP0U+9c8izTQ+Sj+pM3UrvESuFOQ=; b=f8rJ4perkqK+N1J17fNuZ2xM8jj51LVIp1yY5NuY649WhR2Fbx9xvDjPattG7iQ2Kt aIkoAPKS6Govnr2mt86YBbQJ5k8Spx9cVrlsef1Gw5mvZBCStnFgdK/z4A+4NeVWQqi2 pThDDxTEN/YtbXz6uiloJw05TUU3GHgSHWEAelHfI05Xz3KNVQBg+p+xzXpEOnV3Kxi5 iD/pJotuuYf/DyTfKfXaosZLHbYBunHwzIs+Kx3S49Auvheyw0shFTDfP0/brafRv2tU BBISOi1+nuPbe8N7NjgVHoxBdLB6v8o+0kuywfkJMI5m74fq7Kr4G6A50afzWYjbLlQO TrnQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=qwzGuNxOkfiOkPmbP0U+9c8izTQ+Sj+pM3UrvESuFOQ=; b=IzkVoOgUmxo9fTZhzo8QOpQmqxs31fcaPmBeGa/DbriEU/aJlZD7caMtJnuzCtpbWe AfFY8aq9l1juMLixZss/iHCRtERX94Lm34D0D4HhhS8pihjxedeN7s/39She3LrRBiAv pHAY8i3Mrl9jZDDdyWwoNt3SVP7epWijIWN+D3I8KBOKVtuWU1FTcvpp1tChHAnLXMC/ Sv7c+805naSNfWIxbR+RC1GB3aemzSLFIVA9tSS+OOUR3G0bac4vWCRQLvkJBMUCwzUp bqisDakpgQPOyBgCWDKwgWULReaX3TO9mS9B529Ni6JSUrTY9wDca+KVfENb10FObcdh Z1kg==
X-Gm-Message-State: AIVw110XO8Sj/VJs4Keu0KN5UxWXx45MEGL7yQDDXuxHvoWOMboDDN2A i5ZvJjDFz4VTFYFG2qDl0/B2C5DFRQ==
X-Received: by with SMTP id r22mr16439641wra.59.1500918563196; Mon, 24 Jul 2017 10:49:23 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Mon, 24 Jul 2017 10:49:22 -0700 (PDT)
In-Reply-To: <>
References: <>
From: Lyle Bertz <>
Date: Mon, 24 Jul 2017 12:49:22 -0500
Message-ID: <>
To: xin wang <>
Cc: "" <>, IETF ALTO <>
Content-Type: multipart/alternative; boundary="f403045ecfcecbda31055513d5c9"
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: Mon, 24 Jul 2017 17:49:27 -0000


I asked during the meeting about whether or not it made sense to look at
alternatives to W3C SSE.  However, in subsequent WG meetings such as
netconf use of W3C SSE is the norm and the right way to go.

tl;dr - don't change the draft - keep the use of W3C SSE.


On Wed, Jul 19, 2017 at 10:14 PM, 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. 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
> _______________________________________________
> alto mailing list