[tcpm] 64-bit sequence numbers

Jonathan Looney <jtl.ietf@gmail.com> Wed, 15 March 2017 13:17 UTC

Return-Path: <jtl.ietf@gmail.com>
X-Original-To: tcpm@ietfa.amsl.com
Delivered-To: tcpm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 559F6131494 for <tcpm@ietfa.amsl.com>; Wed, 15 Mar 2017 06:17:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.698
X-Spam-Level:
X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 43TmKzdTodFy for <tcpm@ietfa.amsl.com>; Wed, 15 Mar 2017 06:17:09 -0700 (PDT)
Received: from mail-vk0-x22e.google.com (mail-vk0-x22e.google.com [IPv6:2607:f8b0:400c:c05::22e]) (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 82795129C00 for <tcpm@ietf.org>; Wed, 15 Mar 2017 06:17:09 -0700 (PDT)
Received: by mail-vk0-x22e.google.com with SMTP id d188so8184798vka.0 for <tcpm@ietf.org>; Wed, 15 Mar 2017 06:17:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=YSQh6WiCZm3gVxexy5OtZOUxm6LqvWzNtEOfej1N9jc=; b=RyEE04vKApYI6ok+Mqc22EPNSh8xN0bGDn5ev/vRW76UhqaKwg4KlG2QdFU56sfO05 8tC5uGAvOAsrEl0YYSzctKhoGHvpn/UsjF5kpZZ3tRNOwwYqSNNd3oTGO1rIo5nRf8r0 HP8ulRxb0SxvLSnjDvWUdoqunTzhRfzuf8B5eRJX5qGefdayus0R7Ia9WpjaQeuyrFEN i1vIHCypv3273yvZZRhTsGNaxTKCAAHWizYMANBBm7mljL2ezFrQVqSB2+vFIeNA/8mR fAvNX/4ihCSf1w0k16hBKJLplOFZ1S0Ge1ZOs2R/jEo9yF/XvKYZaS5zWJqyJsGYDGO2 2f+Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=YSQh6WiCZm3gVxexy5OtZOUxm6LqvWzNtEOfej1N9jc=; b=CzO1FCcVeP6iybHFkv1AYQMzmrtAu7GvYtX1Ej4mh+1BHqrsuL3I1Od73Tk92Ious2 VfWDnkpy0pe/Rdqb6nt7V1XLLxa40S5QypsMgJ9XqyJqYUK+1Ag7U3vH61x0UtyG2HJ9 aE/5aUm/PzQsq3oYP0DbNbkvAtlxpXW4oxLtespGvlnE2P8KgGTkJN82DjbX5gtv7hR3 zrlV0l0mUwtHwqqeqcLjwF2CKyAroJ56d7L/kp+WrgZWh1Nykm8TnLwJVAgy8hJaprcK 9brFI9bztx7aEZoXvKN6J7JZdZFSPwMy9NBaCufBaGq13RHrc7JsG+s5/End+oZMhdmC iW4Q==
X-Gm-Message-State: AFeK/H10se/oUsM5LRNwMqjIl5nPtDcMQTGM235qVFp6/jwyvRiK/ogJgyDed+YXzgsUXltBSCM2EI5GioG1zg==
X-Received: by 10.31.230.198 with SMTP id d189mr1321674vkh.138.1489583828485; Wed, 15 Mar 2017 06:17:08 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.103.183.69 with HTTP; Wed, 15 Mar 2017 06:17:08 -0700 (PDT)
From: Jonathan Looney <jtl.ietf@gmail.com>
Date: Wed, 15 Mar 2017 09:17:08 -0400
Message-ID: <CAJrujPmZ-H3YfBGpz4D=5K6EH=+XrgN9Hf4Pk3NVgFT47R-7uQ@mail.gmail.com>
To: tcpm@ietf.org
Content-Type: multipart/alternative; boundary="94eb2c092b64f5cda6054ac4c23c"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/fkLK3xYKYbwg3uFGXhkeR-zD044>
Subject: [tcpm] 64-bit sequence numbers
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tcpm/>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 15 Mar 2017 13:17:11 -0000

Hi all,

At the Seoul meeting, we saw two proposals for making TCP perform better on
high-speed networks: increasing the maximum window size to 2**31 bits and
increasing the precision of timestamps to the microsecond or nanosecond
level. As I said in the meeting at Seoul, the combination of these two
proposals led me to believe that we need to begin planning for 64-bit
sequence numbers.

Given that it takes years to rollout new TCP features (especially something
as fundamental as changing sequence numbers), it seems like it is time to
begin thinking about how we will do this.

I submitted the below I-D with a proposal for 64-bit sequence numbers. I'm
sure the proposal isn't perfect. The draft itself highlights some
challenges. I asked the chairs to allocate a few minutes in Chicago to
discuss this topic. Even if we decide to go in a different direction than
this draft, I think it is important that we begin to think about 64-bit
sequence numbers.

Jonathan

---------- Forwarded message ----------
From: <internet-drafts@ietf.org>
Date: Mon, Mar 13, 2017 at 7:32 PM
Subject: New Version Notification for draft-looney-tcpm-64-bit-seqnos-00.txt
To: Jonathan Looney <jtl.ietf@gmail.com>



A new version of I-D, draft-looney-tcpm-64-bit-seqnos-00.txt
has been successfully submitted by Jonathan Looney and posted to the
IETF repository.

Name:           draft-looney-tcpm-64-bit-seqnos
Revision:       00
Title:          64-bit Sequence Numbers for TCP
Document date:  2017-03-13
Group:          Individual Submission
Pages:          17
URL:            https://www.ietf.org/internet-drafts/draft-looney-tcpm-64-
bit-seqnos-00.txt
Status:         https://datatracker.ietf.org/doc/draft-looney-tcpm-64-bit-
seqnos/
Htmlized:       https://tools.ietf.org/html/draft-looney-tcpm-64-bit-
seqnos-00


Abstract:
   This draft updates RFC 793 to allow the optional use of 64-bit
   sequence numbers.  It also updates other standards to support the
   extended sequence number space.




Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat