Re: (virtual) hum on CARD open issues

> The number doesn't have to be determined at each router, it would depend
on
> the deployment and radio protocol.
>
O.K. Anyway you agree that the value would not be the same for various
wireless environment. The value will be configured by the network admin. The
visiting or even home mobile nodes should learn about the value. My point is
how the mobile node will learn the value, in particular, when the value is
different from the default value.

> W.r.t. restrictions, this is an experimental protocol, so the draft might
> suggest a possible use (CARD right after handover) then suggest this as an
> open question, for experimental determination.
If we consider that the protocol is experimental, wouldn't it be better to
allow more options for the application of the protocol and let people figure
out what's the best way to use the protocol?
Putting the restriction just for the rate control does not look good to me.

> A default is necessary,
> however, and one second seems right to me. It can be changed if the draft
is
> ever advanced to Proposed Standard.
>
Again, my point is that a single default value is likely to invalid in
heterogeneous wireless environment. So the question is how we alllow the
mobile node to learn the value when it is different from the default value.

Eunsoo


> ----- Original Message ----- 
> From: "Eunsoo Shim" <[email protected]>
> To: "James Kempf" <[email protected]>; "Vijay Devarapalli"
> <[email protected]>
> Cc: <[email protected]>
> Sent: Friday, August 15, 2003 9:17 AM
> Subject: Re: [Seamoby] (virtual) hum on CARD open issues
>
>
> > Hi, James,
> >
> > I understand your point but I am not sure whether we should put such
> > restrictions on use scenarios.
> >
> > If you mean the number is just a default value and alteration should be
> > allowed, we have the question that how the mobile node will learn the
> value
> > set at each access router.
> > Actually that is the point the authors of the draft thought of and why
we
> > wanted to support a dynamic approach.
> > I don't suggest any negotiation or complicated algorithm for rate
control
> > between AR and MN.  If we want to support configuration of the value at
> each
> > access router, we should provide a way for the access router to inform
the
> > MN of the value different from the default value. What do you think?
> >
> > Eunsoo
> >
> > ----- Original Message ----- 
> > From: "James Kempf" <[email protected]>
> > To: "Eunsoo Shim" <[email protected]>; "Vijay Devarapalli"
> > <[email protected]>
> > Cc: <[email protected]>
> > Sent: Friday, August 15, 2003 11:57 AM
> > Subject: Re: [Seamoby] (virtual) hum on CARD open issues
> >
> >
> > > Eunsoo,
> > >
> > > In general, a node shouldn't be synchronizing CARD so closely with
> > handover
> > > that the intermessage interval is an issue. The less L3 traffic at the
> > time
> > > of handover, the more likely the handover is to succeed within the
> > > constraints of the unavoidable L2 traffic (this is a generalization
that
> > we
> > > have arrived at from experiments). I would think a node would
typically
> > send
> > > a CARD request immediately after handing over into a new subnet, so
the
> > > intermessage interval shouldn't really be an issue.
> > >
> > > However, the number is intended only as a default and can be altered
in
> > > particular circumstances.
> > >
> > >             jak
> > >
> > > ----- Original Message ----- 
> > > From: "Eunsoo Shim" <[email protected]>
> > > To: "Vijay Devarapalli" <[email protected]>
> > > Cc: <[email protected]>
> > > Sent: Friday, August 15, 2003 7:25 AM
> > > Subject: Re: [Seamoby] (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
> > > > >
> > > >
> > > >
> > > > _______________________________________________
> > > > Seamoby mailing list
> > > > [email protected]
> > > > https://www1.ietf.org/mailman/listinfo/seamoby
> > > >
> > >
> > >
> > > _______________________________________________
> > > Seamoby mailing list
> > > [email protected]
> > > https://www1.ietf.org/mailman/listinfo/seamoby
> > >
> >
> >
>
>