CARD issue#2: rate limiting - about to be closed /Re: (virtual) hum on CARD open issues

Since there were no further comments to this issue and the respective
proposal, I guess we can regard this issue as closed and take over the 
proposed
approach on rate limiting to the document.

marco

James Kempf wrote:

>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
>>
>>
>>    
>>
>
>
>_______________________________________________
>Seamoby mailing list
>[email protected]
>https://www1.ietf.org/mailman/listinfo/seamoby
>  
>