[e2e] Reacting to corruption based loss

[Cannara]

Assumptions are great dullers of thought, Rick, aren't they?!  
"
2) > > b) the fact that transfers
> > required many blocks of odd numbers of pkts meant the the Ack Timer at
> > the
> > receiver was expiring on every block, waiting (~100mS) for the magical
> > even-numbered last pkt in the block, which never came.
> 
> 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.  Now, it wouldn't be so bad, if common stacks allowed easy
identification & setting of parameters, like send window, ack timer, delayed
ack, etc.  But, because the Internet folks have never effectively addressed
source and release control, we don't even know if a given stacke we come
across has those knobs available to turn.  That, in itself, is an unacceptable
problem for a public utility, or any product affecting so many every day. 
Imagine if your new TV hadn't been required to meet standards.

Now for:
"> with a send window of only 6 packets, and a synchronous
> request/response protocol like SMB (IIRC) it would seem that fast rtx
> wouldn't have had much of a chance anyway
"
I'll be happy to send the actual packets.  SMB is fully capable of giving any
transport, including TCP, many, many kbytes to send from one buffer.  The
reason Microsoft blocked it into about 32kB chunks is known to them alone. 
But, the proper Fast Retrans implementation in TCPs at both ends would indeed
have improved things a lot.  Again, this falls directly into the pit of
uncontrolled stack releases.

Alex


rick jones wrote:
> 
> On Jun 28, 2005, at 11:35 PM, Cannara wrote:
> >
> > Now, if you were a network manager for a major corporation, would you
> > rush to
> > fix a physical problem that generated less than 1% errors, if your
> > boss &
> > users were complaining about mysterious slowdowns many times larger?
> > 0.4%
> > wasn't even enough to trigger an alert on their management consoles.
> > You'd
> > certainly be looking for bigger fish.  Well, TCP's algorithms create a
> > bigger
> > fish -- talk about Henny Penny.  :]
> >
> > The files were transferred in many 34kB SMB blocks, which required
> > something
> > like 23 server pkts per.  The NT servers had a send window of about 6
> > pkts
> > (uSoft later increased that to about 12).  All interfaces were
> > 100Mb/s, except
> > the T3 and a couple of T1s, depending on path.  RTT was about 70mS for
> > all
> > paths.
> >
> > Thankfully, the Sniffer traces also showed exactly what the TCPs at
> > both ends
> > were doing, despite Fast Retransmit, SACK, etc.: a) the typical,
> > default
> > timeouts were knocking the heck out of throughput;
> 
> with a send window of only 6 packets, and a synchronous
> request/response protocol like SMB (IIRC) it would seem that fast rtx
> wouldn't have had much of a chance anyway
> 
> > b) the fact that transfers
> > required many blocks of odd numbers of pkts meant the the Ack Timer at
> > the
> > receiver was expiring on every block, waiting (~100mS) for the magical
> > even-numbered last pkt in the block, which never came.
> 
> 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?
> 
> rick jones
> Wisdom teeth are impacted, people are affected by the effects of events