Subject: Re: window scale option and urgent pointer
From: [email-masked] (Bob Braden)
To: [email-masked], [email-masked], [email-masked], [email-masked]
Cc: [email-masked]
Date: Tue, 17 May 1994 15:15:35 -0700

Dave,

Nice, cogent explanation! "Egad, Watson, elementary!"

Bob

Date: Tue, 17 May 94 16:50:32 CDT
From: [email-masked] (David A. Borman)
To: [email-masked], [email-masked], [email-masked]
Subject: Re:  window scale option and urgent pointer
Cc: [email-masked]
Content-Length: 2651

The question of how does the urgent pointer interact with
expanded windows has been brought up in some private email.
I'm sending my reply to the [email-masked] mailing list, so
that a wider audience can comment on what I am going to say.

I've discussed this issue before, but I don't remember in
what context and with whom I had the discussion.

Problem: What do you do when an Urgent Pointer cannot be
accuratly reflected with the 16 bit offset field in the
TCP header?

First, this is not specific to expanded windows.  What do
you do if the application writes over 64K of data which
has not yet been sent to the other side, and then wants to
set an Urgent Pointer?  It's the same problem.

I will use the term "Urgent Pointer" to mean the sequence
number of the urgent pointer, and "Urgent Offset" to mean
the 16 bit value in the TCP header.  Normally, Seq# + Urgent
Offset = Urgent Pointer.

The key thing to realize is that once you receive a packet
with the URG bit, you go into urgent mode, and you stay in
urgent mode, until you get to the Urgent Pointer.  While
in urgent mode, there can only be one Urgent Pointer, so
if a TCP packet arrives with an Urgent Offset that indicates
a new Urgent Pointer (i.e., later in the sequence space),
then that new value is the Urgent Pointer, and the old value
is forgotten.

The next thing to realize is that the maximum amount of data
that you can have in a single TCP packet is 65495 (64K-1 minus
IP & TCP headers) bytes of data, and the maximum Urgent Offset is
65535.  This means that for any given packet, you can *always*
set the Urgent Offset (and thus the Urgent Pointer) beyond the
end of the data that is contained in that packet.

So, if the Urgent pointer is beyond what can be reflected
in the 16 Urgent Offset field in the TCP header, then you
set the URG bit and put 65535 into that field.  Each successive
packet that is sent will have the URG flag set, and the Urgent
Offset will keep pointing beyond to data that has not
yet been received.  Eventually you'll get within 16 bits
of the Urgent Pointer, and the Urgent Offset will now be
the correct value (which may still be beyond the data in
any given packet), and will keep shrinking as new data
is sent, until you finally send the data that actually
has the urgent pointer, and the urgent offset will then,
and only then, finally point at data within the packet, and
the TCP can finally go out of urgent mode.

In effect, each packet is saying "There is more urgent
data beyond this packet".

Seems like a nice simple solution, so perhaps that is a
good indication that it is the right answer. :-)

			-David Borman, [email-masked]

From: "Stephen C. Pope" <[email-masked]>
Date: Tue, 17 May 1994 10:06:44 -0600
To: [email-masked] (Stevo Bevo-Devo Wise)
Cc: [email-masked]
Subject: Congestion window & slow start threshold calculation
Reply-To: "Stephen C. Pope" <[email-masked]>
Content-Length: 1483

Stevo> I have a question about computing these two values when using RFC1323.

Stevo> I'm using BSD43 Reno base code, and I notice that in tcp_mss() they
Stevo> compute the congestion window and slow start threshold based on the 
Stevo> MSS.

Stevo> Question:  Should this be changed to compute these values based on the
Stevo> datasize (MSS less any protocol options included in each segment)?

Looks like SunOS (or at least my altered copy of it ;-) uses maxseg
(which is your "datasize"), not mss.  Unicos does not make the
distinction, instead decrementing the packet data length for the TCP
options length at the last moment of packet generation, so MSS is used
for all buffer/window size calculations.

When distinguishing between MSS and datasize (say, for determination
of send/receive buffer sizes and such), and given you know that TSopt
will be used (assumed predicate to making datasize < MSS), I suppose
you could go ahead and use datasize for cwnd and slow start... But
then, what do I know?

Of course, the problem with these different implementations is that
you get some nasty fringe effects when a receiver advertises windows
based on datasize but the sender eyes the advertisement from an mss
point of view; the last segment sent in a given window may come up
12-16 bytes short of what it could have been, spelling disaster for
receivers with penalties for not being a multiple of some magic number
such as pagesize (ibm, hp, sgi) or stripe size (cm5).

stephen.

From: [email-masked] (Stevo Bevo-Devo Wise)
To: [email-masked]
Subject: Congestion window & slow start threshold calculation
Date: Tue, 17 May 94 10:04:24 -0600
Content-Length: 493

I have a question about computing these two values when using RFC1323.

I'm using BSD43 Reno base code, and I notice that in tcp_mss() they
compute the congestion window and slow start threshold based on the 
MSS.

Question:  Should this be changed to compute these values based on the
datasize (MSS less any protocol options included in each segment)?

Thanx in advance...

********
Steve Wise	IBM RISC System/6000 Division - Austin, TX.
Internet:	[email-masked]
VNET:		AUSTIN(SWISE)

Date: Sun, 1 May 94 16:32:47 EDT
From: [email-masked] (Andreas Bovopoulos)
To: [email-masked], [email-masked], [email-masked], [email-masked]
Subject: subscribe
Content-Length: 254

Hi,
Could you please add my name in the mailing list?
Thank you very much
Dr. Andreas D. Bovopoulos
Principal Engineer
Chipcom Corporation
118 Turnpike Road
Southborough, MA 01772-1886

tel:(508) 490-5602 
fax:(508) 490-5873 
e-mail:[email-masked]