[e2e] Reacting to corruption based loss

[rick jones]

>> Why on earth should that have mattered unless perhaps the sending TCP
>> had a broken implementation of Nagle that was going segment by segment
>> rather than send by send?"
> ...When it takes about 32000/1460 pkts to send one block, and the 
> sender's
> window (not easily found & configured in typical stacks) is less than 
> that,
> more than one send window is needed for each block sent.  If the last 
> send
> window needed is odd in pkt count, then the sender is done and 
> awaiting an
> ack, while the receiver is awaiting another pkt (for the ack timer 
> value).  If
> the path is running at a reasonable rate, then this wasted ~100mS 
> every 32k
> block in a mulit-MB transfer adds up to lots of dead time and a 
> significant
> throughput hit.

OK, perhaps I'm being dense, but I still don't see where the TCP specs 
say that the first segment(s) of the next 32KB chunk to be sent 
couldn't be sent while awaiting the ack of that last odd segment.

I thought (I'll avoid saying assume so I don't have to spell it the way 
i was taught as ass-u-me :) that if SMB were request/response, the SMB 
response would have that last odd ACK piggybacked, and even if not, and 
it was back-to-back 32KB sends, there being window into which it could 
send the next 32KB block could start flowing.  Was the SMB/TCP 
combination only allowing one 32KB send to be outstanding at a time, 
and not really making use of sliding window?

In a nutshell, I'm having a hard time seeing where the problem wasn't a 
case of implementation errors.

rick jones
Wisdom teeth are impacted, people are affected by the effects of events