Re: (virtual) hum on CARD open issues

Hi, Vijay,

I am afraid my question is so long after your posting.
But please let me ask a few questions.
Is there any base for 1 second inter-message interval you suggested?
Also is the value valid or justified in any wireless network environment?

Let's consider a scenario that a mobile node receives a list of CARs and
then requests more information on a specific CAR. If this happens as a part
of the handoff procedure, the 1 second CARD inter-message interval will slow
down the handoff procedure. I am not sure this is desirable.
What do you think?

Eunsoo

----- Original Message ----- 
From: "Vijay Devarapalli" <[email protected]>
To: "Hemant Chaskar" <[email protected]>
Cc: <[email protected]>; <[email protected]>;
<[email protected]>; <[email protected]>
Sent: Monday, July 21, 2003 12:37 PM
Subject: Re: [Seamoby] (virtual) hum on CARD open issues


>
> I already provided the text when I reviewed the CARD protocol.
>
>   The MN MUST send only one CARD Request per
>   CARD_RETRANSMISSION_INTERVAL and not more than CARD_MAX_RETRIES.
>   If the MN sends requests more frequently, the AR SHOULD drop the
>   CARD requests and not process them.
>
> and add to the constants section
>
>   CARD_RETRANSMISSION_INTERVAL  1 second
>   CARD_MAX_RETRIES              3
>
> this is similar to ICMP rate limiting.
>
> TCP rate limiting is different, not applicable here. in general
> in any protocol where there is a request and a reply (and no
> more messages), ICMP rate limiting is best suited. you dont have
> to "source-quench" the Mobile Node. :)
>
> Vijay
>
> Hemant Chaskar wrote:
> >
> > Dear Vijay,
> >
> > Could you provide a text to be included in the draft on rate limiting.
We
> > can include it in the draft after discussing it over mailing list. It
> > probably wont suffice to say that rate limiting is in lot of protocols
and
> > hence not needed here. Different protocols use different rate limiting.
E.g.
> > TCP uses rate limiting, but it wont be appropriate for CARD.
> >
> > If you are proposing to limit the rate by simply enforcing limit on
> > aggregate rate of requests, I can easily argue that it is ineffective.
So
> > the question is: Wheater WG wants per MN rate limiting? If so, does it
have
> > to be using R flag or using limit on per-MN rate of request? And then,
you
> > can refer us to protocol that uses that type of rate limiting and we
will
> > simply refer to it - will save lot of writing.
> >
> > Hemant
> >
> > >From: Vijay Devarapalli <[email protected]>
> > >To: Singh Ajoy-ASINGH1 <[email protected]>
> > >CC: "Pat R. Calhoun" <[email protected]>,
[email protected],
> > >     [email protected]
> > >Subject: Re: [Seamoby] (virtual) hum on CARD open issues
> > >Date: Fri, 18 Jul 2003 15:39:12 -0700
> > >
> > >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.
> > >
> > > > > 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.
> > >
> > >
> > > > 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. :)
> > >
> > >Vijay
> > >
> > >_______________________________________________
> > >Seamoby mailing list
> > >[email protected]
> > >https://www1.ietf.org/mailman/listinfo/seamoby
> >
> > _________________________________________________________________
> > Add photos to your e-mail with MSN 8. Get 2 months FREE*.
> > http://join.msn.com/?page=features/featuredemail
>
> _______________________________________________
> Seamoby mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/seamoby
>