Subject: RE: [SeaMoby] Topic #3: Cache contamination

From: [email-masked]
Date: Fri, 14 Mar 2003 14:56:59 -0500

James,

> I am trying to understand Dycard, as, I presume, are others in the
> WG. If you and the rest of your team want it or features of it to be included in
> the protocol (which is why, I presume, you are arguing so strongly against the
> DT draft) then you need to help us understand it. It is not helpful or
> constructive to criticize someone else's work without providing a alternative.
> From my reading of the Dycard draft, there may be some useful features in it, we
> need to have the working group understand those.

[Govind] First, its not my team. Second, I am not speaking for others who
co-authored dycard.

While I agree with you in essense, I think it is unfair to expect us to explain everything
when the draft is available for everyone to read. We read the DT draft and raised questions based on
our study. If those who are interested, read our draft and asks us questions exactly 
as how we handle things and ask us to prove the efficiency of our scheme, we will be more than happy
to do so as it helps improve our ideas too. If something is not upto standards of
the WG we will attempt to rectify those issues. If something is unclear and pointed clarifications
are asked from us we can go forward and clarify things. Instead, same questions are being asked 
again and again, and we seem to go around in circles all the time. I would think similar
effort must be made to understand dycard too by people who wish to critique us .

> 
> So why can't the server scheme limit the number of entries 
> per MN? Limiting the
> number of entries per MN has nothing to do with the back end, 
> where the router
> finds out what is an authorized GAAP, which is where Dycard 
> and the server
> scheme differ as I understand it. It has to do with the front 
> end, where the
> router decides what to do with an incoming message.

[Govind] Overall I agree. 
The main point is in the server scheme you are using APids
sent by the MNs as the means of populating the cache. Since you can't restrict
the number of APids it will hear from outside your domain. You have to 
consider it while setting the limit in rate limiting.
Other than that I believe that tagging the MN with its identity is a nice way
to restrict the number of cache entries created by the MN. 
> I see from the draft that it is the RI message that launches 
> PNE, my bad. Now,
> please tell me why an MN can't bombard the router with RI 
> messages? The router
> can rate limit, as you mention above but, in your comments on 
> the Issues, you
> said that you didn't think rate limiting was an issue, so...? 
> Is rate limiting
> important or isn't it? I'm confused.

[Govind] Let me make myself clear yet again. I think it easier
to set the "limit" while  rate limiting in dycard than in the DT draft. I don't
discount the need for rate limiting.

> OK. What happens when the limit is reached? Wouldn't a cache 
> (regardless of the
> timeout policy) be necessary regardless?
[Govind] I didn't understand your point clearly here. But maybe my
previous explanations about understanding the need for rate limiting
would suffice for you.

Thanks,
Govind.

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

---

From: "James Kempf" <[email-masked]>
Date: Fri, 14 Mar 2003 13:51:16 -0800

> sent by the MNs as the means of populating the cache.

So what does Dycard use to populate the cache? The MN is sending AP ids to it
via the the RI message (pg. 10) after which the AR uses the PNE message to
validate (pg. 5). Seems like the AP ids are the triggering factor for populating
the cache. Or am I missing something?

>Since you can't restrict

OK.

> to restrict the number of cache entries created by the MN.

Um, what is the MN's "identity"? It's MIP home address? It's on link care of
address? I must have missed this in the draft.

            jak

---

From: "James Kempf" <[email-masked]>
Date: Fri, 14 Mar 2003 13:51:16 -0800

OK.

            jak