Re: [alto] Issue about incr-updates-sse update stream control design

"Y. Richard Yang" <> Mon, 05 March 2018 02:23 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BFCE3124C27 for <>; Sun, 4 Mar 2018 18:23:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id OYi8hHUMjfm5 for <>; Sun, 4 Mar 2018 18:23:52 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4010:c07::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 2327A124B0A for <>; Sun, 4 Mar 2018 18:23:52 -0800 (PST)
Received: by with SMTP id 70so20869649lfw.2 for <>; Sun, 04 Mar 2018 18:23:52 -0800 (PST)
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=i+3jLhAO3wECcua3+d/Vx4ZqG2Jq3o5twvKFWWTx7vg=; b=qUgcnzs3Gpe3S87qL6INqDaAGhdI/DUWO7EB9ZvLSd4S4KQ+NKIWH4EdQTIERPsPoW Ch/rMYFE4V6YSJW23xdUvGuW2VHeslYfEtJqXWqE33ExRdJLjSBttJD1o2OT8SLmt8rz 0n6UsJxN+wpdERT7Ic7XH6wbmDvq4T6jccO8VKp8cVkZtGIrN9Ye4HMXjtHOg79lcl1a ePIMq8NHs139I/7nNYaMd1rJd1BVjW8SdmZAHCLU7uIM7tBksUJTMhzm8VThjIxegJQ2 F5Ylsvrd+dmQ56UdzQsbUjo9KDfCCWLILfV9gJanLfuwgK1+djBGExWHelbV9vpkYC6n t12A==
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=i+3jLhAO3wECcua3+d/Vx4ZqG2Jq3o5twvKFWWTx7vg=; b=sJfyRSL3yMRLeechecH2RZdE4hf7YwYaQM63AOpKBfKuLg38SB3Q7Es7F+GuoRB8H2 2ryiMbe71Bbq13qyoDKpsj2ToFMIddS4raH3O/bV9l/YR6cMHIZBhCdEwIjsH6Z57+vi ewIbteo1YtfbQ75JXTVsNpq4FvybFZp+vaYjkdh2k8m+s1vnaf7TyW4lw4A/AUQCjXZs AZ1XpjHoNmtkdk5akUgcelqaGFB58JPHzHjGQwv23ddOCyDijqbwmBeLI0RR4tdftWEG YLHGsFXDQW7/5W6nbeK1dZ/ocAI5s+U1akjXgr+Ao9MP0M/f/UZbwLoQgUTtSKfHKee0 j2cQ==
X-Gm-Message-State: APf1xPB18hDpsmgm9hLN0pclm+G7thE5fLnnZ3mRWVpF25/JD8DThtG5 gLYqSteqU+UCsjQDaYCN7tx6sdx4UKRZ7wXaEPw=
X-Google-Smtp-Source: AG47ELsEElSoi98eMUPSZnhub599NuT4Jl7esBdrlmBtnt9C3ho7AdB1ybLjdVY71Ry5WW7EXP12ksAtCiV9jBTSZis=
X-Received: by with SMTP id i16mr8405981ljd.78.1520216630290; Sun, 04 Mar 2018 18:23:50 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Sun, 4 Mar 2018 18:23:49 -0800 (PST)
In-Reply-To: <>
References: <> <> <>
From: "Y. Richard Yang" <>
Date: Sun, 4 Mar 2018 21:23:49 -0500
X-Google-Sender-Auth: rIo3uQJDgtsIQirNzLJChGO351s
Message-ID: <>
To: Dawn Chan <>
Cc: Jensen Zhang <>, "" <>
Content-Type: multipart/alternative; boundary="f403045f73703aef960566a1042d"
Archived-At: <>
Subject: Re: [alto] Issue about incr-updates-sse update stream control design
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, 05 Mar 2018 02:23:56 -0000

Thanks a lot for the points, Dawn.

Please see below.

On Sat, Mar 3, 2018 at 7:57 AM, Dawn Chan <> wrote:

> Hi Jensen and Richard,
> Here are some of my ideas about the problem.
> Actually, the solution for option 1 is already mentioned in Section 8.6 of
> the draft:
> “If a request is successful, the server returns an HTTP ‘204 No Content’
> response with no data.  If there are any errors, the server MUST return the
> appropriate error code, and MUST NOT add or remove any resources from the
> update stream.  Thus control requests are atomic: they cannot partially
> succeed.”
> Here, the appropriate error code is returned in the HTTP response.
> Actually, an HTTP response has to be sent to the client whether the request
> is successful or not.
> The approach that the server also notifies client outcome in the update
> stream can guarantee that the request does succeed. So I think it is better
> to use them both.
> This way, if the request is processed successfully, the server will return
> with an HTTP “204” no content and a message in the update stream. If the
> request fails, the server will only return an error with ALTO error code in
> the HTTP response.
It is clear that using both, as it is in the current design, is an option.
Make sense to others in the WG?

> Another issue in the draft is the name of “client-id”. The name
> “client-id” looks more likely to distinguish ALTO clients, rather the
> different requests of different resources. So, I think it might be better
> to use another name, maybe “request-id”, to replace “client-id”. Do you
> have any better names?

Since it names an update stream, how about stream-id?


> Dawn
> On 3 Mar 2018, at 7:30 AM, Y. Richard Yang <> wrote:
> Hi Jensen,
> Good question! Let's see the design space:
> 1. Client can send "add" or "remove"; since HTTP requests are "one-way",
> this needs to use a new control channel--a new HTTP request
> 2. Response option 1: Server notifies client outcome in the HTTP response
> by using a HTTP response code;
> 3. Response option 2: Server notifies client outcome in the update stream;
> Note that we can have 3 options: (1) option 1 only; (2) option 2 only;
> (3)  both.
> Option 1 only may have a concurrency issue, depending on the specific
> design and semantics. Consider two semantics:
> 1. Server responds *only after* the last updates have been sent
> successfully. This will lead to synchronization of likely two processes at
> the server; hence the guaranteed serialized sequence is:
> client sends remove request -> server (process 1) processes the request ->
> server (may be process 2) flushes all outstanding updates to client ->
> server (process 1) notifies client by returning in the http request.
> The price here is that the server process structure can be more complex.
> 2. Server responds *immediately* (i.e., not blocked by flushing and ack of
> all pending updates), and hence, the semantics is that although the
> client gets a "remove" success, updates may continue to arrive; hence the
> client code needs to be careful to handle the issue. It is not clear when
> the client can be notified that the buffer is flushed indeed.
> Option 2 does not have the preceding issue: the server HTTP response only
> acknowledges that the "remove" request is received successfully and can be
> processed, but not that it is cleared.
> But thinking about the issue one more time, we can use option 2 only, but
> then the document need to make clear that the client can handle remaining
> updates gracefully---just as after TCP close but data can continue to
> arrive. Is this a design that you appreciate more?
> Richard
> On Fri, Mar 2, 2018 at 10:57 AM, Jensen Zhang <>
>  wrote:
>> Hi incr-update-sse authors and all,
>> I have a question about the current update stream control design in
>> incr-updates-sse.
>> In the last paragraph of Section 7.6.2, the document writes
>> "When the client uses the stream control service to stop updates for one
>> or more resources (Section 8
>> <>),
>> the ALTO server MUST send a control event (Section 6.3
>> <>)
>> whose "remove" field has the client-ids of those resources."
>> As section 7 defines "Update Stream Service", this paragraph means the
>> ALTO server MUST send a control event in the update stream to notify the
>> client the status of a stream control service request. Why do we want to
>> use a different channel to return the output? Why not return this control
>> event from the response of update stream control service? I feel it will
>> introduce the unnecessary complexity.
>> Can anyone of authors elaborate the reason for this design?
>> Thanks,
>> Jensen