Re: Window Scale option

braden@isi.edu Tue, 05 May 1998 19:13 UTC

Delivery-Date: Tue, 05 May 1998 15:13:38 -0400
Return-Path: tcplw-relay@services.BSDI.COM
Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id PAA12519 for <ietf-archive@ietf.org>; Tue, 5 May 1998 15:13:37 -0400 (EDT)
Received: from services.BSDI.COM (services.BSDI.COM [205.230.225.19]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id PAA09430 for <IETF-archive@cnri.reston.va.us>; Tue, 5 May 1998 15:16:03 -0400 (EDT)
Received: (from daemon@localhost) by services.BSDI.COM (8.8.7/8.8.8) id NAA08831 for tcplw-list@bsdi.com; Tue, 5 May 1998 13:13:20 -0600 (MDT)
Received: from mailfilter.bsdi.com (mailfilter.BSDI.COM [205.230.225.21]) by services.BSDI.COM (8.8.7/8.8.8) with ESMTP id NAA08828 for <tcplw@bsdi.com>; Tue, 5 May 1998 13:13:19 -0600 (MDT)
From: braden@isi.edu
Received: from zephyr.isi.edu (zephyr.isi.edu [128.9.160.160]) by mailfilter.bsdi.com (BSDI-MF 1.0) with ESMTP id NAA28081 for <tcplw@bsdi.com> env-from (braden@ISI.EDU); Tue, 5 May 1998 13:12:15 -0600 (MDT)
Received: from gra.isi.edu (gra.isi.edu [128.9.160.133]) by zephyr.isi.edu (8.8.7/8.8.6) with SMTP id MAA13992; Tue, 5 May 1998 12:13:05 -0700 (PDT)
Date: Tue, 05 May 1998 12:12:53 -0700
Posted-Date: Tue, 5 May 1998 12:12:53 -0700
Message-Id: <199805051912.AA21669@gra.isi.edu>
Received: by gra.isi.edu (5.65c/4.0.3-6) id <AA21669>; Tue, 5 May 1998 12:12:53 -0700
To: tcplw@bsdi.com, mathis@psc.edu
Subject: Re: Window Scale option
Cc: braden@isi.edu

  *> 
  *> The SYN only restriction is far more problematic for the timestamp
  *> option than it is for than the window scale option.
  *> 
  *> For example, if you have a laptop with a radio modem and a 100bT
  *> interface, you are likely to find that you are either wasting the
  *> skinny link with uncompressible timestamps, or underfilling the LAN
  *> because you didn't negotiate timestamps.  Although you could implement
  *> per-route or per-interface flags to control TCPLW features, the real
  *> problem is the pervasive 1323 mindset that new options must never
  *> appear after the SYN-ACK.

Matt,

I would not call it a "mindset", I would call it concern about
(possible lack of) interoperability.  However, the issue of breaking
some TCPs with options on non-SYN segments may well be less of a
concern than it was 8 years ago.

In any case, I see no reason why TCPs cannot exchange timestamp options
n the SYN exchange to enable the feature, then suspend sending
time stamps whenever they want (e.g., when the connection throughput
falls below some threshold?)  Am I missing something?

Bob