Re: [alto] New Incremental Update draft

Wendy Roome <w.roome@alcatel-lucent.com> Thu, 01 October 2015 15:53 UTC

Return-Path: <w.roome@alcatel-lucent.com>
X-Original-To: alto@ietfa.amsl.com
Delivered-To: alto@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAC6B1B2D96 for <alto@ietfa.amsl.com>; Thu, 1 Oct 2015 08:53:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.908
X-Spam-Level:
X-Spam-Status: No, score=-6.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 ocExcVzJM_z0 for <alto@ietfa.amsl.com>; Thu, 1 Oct 2015 08:53:46 -0700 (PDT)
Received: from smtp-fr.alcatel-lucent.com (fr-hpgre-esg-01.alcatel-lucent.com [135.245.210.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E69B1B2D79 for <alto@ietf.org>; Thu, 1 Oct 2015 08:53:45 -0700 (PDT)
Received: from us70tusmtp1.zam.alcatel-lucent.com (unknown [135.5.2.63]) by Websense Email Security Gateway with ESMTPS id 6A6D2347BC181; Thu, 1 Oct 2015 15:53:40 +0000 (GMT)
Received: from umail.lucent.com (umail.ndc.lucent.com [135.3.40.61]) by us70tusmtp1.zam.alcatel-lucent.com (GMO) with ESMTP id t91FreAK014042 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 1 Oct 2015 15:53:41 GMT
Received: from [135.222.152.71] (wdr-i7mbp2.mh.lucent.com [135.222.152.71]) by umail.lucent.com (8.13.8/TPES) with ESMTP id t91FrbXI029813; Thu, 1 Oct 2015 10:53:39 -0500 (CDT)
User-Agent: Microsoft-MacOutlook/14.5.5.150821
Date: Thu, 01 Oct 2015 11:53:40 -0400
From: Wendy Roome <w.roome@alcatel-lucent.com>
To: Hans Seidel <hseidel@benocs.com>, "Y. Richard Yang" <yry@cs.yale.edu>
Message-ID: <D232C62E.51667F%w.roome@alcatel-lucent.com>
Thread-Topic: [alto] New Incremental Update draft
References: <D2302448.504B98%w.roome@alcatel-lucent.com> <CANUuoLpK7f3Y3=N6dxSv5vD3cyKE9OjSwKa+D7ctA9fU0fbqkA@mail.gmail.com> <560D4722.5080402@benocs.com>
In-Reply-To: <560D4722.5080402@benocs.com>
Mime-version: 1.0
Content-type: multipart/alternative; boundary="B_3526545224_65213472"
Archived-At: <http://mailarchive.ietf.org/arch/msg/alto/peGfjZ4_s1GXsKx5hlEhQX_CIK0>
Cc: "alto@ietf.org" <alto@ietf.org>
Subject: Re: [alto] New Incremental Update draft
X-BeenThere: alto@ietf.org
X-Mailman-Version: 2.1.15
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: Thu, 01 Oct 2015 15:53:48 -0000

Hans,

Thanks for pointing that out!  First, I assumed they were exclusive: a
request can have start-updates or stop-updates, but not both. But the draft
does not say that. My implementation does not support both in one request,
but does not return an error if a request does. (My server just ignores the
stop-updates field. My culpa!)

But I just realized there is a use for having both in one request. Suppose a
client wants to stop a previous update-stream, and replace it with a new
stream. Combining both in the same request is more efficient. On the other
hand, is that going to happen often enough to matter?

To complicate things, a request with start-updates, stream-id and
stop-updates is ambiguous. The stop-updates part is clear. The ambiguity is
for the new resources in start-updates. Should the server return updates for
those on the new tcp connection? Or should the server add the start-updates
resources to the *other* stream - - the one with the stream-id?

I see several ways to fix that:

1. Say that start-updates & stop-updates are mutually exclusive. That is, a
request has start-updates, or stop-updates and stream-id, but no other
combination. And say the server must return an error if the client violates
that rule.

2. Allow both in one request. But then we have to decide whether the
start-updates resources are to be added to the existing stream, or to be
returned in a new stream.

3. Define two separate requests: start-new-update-stream and
modify-existing-update-stream. They would have different parameter types,
and hence different accepts media-types. That is unambiguous, and is very
general, and would allow a client to add resources to an existing update
stream. But that approach is more complicated, and I do not know if the
extra complication is worth it.

What do the rest of you think?  My vote is for #1, just to keep it simple.

- Wendy Roome


From:  Hans Seidel <hseidel@benocs.com>
Date:  Thu, October 1, 2015 at 10:45
To:  "Y. Richard Yang" <yry@cs.yale.edu>, Wendy Roome
<w.roome@alcatel-lucent.com>
Cc:  "alto@ietf.org" <alto@ietf.org>
Subject:  Re: [alto] New Incremental Update draft

Wendy, Richard,

great work.

One question that came up while reading:

1. Is it allowed to use "start-updates" and "stop-updates" in one HTTP
request? I found nothing specific that neither supports nor contradicts
that. 
    Intuitively, I would say no, it is not allowed to have both in one
request but I am not entirely convinced.

Hans