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.
I think you see fewer ACKs because packets are whipping by so fast on a
high-speed network that TCP's delayed ACK timer doesn't go off until many
segments are received. TCP actually schedules a delayed ACK for each
received segment. After a timer elapses, TCP ACKs everything received so
far. It sends the most recently scheduled ACK and cancels the others.
>i think sending the window size is still used.
The receiver's window size is still sent in every packet.
>also dont forget that sometimes ICMP is used to control certain things.
If you're talking about source quench, that is obsolete. See RFC 1812. I
can't think of anything else in ICMP that would be relevant?
>of course you've read the rfcs, the authoritative source.
>why are you asking questions here?
>if you dont understand, it's time to scroll to the RFC credits, and email
>the writer =)
I wonder if that would be considered kosher. I think Howard has implied
that it is kosher to e-mail the RFC author, but perhaps only if you are
another protocol developer. An e-mail from one of us lowly certification
candidate types might go unacknowledged (at best) or might elicit a NAK. ;-)
In this case, however, the writer, W. Richard Stevens, passed away. May he
RIP. I checked his book, TCP/IP Illustrated, though. In both the book and
RFC 2001, he talks about a common strategy for acknowledgements where the
recipient ACKs every other segment.
TCP schedules a delayed ACK for each segment, as mentioned. Typically, if
more than one delayed ACK is scheduled, the software sends an ACK,
acknowledging all the bytes received so far.
It doesn't sound like that's what you saw, however. Perhaps the
every-other-segment ACK doesn't apply on modern networks. Since 1997 when
the RFC was written, things have changed a lot!
Priscilla
>-----Original Message-----
>From: Brett Johnson [mailto:[EMAIL PROTECTED]]
>Sent: Tuesday, July 10, 2001 9:26 AM
>To: [EMAIL PROTECTED]
>Subject: TCP Ack [7:11703]
>
>
>After reading a few RFCs(2001 is one of them)and Internetworking with TCP/IP
>by Comer I am still having trouble figuring what causes the receiver to send
>an ack. From what I read in RFC 2001, the old versions of TCP/IP the sender
>would send the window size then expect an ack, but now they use a congestion
>window based on the segment size, but what would cause the receiver to send
>an ack. Is it based on some setting inside the receiver, ie response time,
>packet size... I did a little test and I found that when the sender
>receiver were on a high speed connection the receiver acked far less then
>when they were on a slower connection. The difference between the two was
>substantial almost a 12 to 1 ratio. In the first test the two devices were
>on different segments connected through an IP switch, in the second test the
>devices were on two different segments connected by a AIX server acting like
>a router. Thanks for the help.
>
>Brett
________________________
Priscilla Oppenheimer
http://www.priscilla.com
Message Posted at:
http://www.groupstudy.com/form/read.php?f=7&i=11819&t=11703
--------------------------------------------------
FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
