RE: Connected mode draft and retransmit implosion

At 12:30 AM 8/25/2004, Vivek Kashyap wrote:
      On Mon, 23 Aug 2004, Michael Krause wrote:

      > At 06:25 PM 8/13/2004, Fab Tillier wrote:
      > > > From: bill [mailto:[email protected]]
      > > > Sent: Friday, August 13, 2004 5:59 PM
      > > >
      > > > Yes, that is exactly the problem... Both layers retransmitting
      at the
      > > > same time
      > >
      > >While both layers issue retransmits at the same time, the packets
      on the
      > >wire maintain their order.  The first packet sent will be
      delivered first,
      > >with the second queued up behind.  The data will not get
      interleaved.  There
      > >is no way for the retransmitted packet to get delivered first.
      > >
      > > >
      > > > And possibly not recovering for quite a while
      > >
      > >IB recovery is pretty much binary - if an RC QP exceeds its retry
      limit, it
      > >will transition to the error state.  At that point, all processing
      of the
      > >send queue stops and the consumer gets an error completion and an
      async
      > >error notification for that QP.
      > >
      > >I still don't see the harm in TCP retransmitting while IB is also
      > >retransmitting aside from inefficiencies.
      >
      > Given this is a RC QP, the WR are processed in order and must
      complete in
      > order to make forward progress.  As such, the consumer which is
      posting WR
      > can post new or duplicate packets and the underlying QP will not
      see these
      > until it completes the current WR.  As such, IB retransmission and
      consumer
      > retransmission algorithms are orthogonal to one another in all
      respects
      > sans perhaps doing a poor job configuring the associated IB
      retransmission
      > timers as well as the arbitration policies within the fabric such
      that the
      > consumer falls into its retransmission algorithm too often.
      >
      > Mike

      Yes, TCP will not see out of order packets since the underlying layer
      delivers
      in order, reliable data. Also, TCP timers are likely to be much
      longer than
      the RC timers. Therefore, it is quite likely that RC will retransmit
      multiple
      times and recover by the time TCP timers expire.

      As an aside, IPoIB over connected mode is not limited to RC, it
      includes UC
      too. Also, it is IP (which implies UDP, SCTP etc.) over RC or UC.

Hence why I did not state a particular consumer type only that it is
posting to a connected QP.  Whether RC or UC, the processing order remains
the same.  The only difference is the lack of IB ACK as well as Send Credit
management for UC but for this discussion, they are essentially the same
from the consumer's perspective.

Mike_


<VK>
 True... RC/UC are largely indistinuishable in ipoib context.
Vivek
<VK>


______________________________________________
IPoverIB mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/ipoverib

_______________________________________________
IPoverIB mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/ipoverib