Subject: RE: Solving the wrong problems

From: Ralph Droms <[email-masked]>
Date: Fri, 24 Jan 2003 22:11:42 -0500

At 08:51 AM 1/24/2003 -0800, Christian Huitema wrote:
> > > I have yet to hear anyone explain why they would want (as a software
> > > author, sending code into environments of which they have no
>knowledge
> > > at all) to ignore the desires of the local network and simply do
>things
> > > their own way.
> >
> > Appletalk and NetBIOS still ship.  They work *in every LAN
>environment.*
>
>Kind of. Both require multicast, and multicast is problematic in two
>types of LAN environment. It is problematic in large networks, because
>typically too chatty. It is also problematic in wireless network,
>because of reliability issue; for example, 802.11 includes a low level
>packet repetition algorithm, but that algorithm is not used for
>multicast packets.
>
>-- Christian Huitema

I know network administrators who would disagree with the statement

    Appletalk and NetBIOS [...] work *in every LAN environment.*

depending on how the words "work" and "LAN environment" are defined.
Christian pointed out specific problems with multicast and chattiness.

I make this point to illustrate that the statement oversimplifies
the situation and can be either true or false, depending on the
meaning of "work".  Seems to me much of the discussion here has
centered around that word "work", because we all have different
understandings of what it means to have a network "work".

Furthermore, making an observation about AppleTalk and NetBIOS misses
a key differentiation - the hard part of making single-link IP work
is managing the transition or mixed case where a single-link network
becomes a multi-link network or there are some single-link devices
interoperating with multi-link devices.

- Ralph

---

From: "Subrata Goswami" <[email-masked]>
Date: Sun, 26 Jan 2003 01:51:09 -0800

Kre, the park belongs to the public, one can use it as long he/she
behaves. I do not want to steal some one else's WLAN connections, I am
sure stealing is not encouraged in most countries.

LL should serve a different purpose than DHCP, we do not need one more
DHCP clone. The plain old DHCP is doing fine.

It is possible to tell where the packet originated (using MAC address,
triangulation, etc., you can buy 
this stuff now).

Subrata

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Robert Elz
> Sent: Sunday, January 26, 2003 12:23 AM
> To: Subrata Goswami
> Cc: 'Daniel Senie'; [email-masked]
> Subject: Re: Solving the wrong problems
> 
> 
>     Date:        Sat, 25 Jan 2003 12:11:30 -0800
>     From:        "Subrata Goswami" <[email-masked]>
>     Message-ID:  <001901c2c4ad$f394d980$c900a8c0@SGOSWAMIPCL>
> 
>   | I think I would prefer a working service, rather than being told
>   | that I can not use my device because someone nearby is encroaching
>   | into the park's property.
> 
> Of course, and you can have that, you just config your systems to use
> their own private wireless LAN, and ignore what is coming from other 
> places (and do remember that you can't tell the difference between a 
> stranger nearby, and the local council/authority/... who has 
> jurisdiction for the park).
> 
> The point really is that if you're using someone else's LAN, then can
> do whatever to you that they want to do, and there's no way at all 
> that you can prevent that - other than avoiding using their LAN.
> 
> If you somehow believe that just configuring a LL address (assuming
> they allow to to work) will be a panacea, and then you get to use 
> whatever LAN you like for your private purposes, then you have a shock
> coming when you actually try it.   And so you should have.
> 
> kre
>

---

From: "Subrata Goswami" <[email-masked]>
Date: Sun, 26 Jan 2003 01:51:09 -0800

Kre, you are mandating a DHCP Client for all LL hosts - why ???? 
LL is not DHCP Next Gen or mini-DHCP, is it ?

Subrata

> Sent: Sunday, January 26, 2003 12:14 AM
> To: Subrata Goswami
> Cc: 'Erik Guttman'; [email-masked]
>     Date:        Sat, 25 Jan 2003 08:41:42 -0800
>     Message-ID:  <000401c2c490$a50220b0$c900a8c0@SGOSWAMIPCL>
> 
>   | Actually, it has to be specified how the device figures out that 
>   | there is a DHCP server.
> 
> It gets a DHCP reply.    That is obvious.   The only DHCP reply it
> can get is a DHCPOFFER.   So, it gets one of those.   If it doesn't,
> it can assume there's no DHCP server.
> 
>   | Not really, if the DHCP server does not send out any DHCPOFFER 
> then the
>   | device would not know if there is a DHCP server or not.
> 
> Exactly, so we are assuming that it does get a DHCPOFFER.
> 
>   | what happens if the device does not even have an LED, or the LED
>   | malfucntions ?
> 
> What happens if the power supply malfunctions?   Let's be reasonable
> please, if manufacturers want to make devices where it is impossible 
> to work out what kind of problem might exist whenever they don't work 
> perfectly, then it is going to be impossible for anyone to ever work 
> out what is wrong (whether it is a "no address for you" or a broken 
> wire in the drop cable, or too far from base station, or not plugged 
> in properly, or ...)
> 
>   | what happnes if the device received two DHCPOFFERS from two
>   | different DHCP servers, one saying can use LL and the other saying
>   | do not use LL.
> 
> DHCP says that if you get 2 offers, you can pick whichever you like. I

> see no reason at all to change that, so the client picks whichever
> of those 2 it likes.   If one of them offers an address, most likely
> it would pick that one (or one of them if both do).  If
> neither offers an address, and one says "use LL" and the 
> other says "no LL", then I think if I was the client, I'd 
> pick the "use LL" offer, and do it.
> 
>   | I do not see any problem here. The device would not have a 
> corresponding
>   | entry in SLP or mDNS, and the user can easily figure that out from
>   | the absence of the entry.
> 
> But why does it appear to be missing?   Is it the server or the client
> that isn't working properly?   Or the switch/hub/router that 
> is between
> them?   You have to start somewhere when debugging these problems,
> and starting with "it doesn't work" and nothing more, rarely helps.
> 
>   | No, not all devices that would use LL would have blinking LED's.
> 
> No, of course not, but any device rational to use (from toasters to 
> air-conditioners, to washing machines, to car alarms, to ...) has some

> means of "I am working" user feedback.
> 
the examples you have given do not LEDS, and infact none of them does
have LED:
toaster (check for black toast), 
air-conditionres ( do you even where your air conditioner is ?),  
washing machine ( check your clothes, are they wet ? ) , 
car alarm  (try to open a door without using your key).

>   | DHCP has its limitations.
> 
> of course.   And no-one is pretending that a network has to use it, if
> it is inappropriate.
> 
>   | The way you are wording the 3 cases above implicity requires that
>   | every LL device MUST have a DHCP client.
> 
> Yes, that's something I would support - either a DHCP client or
> expect to be manually configured.   Nothing else can possibly allow
> the device to function on the internet.    And remember, it is
> internet standards that the IETF makes.
> 
>   | The onus of deciding whether to use LL or DHCP is placed mostly on

> the
>   | device, which in most cases would be very resource limited
> 
> Supporting a DHCP client is one of the easiest things for a device
> to manage, it takes just about no resources.   What are you imaging
> this client actually doing with so few resources that it can't handle 
> that?
> 

what is the minimum resource required ? probably depends on how much of
DHCP you want to implement. a full implementation needs to have a full
UDP
stack + full DHCP state machine, probably 100KB of code + 5 MIPS of CPU
+
10KB of RAM. 

the point is, why does an LL device that knows that it is never going to
use
DHCP have the DHCP stack in it ? think about a network that does not
have
DHCP server, even here the LL devices need to carry the DHCP client.