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.
>>
> 
> 
> [Eunsoo] Please let me explain a little bit further. The AR will drop
> messages above the rate limit. It protects the AR from the DOS attack. It is
> fine as long as all the MNs know the rate limit set by the AR. So the
> question is how the MN gets to know the rate limit which can be different
> for different ARs. The R flag is an idea that the AR will inform the non
> malicious MN of the fact that the MN reached the rate limit. If the AR
> attaches the rate limit value with the R bit, the MN will know that the rate
> limit of the AR is different from what the MN uses. Certainly the malicious
> attacker will ignore the R flag or whatever information from the AR. As said
> earlier, the AR will protect itself by dropping messages. So the R bit was
> introduced to protect innocent MNs in a dynamic fashion in the case of rate
> limiting.
> 
> 
> 
>>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.
>>
> 
> 
> [Eunsoo] I think dealing with the DOS attack has some common aspects with
> congestion control. But it seems the draft should be clearer about the
> purpose of the rate limiting and its mechanism.
> 
Yes, I think this would be good.

>>>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.
>>
> 
> 
> [Eunsoo] The rate limit is set by the AR. The MN can do nothing about it. We
> don't envision that the AR will change the rate limit dynamically in
> response to any request from the MN. It will be configured by the admin.
> 
> The last part is the idea that was proposed as one of the mechanisms by the
> design team in the meeting. Certainly it works. We just need to make sure
> the MN receive the reply containing the information. Actually this is the
> same for the reply containing the R bit. Well, unless the MN does not
> retransmit the request with the same sequence number, the AR does not know
> whether the MN lost the reply. If the MN gave up retransmitting the request,
> the AR never knows that the reply was lost. We need to resolve this problem.
> 
> Anyway if the reply containing the R bit includes the rate limit
> information, the two mechanisms are almost the same. The R bit can be
> replaced by the rate limit information. Then the difference becomes just
> whether all the MNs will be informed of the rate limit or only the MN
> reaching the rate limit will be informed. The latter can save air interface
> bandwidth because probably most MNs won't reach the rate limit. I'd like to
> hear WG opinion about these two choices.
>
Even if it's reactive rather than proactive, I think adding the actual 
expected rate is much more useful for both the AR and the MN than simply 
indicating that the MN is "overclocked". Otherwise, the MN may not 
backoff fast enough, or possibly too fast. For example, the MN may be 
exceeding the AR's rate by just one packet per period. What should his 
response be to the R-bit, halve his rate? That would be too extreme. But 
if he's pushing twice as much as the AR expects, just dropping his rate 
linearly will not converge very quickly. This also complicates the 
design of the MN quite a bit, having to constantly adjust his rate.


>>>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.
> 
> [Eunsoo] Well, having two types of AVP is currently done by the S bit.
> Categorizing the attribute IDs for static attributes and dynamic attributes
> is the same thing as having a flag. Unfortunately the value field of the AVP
> is generally variable size. So pushing the lifetime field to the end does
> not help the situation very much in terms of data structure. I understand
> having a variable structure is not the best thing. But if we don't do this,
> some people may come up with CARD Compression protocol.^^
>
This is an experimental protocol for G*d sakes. There's time to optimize 
in later drafts if this moves forward towards a standard. Again, I think 
that this is a bit nit-picky at this stage, but oh well.

>>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.
>>
>  [eunsoo] The preferences sub-option contains only the list of attribute IDs
> and the requirements sub-option contains the list of AVPs. So they are quite
> different. Is this not clear in the draft?
> 
Section 5.1.3.2 says:

    AVPs MUST be encoded according to the AVP encoding rule described in
    section 5.1.4. Only ATTRIBUTES (AVP Code) need to be set. The VALUE
    indicator (Data) will not be processed and can be omitted. The 'AVP
    Length' field is to be set appropriately.

Section 5.1.4 is the same AVP section describing Requirements. So they 
have the same structure. The above indicates that Preferences simply 
have an empty Data field. This is what I'm referring to in the next issue.

Anyway, this wasn't the point of the original comment. Rather, the AVP 
encoding in Section 5.1.4 includes the lifetime field and a flag 
indicating whether that field is present. However, a missing lifetime 
field is supposed to indicate a static lifetime. Do Preferences and 
Requirements have a "static" lifetime. I'd say they have no lifetime at 
all. So, it seems odd that I have to set some bit, and skip a field to 
express that! I know this is a bit nit-picky, but I can see it being 
confusing for implementors.

I'd recommend either having a separate structure without the S-bit and 
lifetime fields for Preferences/Requirements, or change the S-bit to a 
more generic L-bit that is set when the lifetime field is present (for 
whatever reason). It's also more consistent to have something set when 
something is included, not the other way around.

>>>>>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.
>>
> 
> [Eunsoo] Hmm, when we thought about it, we thought we would add a flag in
> the sub-option header. Are you proposing putting just attribute ID values in
> the combined Requirement/Preference sub-option? So if the whole sub-option
> is used as Preferences, it contains a list of attribute IDs and if the whole
> sub-option is used as Requirements, it contains a list of AVPs. Is my
> understanding right? If you are suggesting it, then the sub-option should
> have a flag indicating the usage. Otherwise the receiver cannot decode the
> sub-option.
>
No, I don't think it has to be that complicated. As a MN, I include a 
single "Requirement" sub-option with a list of the capabilities that I'm 
interested in. Each capability is encoded as an AVP. If I have a 
particular constraint on a given requirement, then there will be a Data 
field present in the AVP. Otherwise, the AVP will simply be the 
attribute that I'm interested in.

 From the AR's perspective, parsing the single "Requirement" sub-option 
is also straightforward. Everything listed should be returned to the MN 
if a matching capability exists. Anything listed that has a Data value 
should be considered when selecting appropriate CARs. This is almost 
exactly the way it is explained in Section 4:

    Optionally, the MN can provide its current AR with a list of
    capability attribute-value pairs, indicating not only the capability
    parameters (attributes) as required for capability pre-filtering,
    but also a specific value for a particular capability. This allows
    the MN's current AR performing CAR pre-filtering and to send only
    address and capability information of CARs, whose capability values
    meet the requirements of the MN, back to the requesting MN. The
    format of this optional Requirements message parameter is described
    in section 5.1.3.3.

>>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.
> 
> [Eunsoo] Bob, I am not purposefully combative. I am just delivering my
> technical thought in response to your comments.
> 
>>>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.
> 
> [Eunsoo] Pre-filtering means what you said, that is, the AR returns only the
> capabilities requested in the Preferences sub-option rather than all the
> capability information. Do you think "pre-filtering" in the draft is not
> clear enough? If then, how can we make it clearer?
> 
This was a mis-understanding on my part. In the past, we had use 
pre-filtering to refer to the precess of choosing a set of CARS at the 
AR. I see now that you are using it to indicate filtering of the 
returned capabilities.

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/ |

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