Re: Window Scale option

Matt Mathis <mathis@psc.edu> Wed, 06 May 1998 18:14 UTC

Delivery-Date: Wed, 06 May 1998 14:16:53 -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 OAA17097 for <ietf-archive@ietf.org>; Wed, 6 May 1998 14:14:13 -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 OAA13864 for <IETF-archive@cnri.reston.va.us>; Wed, 6 May 1998 14:16:35 -0400 (EDT)
Received: (from daemon@localhost) by services.BSDI.COM (8.8.7/8.8.8) id MAA09483 for tcplw-list@bsdi.com; Wed, 6 May 1998 12:11:04 -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 MAA09473 for <tcplw@bsdi.com>; Wed, 6 May 1998 12:10:59 -0600 (MDT)
Received: from zippy.psc.edu (zippy.psc.edu [128.182.61.149]) by mailfilter.bsdi.com (BSDI-MF 1.0) with ESMTP id LAA08238 for <tcplw@bsdi.com> env-from (mathis@psc.edu); Wed, 6 May 1998 11:04:57 -0600 (MDT)
Received: (from mathis@localhost) by zippy.psc.edu (8.8.5/8.8.2) id NAA11815; Wed, 6 May 1998 13:05:58 -0400 (EDT)
To: Jason Thorpe <thorpej@nas.nasa.gov>
Cc: tcplw@bsdi.com
Subject: Re: Window Scale option
References: <199805060721.AAA29254@lestat.nas.nasa.gov>
From: Matt Mathis <mathis@psc.edu>
Date: Wed, 06 May 1998 13:05:58 -0400
In-Reply-To: Jason Thorpe's message of Wed, 06 May 1998 00:21:36 -0700
Message-ID: <9j4sz3tjm1.fsf@zippy.psc.edu>
Lines: 21
X-Mailer: Gnus v5.3/Emacs 19.34

>Unfortunately, there's still the concern of intermediate agents (e.g.
>routers, terminal servers, etc.) completely losing if they encounter
>non-SYN packets with options.

We ran into this as well, and your diagnosis isn't quite correct.
There are a number of VJ header compression implementations that
completely and totally botch *all* TCP or IP options.  But under VJ
compression some packets such as SYNs and retransmissions (data which
is non-contigious with the prior segment) are not compressed, so they
make it through.  These implementations are just busted because they
are incorrectly compressing packets containing options.

This situation is precisely what started me thinking about initiating
timestamps later in the connection.  These paths are the very ones
that benefit the least and can least afford the overhead of
timestamps.  Under 1323, the TCP has to know in advance of the SYNACK
if timestamps are a gain or loss, and negotiate accordingly.  This is
way too early, long before TCP has had any opportunity to measure
anything useful about the path.

--MM--