Subject: [manet] credit windowing questions (was Re: DLEP 15)

From: "Wiggins, David - 0665 - MITLL" <[email-masked]>
Date: Fri, 10 Jul 2015 16:46:33 +0000

Heavily trimmed...

On 7/10/15, 10:55 AM, "Ratliff, Stanley" <[email-masked]> wrote:
>>> On 10/07/15 13:46, Wiggins, David - 0665 - MITLL wrote:
>>> > A Destination Update message can contain both Credit Window Status
>> > > and Credit Grant data items.  In that case, does the window value in
>> > > the Credit Window Status already reflect the Credit Grant increment,
>> > > or should the recipient add the window value + credit increment to
>> > > get the real new credit window?
>> 
>> Uhhh, I don't think so. Seems to me that the root of the question here
>>is
>> whether the peer would have added in the grant before creating the
>> window status or not. So I would think the correct processing flow
>>would be
>> to add the credit increment to your existing, running counter, then
>>compare
>> to the value in window status.

So let's say the modem sends a destination update to the router containing
a
MRW value in the window status, and a Credit Grant value CG.  Is this what
the
router should do?

1. new MRW = CG + router's locally maintained MRW
2. If new MRW != MRW from the window status
       new MRW = MRW from the window status
3. router's locally maintained MRW = new MRW

If that's right, then it can be simplified to just:

1. router's locally maintained MRW = MRW from the window status

This eliminates the need for CG, so why even send it?

>> 
>> > >
>> > > When a peer receives a Credit Window Status, if it has a different
>> > > value for the other side's receive window than what is in the Credit
>> > > Window Status, should it update its value to be the one in the
>> > > Credit Window Status?  It seems like this should be a MUST.
>> 
>> Here's the corresponding verbiage (with all of the PPPoE-isms,
>> unfortunately) from RFC 5578:
>> 
>> "During normal operation, nodes may disagree about the number of
>>    credits.  Operational credit mismatches would occur due to packets in
>>    transit on the wire.  Much larger credit mismatches can occur if
>>    there are transmission errors.  To correct these larger errors, the
>>    BCN fields of the PADG and PADC packets and in-band credit grants
>>    from a peer can be used by the receiving node to reset the credit
>>    values of its peer."
>> 
>> Not really a MUST, but it's certainly a MAY. We can add the DLEP-ized
>>version
>> of this text.

Yes, that would be good.  If you make it a MUST, then you have two options
for granting credits: a solicited method via credit request/grant,
and an unsolicited method whereby the peer can just send you more credits
whenever it wants via the window status.  If you don't make it a MUST, then
the unsolicited method can't be relied on because you don't know if the
receiver is going to accept new credits this way.  I think having both
options would be useful.

David