Subject: RE: slow-start bit

From: "Spencer Dawkins" <[email-masked]>
Date: Sat, 15 May 1999 22:22:20 -0500

The I-D
http://search.ietf.org/internet-drafts/draft-montenegro-pilc-ltn-01.txt
(soon to be 02, but hasn't made it onto the web site yet) talks about some
aspects of larger initial windows and ACK-first/ACK-every strategies in
4.3.1 and 4.3.2. The target environment for this draft isn't just HTTP, but
we were thinking about HTTP, and it bothered us that the default was to do a
delayed-ACK timeout at the server if the HTTP request is bigger than a
single segment, followed by a delayed-ACK timeout at the client if the HTTP
response is bigger than a single segment - as it almost certainly would be.

We were pretty sure that ACK-first was safe, because it doesn't increase the
traffic level on the network (you send the ACK immediately instead of
delaying it, but it's the same ACK).

This draft is being discussed in the PILC working group (although it won't
be a WG output), but we would love to hear your thoughts as well.

Spencer 

> -----Original Message-----
> From:	David S. Miller [SMTP:[email-masked]]
> Sent:	Saturday, May 15, 1999 7:26 AM
> To:	[email-masked]
> Cc:	[email-masked]
> Subject:	Re: slow-start bit
> 
>    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: Neal Cardwell <[email-masked]>
Date: Sun, 16 May 1999 14:49:46 -0700 (PDT)

On a related note, delayed ACKs can hurt performance even after the first
few RTTs of slow start. Whether in congestion avoidance or slow start, a
sender that uses any Vegas-like bandwidth estimation scheme incoporating
delay as a congestion signal will work much better if either
  o the receiver does not delay ACKs
  o the receiver tells the sender (with, say, a TCP option) by how much an
    ACK was delayed

Currently, Vegas and other bandwidth estimation schemes are forced to jump
through hoops to filter out the effect of delayed ACKs because they
introduce delays that look similar to queuing delay.

neal