Comments on draft-iab-link-indications-03.txt

[Elwyn Davies <[e-mail]>]

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
[e-mail]
https://www1.ietf.org/mailman/listinfo/ietf