🚀 go-pugleaf

"Randy S." wrote:
> 
> James Knott wrote:
> 
> > A while ago, when John first posted that link, I read the
> > article.  One thing I found puzzling, was the formula used
> > implied a larger data packet would worsen the situation,
> > even though it would require fewer acks.  I posted a note
> > here to John about that, but he didn't reply to my question
> > on it.  If the data packets were, for example 20 times the
> > size of the acks, you should theoretically be fine with a
> > 20:1 down/up ratio.
> 
> You have to look at typical data streams.  The MAX ratio of data packet to Ack is 23:1,
> because an Ack is 64 bytes and a max size Ethernet Packet is 1500 bytes, and of course
> you'll average significantly less than that..  It doesn't matter anyways, because the TCP
> receive window is set to send Acks based on the number of bytes received, not the number
> of packets.  The TCP receive window can be set as low as 8K or as high as 128K, but
> typically it is set to 32 or 64K for high bandwidth home connections.

My understanding was that the receiving computer would ack
up to the highest received consecutive position in the data
stream and that it may ack on receipt of any packet. i.e. if
one packet is delayed or lost, it will ack the position of
the data in the last packet prior to the missing one, even
though it may have received other packets beyond the missing
one.  Receipt of that missing packet will then cause the ack
of all the consecutive received data beyond it. The
receiving end will also attempt to ack on each packet
received and not wait until a few packets have been
received.

Also, the ratio I used was merely a convenient example, not
any claim to specific sizes.

This still leaves open my original question, about the
formula used in that document John referred to, which
appeared to show a larger data packet would worsen the
situation vs a small one.

Here's the relavent text from that link.

   "If the reverse bottleneck link has deep queues so that
ACKs do not 
   get dropped on the reverse path, then performance is a
strong 
   function of the normalized bandwidth ratio, k, defined in
[LMS97]. k 
   is the ratio of the raw bandwidths divided by the ratio
of the 
   packet sizes used in the two directions. For example, for
a 10 Mbps 
   forward channel and a 50 Kbps reverse channel, the raw
bandwidth 
   ratio is 200. With 1000-byte data packets and 40-byte
ACKs, the 
   ratio of the packet sizes is 25. This implies that k is
200/25 = 8. 
   Thus, if the receiver acknowledges more frequently than
one ACK 
   every k = 8 data packets, the reverse bottleneck link
will get 
   saturated before the forward bottleneck link does,
limiting the 
   throughput in the forward direction."

Notice that variable k for the packet size (they shouldn't
have used the same letter for the 2 values).  It's the ratio
of data/ack packet size.  As you go to larger packets, k
gets bigger. i.e. if you had a 2000 byte packet, k becomes
16.  This implies that even though you're sending twice as
much data, you can experience this slow down with half as
many acks as before. i.e. sending 1 in 16, rather than 1 in
8.  Perhaps I'm reading it wrong, but those numbers just
don't add up.  If you were to double the packet size, you
should be able to move twice as much data for the same
number of acks.  Please note, I'm not saying the problem
doesn't exist, but rather the calculations appear flawed.

  

-- 
Replies sent via e-mail to this address will be promptly
ignored.
To reply, replace everything to the left of "@" with
"james.knott".