Subject: RE: Cellular host issues

From: [email-masked]
Date: Thu, 30 May 2002 10:27:24 +0300

Hi Margaret,

> >        "2.4 RFC2461 - Neighbor Discovery for IPv6
> >
> >        Neighbor Discovery is described in [RFC-2461]. This
> >        specification is a mandatory part of IPv6.
> >
> >        2.4.1 Neighbor Discovery in 3GPP Networks
> >
> >        In GPRS and UMTS networks, some Neighbor Discovery
> >        messages can cause unnecessary traffic and consume
> >        valuable (limited) bandwidth. GPRS and UMTS links
> >        resemble a point-to-point link; hence, the host's
> >        only neighbor on the cellular link is the default
> >        router that is already known through Router Discovery.
> >        Therefore, while the host must support Neighbor
> >        Solicitation and Advertisement messages, their use
> >        in address resolution and next-hop determination is
> >        not necessary and the host may choose to not initiate
> >        them.
> 
> I don't think that we should include the last sentence of 
> this paragraph.

Can you detail what your objection to the last sentence is? 

>     2.4.1 Neighbor Discovery in 3GPP Networks
> 
>          The host must support the Neighbor Solicitation and
>          Advertisement messages for neighbor unreachability
>          detection as specified in [RFC-2461].
> 
>          In GPRS and UMTS networks, it is very desireable to
>          conserve bandwidth.  Therefore, hosts stacks used in
>          these environments should include a mechanism in 
>          upper layer protocols (such as TCP) to provide 
>          reachability confirmation when two-way reachability 
>          can be  confirmed (see RFC-2461, section 7.3.1).
>          These confirmations will allow the suppression of 
>          most NUD-related messages.

My feeling is that upper-layer protocols are out of scope of
this document, and I am uncomfortable making a recommendation on 
including them in this document.  I think that it would be possible
to say that, when available, these mechanisms can be used,
something like this:

        In GPRS and UMTS networks, some Neighbor Discovery
        messages can cause unnecessary traffic and consume
        valuable (limited) bandwidth. GPRS and UMTS links
        resemble a point-to-point link; hence, the host's
        only neighbor on the cellular link is the default
        router that is already known through Router Discovery.
        Additionally, upper-layer protocols can provide
	  reachability confirmation when two-way reachability 
        can be  confirmed (see RFC-2461, section 7.3.1).
        These confirmations allow the suppression of 
        most NUD-related messages. Therefore, while the host must 
        support Neighbor Solicitation and Advertisement messages, 
        their use in address resolution and next-hop determination is
        not necessary and the host may choose to not initiate
        them.
 
>          [If there are any upper-layer 3GPP protocols that can
>          provide reachability confirmation, meeting the definition
>          in the ND spec, we should mention them here.]

I don't have the 3GPP documentation in front of me, perhaps one of the other
authors can comment here.

> Please note that the IPv6 specs consistenly misspell neighbour as
> "neighbor" :-).  We should also use that spelling in this 
> specification.

Actually, Neighbour is the correct spelling in British English,
so I would not classify it as a misspelling (I think that several
of the authors of the document have been taught British English).
However, we should be consistant in the document.

John

--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: Thomas Narten <[email-masked]>
Date: Thu, 30 May 2002 11:18:04 -0400

Speaking individually, as someone involved in the original NUD
discussions...

> > I don't think that we should include the last sentence of 

Some of the thinking behind NUD is:

1) it's intended to test end-2-end IP connectivity at the
   neighbor-to-neighbor level. Even of L2 can indicate to L3 when the
   L2 link "goes away", that doesn't mean NUD is not necessary. The IP
   module on the neighbor may not be functioning properly, even though
   the L2 link is up. NUD detects such situations.

2) If NUD indicates there is a problem with neighbor connectivity,
   there are some steps to take to try and find an alternate
   path. Rerunning ND may result in a new link-layer address being
   found for the destination that reestablishes connectivity. Or,
   perhaps the neighbor is actually a router and an alternate router
   can be found.

3) NUD is only used if there is IP traffic thorough some neighbor, but
   the upper layers (TCP, specifically) are not telling the IP/NUD
   layer that ACKS are coming back. I.e., normally, if there is (say)
   TCP usage, NUD won't need to be used at all. So no
   extra/unnecessary traffic.

From the above, I don't quite buy the argument that NUD is not needed
on the link for the reasons given in the document.  On the other hand,
I understand that things are more complex in some scenarios (like the
target of the document at issue). Specifically:

1) 3GPP will be using lots of UDP (RTP and friends) and maybe not so
   much TCP? So upper layer hints may not be readily available (or, in
   anycase, there is no document explainig how to do this).

2) If (and only if) there is only a single p2p (e.g., no other
   interfaces to other networks), there is presumably no recovery
   possible in the case that NUD fails. So one could argue, what's the
   point?

But the celluar document could do a better job of explaining these
issues and the tradeoffs than it does.

> to say that, when available, these mechanisms can be used,

Actually, it makes sense to me to encourage stack builders to be smart
about providing feedback from upper layers to lower layers in order to
avoid the need for NUD _in those cases where it makes sense to from
the NUD protocol perspective_. Not mentioning this, seems like not
providing good guidance.

Thomas