RE: (virtual) hum on CARD open issues

Hello Vijay,
Please find my inline reply.
Regards,
Ajoy 

-----Original Message-----
From: Vijay Devarapalli [mailto:[email protected]] 
Sent: Friday, July 18, 2003 5:39 PM
To: Singh Ajoy-ASINGH1
Cc: Pat R. Calhoun; [email protected]; [email protected]
Subject: Re: [Seamoby] (virtual) hum on CARD open issues


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 
> AJOY-> 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). 

AJOY->  I guess you can still keep 
CARD AVP parsing code same. But I do admit some additional code will 
be required to support two different transport protocols. 
But does this justify ICMP as an AR-AR transport 
Protocol? As far as I know ICMP was not designed for transport
Protocol so why are you changing this? Well, what other's think?  

also, if it is an ICMP message, I can piggyback
CARD messages on HI/HACK messages of FMIPv6.

AJOY-> Sometime. But timing of CARD Request/CARD Reply may not coincide with that 
of HI/HACK.


> 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. :)

AJOY-> I am really not convinced that complexity of processing one additional 
flag outweighs the saving. But what other's think?