Subject: RE: Should connecting to the Internet be Optional?

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Mon, 4 Mar 2002 18:28:49 +0100

Tony, 

First of all, I think that connecting to the
Internet MUST be madated, not optional :) 

Having cleared that out, I have a couple of 
comments below.

While I am willing to believe that 
  > there are valid
  > reasons to make adjustments based on characteristics of the 
  > link, this
  > document is fundamentally flawed because it is based around 
  > the pretense
  > that small footprint devices are somehow special. We MUST NOT allow
  > ourselves to modify well thought out architectural 
  > fundamentals based on
  > point-in-time engineering constraints that are dubious at best. 

=> That's a bit inaccurate, there is a major difference
that is due to the BW contraints of the air link. 
I see your points about size and memory, but it would
be good if we identify the parts related to size
and memory in which the draft deviates from IPv6
standards and distinguish them from the BW and 
l2-specific impacts.

  > The argument that small devices have limited processors or memory
  > overlooks the fact that the processor and memory of many hand-held
  > devices today is significantly greater than the 
  > workstations that were
  > available when IPv4 was defined. Interesting point; there 
  > was no problem
  > getting the stack and an array of applications to fit then. Another
  > interesting point; there are frequently rumors that laptops 
  > will include
  > cellular interfaces, so where does the processing and 
  > memory constraint
  > fit in that case?

=> It doesn't. But this is a classical argument
which essentially says :'if you can't build it 
now, wait for a few years and you'll fit everything
in'... well, as an engineer I don't have a major
problem with that, but if I was someone who's 
trying to sell a wide range of products for 
different market segments, and some of those 
need to be limited in many ways to be sellable
at all, then I would have a problem with this 
logic.

Again, to be able to improve the quality of the
draft, we need to point out *exactly* where
the relevant problems are. Margaret did some 
of this already and it is being discussed.

  > 
  > If a document on cellular requirements makes any sense, it has to be
  > based on differences in fundamental characteristics of the 
  > air link, not
  > the device on either end. Avoiding DAD simply due to 
  > expense is not a
  > valid justification, but if the loss characteristics of the 
  > link make it
  > more problematic than valuable, there may be an argument. 

=> The document does NOT avoid DAD. The document
is aimed at a generic cellular host, and wherever
applicable, makes an applicability statement on the
3GPP-specific cases. The reason DAD is not needed
in 3GPP, is that the way an address is allocated
leaves no room for on-link duplication. And still, 
the document does not say, you MUST NOT do DAD, 
it simply says that in *this* instance of a cellular
network, DAD is not needed. So if you just want
to implement it anyway, then go ahead. 

  > Keep in mind
  > that doing so precludes the use of RFC3041 addresses, so the
  > applications where anonymity is most valuable (as one moves 
  > around and
  > doesn't movement traced) are precluded. 

=> This is not a problem and address privacy is already
supported without the need for DAD. 
The 3gpp-advice draft, the cellular host draft
and 3GPP TS 23.060 can provide the exact details. 

A non-zero probability of
  > collision requires a mechanism to resolve duplicates, and DAD is the
  > currently defined one. If another one exists that makes 
  > more sense over
  > a lossy air-link, we should consider replacing DAD because it will
  > probably be more reliable in the general case as well.

=> It doesn't make sense if a host gets a /64
prefix that can not be used by anyone else on 
the cellular interface. 

Hesham

--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: "Tony Hain" <[email-masked]>
Date: Mon, 4 Mar 2002 10:47:31 -0800

> Internet MUST be madated, not optional :)

I am glad we agree.

>  ...

Let's not go there. Those of us with lots of grey recall the days when
half the 3G bandwidth cost in the 6 figure range a month, with loss and
latencies were about the same as the 3G link. Yes it is a constrained
environment relative to other options today, but there is nothing
inherent in the BW, loss, latency, cost that limits the potential for
use as a packet network. While we can't assume that everything is
reasonable in the constrained environment, we also shouldn't be throwing
out capabilities that history has proven useful simply because they are
hard or cost a little more.

> at all, then I would have a problem with this

Product decisions beyond what is technically possible don't belong in
the discussion about standards. My son's 3-year old calculator has more
low-power CPU & memory than the SGI workstation I had 10 years ago, and
it would fit in a package small enough for a 3G handset (and has a
longer battery life than my phone). I have to believe that there are
better options out there now (at least 5 years after that device design
was done), so the fact that a product team doesn't want to use those for
a specific market is not a problem for the IETF.

> of this already and it is being discussed.

I only had time for a quick pass this morning, and don't expect to get
much more this month. Not that my personal time should drive a WG
schedule, but if Margret raised several questions, and my quick pass
found fundamental issues, I would argue that this doc is not even close
to ready for last call.

> to implement it anyway, then go ahead.

'A cellular host SHOULD NOT perform Duplicate Address Detection...'
While that is not a MUST NOT, it is a very strong instruction to avoid
it. If it said something like 'A cellular host MAY choose NOT perform
Duplicate Address Detection when it has other means to ensure
uniqueness...' I would be less concerned.

> and 3GPP TS 23.060 can provide the exact details.

If there is something specific that makes the statement true, it should
be written here so people don't have to chase around to find it. The
only thing that might make it true is that the router interface on the
subnet will ALWAYS have the 'unique bit' set in an EUI-64 derived
address, and will never use another format. This also presumes that the
handset doesn't provide layer-2 bridging services to other locally
connected devices. If it does that then there is no guarantee that some
device on the allocated subnet will not collide.

> prefix that can not be used by anyone else on

See previous comment about L2 bridging by the handset/embedded device in
a laptop ...

Tony