Re: gaps in a tcp flow
Murali Bashyam <mbashyam@cisco.com> Thu, 01 May 2003 16:03 UTC
Message-ID: <3EB14538.5A99B417@cisco.com>
Date: Thu, 01 May 2003 09:03:04 -0700
From: Murali Bashyam <mbashyam@cisco.com>
X-Mailer: Mozilla 4.79 [en]C-CCK-MCD (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: raj@cup.hp.com
Cc: tcp-impl@grc.nasa.gov
Subject: Re: gaps in a tcp flow
References: <20030501025926.6F5166B2B7@lawyers.ir.bbn.com>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: owner-tcp-impl@grc.nasa.gov
Precedence: bulk
Status: RO
Content-Length: 2293
Lines: 64
Mark Allman wrote: > > ------- 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. Refer to RFC2525 for this. Stretch ack is basically an ack that gets delayed by a huge amount either by the network or the receiver and ends up acknowledging a whole lot of segments as opposed to normal behaviour of 2 segments, resulting in bursty traffic, and RTT jitter. > > > 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. The initial RTO of 3s is only a conservative estimate in the absence of that ACK, so SYN retransmission is not an issue. I agree the higher 'RTT' estimate on the server is only brief and in this case it does not affect the connection throughput in an adverse manner, since with the HTTP request-response transaction, the RTT should quickly converge in a few iterations when the ACK of the HTTP response starts coming back, to a much smaller and correct one. Piggybacking GET requests with the ACK of a syn|ack is a common feature, but i haven't seen the ACK delayed by as much as 70 ms. Murali > > > 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
- gaps in a tcp flow kunchanl
- Re: gaps in a tcp flow Murali Bashyam
- Re: gaps in a tcp flow karen mclane thomas
- Re: gaps in a tcp flow Mark Allman
- Re: gaps in a tcp flow Murali Bashyam
- Re: gaps in a tcp flow Mark Allman
- Re: gaps in a tcp flow Murali Bashyam
- Re: gaps in a tcp flow Lloyd Wood