Re: [remote protocol] support for disabling packet acknowledgement

[Paul Koning <Paul_Koning@dell.com>]

>>>>> "Sandra" == Sandra Loosemore <sandra@codesourcery.com> writes:

 Sandra> Paul Koning wrote:
 >>>>>>> "Sandra" == Sandra Loosemore <sandra@codesourcery.com>
 >>>>>>> writes:
 >>
 Sandra> You'll note the documentation says turning off acks may be
 Sandra> desirable to reduce communication overhead *or* "for other
 Sandra> reasons".  In fact, it is the "other reasons" that motivated
 Sandra> this patch.  We are working on designing the extensions to
 Sandra> the remote protocol to support nonstop mode, and we realized
 Sandra> that we simply cannot do it in combination with using +/-
 Sandra> acks on the asynchronous responses.  If we need a reliable
 Sandra> transport layer to support nonstop mode, we might as well
 Sandra> turn the acks off completely instead of dealing with the
 Sandra> extra complexity of trying to design the nonstop protocol
 Sandra> around them.
 >>  Ok, so does that mean the nonstop mode features won't work unless
 >> the remote protocol is layered on TCP?  Given that a lot of the
 >> time the remote link is simply a UART serial link, is there an
 >> issue here?

 Sandra> Probably so, but the +/- acks are not the way to solve it.
 Sandra> :-(

 Sandra> Our internal discussion on that issue was getting more and
 Sandra> more complicated, to the point where I could not even follow
 Sandra> what the exact problem was.  ...

 Sandra> There's current practice (the existing Apple implementation)
 Sandra> to support disabling +/- acks and it seems useful as a
 Sandra> performance hack for TCP connections independently of the
 Sandra> nonstop extensions, so why not formalize it?

Let me see if I understand this right.

1. +/- ACKs are fine for the clasis (without non-stop) remote
   protocol.

2. ACKs are needed if the underlying transport isn't a reliable 
   transport (for example a raw UART).  They aren't needed if the
   underlying transport is TCP or equivalent.

3. +/- ACKs are not good enough for non-stop mode.  (It's not clear to
   me why -- is it because there may need to be more than one packet
   in flight?  An explanation of what exactly is wrong would be
   helpful to understand how to fix the issue.)

and finally

4. The proposal is to have a way to turn off +/-ACKs and this will be 
   used for non-stop mode.

The implication is that the non-stop mode design abandons support for
non-TCP transports.  This doesn't seem like a good thing.  I would
argue you need to identify why +/- ACKs aren't good enough, and
propose a replacement that is good enough.  With that replacement you
have a way to add the non-stop mode.  If the overhead of that
replacement is significant in some plausible use case, you could then
add a way to turn it off for the case where TCP is used end to end.

By the way, note that "target remote host:port" does NOT mean that you
have TCP end to end.  You may have TCP to a terminal server and raw
UART the rest of the way, so you still need ACKs (of one kind or
another). 

	  paul