OK I'm reposting because my original got cut off.
See if I have it here.
The receive window is a buffer. It is specified in bytes. During the 3 way
handshake, each side tells the other it's buffer size. This is the start of
our flow control.
During the 3 way handshake, Each side also specifies a sequence number. The
other will reply with an ACK requesting THE NEXT sequence number it expects
from the sender..
As data is transferred, the sender sets a retransmit timer for each segment
sent out. As the recipient receives segments, it sets a delayed ACK timer
( its own receive window size, based on its own buffer space. It used to be
> that a recipient ACKed when it had received the number of bytes in its
> receive window. But that caused problems. So we now have slow start and
> congestion avoidance enhancements, which I think is what you are
describing
> below.
This is good..... I didn't realize this......
> Be careful not to confuse send windows (which are based on the other
side's
> receive window), receive windows, and the newer congestion windows.
> According to RFC 2001, the increase in the number of segments the sender
> sends "provides an exponential growth, although it is not exactly
> exponential because the receiver may delay its ACKs, typically sending one
> ACK for every two segments that it receives." Other than that, the RFC
> doesn't say when to send ACKs, which is why the original poster asked the
> question. It's a good question.
You're correct, and I should be more careful with my terminology....
segments are what TCP deals with.... I'm wondering how you could get away
with writing an RFC that doesn't specify something as critical as sending
ACKs.... =)
> I think you mean bytes. He certainly didn't see that many packets without
> an ACK! Plus TCP sequences and ACKs bytes, not packets.
My numbers (32768, 65536, etc) were just "made up" for sake of example....
but your statement confuses me.... ACKs bytes? Since this is all TCP, and
the segments are what receive the sequence numbers, wouldn't TCP send an ACK
saying "I've received sequence (or up to sequence) number "? Why
would the ACK acknowledge the actual number of bytes?
I've read RFC 2001 and it's cool.... I need to read it closer and get a
better understanding of slow start, congestion avoidance, fast retransmit,
and fast recovery....
Mike W.
Privileged/Confidential Information may be contained in this message or
attachments hereto. Please advise immediately if you or your employer do
not consent to Internet email for messages of this kind. Opinions,
conclusions and other information in this message that do not relate to the
official business of this company shall be understood as neither given nor
endorsed by it.
Privileged/Confidential Information may be contained in this message or
attachments hereto. Please advise immediately if you or your employer do
not consent to Internet email for messages of this kind. Opinions,
conclusions and other information in this message that do not relate to the
official business of this company shall be understood as neither given nor
endorsed by it.
Message Posted at:
http://www.groupstudy.com/form/read.php?f=7&i=11980&t=11703
--------------------------------------------------
FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
