Re: (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