Re: draft-ietf-tcpimpl-prob-04.txt

alan@lxorguk.ukuu.org.uk (Alan Cox) Fri, 07 August 1998 18:47 UTC

Return-Path: <owner-tcp-impl@relay.engr.sgi.com>
Message-Id: <m0z4rYC-000aNFC@the-village.bc.nu>
From: alan@lxorguk.ukuu.org.uk
Subject: Re: draft-ietf-tcpimpl-prob-04.txt
To: vern@ee.lbl.gov
Date: Fri, 07 Aug 1998 19:47:40 +0100
Cc: alan@lxorguk.ukuu.org.uk, tcp-impl@cthulhu.engr.sgi.com
In-Reply-To: <199808071844.LAA04985@daffy.ee.lbl.gov> from "Vern Paxson" at Aug 7, 98 11:44:39 am
Content-Type: text
Sender: owner-tcp-impl@relay.engr.sgi.com
Precedence: bulk
Status: RO
Content-Length: 788
Lines: 19

> > 	Failing to clear reserved bits. At least one OS turns around
> > 	received frames in some cases. It assumes the reserved bits were
> > 	clear when they may not be.
> 
> If the bits are reserved, but not must-be-zero, then it seems a bit hard to
> fault the OS.  Its peer is fiddling with bits that aren't supposed to be
> fiddled with, and it's just (inadvertantly) cooperating with that.
> 
> If they're MBZ, though, then I agree it's a bug.

The TCP RFC seems to think the reserved bits must be zero. Arguably the OS is 
behaving validly since the received frame wasnt valid tcp either but I dont 
think its 'expected behaviour ;)'

Ironically there other scheme using TOS upper bits also broke as we do
ToS reflection (ie you connect with bulk data you get bulk data back)

Alan

draft-ietf-tcpimpl-prob-04.txt Vern Paxson
Re: draft-ietf-tcpimpl-prob-04.txt Alan Cox
Re: draft-ietf-tcpimpl-prob-04.txt Vern Paxson
Re: draft-ietf-tcpimpl-prob-04.txt Alan Cox