Re: (virtual) hum on CARD open issues

Hi, Marco and Vijay,

My comments are inline.

-----

> Hi Vijay,
>
> please see below for comments.
> marco
>
> Vijay Devarapalli wrote:
>
> >Singh Ajoy-ASINGH1 wrote:
> >
> >
> >>>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?)
> >>>
> >>>
> >>this is wrong, IMHO. rate limiting is a well known mechanism.
> >>introducing a new flag is not a bright idea.
> >>
> >>ajoy-> Why it is a bad idea?  Well, I am neutral in this
> >>issue but I am not convinced why using R bit is worse than
> >>your proposed solution.
> >>
> >>
> >
> >simple. rate-limiting is implemented in a wide variety of
> >protocols (infact for any message that creates state at
> >the receiving node). nothing new here. you dont need a new
> >mechanism for this.
> >
> >

[eunsoo] Already it was pointed out that the ECN bit of TCP (RFC 3168) was
another example of this kind of flag. So using a flag is not a very new
invention.

We considered specifying a fixed minimum inter-message interval but we did
not like it because of inflexibility. As the MN roams around, it will
encounter ARs with different requrements and thus a fixed value may not
work. So we looked for a dynamic mechanism. One way is having the AR send
the rate information to all the MNs. It is not good in terms of bandwidth
efficiency.

What mechanism are you suggesting, Vijay?

> I see your point. However, I don't see a reason why the flag as
> flow-control indicator
> should not work. Maybe there is also a benefit from implementation point
> of view on
> the MN. In case of having a flag, MN is notified when exceeding the
> request rate. Of course,
> AR has to maintain a per-MN state. Furthermore, rules have to be
> specified for MNs
> on how to behave when CARD Reply indicates exceeding rate. But from
> implementation point
> of view, this does not look very complicated on the MN side. However,
> having a
> "n-requests allowed per second"-rule on the MN, this needs to be
> controlled and
> implemented on the MN side, which looks like requiring a bit more effort
>
> Alternative proposal was to indicate a maximum rate for a particular AR
> in the
> first CARD Reply. This keeps individual request rates flexible and avoids
> defining static numbers.
>
> >
> >
> >>>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.
> >>>
> >>>
> >>2 and 3 dont go togetheer. defining CARD messages as ICMP
> >>options lets you piggyback these options on FMIPv6 messages.
> >>I am not sure how you can achieve piggybacking if the MN-AR
> >>signaling becomes UDP. ICMP was the right choice between
> >>the MN and the AR.
> >>
> >>AJOY-> Well I did not attend IETF meeting, but I guess this means ICMP
for
> >>MN-AR and UDP for AR-AR interface. Others' please correct me.
> >>
> >>
> >
> >oops... I misunderstood. I thought the concensus at the
> >meeting was to use UDP for both.
> >
> >
> >
> >>BTW, why are you in favor of
> >>using ICMP for AR-AR interface?
> >>
> >>
> >
> >otherwise you need seperate code for processing an ICMP
> >CARD Request (from the MN) and UDP CARD Request (from
> >the PAR). also, if it is an ICMP message, I can piggyback
> >CARD messages on HI/HACK messages of FMIPv6.
> >
> >
[eunsoo] There was discussion about this in the meeting. It was pointed out
that it was difficult to protect ICMP messages using IP Sec and thus people
preferred keeing UDP for AR-AR communication. BTW, piggybacking is a good
point. A new IRTF effort started to integrate many mobility management
related protocols such as FMIP, CT and CARD. A good way of integration
should be found.

> >
> >
> >>unbelievable. the CARD protocol is already complicated (IMO).
> >>the emphasis should be on reducing the complexity. just use
> >>a value of infinity for the lifetime field to indicate a
> >>static capability. any other value for the lifetime indicates
> >>dynamic capability. I think for the CARD protocol, emphasis
> >>should be on making it a simpler protocol than saving 4 bytes
> >>over the air. :)
> >>
> >>if you are concerned about an overhead of 4 bytes, make the
> >>lifetime field 2 bytes. a 2 byte lifetime field gives you
> >>65536 seconds which should be enough. do you need a 4 byte
> >>lifetime field?
> >>
> >>AJOY-> I disagree here. Saving even 2 bytes per capability is
> >>huge saving for bandwidth constraint network. I am not sure
> >>processing one flag will make CARD protocol any more complicated.
> >>Btw, in cellular standard I have seen even more complicated
> >>procedure for saving 4 bits per frame. Please note that
> >>the CARD protocol is being proposed as an experimental
> >>protocol so we will have opportunity to make such
> >>changes in future if required.
> >>
> >>
> >
> >but in the current form not many people are going to use
> >it. it might remain forever as an experimental, untouched,
> >ignored, just another RFC.... that is something we should
> >avoid. I want a protocol that I can use. :)
> >
> >
>  From complexity and implementation point of view, I don't really
> understand why
> the proposed mechanism makes the protocol complex? I don't see
> any difference between having a check on the lifetime (==0x00000000?)
> and in case it's
> zero assume the capability to be static, and having a check on a
> specific flag (flag == 1?),
> indicating a static capability, hence, no lifetime field is present but
> "value" descriptor
> follows immediately.

[eunsoo] I don't understand either that the bit is more complex than the
null lifetime. Also the bandwidth overhead of sending null lifetime value
can be significant when multiple (or many) static attributes are contained
in the CARD Reply. Bandwidth efficiency for the air interface is always a
very important requirement. As you know, people are talking about IP head
compression which is much more complex than using a bit to save bandwidth.

Regards,

Eunsoo