RE: (virtual) hum on CARD open issues

Hello Vijay,
Please find my inline comments.
regards,
ajoy

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


"Pat R. Calhoun" wrote:
> 
> Following today's meeeting in Vienna, we've been able to get consensus on most issues. However, we need to get consensus on the mailing list. Please send your opinion to both myself and James on each of the issues below (in a single e-mail, please), and I will tabulate the responses and send a resume to the list.
> 
> 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. 

 the MN has to
send one request per second upto a maximum of 3 requests. or
it can exponentially backoff. if the MN sends requests more
frequent than this, they are dropped by the AR. I even sent
some text for this, when I reviewed the CARD protocol.

> 
> 2. Issue #4: Drop CARD protocol message piggybacking with FMIPv6? Meeting consensus is to keep the current text for CARD protocol operation with FMIPv6.
> 
> 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.
BTW, why are you in favor of 
using ICMP for AR-AR interface? 

from a recent discussion on the IPsec mailing list, it
looks like we might get the ICMP type as an IPsec selector.
then you would be able to distinguish between different
ICMP messages. ofcourse I dont when it might be 
standardized.


> 
> 4. Issue #5: Static vs. dynamic capability attributes. The editor recommends that we keep the S-bit and use the 32-bit lifetime only when really required for dynamic capabilities. This saves bandwidth, but does complicate processing. Meeting consensus is to keep S-bit.

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. 

> 
> 5. Issue #6: Unsolicited CARD Reply message broadcast/multicast. Proposal by the editor is to use broadcast for IPv4 and multicast for IPv6. Add an unsolicited CARD reply unicast. Broadcast on wireless links can generate heavy traffic. James Kempf proposes that we drop this for now as we enter experimental. Alternative proposal is to mimic router advertisements, send when changes occur and send when new mobile shows up. Meeting consensus is to add a statement in the document that we considered multicast and leave it for future.

I am not sure I understood. is the unsolicited CARD Reply
message being dropped from the spec, because it cant be
protected?

> 
> 7. Issue #7. Preferences/Requirements sub-option. We should only use one of the two methods. Meeting consensus is to keep both the sub-option and the preference.

I believe combining these two will go a long way in 
simplifying the CARD protocol. I looked up the meeting
minutes, which said there were no comments on this at
all. I strongly suggest combining the two.

>
> 8. Issue #18. Requesting ARs to perform ONLY reverse address translation. This is an essential feature for the MN to indicate reverse translation. Ultimately, this could become obsolete since the Proxy message does this too. Meeting consensus is to specify a R-flag in the CARD request message.

great. I like this.

Vijay

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