Re: (virtual) hum on CARD open issues

Eunsoo,

>>> 1. Issue #2: R-flag for CARD Request rate limiting. What to do 
>>> about potential Dos issues? WG consensus is to Keep the R-flag 
>>> approach. Meeting consensus is to add clarifying text to section 
>>> 4.2 (4.3?)
>>> 
>> 
>> Disagree. R-flag seems like an odd design for rate-limiting. Are we
>>  expecting MN's to be constantly querying their AR's for the latest
>>  news, or will they make one or two requests prior to handover. 
>> Resending will be due to losses, and normal rate-limiting 
>> techniques work well in this environment (especially if AR isn't 
>> even receiving the messages due to congestion on the wireless link 
>> - no reply - no R-bit).
>> 
> 
> 
> [eunsoo] First of all, the R flag or the rate limiting was not 
> introduced for congestion control. It was introduced to defend the AR
>  against the DOS attack. The R flag is to notifiy the non-malicious
> MN about future message dropping.
> 
This makes no sense to me. The R-flag protects the AR from Dos attacks
by telling non-attacking mobiles to slow down? It's pretty clear that an
attacking mobile is going to ignore the R-bit anyways. So, all you end
up doing is degrading service to those mobiles not causing the problem,
and opening up bandwidth for the attacker.

According to the draft:

    Since the MN-AR CARD Request is sent when a MN discovers new AP(s)
    during link layer scanning, sometimes a MN might send frequent MN-AR
    CARD Requests, thereby overwhelming its current AR with CARD Request
    signaling messages. To counteract this problem, the AR SHOULD set
    the R-flag (rate limiting) of a subsequent CARD Reply message for
    flow-control purposes (section 5.1.2.2), thereby requesting the MN
    to reduce the generation rate of MN-AR CARD Requests. Upon receipt
    of the MN-AR CARD Reply with the R-flag set, the requesting MN MUST
    reduce the rate of generation of MN-AR CARD Requests. The exact
    implementation of a rate-limiting algorithm should be decided by the
    implementers.

This sounds more like a "congestion control" feature to me.

> We don't like the fixed rate limit because the admin might want to 
> set different rate limits for different ARs. Then the question is how
>  to inform the MNs about it. A solution is to inform every MN.
> Another solution is the R bit, which is to inform only the MNs that
> exceed the rate limit. By adding the rate limit information with the
> R flag, the MN is informed that the current AR has a different rate
> limit from the value the MN uses by default.
> 
It just seems better to develop guidelines by which MN's behave
"properly". For instance, they should hold off on immediately resolving
each new AP in an effort to batch the requests and limit the rate of
signalling. I understand your desire for the AR to have some control
over what a "good" rate is, but the R-bit seems to me to be too reactive
for this; "Wow partner, you'd better throw on the breaks there!" Can the
MN later try to push this limit (a la TCP)? Rather, have the AR include
a sub-option on the first reply to a MN with the preferred maximum rate,
and let the MN maintain that rate. My 2 cents.

> BTW, what is the normal rate-limiting technique you propose?
> 
Vijay has already answered this a number of times.


>>> 4. Issue #5: Static vs. dynamic capability attributes. The editor
>>>  recommends that we keep the S-bit and use the 32-bit lifetime 
>>> only when really required for dynamic capabilities. This saves 
>>> bandwidth, but does complicate processing. Meeting consensus is 
>>> to keep S-bit.
>>> 
>> 
>> Disagree. This is a bit nit-picky for an experimental draft. I'd 
>> like to see the protocol simplified as much as possible. People can
>>  experiment with it and determine whether saving a few bytes here
>> or there would make a real difference.
>> 
> [Eunsoo] Saving air interface bandwidth is very important. I don't 
> think people argue about it. Please notice that people work on header
>  compression to save a few bytes here and there. The S-bit is much 
> simpler than the header compression but can save a lot more 
> bandwidth.
> 
Another option is to separate the sub-options so that the type
explicitly determines whether a lifetime is present or not. This is
probably not much better. In general, I don't care too much about this
one, but as an implementor I always question the need for variable
structures to represent packets. If so, then the variable values are
usually left to the end of the packet, not smack dab in the middle of it.

As side note, it seems odd to use the same capabilities structure (with
the variable lifetime) for preferences and requirements since these 
shouldn't contain lifetimes. Should they? That's what originally 
prompted the previous suggestion.

>>> 7. Issue #7. Preferences/Requirements sub-option. We should only 
>>> use one of the two methods. Meeting consensus is to keep both the
>>>  sub-option and the preference.
>>> 
>> 
>> Disagree. It seems like these options could be combined. Simpllify 
>> the protocol going into experimental so that people are willing to 
>> implement it and experiment. If the separation is truly necessary, 
>> it should become clear then.
>> 
> 
> 
> [Eunsoo] Please notice that you are proposing introduction of a flag 
> to combing the two sub-options, which you claim introduces 
> complexity.
> 
Not at all. If you look at the structure of the sub-option, Preferences
do not have a value in the AVP format while requirements do. So, any
(Requirement|Preference) without a specific value can be considered as a
wildcard for pre-filtering. No need for a flag.

But Eunsoo, please don't be purposefully combative. Flags do not
introduce undo complexity by themselves. In the previous instance, I was
primarily concerned that the flag indicates the existence of an extra
field in the middle of the message structure which then changes the
offsets of subsequent fields.

> I am neutral about this issue. But I don't think having two separate
>  sub-options make the protocol a bit more complex.
> 
As a side note, why does it specify in Section 5.1.1 that the
Preferences sub-option is "used only in case of performing
         optional capability pre-filtering". It really has no impact on
pre-filtering, does it? My understanding is that it simply states which
capabilities should be returned in the reply message.

ttyl,
bob

-- 
/****************************************************************

  Robert Chalmers
  UCSB Computer Science Doctoral Candidate
  Network and Multimedia Systems Lab (NMSL)

  "My heart is in the code, but my soul lies in the process"

  | [email protected] || http://www.cs.ucsb.edu/~robertc/ |

*****************************************************************/