Subject: RE: Cellular host issues

From: Margaret Wasserman <[email-masked]>
Date: Thu, 30 May 2002 11:05:33 -0400

>
> > >        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? 

Saying that a host "may choose to not initiate" NUD messages is 
the same thing as saying that a host may choose not to comply with
the NUD portions of RFC 2461, which clearly indicates that hosts send 
NUD-related NA and NS messages in certain situations, such as when
an IPv6 packet is sent to/through a neighbor whose neighbor cache
entry is in the PROBE state.

I object to telling cellular host implementers that they don't have to comply 
with portions of RFC 2461.  RFC 2461 is a mandatory, core IPv6 specification, 
and all IPv6 nodes should comply with it. 

Your suggested text will not result in a significant decrease in traffic over the
wireless interface.  In fact, the suggested text will not result in the
elimination of _any_ NUD messages in the most typical case where everything 
is working properly.

And, even if we do form a rough consensus (despite my objections) that 
cellular hosts do not have to comply fully with the NUD-related portions
of RFC 2461, your proposed text is insufficient to specify what cellular 
hosts should/shouldn't implement.  If a host fully complies with RFC 2461, 
with the single exception that it doesn't initiate any NUD-related NS or NA 
messages, it could reach a point where it can't send any IPv6 packets at all.

Let me explain further...

Lets assume that a cellular host (CH) is attempting to establish communication
with a web server on the Internet (WS), using a 3GPP GGSN as its default
gateway, of course. 

Let's further assume that the neighbor cache on the CH already includes an entry 
for the GGSN, with the IsRouter bit set, due to previous Router Advertisements 
received from the GGSN -- otherwise, the CH wouldn't have an IPv6 address. 
This entry will be in the STALE state, as defined in RFC 2461 section 6.3.4.

First, let's look at what happens when all is going well...

ND indicates that address resolution is unnecessary when the link-layer address 
of the neighbor is already known.  This would apply in the 3GPP case, so no address 
resolution step would be required for CH to determine the link-layer address of the 
GGSN.

When the CH attempts to connect to the WS, with the neighbor cache entry in the 
stale state, no NUD NS will be sent.  The HTTP/TCP/IPv6 packet will be sent to the 
WS, and the neighbor cache entry will be moved to the DELAY state.  As long as 
a TCP acknowledgement is received, and upper layer advice provided to ND, within
5 seconds, no NUD messages are require.  Going forward, the neighbor cache will 
continue to be updated by the TCP layer whenever a newill proceed without any 
NUD messages at all.  

IMPORTANT POINT:  No NS or NA messages are sent, at all, in the case where full
connectivity exists between the CH, the GGSN and the WS.  This would be true
even if we were willing to initiate NUD messages, so your proposed optimization
does not actually save any bandwidth in normal operation.

But, what will happen when something goes wrong?  Let's assume that there is a 
network failure, perhaps between the GGSN and the WS, that is preventing traffic from 
passing between the CH and the WS.  

The CH may make repeated attempts to connect, over an extended period of time
(greater than 35 seconds), with the neighbor cache entry progressing from the 
REACHABLE state, to the STALE state, to the DELAY state, to the PROBE state.  

At that point, no HTTP/TCP/IPv6 packets will be sent (for any traffic to or through the 
GGSN -- which is all traffic that the CH might send) until two-way reachability can be 
established between the CH and the GGSN.  This would normally happen through the
GGSN's response to a NUD NS message sent by the CH, but what happens if the 
CH chooses not initiate those  messages, as suggested in the cellular host draft?  
Nothing.  No IPv6 packets will ever be sent by the CH again, until it is rebooted.  
Obviously this is not a desireable outcome.

So, along with your statement that the cellular host may choose not to initiate 
NUD-related NS messages, you would also need some changes to the NUD state 
machine to avoid entering the PROBE state.  This is a non-trivial change to ND,
and I don't think that we should suggest it in this document.

Margaret

> >     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: Jari Arkko <[email-masked]>
Date: Thu, 30 May 2002 23:08:56 +0300

> entry is in the PROBE state.

Ok, but this text fragment was not attempting to say anything about NUD,
that's why it explicitly said "in address resolution and next-hop
determination". But I can see that it can be interpreted the other
way. How about the following:

2.4 RFC2461 - Neighbor Discovery for IPv6

         Neighbor Discovery is described in [RFC-2461]. This
         specification is a mandatory part of IPv6.

         Hosts must support Neighbour Solicitation and
         Advertisement messages.

         In GPRS and UMTS networks, some Neighbor Discovery
         messaging can be unnecessary in certain cases.
         GPRS and UMTS links resemble a point-to-point link;
         hence, the host's only neighbor on the cellular
         link is the defaul router that is already known
         through Router Discovery. Therefore, while the
         host must support address resolution and next-hop
         determination, the host may choose to not initiate
         these tasks.

So hopefully this covers part of the problem. We still have to
deal with NUD. We already stated earlier that NUD is mandatory.
My understanding is that the discussion relates to the
kind of advice we can give to NUD for the suppression of
the messages:

   1) From the PDP context positive feedback all
      the way up to and including a working GGSN IP layer,
      even if this is strictly speaking lower layer from the
      point of view of the cellular host.

   2) From the upper layers, without mentioning specifics.
      Basically exactly what RFC 2461 says.

   3) From the upper layers, with some specific 3GPP
      guidance. For instance, SIP is heavily used over UDP.
      It might make sense to state that a SIP application
      should give the progress information it has to the
      UDP layer (which doesn't get any progress information)
      so that it can tell this information to IP.

Margaret, I do see the problem you described in your e-mail
about getting to the PROBE state, but as far as I can see,
the current proposal was to use suppress NUD *only* if you
got positive feedback. So, in your problem example the
host would actually get positive feedback and the entry
would be kept in the REACHABLE state.

The remaining question is whether the source of the feedback
can be 1, 2, or 3. Let me propose that we pick either 1 or 3.
Assuming 1 is ok, the following text would appear to do the
job:

         The host must support neighbour 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
         other layer protocols (such as TCP or PDP Context)
         to provide reachability confirmation when two-way
         IP layer reachability can be confirmed (see RFC-2461,
         section 7.3.1). These confirmations will allow the
         suppression of most NUD-related messages.

Assuming 3 is ok, the following text discusses a bit more
into the details regarding the upper layers in typical
3GPP hosts:

         The host must support neighbour 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 to provide
         reachability confirmation when two-way IP layer
         reachability can be confirmed (see RFC-2461,
         section 7.3.1). These confirmations will allow the
         suppression of most NUD-related messages.

         Host TCP implementation should provide
         reachability confirmation.

         The use of UDP for many purposes in 3GPP
         networks poses a problem for providing this
         reachability confirmation. UDP itself is
         unable provide such confirmation. Instead,
         applications running over UDP should provide
         the confirmation where possible. In particular,
         when UDP is used for transporting RTP, the RTCP
         protocol feedback should be used as a basis for
         the reachability confirmation. When UDP is used
         for transporting SIP, responses to SIP requests
         should be used as the confirmation.

Jari

---

From: Margaret Wasserman <[email-masked]>
Date: Thu, 30 May 2002 20:52:44 -0400

Hi Jari,

This looks good to me.

Margaret

At 06:34 PM 5/30/02 , Jari Arkko wrote:

>Follow-up to my own e-mail, after some off-line discussions.
>Here's an updated suggestion for the address resolution etc part:
>
>
>        through Router Discovery. There are no link layer
>
>        addresses. Therefore, address resolution and next-hop
>        determination are not needed.
>
>Secondly, about alternative 1 for the advice to give for NUD.
>
>I've been asked to provide more details about the specific
>protocol layers, whether the tunnel and the payload stacks
>are the same etc. We'll send an e-mail about this tomorrow.
>
>Finally, for alternative 3 I have some updated text regarding
>what kind of advice to give:
>
>
>        Section 7.3.1). These confirmations will allow the
>        reachability confirmation in the manner
>
>         explained in RFC 2461, Section 7.3.1.
>
>
>        the reachability confirmation. If an RTCP
>
>         packet is received with a reception report block
>         indicating some packets have gone through, then packets
>         are reaching the peer. If they have reached the
>         peer, they have also reached the neighbour.
>
>        When UDP is used for transporting SIP, responses to
>
>        SIP requests should be used as the confirmation that
>
>         packets sent to the peer are reaching it.
>         The receipt of new non-retransmitted requests within
>         a SIP dialog should be used as a confirmation that
>         previous responses have reached the peer.
>
>Jari

---

From: Jari Arkko <[email-masked]>
Date: Fri, 31 May 2002 01:34:05 +0300

Jari

---

From: Robert Elz <[email-masked]>
Date: Fri, 31 May 2002 17:37:23 +0700

Date:        Thu, 30 May 2002 23:08:56 +0300
    From:        Jari Arkko <[email-masked]>
    Message-ID:  <[email-masked]>

  | But I can see that it can be interpreted the other
  | way. How about the following:

How about you include this ...

  | 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
  | 
  |          Hosts must support Neighbour Solicitation and
  |          Advertisement messages.
  | 
  |          In GPRS and UMTS networks, some Neighbor Discovery
  |          messaging can be unnecessary in certain cases.
  |          GPRS and UMTS links resemble a point-to-point link;
  |          hence, the host's only neighbor on the cellular
  |          link is the defaul router that is already known
  |          through Router Discovery.

But stop there (and s/defaul/default/ of course).

ND (for link address discovery) is only ever necessary when the link
address isn't known - there's no real need to emphasize that point,
and by so doing, perhaps lead people to infer things that are not
really intended.

It's also worth noting of course, that RA messages aren't required
to carry the link level address (in general anyway, perhaps for 3GPP
you are mandating that?)

If the link level address isn't there, ND would be required to find
it, wouldn't it?

kre

---

From: Margaret Wasserman <[email-masked]>
Date: Fri, 31 May 2002 08:13:39 -0400

Hi Robert,

>If the link level address isn't there, ND would be required to find

There are not link-level addresses on the point-to-point link between
the handset and the GGSN.  So, no need to do anything to resolve
them.

Margaret

---

From: Robert Elz <[email-masked]>
Date: Fri, 31 May 2002 22:46:49 +0700

Date:        Fri, 31 May 2002 08:13:39 -0400
    From:        Margaret Wasserman <[email-masked]>
    Message-ID:  <[email-masked]>

  | There are not link-level addresses on the point-to-point link between
  | the handset and the GGSN.  So, no need to do anything to resolve
  | them.

OK, in that case, I don't understand why there's any kind of issue
at all - and I certainly wouldn't be explaining away the need for
ND by reference to RA packets ("router discovery").

If there are no link level addresses, just say that, no need to mention
ND at all, it will clearly be irrelevant.

kre