Re: [Autoconf] aspects of multi-hop wireless communication

Charlie's right.  But IMHO, not quite complete.

The issue is not one of standards but provisioning.  In almost every
instance I can think of where we'd want MANET and multi-hop features,
high availability is a concern -- indeed usually a trumping one.  There
are three principles of high availability engineering: the second one is
'reliable crossover'.  
	The protocol design of IP (connectionless, stateless) solves this
second principle by protocol design.  Routers use altroutes, if they are
provisioned, all day every day.  
	Bridges, at least in the classical sense do not.  An off-shelf bridge
runs spanning tree protocol which curtails loops by killing off the
altroutes (turns a graph back into a tree).  This flat defeats the
second principle of high availability engineering.  

brctl .... I don't know what that is.  But the litmus test I'd apply is
whether it still preserves the second principle.  

This is not really a standards and protocols issue but a configuration,
provisioning and implementation one.  

On Fri, 2008-12-19 at 10:54 -0800, Charles E. Perkins wrote:
> Hello again Alex,
> 
> Alexandru Petrescu wrote:
> >
> >>
> >> Actually, all that is needed is for IP to have a useful interface to the
> >> device driver.
> >
> > I agree.  Device driver interfaces are known for several wireless link 
> > layers.  I think there isn't one special for the A-B-C hidden terminal 
> > problem.  I may be wrong, but I think.
> 
> That's because IP doesn't need to know whether the link
> has problems with hidden terminals.
> 
> >
> >>>> If you would like to suggest limiting the applicability of IP to 
> >>>> _only_ be allowed to work for links with specific characteristics, 
> >>>> then I think you should be explicit about it.
> >>>
> >>> YEs, I'm explicit: it's wifi.
> >>
> >> That restriction is not in the charter.  Do you want to campaign
> >> for a charter revision?
> >
> > Right... No, no, I don't want to restrict to wifi.  I think the A-B-C 
> > hidden terminal problem was mentioned in the wifi context.  I haven't 
> > seen it elsewhere.
> >
> > I agree for a solution IP to run over several link layers, for example 
> > wifi and 802.16.
> >
> > When a router needs to route between a wifi and a 802.16 link it never 
> > has the hidden terminal problem.
> 
> The main thing a router needs, is to know the next hop.
> 
> 
> >
> >
> >
> > Yes, I'd like to help with a protocol for wireless links, like wifi 
> > and 802.16.  But routing between these two doesn't expose the hidden 
> > terminal problem.  I'm pretty sure about it, I can say that because I 
> > have experience with IP over wifi and over 802.16 (emulated) links.
> 
> Again, routing doesn't need to know about that.  And, in fact,
> I believe that IP doesn't have to know about asymmetry, nontransitivity,
> or the time of day.  It just has to know about the next hop.
> 
> But the routing protocols have to be engineered to provide that
> information.  And, as this overly long and time-consuming discussion
> has shown, there is a bit of confusion about how to engineer
> routing protocols that work over the links under discussion.
> 
> You seem to claim that we shouldn't worry about them because
> the link layer has to solve problems like asymmetry and hidden
> terminal problems.  I'm of the opinion that routing protocols have
> to be engineered in some circumstances to avoid making
> unwarranted inferences about symmetry and transitivity.
> 
> I think it would be nice to identify exactly what your concern is.
> Once it was WiFi only, now it's not.  Do you think that routing
> protocol work should only be chartered for links that conform to
> certain regularity assumptions like symmetry and transitivity?
> 
> Regards,
> Charlie P.
> 
> _______________________________________________
> Autoconf mailing list
> Autoconf@ietf.org
> https://www.ietf.org/mailman/listinfo/autoconf

_______________________________________________
Autoconf mailing list
Autoconf@ietf.org
https://www.ietf.org/mailman/listinfo/autoconf