OK, last try on my post
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
(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
Yes. You got it. Follow it through with what happens as data is
transmitted, acked, retransmitted possibly, as window sizes shrink and
expand, etc.
Priscilla
>( 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.
________________________
Priscilla Oppenheimer
http://www.priscilla.com
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=12025&t=11703
--------------------------------------------------
FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
