Subject: [manet] DLEP Credit Windowing synchronization issue

From: "Wiggins, David - 0665 - MITLL" <[email-masked]>
Date: Fri, 8 Jul 2016 19:02:54 +0000

I think I see a problem in the Credit Windowing extension draft.
In a nutshell, the way that credit window synchronization is specified
will probably cause destinations to endlessly cycle up and down.

The text at issue is in section 9.2 (draft 4):

   Upon receipt of a Credit Window Status data item, an implementation
   SHOULD compare its own credit counts with that of the originator.  If
   the receiver of Credit Window Status detects that the local credit
   counts are not synchronized with the originator, the receiving
   implementation MAY either: o Attempt resynchronization using an
   additional Credit Grant, if applicable, or o Issue a DLEP Destination
   Down message, to clear credit counts on the session.

Let's say that an implementation does send periodic Destination Updates
containing Credit Window Status data items, as is suggested a bit further
down in the draft.  Furthermore, let's pretend that the sender is able to
fill in the credit counts that are current at the instant the update
message is put on the wire.  There will still be some delay, maybe just a
few milliseconds, before the DLEP peer receives and processes the update
message.  During that time, additional data traffic might have been sent,
which would alter the credit counts on both sides, but the update message
will still have the snapshot taken when it was sent.  If there is a steady
stream of data traffic, this could be quite likely to occur.  So the
receiving peer's credit counts will not match the ones in the message.

I interpret the draft text "counts are not synchronized" to mean "counts
are not exactly equal."  Assuming additional data traffic was sent while
the update was in flight (as described above), the counts on the receiving
side will be lower than those in the update message.  So the draft's first
remedy, "attempt resynchronization using an additional Credit Grant,"
doesn't make sense because the sender already appears to have more credits
than it should (and credit grants can't be negative).  The only choice
left is to Down the destination.  Presumably it will come back up
eventually, only to have it all happen again.

This could possibly be solved by having a margin in the credit comparison,
e.g., only assume we're out of sync if off by over 1000 credits.  I'm not
sure how to pick the number for the margin, though.  It depends on the
traffic flow.  This is just the first fix that came to mind; there are
likely better strategies.

Let me know if this makes sense or if I have missed something.

Thanks,
David