IETF Logo Mail Archive

Re: [tcpm] TCP Long Options

"Adam Langley" <agl@imperialviolet.org> Mon, 07 July 2008 21:27 UTC

Return-Path: <tcpm-bounces@ietf.org>
X-Original-To: tcpm-archive@megatron.ietf.org
Delivered-To: ietfarch-tcpm-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2C46F28C249; Mon, 7 Jul 2008 14:27:04 -0700 (PDT)
X-Original-To: tcpm@core3.amsl.com
Delivered-To: tcpm@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6C9E028C249 for <tcpm@core3.amsl.com>; Mon, 7 Jul 2008 14:27:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Level:
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mqjDcXPkYBJL for <tcpm@core3.amsl.com>; Mon, 7 Jul 2008 14:27:02 -0700 (PDT)
Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.235]) by core3.amsl.com (Postfix) with ESMTP id A23E928C248 for <tcpm@ietf.org>; Mon, 7 Jul 2008 14:27:02 -0700 (PDT)
Received: by rv-out-0506.google.com with SMTP id b25so2178268rvf.49 for <tcpm@ietf.org>; Mon, 07 Jul 2008 14:27:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references :x-google-sender-auth; bh=LqSVa9HvbQSXtkzV0x3+salyKc+oFD5rOra7gf52fxc=; b=RkHW78go9SZqjSe3lX+FgA1GbwpgkUK9QQS0/139LnS4+WuZboi3c8nP5QnAh5hGEC ob2bZFmGmp6CtKV3oOY153xBFo22xokena21mqeL0qq8pd2RdjpMWwYbzLlVR2dxPXau enIIdjLAGo/AgK3ySTJ5CXtugPa4x78JuP5y4=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=oRA+YEkli+h65gMCs6QWRhiuIpU294P+WfIjxhOGj+mJJZyWY/sl3QSpcHz2xNWyKH F1o45sINqq6CxN7VmzBHEusStSIhs9+sGTPLNv0Al7RasDGPUX8KuBAb4D3tWfRCYd3O BC2c0BingqS8aCKvYBE2QdcWNvA/VnwFa4+sU=
Received: by 10.141.114.19 with SMTP id r19mr2752195rvm.295.1215466025899; Mon, 07 Jul 2008 14:27:05 -0700 (PDT)
Received: by 10.141.37.3 with HTTP; Mon, 7 Jul 2008 14:27:05 -0700 (PDT)
Message-ID: <396556a20807071427l27ec0087ya7d68f321749e36@mail.gmail.com>
Date: Mon, 07 Jul 2008 14:27:05 -0700
From: Adam Langley <agl@imperialviolet.org>
To: Joe Touch <touch@isi.edu>
In-Reply-To: <48728582.5080904@isi.edu>
MIME-Version: 1.0
Content-Disposition: inline
References: <396556a20807010949i6c6c1d16g41c74e2f78414a92@mail.gmail.com> <486A6777.80809@isi.edu> <396556a20807011128v27796016k81204b84e78fc25a@mail.gmail.com> <B5A5E01F9387F4409E67604C0257C71E220E3A@NDJSEVS25A.ndc.nasa.gov> <48728582.5080904@isi.edu>
X-Google-Sender-Auth: 2fdf9a7de9cfa6dc
Cc: tcpm@ietf.org
Subject: Re: [tcpm] TCP Long Options
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: tcpm-bounces@ietf.org
Errors-To: tcpm-bounces@ietf.org

On Mon, Jul 7, 2008 at 2:07 PM, Joe Touch <touch@isi.edu> wrote:
> I'm recalling that no mechanism was ever developed that was backward
> compatible with legacy TCP implementations, i.e., that "did the right thing"
> for SYNs with long options. Doing well for other segments is somewhat moot
> if SYNs cannot be extended, because space is most critical for them.

I don't believe that such a system is actually possible; if anyone has
an idea about this please speak up. One could imagine assuming that
the remote end supports long options and backing off when
retransmitting the SYN frame, but I don't believe such behaviour is
actually reasonable because of the additional latency.


AGL

-- 
Adam Langley agl@imperialviolet.org http://www.imperialviolet.org
_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm

v2.31.3 | Report a Bug | By Email | System Status