Re: (virtual) hum on CARD open issues

Hi, Bob,



Please see my inline comments below.


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

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.



BTW, what is the normal rate-limiting technique you propose?


> > 2. Issue #4: Drop CARD protocol message piggybacking with FMIPv6?
> > Meeting consensus is to keep the current text for CARD protocol
> > operation with FMIPv6.
> >
> Agree. Since this is an experimental draft, leaving the capability to
> piggy-back is fine. However, the draft shouldn't waste too much text on
> the issue.
>
> > 3. Issue #33: Inter-AR CARD protocol transport from UDP to ICMP. The
> > editor recommends the use of ICMP to make it consistent with the
> > mobile interface. Potential downsides: ICMP has potential security
> > implications. ICMP message types on binding is also very
> > implementation specific. Also, securing ICMP would require that all
> > ICMP packets be secured. Meeting consensus is to keep UDP.
> >
> Agree. I've never felt that inter-AR protocols should use ICMP.
>
> > 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.


> > 5. Issue #6: Unsolicited CARD Reply message broadcast/multicast.
> > Proposal by the editor is to use broadcast for IPv4 and multicast for
> > IPv6. Add an unsolicited CARD reply unicast. Broadcast on wireless
> > links can generate heavy traffic. James Kempf proposes that we drop
> > this for now as we enter experimental. Alternative proposal is to
> > mimic router advertisements, send when changes occur and send when
> > new mobile shows up. Meeting consensus is to add a statement in the
> > document that we considered multicast and leave it for future.
> >
> Agree. Although, I'm not sure what the statement accomplishes.
>
> > 6. Issue #12: Link Layer triggers for unsolicited CARD reply.
> > Proposal is to remove the text that deals with layer 2 triggers.
> > Meeting consensus is to remove text.
> >
> Agree.
>
> > 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.

I am neutral about this issue. But I don't think having two separate
sub-options make the protocol a bit more complex.


> > 8. Issue #18. Requesting ARs to perform ONLY reverse address
> > translation. This is an essential feature for the MN to indicate
> > reverse translation. Ultimately, this could become obsolete since the
> > Proxy message does this too. Meeting consensus is to specify a R-flag
> > in the CARD request message.
> >
> Agree with a slight twist. The basic thing here is the reverse-address
> translation (whether or not FMIPv6 may overlap). So, the flag should
> indicate whether the MN would like the extra cabalities returned in the
> message in addition to the address info (a C-flag). Just a side note:
> beware of using R-flag hear for one purpose and using another R-flag in
> the reply for rate-limiting. It could be confusing.
>
> > 9. Issue #25: Addressing of unicast CARD protocol messages. Should we
> > use global or link local addresses? Meeting consensus is that since
> > MN-AR is always on a single hop, use keep link local addresses.
> >
> Agree.
>
> > 10. Issue #36: Removal of per-session state from ARs. Meeting
> > consensus is to keep signalling failure recovery on AR-AR interface,
> > but make it optional (MAY).
> >
> Agree.
>
> > 11. Issue #39: Further detail of signalling failure recovery
> > required. Meeting consensus is that if the MN is not able to resolve
> > an L2 ID, put an error code or some flag.
> >
> Not sure what this means. If MN is unable to do something, who is it
> telling? Is this supposed to say if the AR can't resolve then tell the
> MN. If so, I definitely agree.
>

[Eunsoo] Your understanding is right.


> > 12. Issue #17: Separate appendix from the CARD protocol
> > specification. The appendix is very large which describes many
> > options. James Kempf believes that the appendix really needs to be
> > shortened down to 2 pages, describing the two solutions - these are
> > items that need to be resolved during the experimental phase. Meeting
> > consensus is to take the appendix to 2 pages.
> >
> Agree. Although I would probably prefer to see them as separate drafts.
> Two pages won't tell you much. What exactly is the purpose of the
> appendix then? Just to hint at the solutions?
>


Eunsoo