[tcpm] Extending TCP option space

Pasi Sarolahti <pasi.sarolahti@iki.fi> Wed, 31 August 2011 13:55 UTC

Return-Path: <pasi.sarolahti@iki.fi>
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 2EBB521F8BB5 for <tcpm@ietfa.amsl.com>; Wed, 31 Aug 2011 06:55:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level:
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TTtkpDlAcJIL for <tcpm@ietfa.amsl.com>; Wed, 31 Aug 2011 06:55:35 -0700 (PDT)
Received: from smtp.netlab.hut.fi (luuri.netlab.hut.fi [130.233.154.177]) by ietfa.amsl.com (Postfix) with ESMTP id 2AE0221F8BB1 for <tcpm@ietf.org>; Wed, 31 Aug 2011 06:55:34 -0700 (PDT)
Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp.netlab.hut.fi (Postfix) with ESMTP id 994D81E052 for <tcpm@ietf.org>; Wed, 31 Aug 2011 16:57:04 +0300 (EEST)
X-Virus-Scanned: by amavisd-new at luuri.netlab.hut.fi
Received: from smtp.netlab.hut.fi ([127.0.0.1]) by localhost (luuri.netlab.hut.fi [127.0.0.1]) (amavisd-new, port 10024) with LMTP id O0jq33R48JUz for <tcpm@ietf.org>; Wed, 31 Aug 2011 16:57:00 +0300 (EEST)
Received: from pc75.netlab.hut.fi (pc75.netlab.hut.fi [130.233.154.75]) by smtp.netlab.hut.fi (Postfix) with ESMTPSA id 98F791E04E for <tcpm@ietf.org>; Wed, 31 Aug 2011 16:57:00 +0300 (EEST)
From: Pasi Sarolahti <pasi.sarolahti@iki.fi>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Wed, 31 Aug 2011 16:57:00 +0300
Message-Id: <9605EAA4-F1C4-4D83-B76E-88C81BFE1555@iki.fi>
To: tcpm@ietf.org
Mime-Version: 1.0 (Apple Message framework v1084)
X-Mailer: Apple Mail (2.1084)
Subject: [tcpm] Extending TCP option space
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.12
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: <http://www.ietf.org/mail-archive/web/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, 31 Aug 2011 13:55:36 -0000

Hi,

TCP's option space has been under increasing demand recently, with new option-space hungry extensions such as MPTCP, and some recent ideas in the research domain. In the past there have been some discussion about mechanisms to extend the option space, and an extension option was proposed in draft-eddy-tcp-loo, but since then these efforts have died down. I'm wondering if there would be any interest in the tcpm community to resume this work.

I recall that re-segmenting middleboxes were mentioned as one potential problem for such extension, and there might be other problems. Nevertheless, I would find it useful, if there was an RFC that a) documented the known problems with option space extension; and b) defined an option format and assigned the needed type codes, to enable experimentations with larger than 40-byte option space.

Thoughts?

- Pasi