At 01:29 PM 7/11/01, Ayers, Michael wrote:
>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
Message Posted at:
http://www.groupstudy.com/form/read.php?f=7&i=12001&t=11703
--------------------------------------------------
FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
