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

"Y. Richard Yang" <yry@cs.yale.edu> Fri, 02 March 2018 23:30 UTC

Return-Path: <yang.r.yang@gmail.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 A5CF41242EA for <alto@ietfa.amsl.com>; Fri, 2 Mar 2018 15:30:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 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] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 Ne5DP37MamCI for <alto@ietfa.amsl.com>; Fri, 2 Mar 2018 15:30:27 -0800 (PST)
Received: from mail-lf0-x236.google.com (mail-lf0-x236.google.com [IPv6:2a00:1450:4010:c07::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 107181200C1 for <alto@ietf.org>; Fri, 2 Mar 2018 15:30:27 -0800 (PST)
Received: by mail-lf0-x236.google.com with SMTP id q69so15561501lfi.10 for <alto@ietf.org>; Fri, 02 Mar 2018 15:30:26 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=pjLT5kYmf9S46JXdn+VnZ0LCdi5Cjf9eEXe8gW3PtFQ=; b=TF8sw6AXCJJZKUK/a8nlALK5kCNQKwvnFqnPFf1aHu6DRvqLn3xFo4X+VXT51vZtXO FaobtuQP5/dRIiMyDxZC27I67jBfLdkcfBmZxsNZRF65eaFy4WGXq2E16KQSBq5AZ05M CTJ9BqLb/C8xWQbUIIITa1hgwkCG0eRisZZo9pEFhKdFh1qViRCGdqScIpOFcC33PuX1 wmshehleXkuiAw2WwD84n7b8FJgw+VsO/insGImqYFDN5Q7Fqf/za+Yk7DrgcY0LH7bk XZI4yIGYVmGI9iCerCiiSisrHW78UMMsV0nruXjYdLodRK+J7CDz9CJAX8juKK7y0zSu NfqQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=pjLT5kYmf9S46JXdn+VnZ0LCdi5Cjf9eEXe8gW3PtFQ=; b=e73PEBIuPqfheHHJRwUm1C6eYwSIBWb7cEUhHm7ZwZupfTuKLy/Y7BIRVlWjIwHBLA 2nSrMMB3g0k0nwuBzykW2pLPGgyAbsUt012B1mzu/yjukvukXRoTrajvzhtt0OXe5svy TPYzthQEDAInEOjKT/2hVi7hol3wdkAkW0WN6jtnMZIzWLRRdzerhoGEtEoCPxnUG+d/ fojnRCoKZzj6mYYaJMl3iuvhO1YptJqoW2l4wVpJXm5fPGKqeeERDCpjGAlEbKsJen+S WPwgcyinZVLOjVhzarAB4kdVXHIk6q5rfk04yd7zMQYIrKJjUIHbvQ4EiMUrmE+FOuXe whpw==
X-Gm-Message-State: AElRT7HKNoUoIbR/i7iCmfQ/08U8PQ0ho6HQdojV62PMO2lCxZJYw/TB gfkRiZU1yLpsdt1UmqXGjBXGQwijew91lkuldC67OQ==
X-Google-Smtp-Source: AG47ELs42hYk3D87Oc/TrHOchUq2A/ELbqHRfs1fKR4DBCNigT9WcFhsNVqEUtIPa8dkDFu/11gs/Ksct8on2+FemHU=
X-Received: by 10.25.89.12 with SMTP id n12mr5332197lfb.10.1520033425275; Fri, 02 Mar 2018 15:30:25 -0800 (PST)
MIME-Version: 1.0
Sender: yang.r.yang@gmail.com
Received: by 10.46.50.26 with HTTP; Fri, 2 Mar 2018 15:30:24 -0800 (PST)
In-Reply-To: <CAAbpuyp_JjsOugb838xXk5r-ft26nJbNuGzDHKZG=Dk2oUzPcw@mail.gmail.com>
References: <CAAbpuyp_JjsOugb838xXk5r-ft26nJbNuGzDHKZG=Dk2oUzPcw@mail.gmail.com>
From: "Y. Richard Yang" <yry@cs.yale.edu>
Date: Fri, 2 Mar 2018 18:30:24 -0500
X-Google-Sender-Auth: V5t7RbG5KI8VtElSZZRDoXEtOHY
Message-ID: <CANUuoLpmn0FPL3552QJVEBBKK22L-SsXej82Vead2W3M0FbG+A@mail.gmail.com>
To: Jensen Zhang <jingxuan.n.zhang@gmail.com>
Cc: Wendy Roome <wendy@wdroome.com>, IETF ALTO <alto@ietf.org>
Content-Type: multipart/alternative; boundary="001a11412e185c43d10566765c48"
Archived-At: <https://mailarchive.ietf.org/arch/msg/alto/Y1zOuiXyLYSWMsaWS4gU10oNybs>
Subject: Re: [alto] Issue about incr-updates-sse update stream control design
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: Fri, 02 Mar 2018 23:30:30 -0000

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 <jingxuan.n.zhang@gmail.com>
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
> <https://tools.ietf.org/html/draft-ietf-alto-incr-update-sse-09#section-8>),
> the ALTO server MUST send a control event (Section 6.3
> <https://tools.ietf.org/html/draft-ietf-alto-incr-update-sse-09#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
>



-- 
-- 
 =====================================
| Y. Richard Yang <yry@cs.yale.edu>   |
| Professor of Computer Science       |
| http://www.cs.yale.edu/~yry/        |
 =====================================