[DNA] Review of draft-yegin-dna-l2-hints-01.txt

[Bernard Aboba <aboba@internaut.com>]

Review of
http://www.ietf.org/internet-drafts/draft-yegin-dna-l2-hints-01.txt

Overall:

Overall, it is easy to lose the forrest for the trees
in this document.  I think what the document is trying to do is to define
how each link-layer provides indications and hints useful for DNA.

In order to accomplish this, somewhere in the document the DNA model
needs to be explained so that we know what DNA is looking for.  Then
it needs to describe how the various link-layers provide that information:
such as an indication of "link up" and whether the subnet has changed or
not.

"Hints" (especially hints relating to subnet change) aren't discussed
much.  This is needed because subnet change indications are required in
DNAv4 -- otherwise DNAv4 cannot function reliably and could do more harm
than good.

I'd therefore suggest that this document needs to analyze the down-side
risks in DNAv4/v6 early on and then categorize the "triggers" and "hints"
according to their reliability and usefulness.  For example, "link up"
is more useful in DNA than "link down" or "going down".  Also, the
underlying reliability of the indications is important.

One of the fundamental concepts underlying DNA is that link-layer
information may be unreliable -- and that therefore DNA needs to be robust
against misleading link-layer indications.

For example, it is possible for a link-layer indication to be accurate an
overwhelming portion of the time -- and still to be not worth considering,
depending on the penalty to be paid if the indication is wrong.

Therefore merely cataloging potential triggers and hints is not inherently
useful to DNA, unless the level of reliability/accuracy of "hints" is
categorized for each link-layer technology.

I'd suggest that the document would be easier to read if more
technology-specific information were moved to the Appendix.  Then the
sections on technology could include a summary sub-section within them,
providing the key information. As it is, it's hard to pick out what
the conclusions are for DNA among all the information provided.

As it stands, the document is more of an overall catalog of "triggers"
than a guide to use of link-layer information in DNA.
Reference is made to the "IP layer" consuming "triggers"
without a description or reference to what the DNA or IP specifications
say to do.  In places the lack of specificity could even be interpretted
as being in conflict with the DNA specification, as well as the
IPv4 Link-Local and DHCP specifications.

Abstract

"Certain link-layer technologies are capable of providing various link
status information to the IP module. Link-layer event notifications
(triggers) along with optional auxiliary data (hints) can help the IP
module make expedited decisions regarding configuration changes. This
draft provides a non-exhaustive catalogue of triggers and hints from
well-known link-layer technologies."

This abstract appears to distinguish between link-layer event
notifications and "hints".   I find this distinction confusing -- because
in DNA, triggers cannot be taken as reliable indications, and therefore
are themselves "hints".  Overall "hints" are not discussed much in this
document.

Section 1.0

"   It is not an uncommon occurrence for a host to change its point-of
   attachment to the network. This can happen due to mobile usage
   (e.g., a mobile phone moving among base stations) or nomadic usage
   (e.g., road-warrior case)."

I'm not clear whether this sentence is making the assertion that DNA
is useful even when the host is not mobile/nomadic.   For example,
are we saying that even a stationary host may encounter link-layer
events and therefore may need to determine if the point of attachment
has changed?

"   Each time a host changes its point-of attachment, it is possible
   that it will also have to change its IP-layer configurations, such
   as its IP address and default gateway information. "

I'd change this to "IP address, default gateway information and other
configuration parameters such as DNS server address(es)."

"The network detection phase can usually use network-layer indications
such as a change in the advertised prefixes."

This sentence implies a model that is not presented in the document
prior to now.  If you're going to refer to "phases" you need to
lay out what the phases are earlier on.

"Link-layer event notifications to the IP are considered link-layer
triggers."

I'm not sure whether this is a definition of "trigger" or something
else.  The word "trigger" implies that something is supposed to happen --
but I'm not clear that this is really the case in DNA.  I'd suggest that
this draft needs a terminology section to clarify the use of terms.

"It has been identified that receiving explicit triggers and
hints from the link-layer would expedite the detection process."

It is possible for link-layer indications to delay the detection
process considerably if they are incorrect, so that I would say
"can in certain circumstances be used to expedite".

The analysis of the conditions under which link-layer indications
are actually useful should be the main focus of this document.

"The link-layer indicating that the host has established a new connection
can be used as a trigger to further probe the network for a possible
configuration change. Additional hints when present can be used as
input to this process."

This sentence implies that link-layer indications can potentially
be unreliable, since the words "can" and "Additional hints" are used.
However, the previous sentence appears to make a distinction between
triggers and "hints", implying that triggers are not themselves hints.

I'd suggest that the draft needs to clarify this distinction.

"  A link-layer trigger cannot be used to positively determine the need
   for a configuration change as it might very well be the case that
   the host is still connected to the same IP subnet despite the link
   change."

This sentence doesn't clarify what potential "triggers" might
cause a configuration change -- and I think that discussion is needed
earlier.  For example, if the "trigger" in question is "link down"
then a host can't be "still connected", right?

Also, even though the host might still be connected to the same IP
subnet, it might still make sense to attempt to retrieve a new
IP configuration -- unless the "hint" is sufficiently reliable.

"   This is why the link-layer triggers should be used as "advisory-
   only" unless stated otherwise."

This sentence is essentially saying that a "triggers" is advisory.
Given this, what is the difference between a "trigger" and a
"hint"?

"   In order to enable an enhanced network attachment detection scheme,
   we need to identify types of link-layer triggers and hints that can
   be realistically expected from various access technologies. The
   objective of this draft is to provide a catalogue of existing link-
   layer triggers and hints in various architectures."

I'd argue that such a catalog is not inherently useful without discussing
the reliability of the hints involved for the purposes of DNA.  The
problem is that unreliable hints can actually make things worse, depending
on the downside for being wrong.

Section 3.1.2

In practice, GPRS networks typically interface to the IP layer via
use of PPP, so that the IP layer does not in fact see the indications
described in this section directly.  I'd suggest that this section
needs to describe the mapping of link-layer states to PPP states,
as Section 3.2.2 does.


"   In GPRS networks, only network attachment/detachment and subsequent
   PDP context changing events will directly impact the IP
   configurations, hence should be used as link-layer triggers by IP."

This sentence appears to imply that "link down" triggers are used by
IP somehow.  To my knowledge this is not defined anywhere -- nor are
we discussing this for DNA.  I'd suggest that we be more specific
here -- "only network attachment and subsequent PDP context changing
events are used as a trigger for evaluating the IP configuration".

I would therefore suggest that this section needs to describe the mapping
of the "triggers" to PPP link-layer behavior.

"The network-layer could then anticipate the loss of connectivity."

What is the implication for DNA?  For the IP layer?

Section 3.2.2

This section does describe how 3GPP2 link-layer events relate to
PPP states, unlike Section 3.1.2.

However, it also gets into how "triggers" are consumed by Mobile IP,
which appears out of scope for DNA.

"  Hence, a PPP resynchronization from the PDSN could be viewed as a
   link-layer event that updates network configuration information in
   the MN and further provides an indication to the MN that Mobile IP
   registration is required to update the binding in the HA with the
   new FA address."

In general, a change in network layer configuration requires re-running
NCP, no?  Remember, the IP layer may not even know that 3GPP2 is running
below it.

"From IP's perspective, changes in the PPP link status
provide a trigger and hints about the network attachment change."

I think you need to go into more detail on this. What PPP states map
to what DNA actions?

3.3.1

"An AP is a bridge between the wireless domain and the wired domain."

An AP is not actually a bridge as defined by 802.1D.

"
   A MN must be associated and authenticated with an AP in order to
   send and receive data frames. "

In IBSS, it is possible to send Class 1 data frames (with "From DS" and
"To DS" bits set to 0) in state 1 (unauthenticated and unassociated).

"At any given time, a MN can be associated with only one AP on each IEEE
802.11 radio interface."

This makes it sound like this is a radio issue.  It isn't.  Projects
like MultiNet have shown that a STA can simultaneously be associated
to multiple APs in different ESSes on a single radio interface
without problems.

The problem is being simultaneously connected to two APs within the
same ESS -- because of the confusion that results within the DS
(e.g. switch learning).

"A MN cannot send IP packets during the establishment of a connection with
an AP."

I think you mean to say that "In Infrastructure BSS mode, a STA cannot
send and receive Class 3 data frames (with "From DS" or "To DS" bits
set to 1) until it reaches State 3 (authenticated and associated)."

"   When a MN moves between two APs, it has to switch into promiscuous
   mode to discover and initiate a connection with a new AP. "

This is not accurate.  A STA does not receive packets not addressed to
it even when scanning.

"   Once the MN discovers its target AP and its parameters, an
   authentication phase begins (exchange of Authentication
   Request/Response)."

"When a MN succeeds the authentication process, it can associate with
the AP (exchange of Association Request/Response)."

It might help to say "In IEEE 802.11-2003, authentication occurs
prior to Association."

"In this framework, the
authentication is performed after the MN is connected to the AP by
utilizing protocols above the MAC layer. The process to be
associated with an AP is the same as in the model described above,
except that authentication at the MAC layer must not take place."

802.11i supports pre-authentication where authentication occurs
prior to association.  Also, technically there is authentication
at the MAC layer (Open Auth).

"As long as the MN moves between APs in the same access network, the IP
layer is not involved in the movement management. "

As you point out, movement within an ESS may imply change of subnets, so
this is not really true.

"This association is valid as long as the MN does not receive a
De-authentication message or a De-association message from its AP,
or the MN moves to a new AP."

The STA can just move out of range, no?  Also, it's "Disassociation".

"   So the reception of a (Re-)Association Response that completes a
   successful association conveys that the MN's point of attachment to
   the network may have changed."

Why not just say "implies that the link is usable for IP layer
connectivity (link up)."

"There is no mechanism at the link-
layer that allows the MN to know if it has also changed the IP
subnet."

Perhaps you should say to "reliably determine whether the STA has
changed IP subnets."  Some examples also might be helpful -- associating
to one "Linksys" AP and then to another "Linksys" AP doesn't even imply
that you're still on the same continent -- this SSID is set by default in
the equipment.

Section 4.2

"Network-layer may interpret this trigger as a sign of possible
configuration change."

In fact the DNAv4 specification says that a link-down indication
should not be considered.  There is a conflict here.