Hi.
I did a quick read of this document and have a couple of general
comments (plus I spotted a very few trival nits).
It seems to be a very useful survey of what has been done in the area of
Wireless LAN and the interactions of link indications for hosts
connected directly to such links. The architectural concerns and
recommendations are then principally derived from this area of study - I
agree generally with what is said in these recommendations in the
primary situation investigated but I am not sure if the conclusions
would be modified if other situations were more explicitly considered.
I am not sure without much deeper thinking and indeed a deeper knowledge
of the types of links whether the characteristics of the various mobile
phone links (which are very briefly mentioned) would have much of an
impact on the conclusions. Their behaviour is significantly different
from that of WLAN and given the rather limited performance of the
browser on my mobile phone I wonder if more advice is needed here!
Similarly Bluetooth and other sorts of short range communication; and
802.16 type links don't get much consideration.
The draft implicitly concentrates on link indications directly into
hosts where they can interact with the transport and application layers
as well as the IP and routing control plane. Carriage of link
indications beyond the node where they are directly detected is rather
frowned upon: I think that some more analysis is needed for situations
where the wireless link attaches to a router (a mobile network such as a
car or plane comes to mind) and the hosts attached to the wirelesss
router don't see the link indications directly. It occurred to me that
the nsis work both needs the link indications (to help with rerouting)
and could be effectively used to carry the indications - either as a
on/off signal or as part of the QoS signaling to tell the application
that the bandwidth it was going to get was not what it negotiated
originally.
Another area whcih is not considered is the usage of link indications
for traffic engineering. There is quite a lot to be said about managing
layered recovery where multiple link layers can provide both indications
of failure and/or rerouting. The total problem in this case is very
complex (just which layer should do the rerouting?).
I also though that IPv6 was not considered very thoroughly. The
following sections should probably say more about IPv6:
s1.2: Routable addresses: what about IPv6 addresses?
s1.4.2: Needs to consider ICMPv6
ss2.3.1, 2.3.2, 2.3.3: Need to consider IPv6 address configuration
Minor point:
In s2.4: there should probably be some discussion of the controlability
of TCP keepalives - most OS provide very rudimentary capabilities for
controlling TCP keepalives and the usual default interval is totally
useless for almost any real world application.
Editorial nits:
s2.1, para 3: (language difficult to parse) s/documents
dependent/documents that describe capabilities that are dependent/
s2.2, para 5: s/head/heed/
s4.1, para 3: s/receiving/receive/
s4.3, para 1: s/particular/particularly/
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf