NICE!!!!!
See below.........
"Priscilla Oppenheimer" wrote in message
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
> 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.
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.
Message Posted at:
http://www.groupstudy.com/form/read.php?f=7&i=11866&t=11703
--------------------------------------------------
FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
