Re: [tcpm] Extending TCP option space

"SCHARF, Michael" <Michael.Scharf@alcatel-lucent.com> Wed, 31 August 2011 14:43 UTC

Return-Path: <Michael.Scharf@alcatel-lucent.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 BEBDB21F8B73 for <tcpm@ietfa.amsl.com>; Wed, 31 Aug 2011 07:43:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.193
X-Spam-Level:
X-Spam-Status: No, score=-6.193 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4]
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 AqYyQJ9A-J4X for <tcpm@ietfa.amsl.com>; Wed, 31 Aug 2011 07:43:15 -0700 (PDT)
Received: from mailrelay2.alcatel.de (mailrelay2.alcatel.de [194.113.59.96]) by ietfa.amsl.com (Postfix) with ESMTP id 07A5C21F8B6C for <tcpm@ietf.org>; Wed, 31 Aug 2011 07:43:14 -0700 (PDT)
Received: from SLFSNX.rcs.alcatel-research.de (slfsn1.rcs.de.alcatel-lucent.com [149.204.60.98]) by mailrelay2.alcatel.de (8.14.3/8.14.3/ICT) with ESMTP id p7VEihtD002402 for <tcpm@ietf.org>; Wed, 31 Aug 2011 16:44:43 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Wed, 31 Aug 2011 16:44:11 +0200
Message-ID: <133D9897FB9C5E4E9DF2779DC91E947C066832A6@SLFSNX.rcs.alcatel-research.de>
In-Reply-To: <9605EAA4-F1C4-4D83-B76E-88C81BFE1555@iki.fi>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [tcpm] Extending TCP option space
Thread-Index: Acxn5eo6vrh10eDiSgikAaYRk604WgABnF5w
References: <9605EAA4-F1C4-4D83-B76E-88C81BFE1555@iki.fi>
From: "SCHARF, Michael" <Michael.Scharf@alcatel-lucent.com>
To: TCP Maintenance and Minor Extensions WG <tcpm@ietf.org>
X-Scanned-By: MIMEDefang 2.69 on 149.204.45.73
Subject: Re: [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 14:43:15 -0000

Hi Pasi,

> 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?

actually, I happened to argue in favor of a) in hallway discussions
during the last IETF meetings. Maybe someone should just start to put
together some text, at least for a)... (And I think it would really make
sense to raise awareness among researchers that TCP option space in SYNs
is a really scarce resource.)

Michael