Re: gaps in a tcp flow

Mark Allman <mallman@grc.nasa.gov> Thu, 01 May 2003 02:59 UTC

To: tcp-impl@grc.nasa.gov
From: Mark Allman <mallman@grc.nasa.gov>
Reply-To: raj@cup.hp.com
Subject: Re: gaps in a tcp flow
Organization: BBN Technologies/NASA GRC
Song-of-the-Day: Dead Flowers
Date: Wed, 30 Apr 2003 22:59:26 -0400
Message-Id: <20030501025926.6F5166B2B7@lawyers.ir.bbn.com>
Sender: owner-tcp-impl@grc.nasa.gov
Precedence: bulk
Status: RO
Content-Length: 1327
Lines: 36

 
------- Forwarded Message

Date: Wed, 30 Apr 2003 16:14:16 -0700
From: Rick Jones <rick_jones2@hp.com>
Reply-To: raj@cup.hp.com
Organization: the Unofficial HP
To: tcp-impl@grc.nasa.gov
Subject: Re: gaps in a tcp flow

Murali Bashyam wrote:
> 
> Mark Allman wrote:
> 
> Doesn't this cause  problems for the initial RTT estimate of the
> server ? And in the attached example the delay seems to be negligible
> so it's ok, but if the client is delaying the ACK by 70 ms  to
> piggyback the GET request, it seems like a  variant of stretch ack
> violation.

I'll make the embarassing statement that I'm not familiar with "stretch
ack violation" and so a reference would be really nice.

Apart from that, it doesn't seem all that evil if the initial RTT is a
bit longer than it might be later.  If anything that would seem to be
"conservative" in the sense that it leads to a longer RTO and so less
likely to have a spurrious RTO. On top of that, most stacks start with
an intial RTO for the SYN or the SYN|ACK of something much larger than
the standalone ACK timer anyway.

rick
- -- 
Wisdom Teeth are impacted, people are affected by the effects of events.
these opinions are mine, all mine; HP might not want them anyway... :)
feel free to post, OR email to raj in cup.hp.com  but NOT BOTH...

------- End of Forwarded Message