Re: (virtual) hum on CARD open issues

I agree.

            jak

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


> Hi all,
>
> Does WG agree to text provided by Vijay? Pat, James could you do consensus
> call on this text.
>
> Hemant
>
> >From: Vijay Devarapalli <[email protected]>
> >To: Hemant Chaskar <[email protected]>
> >CC: [email protected], [email protected],
[email protected],
> >        [email protected]
> >Subject: Re: [Seamoby] (virtual) hum on CARD open issues
> >Date: Mon, 21 Jul 2003 09:37:26 -0700
> >
> >
> >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
>
> _________________________________________________________________
> Help STOP SPAM with the new MSN 8 and get 2 months FREE*
> http://join.msn.com/?page=features/junkmail
>
>