Just a few more picky comments! ;-)
At 02:09 PM 7/11/01, Ayers, Michael wrote:
>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
>( As the recipient receives segments, it
>will start ACKing every 2 segments received by stating which one it expects
>to receive next.
Technically, it ACKs bytes and specifies the next byte it expects.
It works out to 2 segments on some networks, but it's based on the timer.
In Brett's example, because of the high speed that segments were
transmitted, it worked out to numerous segments.
>(the second part of our flow control). If it doesn't
>receive the second in a series of 2 after the delayed ACK timer expires, it
>ACKs the 1 segment. The sender will time out the missing segment and
>retransmit (error correction).
A retransmit might not be necessary if the recipient does finally ACK the
second set of bytes (segment).
>When the recipient receives the retransmitted
>segment, it will ACK that segment, and resume normal processing. The sender
>has not sent any more segments because it sent the window size worth of
>data, and received no ACKs due to the retransmit timeout.
The sender sent the congestion window size worth of data. If there had been
no congestion, it could pick up the pace and at some point send as much
data as is advertised in the recipient's receive window.
RFC 2001 says this: "Each time an ACK is received, the congestion window is
increased by one segment. The sender can transmit up to the minimum of the
congestion window and the advertised window. The congestion window is flow
control imposed by the sender, while the advertised window is flow control
imposed by the receiver. The former is based on the sender's assessment of
perceived network congestion; the latter is related to the amount of
available buffer space at the receiver for this connection."
The advertised window is what I call the receive window. A station
advertises it with every packet.
People (not you) think they know TCP because they can describe the 3-way
handshake (usually incorrectly!) Of course, it's more complicated than it
seems! ;-)
Priscilla
>Congested Networks can throw a packet away during congestion. This forces
>the timeouts I just mentioned, i.e. decongestant. Bursty FTP traffic can
>be slowed by just dropping a packet here and there during the file transfer.
>
>The default window size on most machines is good for slower connections, but
>can be inefficient a high speed world. When I had my Sprint Broadband
>installed, the only mod to my PC they made was to set the receive window to
>48k. This allows asymmetrical connections (DSL, Cable, Broadband) to
>receive a lot faster, and be ACKing the first segments received just as the
>sender is sending the last packets of the 48k window. If the high speed
>sender had to stop and wait for ACKs from the low speed receiver (download
>being faster than upload), the file transfer would not be any better than a
>dialup user.
>
>My $9.99 :)
>
>
> -----Original Message-----
>From: Priscilla Oppenheimer [mailto:[EMAIL PROTECTED]]
>Sent: Wednesday, July 11, 2001 11:53 AM
>To: [EMAIL PROTECTED]
>Subject: RE: TCP Ack [7:11703]
>
>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
>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=12038&t=11703
--------------------------------------------------
FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
