On 1/28/2015 7:28 AM, Alexandru Petrescu wrote: > Le 27/01/2015 18:06, Joe Touch a écrit : ... >> Please tell us something we haven't known and dealt with for >> decades. > > Hi Joe, > > I tend to agree with this invitation. > > To further support it I would like to point to "Issues in Packet Radio > Network Design", Proceedings of the IEEE, January 1987. I can read this > paper because my employer has an institutional subscription. > > The paper tells at some point: >> The problem of collisions caused by hidden nodes can be alleviated by >> the use of a busy tone which is transmitted by a node on a separate >> channel to indicate that it is currently receiving a packet. > > That is a recommendation for alleviating hidden terminal problems. > > IEEE 802.11 also offers methods to alleviate for the hidden terminal > problems (request to send/clear to send). > > If this draft were to describe the hidden terminal problem, and suggest > that the IP networking layer should not be used to solve it, would it be > a satisfactory approach? (instead of saying "may affect the IP layer", > as it currently does).
IP should never be used to solve link layer deficiencies. We do not need an RFC to state that. The hidden terminal problem has been around since the origins of the Internet. We do not need an RFC to highlight that this problem exists. > Another problem described in this draft is the following: > >> There may be no indication to the IP layer when a previously >> established communication channel becomes unusable; "link down" >> triggers are generally absent in multi-hop ad hoc wireless networks, >> since the absence of detectable radio energy (e.g., in carrier >> waves) may simply indicate that neighboring devices are not currently >> transmitting. Such an absence of detectable radio energy does not >> therefore indicate whether or not transmissions have failed to reach >> the intended destination. > > This describes a problem. L3 routing infers link availability by exchanging messages. Link up/down indicators help routing protocols react more quickly, but are just optimizations compared to sending explicit discovery messages. I.e., the problem is that you have a link layer that doesn't optimize. > If the solution to it were a link-layer > solution, would you agree with the problem per se? There are hazards to any L2 attempt to determine link availability. In particular, if the link is deemed available when IP packets cannot transit, the information provided to L3 isn't helpful. So maybe this can or should be solved at L2 (which would be outside the scope of the IETF IMO), but whether it is solved or not should have no impact on L3 except as a performance tweak. > The paper that I cite above gives a solution to that problem, at the > link layer: > >> Radio connectivity must be determnined by the two ends of the radio >> link (i.e. the two packet radio units which are connected). The >> information from each node can be collectd at a central location >> where connectivity is then detemrined, or it can be determined by >> the nodes themselves through a cooperative mechanism, such as >> exchange of the number of transmitted and receveived packets. [...] >> One set of methodes that can be used to detemrine the existence of a >> link is to directly use measurements made on the radio channel. >> These can include such measurements as signal strength, >> signal-to-noise ratio and bit-error rate. This is something that belongs in a textbook (and probably already exists there). Again, you're far from something that warrants an RFC, IMO. Joe _______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
