[Seamoby] AD Review Issues with draft-ietf-seamoby-ctp-08.txt

["James Kempf" <[e-mail]>]

AD Review of the CTP draft (draft-ietf-seamoby-ctp-08.txt) is now complete.
The review by someone from the ROHC WG turned up no issues. However, in
discussions with Allison, there were a couple issues that arose. They are
listed below. Prior to submitting a revised draft to the IESG for review,
Allison and I would like to obtain resolution on these issues. Please send
comments to the list by next Fri. (March 19).

            jak

-------------------------------

Issue 1
--------

Issue: The MLD example in Appendix B as written is not very persuasive. The
3G protocols don't use ND, and 802.11 is fast enough that it wouldn't make
much difference.

Suggested resolution: Replace the first paragraph of Appendix B with the
following:

   In the past, credible proposals have been made in the Seamoby Working
Group
   and elsewhere for using context transfer to speed handover of
authentication, authorization,
   and accounting information, distributed firewall state, PPP context, and
header
   compression context. Because the Working Group was not chartered to
   develop context profile definitions for specific applications, none of
the proposals
   submitted to Seamoby were accepted as Working Group items. At this time,
work
   continues to develop a context profile definition for RFC 3095 header
compression
   context [RFC3095] and to characterize the performance gains obtainable by
using
   header compression, but the work is not yet complete. In addition, there
are several
   commercial wireless products that reportedly use non-standard,
non-interoperable
   context transfer protocols.

   As a consequence, it is difficult at this time to point to with a solid
example of
   how context transfer could result in a commercially viable, widely
deployable,
   interoperable benefit  for wireless networks. This is one reason why CTP
is being
   proposed as an Experimental protocol, rather than Standards Track.
However, it
   nevertheless seems valuable to have a simple example that shows how
handover
   could benefit from using CTP. As an example of how context transfer can
improve the
   performance of IP layer handover, we consider transferring IPv6 MLD state
[RFC2710].
   MLD state is a particularly good example because every IPv6 node must
  perform two MLD messaging sequences on the wireless link to establish
   itself as an MLD listener prior to performing router discovery
   [RFC2461] or duplicate address detection [RFC2462] or before
   sending/receiving any application-specific traffic (including Mobile
   IP handover signaling, if any). The node must subscribe to the Soli-
   cited Node Multicast Address as soon as it comes up on the link. Any
   application-specific multicast addresses must be re-established as
   well. Context transfer can significantly speed up re-establishing
   multicast state by allowing the nAR to initialize MLD for a node that
   just completed handover; without any MLD signaling on the new wire-
   less link. The same approach could be used for transferring multicast
   context in IPv4.

and add the following paragraph after the second paragraph Appendix B in the
current draft:

   This example might seem a bit contrived because MLD isn't used in typical
   cellular protocols and wireless local area network protocols typically
have
   enough bandwidth that sending a single MLD message might not be viewed
   as such a performance burden. An example of a wireless protocol where MLD
   context transfer might be useful is IEEE 802.15.1 (Bluetooth). IEEE
802.15.1 has
   two IP "profiles": one with and one without PPP. The profile without PPP
would
   use MLD. 802.15.1 has a maximum bandwidth of about 800kbps, shared
between
   all nodes on the link, so a host on a moderately loaded 802.15.1 access
point could
   experience the kind of bandwith described in the previous paragraph. In
addition
   802.15.1 handover times typically run upwards of a second or more because
the
   host must resynchronize its frequency hopping pattern with the access
point, so
   anything the IP layer could do to to alleviate further delay would be
beneficial.

and removing the following two sentences from the second paragraph in
Appendix B:

  The former is approximate for a narrowband 3G cel-
   lular links and the latter for a heavily utilized 802.11b WLAN link,
   both running Voice over IP (VoIP).

  Considering most ATM-based 3G voice cellular pro-
   tocols try to keep total voice handover delay less than 40- 80 msec.,
   MLD signaling could have a large impact on the performance of inter-
   subnet VoIP handover.

Issue 2
--------

Issue: The draft as written specifies using UDP without retransmit for the
transport protocol. This is not acceptable from a congestion control and
usability standpoint, the points made in Appendix  A about timing
notwidthstanding. Both Allison and James brought up these issues at various
times during the requirements discussion and during previous reviews of the
draft.

The issue with UDP is that CTP is expected to be used frequently between
access routers in a wide area network, like between two hotspot clusters
connected by T1 or other low capacity lines. Since access networks of these
types are just where one might expect congestion to develop, the frequency
of packet drops for UDP without retransmit would be expected to be high
enough to render the protocol unusable in general. While the Working Group
could develop a specialized UDP retransmit algorithm, there is no need since
both TCP and SCTP could provide adequate performance for CTP. Below are two
suggestions for resolution of the issue, and a preferred resolution.

Suggestion 1: Use TCP.

The advantage of this suggestion is that TCP is already widely implemented
and is well understood, so it could serve for immediate implementation and
experiment. The disadvantage is that TCP provides no way to control the
retransmit timer in general, so the timeliness of the transfer could not be
assured without additional measures.

Suggestion 2: Use SCTP.

The advantage of using SCTP is that it provides a partial reliability mode
which allows the retransmit timer to be set. This would allow the timeliness
of the transfer to be controlled. The disadvantage is that SCTP is not yet
widely implemented.

Preferred Resolution: Suggestion 2.




_______________________________________________
Seamoby mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/seamoby