Subject: Re: [Seamoby] (virtual) hum on CARD open issues

From: "Hemant Chaskar" <[email-masked]>
Date: Mon, 21 Jul 2003 17:37:15 +0000

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-masked]>
>To: Hemant Chaskar <[email-masked]>
>CC: [email-masked], [email-masked], [email-masked], 
>        [email-masked]
>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-masked]>
> > >To: Singh Ajoy-ASINGH1 <[email-masked]>
> > >CC: "Pat R. Calhoun" <[email-masked]>, 
>[email-masked],
> > >     [email-masked]
> > >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-masked]
> > >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

_______________________________________________
Seamoby mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/seamoby

---

From: "James Kempf" <[email-masked]>
Date: Sat, 26 Jul 2003 14:55:11 +0200

I agree.

            jak

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