At 06:38 PM 7/10/01, Michael L. Williams wrote:
>Comments below......
>
>"Priscilla Oppenheimer" wrote in message
>[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
> > At 10:01 AM 7/10/01, Peter Slow wrote:
> > >i think this is because the window size is allowed to get much larger
> > >befrore something gets dropped on a higer speed segment.
> >
> > Would a TCP recipient know it was on a high-speed segment, though? A
>sender
> > might have some idea because it tracks congestion, but not the recipient.
>
>IT seems to me, tho, that the receipient only sends an ack based on the
>window size it is told to use by the sender.
A recipient is not told to use a window size by the sender. Each side has
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.
Be careful not to confuse send windows (which are based on the other side's
receive window), receive windows, and the newer congestion windows.
> Therefore, on a high speed
>connection, the send doubles it's windows size (and therefore doubles the
That's the congestion window.
>amount of packets that can be recieved by the receiver before an ACK) until
>it hits congestion (the speed limit).
>
>For instance, starting at one (S = Sender, R = Receiver)
>
>S -> pack1 -> R
>S pack2 -> R
>S -> pack3 -> R
>S pack4 -> R
>S -> pack5 -> R
>S -> pack6 -> R
>S -> pack7 -> R
>S and so on......
>
>Since TCP doubles its window size after each successfully ACK, the receiver
>only needs to ack after a "window full" of packets are received (assuming
>they all get there).
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.
>When the TCP windows gets so large to overwhelm the
>link (anywhere in the path), it halves the window size and congestion
>avoidance takes over, etc.... so it would make total sense on a high speed
>link that you'd see many less acks because the TCP window size may be
>bouncing between 32768 and 65536 packets per ACK instead of 128 and 256
>packets per ACK.
I think you mean bytes. He certainly didn't see that many packets without
an ACK! Plus TCP sequences and ACKs bytes, not packets.
Priscilla
>My 2 cents......
>
>Mike W.
________________________
Priscilla Oppenheimer
http://www.priscilla.com
Message Posted at:
http://www.groupstudy.com/form/read.php?f=7&i=11851&t=11703
--------------------------------------------------
FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
