Subject: slow-start bit

From: [email-masked] (Sam Manthorpe)
Date: Fri, 14 May 1999 21:15:33 -0700 (PDT)

Hi,

Is there any reason why it wouldn't be a good idea to use one of the
free bits in the TCP header as a `slow-start' bit to enable a sender
to indicate to the receiver that it is sending the first packet
of a slow-start phase?  This would enable the receiver to ACK
immediately rather than delay the ACK, which can cause an unnecessary
200ms delay in some scenarios.

Thanks,
Sam.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Sam Manthorpe, SGI.  tel: (650)933-2856 fax: (650)932-2856  [email-masked]

---

From: "David S. Miller" <[email-masked]>
Date: Sat, 15 May 1999 05:25:42 -0700

From: [email-masked] (Sam Manthorpe)
   Date: Fri, 14 May 1999 21:15:33 -0700 (PDT)

   Is there any reason why it wouldn't be a good idea to use one of
   the free bits in the TCP header as a `slow-start' bit to enable a
   sender to indicate to the receiver that it is sending the first
   packet of a slow-start phase?

I would first want to test to see if other implementations will not
have interoperability problems.  The bits are marked as reserved now,
but who knows what some TCP stack in a printer will do if they are not
zero.

Later,
David S. Miller
[email-masked]

---

From: Kevin Fall <[email-masked]>
Date: Sat, 15 May 1999 09:49:51 -0700

>
> From:  "Eric A. Hall" <[email-masked]>
> To:    Sam Manthorpe <[email-masked]>
> cc:    [email-masked]
> Subject: Re: slow-start bit
> Date:  Sat, 15 May 1999 09:29:47 PDT
>
> 
> > of a slow-start phase?
> I read this as "what are the mechanisms for doing circuit-setup messages
> with TCP, and is it a good idea?" Right now, the only circuit-setup
> message we have is the MSS option. I suppose that it would be possible
> to add a flag that indicated that slow start was in effect, but why stop
> there? Shouldn't we also add flags for congestion avoidance, current
> retransmission timer, and so forth? All of these things will affect the
> bi-directional exchange of data in some manner.
> 
> One could define a set of bits or options that passed this info back and
> forth.

RFC2481 deals with this to some extent.  Basically, a sender can
indicate it has "reacted to congestion" in some way.  This is useful
in the scenario where a forward-traveling packet experiences ECN,
the receiver needs to reflect this fact back in an ACK but the ACK
may get lost, meaning the receiver actually echoes it back in each
ack until it sees the sender's "reacted to congestion" bit.
{thats the idea in a nutshell anyhow}.

- K

---

From: "Eric A. Hall" <[email-masked]>
Date: Sat, 15 May 1999 09:29:47 -0700

One could define a set of bits or options that passed this info back and
forth. This would let the sender say "I'm at multiple four with slow
start" and "my retransmission timer is currently set to 28 ms" for
example. Or, going even further, it would be possible for one end-point
to request certain values from the other end-point, like "please use
28ms". It's early on a saturday morning and I'm just going through mail
so I can't really think of a situation where that would be useful, but
if it needs to be advertised then it can probably benefit from being set
as well. Probably.

There are lots of issues here of course. First and foremost is legacy
support, which is the big thorn for all new options. It would take a
really long time to update all of the existing products to use any new
data in the header. Another issue is that lots of products out there
don't do slow start, so passing the data would be irrelevant.

I guess my feeling is that the broader issue of circuit-negotiation
should definitely be addressed, but that it is sufficiently complex that
it should probably be tabled for TCPng whenever that gets started. Would
it make life easier or harder, and who would be affected by these
messages (developers? users? admins?).

I also think its time to start the work on TCPng.

-- 
Eric A. Hall                                            [email-masked]
+1-650-685-0557                                    http://www.ehsco.com

---

From: John Hanley <[email-masked]>
Date: Sat, 15 May 1999 11:05:38 -0700

You propose modifying sender behavior so that cooperating receivers
could improve throughput.  Could we achieve the same thing purely within
the receiver?

Going to one end of the spectrum, we might grumble "delayed ACK increases
the complexity of TCP dynamics and sometimes Does The Wrong Thing," and so
we modify the receiver to never delay ACK.  OK, clearly not what we want;
under some conditions delayed ACK is winning.

So let's think about those conditions: low packet loss, high throughput,
typically corresponds to LAN latencies or at least large open window.
How about just causing the receiver to never delay ACK if more than
`threshold' time has elapsed since the last ACK sent by the receiver?
Certainly `threshold' would be < 200ms; I'm thinking around 100ms or 50ms.
If it is much less than sender's RTO interval, then receiver would effectively
suppress delayed ACK *without* the sender signaling that in an option bit.

	Cheers,
	JH

---

From: [email-masked] (Sam Manthorpe)
Date: Sat, 15 May 1999 19:08:03 -0700 (PDT)

> could improve throughput.  Could we achieve the same thing purely within

I'm not sure.  It would certainly be desirable but I haven't been able
to think of a _simple_ way of doing it and that is an important criteria
for me.

> Certainly `threshold' would be < 200ms; I'm thinking around 100ms or 50ms.

Wouldn't this be bad for slow, high latency connections?   This would
effectively switch off delayed-ack altogether since it wouldn't be
too hard to have a connection where the inter-packet-arrival time at
the receiver is greater than 50ms.

> suppress delayed ACK *without* the sender signaling that in an option bit.

How can the receiver know the sender's RTO?  It could estimate it, but I
can't think of any simple mechanism that would give a reliable enough
estimate.  Time between acking byte x and receiving byte x+1 wouldn't
work because the receiver can't be sure that the sender's congestion
window is such that sending byte x+1 requires byte x being acked.

I would want to avoid any excessive complexity in the TCP stack since
this is bad for low network latency, high bandwidth situations where
performance is CPU and memory-access speed bound.

The simplicity of the `slow-start-bit' appeals to me.  I don't know
how big of an issue the implementations using the reserved bits that
David brough up is.  This would also be an issue for ECN then.

Cheers,
Sam.

---

From: "Jamal Hadi Salim" <[email-masked]>
Date: Sat, 15 May 1999 22:18:04 -0400 (EDT)

> but who knows what some TCP stack in a printer will do if they are not

ECN (RFC2481), for example, tests by setting two of the bits during the
SYN exchange. If the remote end responds with the same bit set then it is
highly likely that it is lying. You can use a combination of such tricks.
In the established state, it would be very tricky to catch
any misuse of the reserved bits.

cheers,
jamal

Computing Technology Labs (CTL), Nortel

---

From: [email-masked] (Sam Manthorpe)
Date: Sat, 15 May 1999 19:11:39 -0700 (PDT)

> but who knows what some TCP stack in a printer will do if they are not

This is impossible to thoroughly test prior to software release, isn't it.  
I would introduce a systuneable to enable/disable the feature,
default on, so you could switch it off if your LAN has hosts with
broken stacks.

This would also be an issue for RFC 2481.

Cheers,
Sam.

---

From: Jamshid Mahdavi <[email-masked]>
Date: 17 May 1999 10:11:56 -0700

> 200ms delay in some scenarios.

Note that RFC2414 allows 2, 3, or 4 packets on initial slowstart,
which alleviates the specific problem you are concerned with.  Some of
the other concerns which people brought up might still be interesting
to consider.  The increased initial window doesn't apply after a
timeout, but generally you've already been waiting for ~ 1 sec on a
timeout anyway, so saving the 200 msec in that case may not be as
important to you.

--J

---

From: Kacheong Poon <[email-masked]>
Date: Mon, 17 May 1999 12:24:40 -0700 (PDT)

> 200ms delay in some scenarios.

First of all, I think most stacks now default to have a larger initial
window according to RFC2414.  But let's assume otherwise.  TCP does slow
start in 3 cases, initial slow start, slow start after idle, and slow
start after a retransmission timeout.

In the first case, if a receiver acks immediately for the first segment,
there will be no delay ack.  In the third case, it is quite probable that
the first segment will be out of order, unless all the segments in the
last window are lost.  The receiver should ack immediately.  So I guess the
slow start bit is most useful in the second case.  But because of an
implementation artifact (use last receive time to do idle check), most stacks
do not perform slow start after idle in many cases, like HTTP requests.  Again
there will be no delay ack.

It seems to me that the slow start bit may not be very useful in the context
of the problem you described above, even with stacks which do not support
RFC2414.  Well, I assume that most stacks ack immediatley at least for the
first segment and slow start after timeout is likely to trigger an immediate
ack...  There can be other uses of slow start bit.  But I do not think it is a
good idea to use it to solve the delay ack problem you described.  Larger
initial window is better solution.

							K. Poon.
							[email-masked]