IETF Logo Mail Archive

Re: [Spud] Connect and ACK Bits: Why?

Joe Touch <touch@isi.edu> Mon, 13 July 2015 17:45 UTC

Return-Path: <touch@isi.edu>
X-Original-To: spud@ietfa.amsl.com
Delivered-To: spud@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 238951B2CB5 for <spud@ietfa.amsl.com>; Mon, 13 Jul 2015 10:45:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.61
X-Spam-Level:
X-Spam-Status: No, score=-6.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, 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 et-ljMnQK6kY for <spud@ietfa.amsl.com>; Mon, 13 Jul 2015 10:45:40 -0700 (PDT)
Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3980C1B2C8B for <spud@ietf.org>; Mon, 13 Jul 2015 10:45:40 -0700 (PDT)
Received: from [128.9.160.211] (mul.isi.edu [128.9.160.211]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id t6DHjKoH022741 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 13 Jul 2015 10:45:21 -0700 (PDT)
Message-ID: <55A3F930.3040105@isi.edu>
Date: Mon, 13 Jul 2015 10:45:20 -0700
From: Joe Touch <touch@isi.edu>
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
To: Christian Huitema <huitema@microsoft.com>, =?UTF-8?B?TWlyamEgS8O8aGxl?= =?UTF-8?B?d2luZA==?= <mirja.kuehlewind@tik.ee.ethz.ch>, Jacob Chappell <chappellind@gmail.com>
References: <CANJ8QndAWK1ErRsUNAUHkA00aA5xzFsaQHiArCaN9jr64qCSnQ@mail.gmail.com> <FD304957-E34A-4CA5-B05A-3394D9062F1D@tik.ee.ethz.ch> <DM2PR0301MB06551595B03037418CD24D75A89C0@DM2PR0301MB0655.namprd03.prod.outlook.com>
In-Reply-To: <DM2PR0301MB06551595B03037418CD24D75A89C0@DM2PR0301MB0655.namprd03.prod.outlook.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
Archived-At: <http://mailarchive.ietf.org/arch/msg/spud/g3sYCH1VylhYOiIsH9MrZ8sjnZk>
Cc: "spud@ietf.org" <spud@ietf.org>, touch@isi.edu
Subject: Re: [Spud] Connect and ACK Bits: Why?
X-BeenThere: spud@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Session Protocol Underneath Datagrams <spud.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/spud>, <mailto:spud-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/spud/>
List-Post: <mailto:spud@ietf.org>
List-Help: <mailto:spud-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/spud>, <mailto:spud-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 13 Jul 2015 17:45:41 -0000


On 7/13/2015 10:19 AM, Christian Huitema wrote:
...
> We have to account for possible route changes, without the endpoint
> being aware. That means that the first packet visible on the new path
> will not be the first packet end-to-end. This is a strong argument for
> NOT relying on an explicit "Start" flag.

It doesn't matter whether that state change is signaled by an explicit
START flag or not.

If you have state that persists between messages, then you have to know
when that state is established and which messages it affects, and the
result is the same.

Joe

v2.8.7 | Report a Bug | By Email