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

Dawn Chan <dawn_chen_f@hotmail.com> Fri, 09 March 2018 11:31 UTC

Return-Path: <dawn_chen_f@hotmail.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 769E712D574 for <alto@ietfa.amsl.com>; Fri, 9 Mar 2018 03:31:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.124
X-Spam-Level:
X-Spam-Status: No, score=-0.124 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FORGED_HOTMAIL_RCVD2=0.874, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=hotmail.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 IlZIs1AXgADM for <alto@ietfa.amsl.com>; Fri, 9 Mar 2018 03:31:26 -0800 (PST)
Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-oln040092000086.outbound.protection.outlook.com [40.92.0.86]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 91D6412426E for <alto@ietf.org>; Fri, 9 Mar 2018 03:31:26 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hotmail.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=wCgE4EF4zRRXxrZ6EQZf9KJ8MmtfoRPWYfhTgee864w=; b=b/NDTcPerw1IelhREKqEVGctCNeSlDdvhtjKAoi8tAsUCO8k44vCXbbQC1+8NWoxcwoYZETZ8hg8nYzKvzTuldfFY1zNrzJzi8gCbichQlHhgsQRuS2z4jTlkn3y6LaueT9/hj6p2ljxKWxh0LPhcPaN2wEzRwSuBFUWZK5nlfPm1eqoCOpO/tt9JVq5H+1qDEXhVGFvZdNv3oRR7eKkb91wAK4tqiVpREek8mbmSenLq7270spC0DENXYQ+t+F5Nx4hrNrfukM3b16FLZSVc3OC3rs6Sd1jl0wAo+SCSW8H3m0WQs0BaaAhpkMp9twazcVcF0Z8cvheYEvaGUXD7A==
Received: from SN1NAM01FT021.eop-nam01.prod.protection.outlook.com (10.152.64.54) by SN1NAM01HT107.eop-nam01.prod.protection.outlook.com (10.152.65.247) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.20.527.18; Fri, 9 Mar 2018 11:31:25 +0000
Received: from BLUPR02MB1202.namprd02.prod.outlook.com (10.152.64.54) by SN1NAM01FT021.mail.protection.outlook.com (10.152.65.191) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.20.527.18 via Frontend Transport; Fri, 9 Mar 2018 11:31:25 +0000
Received: from BLUPR02MB1202.namprd02.prod.outlook.com ([fe80::f5e6:68f8:39a:2dae]) by BLUPR02MB1202.namprd02.prod.outlook.com ([fe80::f5e6:68f8:39a:2dae%14]) with mapi id 15.20.0548.018; Fri, 9 Mar 2018 11:31:25 +0000
From: Dawn Chan <dawn_chen_f@hotmail.com>
To: "Y. Richard Yang" <yry@cs.yale.edu>
CC: "alto@ietf.org" <alto@ietf.org>
Thread-Topic: [alto] Issue about incr-updates-sse update stream control design
Thread-Index: AQHTsj8x4DwCmmDLBEmRZf/L6Yq0c6O9mGEAgADhcgCAAnOsgIAG4j+A
Date: Fri, 9 Mar 2018 11:31:25 +0000
Message-ID: <BLUPR02MB1202E4D7ED7D829E73A01019B5DE0@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> <CANUuoLrhsfj1HDsBP27msP9uLJ+p2TmMbkKwjW6fPerc4WimxA@mail.gmail.com>
In-Reply-To: <CANUuoLrhsfj1HDsBP27msP9uLJ+p2TmMbkKwjW6fPerc4WimxA@mail.gmail.com>
Accept-Language: en-US, zh-CN
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-incomingtopheadermarker: OriginalChecksum:C44D9134E4FC54F446D693DDBD33D9B73542A5A3D62CC9B63DC4A96F716AD8E5; UpperCasedChecksum:366AA88789C7B117D98FEA9F2F2269B34A7BAFB41573456393C4AD4C34C3E3A4; SizeAsReceived:7414; Count:47
x-ms-exchange-messagesentrepresentingtype: 1
x-tmn: [VGSMrvrgJKpnd7Ou9PBncFdE1EQBRKMF]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; SN1NAM01HT107; 6:TZpodMyrLMgPWq7apc8YgAEWKt5ifxty5oSiIiLgIR9pZ6+qLtq5N6hyeZ+7h5i3wTCJdOPH9pm5F+91U2mE/q6tyGk4EA3hoa16k4tO2BaifrhPcb4oUdtyDsNBn7350rBo67m8fylOo9EsnF5rETFt60QHEFtokS/GTXPept1TjHV3oYaiDhC707H1S+lnUttJ1nE0HfT4/gmSQBzA/8hd2FvG08w8KTTAq2JQ3DXMVBUPBOypnTPEksuMaaSGvQkuR7alwkaCaUpQGzsw81qvBweTtEiCiUJBtCEc2v4xjbibThUlZbT72e2jZxT2QokbEGW14FmIN8pM4L7I+5FqwdaciAllBNCWRmggSS4=; 5:MFyynwKgOA4mrDS4Pv1D6qxp+HzI6ts66n3SNJhRy+LrFtiawCh3S9jq9AzBFN0R0TqoxOHXrA+wA9sJXaJilrFrQCf5X/XVtGr7ORQ2VMQr+azSFyVSX0iTSjgO43E8pPyNElG++uikVVt/iDNe9hk1VCbKbredUPoYw4m6rM8=; 24:ixQ7vqbwr+yCupOlFFhriw6TLyUnZzNohyEaIEfHlse7HrYEE41AL1lO51+d4Dla6WT7vnEq4mJKsJNI4FW06EiXOov5ayOkvDHRU8CMYrk=; 7:/LXgYp58XGFGXqNfXgmkUEgX9v6WFtVfiHPaZhMwj35xaEPWl5B0UkmsV+OeKEqHyAopjQfxhbXEK3BVS+TQfZLmSrqtAvhpD3utvHs3cwJsXUcC8C1qS2lBPaQslEvPc6com90E0Vn2Tc50TXmpE9278wjzKtUiZBdUyHrnwsK/+Wpv+r06sDLECU1OpLOPTejm/9/S13l+P6g3BWxqUDoyL9e06z/QnwjxWSxCDHddrhtSv2C7i672HBtm4167
x-incomingheadercount: 47
x-eopattributedmessage: 0
x-microsoft-antispam: UriScan:(189865482101610); BCL:0; PCL:0; RULEID:(7020095)(201702061078)(5061506573)(5061507331)(1603103135)(2017031320274)(2017031324274)(2017031323274)(2017031322404)(1603101448)(1601125374)(1701031045); SRVR:SN1NAM01HT107;
x-ms-traffictypediagnostic: SN1NAM01HT107:
x-ms-office365-filtering-correlation-id: 6a568dce-f0e8-47cd-5b91-08d585b149a7
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(444000031); SRVR:SN1NAM01HT107; BCL:0; PCL:0; RULEID:; SRVR:SN1NAM01HT107;
x-forefront-prvs: 0606BBEB39
x-forefront-antispam-report: SFV:NSPM; SFS:(7070007)(98901004); DIR:OUT; SFP:1901; SCL:1; SRVR:SN1NAM01HT107; H:BLUPR02MB1202.namprd02.prod.outlook.com; FPR:; SPF:None; LANG:;
x-microsoft-antispam-message-info: G5ShNJg9enb4QeJyGKrouEtmuW5hlgp5cpGwDj6EJ7RKQ7NeSf06TBzPYGmbas8oZ5uPzP2F9pOqtZ5IcVm+f9Z7DbnqlvOKmtPo6a2mlIYD82J8d/KSWwl3SaU+LKV06zaJ2U2tliouHo7LOASlMlvEHJeEVmY+wLHGHm2IOTL53TscBgtJ9/502BwJhKwf
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_BLUPR02MB1202E4D7ED7D829E73A01019B5DE0BLUPR02MB1202namp_"
MIME-Version: 1.0
X-OriginatorOrg: hotmail.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 6a568dce-f0e8-47cd-5b91-08d585b149a7
X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Mar 2018 11:31:25.1392 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Internet
X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1NAM01HT107
Archived-At: <https://mailarchive.ietf.org/arch/msg/alto/3e-wZ9YKbQ9WA2GNGo6Uq2WUPe4>
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, 09 Mar 2018 11:31:29 -0000

Hi Richard,

Sorry for the late reply. I do not think “stream-id” is a good name to distinguish the request for different resources in one update stream. I failed to find a better name at the moment. Do other members have a better one?

Dawn
On 5 Mar 2018, at 10:23 AM, Y. Richard Yang <yry@cs.yale.edu<mailto:yry@cs.yale.edu>> wrote:

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<mailto: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<mailto: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<mailto: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>)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