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

"Y. Richard Yang" <yry@cs.yale.edu> Mon, 05 March 2018 02:23 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 BFCE3124C27 for <alto@ietfa.amsl.com>; Sun, 4 Mar 2018 18:23:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
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: 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 OYi8hHUMjfm5 for <alto@ietfa.amsl.com>; Sun, 4 Mar 2018 18:23:52 -0800 (PST)
Received: from mail-lf0-x22b.google.com (mail-lf0-x22b.google.com [IPv6:2a00:1450:4010:c07::22b]) (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 2327A124B0A for <alto@ietf.org>; Sun, 4 Mar 2018 18:23:52 -0800 (PST)
Received: by mail-lf0-x22b.google.com with SMTP id 70so20869649lfw.2 for <alto@ietf.org>; Sun, 04 Mar 2018 18:23:52 -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=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; 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=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 10.46.7.80 with SMTP id i16mr8405981ljd.78.1520216630290; Sun, 04 Mar 2018 18:23:50 -0800 (PST)
MIME-Version: 1.0
Sender: yang.r.yang@gmail.com
Received: by 10.46.50.26 with HTTP; Sun, 4 Mar 2018 18:23:49 -0800 (PST)
In-Reply-To: <BLUPR02MB12028DC2BEE31A2164FC0AE3B5C40@BLUPR02MB1202.namprd02.prod.outlook.com>
References: <CAAbpuyp_JjsOugb838xXk5r-ft26nJbNuGzDHKZG=Dk2oUzPcw@mail.gmail.com> <CANUuoLpmn0FPL3552QJVEBBKK22L-SsXej82Vead2W3M0FbG+A@mail.gmail.com> <BLUPR02MB12028DC2BEE31A2164FC0AE3B5C40@BLUPR02MB1202.namprd02.prod.outlook.com>
From: "Y. Richard Yang" <yry@cs.yale.edu>
Date: Sun, 4 Mar 2018 21:23:49 -0500
X-Google-Sender-Auth: rIo3uQJDgtsIQirNzLJChGO351s
Message-ID: <CANUuoLrhsfj1HDsBP27msP9uLJ+p2TmMbkKwjW6fPerc4WimxA@mail.gmail.com>
To: Dawn Chan <dawn_chen_f@hotmail.com>
Cc: Jensen Zhang <jingxuan.n.zhang@gmail.com>, "alto@ietf.org" <alto@ietf.org>
Content-Type: multipart/alternative; boundary="f403045f73703aef960566a1042d"
Archived-At: <https://mailarchive.ietf.org/arch/msg/alto/nGJOTWsJ_mNavFjs7Bh27ksnT8s>
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: 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 <dawn_chen_f@hotmail.com> 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?

Richard

>
> Dawn
>
> On 3 Mar 2018, at 7:30 AM, Y. Richard Yang <yry@cs.yale.edu> 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 <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
>>
>
>