Subject: [Seamoby] updated dyCARD draft

From: Robert Chalmers <[email-masked]>
Date: Fri, 14 Mar 2003 11:29:25 -0800

Folks,

I updated the dyCARD draft with a short section indicating that all 
messages must be rate limited (Section 7.9). The draft is available at 
http://www.cs.ucsb.edu/~robertc/drafts/draft-trossen-seamoby-dycard-01.txt

enjoy,
bob

-- 
/****************************************************************

  Robert Chalmers
  UCSB Computer Science Doctoral Candidate
  Network and Multimedia Systems Lab (NMSL)

  "My heart is in the code, but my soul lies in the process"

  | [email-masked] || http://www.cs.ucsb.edu/~robertc/ |

*****************************************************************/

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

---

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

Robert,

Do you want to propose this text as the resolution to Issue 3?

            jak

---

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

Robert,

            jak

---

From: Robert Chalmers <[email-masked]>
Date: Fri, 14 Mar 2003 17:44:47 -0800

James,

> Do you want to propose this text as the resolution to Issue 3?
I think the text is probably a bit rough and too specific to dyCARD, but 
the idea is about right. I actually sent that e-mail before I read your 
mail concerning text to resolve the issue. I just wanted to make sure 
that something was in the draft to address rate limiting (meant to put 
it in earlier). For some reason, the DT draft stands with gaping holes, 
but dyCARD has to be explicit in every respect before it's "understandable".

In short, we need to be sure that the router can rate limit the messages 
it receives from MNs, as well as any messages it sends to other 
participants (neighboring ARs or backend server).

On a side note, I agree with you that we should pobably separate the 
AR-MN signalling from the AR-AR or AR-server signalling. Whether or not 
the WG wants to standardize mutiple back-end schemes (static, 
server-based, learning-based), I don't know.

Finally, I definitely agree with you that we need some input from people 
who don't have invested interest in either approach. Please don't take 
this the wrong way, but are you invested in either approach? It seems 
that some of the dyHardness might stem from the perception that you 
might or the DT in general might be invested. Moreover, while the DT was 
hashing out which direction they would take, we (the dyCARD team) 
received a lot of questions concerning how to secure the protocol. It 
was my impression that the the DT eventually went towards the 
server-based solution because we couldn't guarantee absolutely that the 
caches could not be contaminated with non-GAAR entries (this is not the 
same as bad AR-AP mapping - that we can guarantee). With the recent 
discussion, though, these problems seem to have taken a back seat. Now, 
it seems that malicious MNs aren't that big of a deal, cache 
contamination is not a big issue.

Maybe, the next step is to start talking about what properties would 
make for the best protocol, not what's wrong with one approach or the other.

my 2 cents,
bob

  Robert Chalmers

---

From: Robert Chalmers <[email-masked]>
Date: Fri, 14 Mar 2003 17:44:47 -0800

James,

my 2 cents,
bob

  Robert Chalmers

---

From: "James Kempf" <[email-masked]>
Date: Sat, 15 Mar 2003 12:10:18 -0800

Robert,

> but dyCARD has to be explicit in every respect before it's "understandable".

I think you and perhaps others in the WG may have some misunderstands about the
nature of IETF Design Teams.

The product of the Design Team is only a suggestion and it can be amended by the
Working Group. Thus, if it turns out that the DT draft has "gaping holes" (and I
would be the last one to suggest that it is a finished product), they must be
filled. If it turns out that Dycard has some good ideas to fill them, and the WG
agrees, then those ideas will be used. I believe the discussion in the last
couple weeks has identified a couple holes in the DT draft, and I believe there
have been some reasonable suggestions from the Dycard team to fill them. We need
to consider them.

Of course, if the intent of the Dycard team in posting the draft was that the
Dycard design was a "take it or leave it" proposition, then I'm afraid that is
not how IETF WGs function. Even if the original base WG draft is an individual
contribution,  it is often amended and ultimately may look nothing like the
original design (in fact, the original designers may get sick of working on it
and leave the working group after a couple years).

            jak

---

From: "James Kempf" <[email-masked]>
Date: Sat, 15 Mar 2003 12:10:18 -0800

Robert,

            jak

---

From: "James Kempf" <[email-masked]>
Date: Sat, 15 Mar 2003 12:20:40 -0800

> server-based, learning-based), I don't know.

I think concentrating on the back-end is probably better. The front end has lots
of overlap with FMIP. The DT draft has basically two front end protocols, one
with and one without FMIP. I think we need only one. Of course, we must be sure
that the front end provides what the back end needs.

That's my opinion.

> this the wrong way, but are you invested in either approach? It seems

No. Regardless of who has IPR on what. But I am invested in getting a
well-integrated realtime handover protocol suite. As WG chair (and, further, IAB
member), I need to make sure the design changes we are making in local link
protocols and router protocols integrate well with the existing Internet, and
provide the functionality required. And I need to advise the IESG about how I
think we can best get there.

Like I said in another posting, the DT draft is just a suggestion. The WG has
ultimate responsiblity for the result.

> contamination is not a big issue.

My view is that preventing false information from getting to the MN is the
absolute baseline. Any protocol that doesn't supply this is broken. Further than
that, we need to discuss how accurate the wireless connectivity information
should be in the absence of full geographical information, and weigh that
against the cost in terms of infrastructure and inter-router signaling. Pat and
I have asked Eunsoo to discuss this topic and problems with the server approach
at the meeting. Ajoy and Marco's talk will discuss how the scope-id and server
approach work.

> make for the best protocol, not what's wrong with one approach or the other.

Yes,exactly.

            jak

---

From: "James Kempf" <[email-masked]>
Date: Sat, 15 Mar 2003 12:20:40 -0800

That's my opinion.

Yes,exactly.

            jak

---

From: Robert Chalmers <[email-masked]>
Date: Sun, 16 Mar 2003 00:17:08 -0800

James,

> I think you and perhaps others in the WG may have some misunderstands
>  about the nature of IETF Design Teams.
> 
I don't think so. I do feel, however, that in reality design teams end
up wielding more power than is intended. It seems like this basic
argument should have taken place before the design team was ever formed.

> The product of the Design Team is only a suggestion and it can be 
> amended by the Working Group. Thus, if it turns out that the DT draft
>  has "gaping holes" (and I would be the last one to suggest that it 
> is a finished product), they must be filled. If it turns out that 
> Dycard has some good ideas to fill them, and the WG agrees, then 
> those ideas will be used. I believe the discussion in the last couple
>  weeks has identified a couple holes in the DT draft, and I believe 
> there have been some reasonable suggestions from the Dycard team to 
> fill them. We need to consider them.
> 
The point I was trying to make had more to do with your recent comments
concerning the fact that dyCARD needs to be explained to the WG. Is the
DT draft somehow crystal clear? The dyCARD draft is pretty explicit, but
there are bound to be omissions and/or implicit
assumptions that are not explained well enough (e.g., rate limiting). I
just want to make sure that everything is spelled out so that its
"understandable" to the WG, so that the concepts aren't disregarded
simply because a detail has not been fully addressed in writing.

> Of course, if the intent of the Dycard team in posting the draft was
>  that the Dycard design was a "take it or leave it" proposition, then
>  I'm afraid that is not how IETF WGs function. Even if the original 
> base WG draft is an individual contribution,  it is often amended and
>  ultimately may look nothing like the original design (in fact, the 
> original designers may get sick of working on it and leave the 
> working group after a couple years).
> 
Absolutely not. But it does seem that every detail of dyCARD has to be
addressed before the general concept is given due consideration by the
design team. And I really don't feel that the server-based approach has
been faced with the same restrictions. That's just my impression of the
way the argument has progressed over the last week or so.

Please don't take this as some outraged rant. It's just a little annoyed
rant :0) Your comment just struck me as odd, not to mention the dyHard
references. I'm just looking for a fair consideration of both general
techniques.

enjoy,
bob

  Robert Chalmers

---

From: Robert Chalmers <[email-masked]>
Date: Sun, 16 Mar 2003 00:17:08 -0800

James,

enjoy,
bob

  Robert Chalmers

---

From: Pat Calhoun <[email-masked]>
Date: 16 Mar 2003 13:12:05 -0800

Robert,

First off, the DT does not (or should not) have more power than anyone
else in the WG. They were merely selected to help work on a document,
but the ultimate decision comes from the WG, not the DT. If the DT comes
out with a document, and the general consensus is that the work is not
worth the disk space it takes up, then we trash it.

I appreciate the fact that some folks have come up with an alternative
proposal. This provides the WG with some alternatives on how to solve a
problem, which the DT may not have thought of.

Ultimately, it's up to the WG. If the consensus is that the DT was
wrong, and that dycard should be used as a starting point, then that's
the decision we'll make...

However, I haven't heard that... yet.

Keep up the great discussions. <WG Char hat off>I understand there's
alot of controversy here, but I have to agree that I do see some
benefits to some of the dycard proposal <WG Char hat on>

PatC

---

From: Pat Calhoun <[email-masked]>
Date: 16 Mar 2003 13:12:05 -0800

Robert,

PatC