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

From: "James Kempf" <[email-masked]>
Date: Fri, 12 Mar 2004 15:51:58 -0800

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
[email-masked]
https://www1.ietf.org/mailman/listinfo/seamoby

---

From: Rajeev Koodli <[email-masked]>
Date: Fri, 19 Mar 2004 15:25:20 -0800

Hello Jim,

"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. " does not sound like a
good reason for an experimental protocol. We have not had any
experiences with actual deployments to support this seemingly logical
statement. And, one could argue that we could state in the applicability
statement that "the usefulness of the protocol on routinely congested
networks could be limited". BTW, I am not arguing for UDP. I would
like to have the CTP messages as blocks that could be carried in ICMP
so that they could be used in conjunction with fast handovers.

As you note below, both TCP and SCTP have shortcomings not suitable
for CT which is useful mostly when synchronized tightly with fast
handovers. The distinction between failed CT due to a dropped packet and
a CT that is not on time is thin. Besides, features (QoS, HC) always need to
have recovery mechanisms anyway, which would re-build the state.
So, I would suggest using ICMP without re-transmissions. We know
the links where it works. We would like to try it on bottlenecked links and
provide some data, which we could use when the spec is up for PS.

Regards,

-Rajeev

---

From: Ghyslain Pelletier <[email-masked]>
Date: Tue, 23 Mar 2004 14:27:01 +0100

Hi,

> The review by someone from the ROHC WG turned up no issues.

Who is this reviewer? What were the comments?
If I understand correctly from an earlier mail from James Kempf (March
11th), this person is not Carsten Bormann, and I know that it is not his
ROHC co-chair either for having asked.

I think the draft should be submitted for review to the ROHC wg via
their mailing list. After all, it has been written many times on the
Seamoby mailing list that "ROHC is a potential customer of CTP", so I
don't see any reason not to send the document for a somewhat broader
review to that wg.

Best regards,

/Ghyslain  

-- 
Ghyslain Pelletier, Dipl. Ing.
Wireless IP Optimizations
AWARE - Advanced Wireless Algorithm Research
Ericsson Research, Corporate Unit

Ericsson AB, Laboratoriegränd 11
Box 920, S-97128 Luleå, SWEDEN
Phone : +46 (0) 920 20 24 32 
Mobile: +46 (0) 706 09 27 73
[email-masked]
http://www.ericsson.com

I have a new mail address: [email-masked]
My old e-mail address will function until 2004-06-01.
Please change my address in your personal address book.

This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you.

E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof.

---

From: "James Kempf" <[email-masked]>
Date: Tue, 23 Mar 2004 10:54:17 -0800

Ghyslain,

The draft is at
http://www.ietf.org/internet-drafts/draft-ietf-seamoby-ctp-08.txt. Since we
currently have a disagreement about what transport protocol to use, we will
not be able to send the draft to the IESG until that is resolved, which
might take a while. If you or anyone else in ROHC have comments on the
draft, please send them to the Seamoby list by April 5. Otherwise, as with
any IETF draft, you can send your comments during IETF Last Call if you
don't manage to read the draft in the next two weeks. When you read the
draft, please keep in mind that the protocol is intended to be published as
Experimental, not Standards Track, because there are many open questions,
and also please remember that ROHC is not the only application for CT.

BTW, there is a draft draft-koodli-seamoby-hc-relocate-03.txt which is now
expired that describes a ROHC context profile. There are efforts under way
to implement and test this draft, in the context of the MOBOPTS IRTF
research group. Since the Seamoby charter does not cover doing specific
context profiles (and the IESG wants Seamoby to close down as soon as
possible), Seamoby can't really continue working on it, but there is some
interest in seeing it discussed in ROHC, where the experts on header
compression are. Hopefully, the experiments that are currently under way can
help resolve some of the controversy about CT for header compression by
basing discussion about whether CT for header compression actually helps
reduce handover latency on experimental data rather than on microphone time
and mailing list opinion.

            jak

----- Original Message ----- 
From: "Ghyslain Pelletier" <[email-masked]>
To: "James Kempf" <[email-masked]>; "Carsten Bormann"
<[email-masked]>; "Lars-Erik Jonsson (EPL)" <[email-masked]>;
<[email-masked]>
Cc: <[email-masked]>
Sent: Tuesday, March 23, 2004 5:27 AM
Subject: Re: [Seamoby] AD Review Issues with draft-ietf-seamoby-ctp-08.txt

> This communication is confidential and intended solely for the
addressee(s). Any unauthorized review, use, disclosure or distribution is
prohibited. If you believe this message has been sent to you in error,
please notify the sender by replying to this transmission and delete the
message without disclosing it. Thank you.
>
> E-mail including attachments is susceptible to data corruption,
interruption, unauthorized amendment, tampering and viruses, and we only
send and receive e-mails on the basis that we are not liable for any such
corruption, interception, amendment, tampering or viruses or any
consequences thereof.

---

From: "James Kempf" <[email-masked]>
Date: Mon, 29 Mar 2004 09:11:40 -0800

Rajeev,

Since nobody has responded to your message, I suppose I must. Note that I'm
responding here from a technical standpoint and not as WG chair.

Your assertion that we do not know today definitively how these access
networks will be deployed, nor do we really have any data on existing
deployed hotspot or WAN wireless networks sounds accurate, at least as far
as I'm aware. My assertion in the original email about congestion was based
on talking with people who have been working on congestion control for most
of their career and my limited knowledge about how some of these networks
are deployed. In the US, it is common to underprovision DSL networks by up
to 80:1 through a T1 line, and T1 is also being used extensively for hotspot
deployments, such as T-mobile's deployments in Starbucks. Nevertheless,
there are other networks, such as most of those in Japan, that don't use T1
much, and intuition is never a substitute for hard experimental data. Until
someone has measured traffic on access networks and can say whether
congestion will be a problem, it remains conjecture.

With regard to your proposal to use ICMP, even disregarding the congestion
issue, I think this is a basic nonstarter as far as CTP is concerned, since,
at least for IPv6, there is a limitation on packet size of the MTU, and I
think there is also a limit for IPv4,  but I've been unable to find a
reference. While again it is difficult to predict, it is possible that the
amount of context information could exceed that limit, since unlike FMIP,
the amount of information in a CTD message is not fixed. A node could have
any number of video/audio sessions active, to say nothing of other context
information.

From the standpoint of achieving a uniform interrouter protocol for mobile
handover information transfer, it would certainly be prefereable from an
architectural standpoint to have one transport protocol for all of FMIP,
CARD, and CTP. Currently, FMIP uses ICMP, CARD uses a UDP with fixed
retransmit (also a problem that will need to be fixed), and CTP used UDP
with optional, unspecified fixed retransmit interval. Since FMIP and CTP are
time critical, their requirements for timeliness are a bit different than
for CARD, but I think that the congestion properties of the networks in
which they operate would be expected to be approximately the same. Do you
agree?

The proposal for SCTP was based on what I believe is called "partial
retransmit" mode, in which SCTP only retransmits until a timer pops. This is
different from TCP. I'm not familiar with the details of this, maybe someone
who knows SCTP better can comment. The people who I've talked to about this
believe that the partial retransmit mode should accommodate the need for
timeliness. With regard to the assertion that reliability is not needed
because the node can re-establish the state anyway, this is true, but the
difficulty is that if access networks do turn out to be congested and the
traffic is dropped, the handover optimizations could potentially fail so
often as to make them not useful, which is the point I was trying to make in
the original note.

Putting back my WG chair hat on, Allison's proposal to use SCTP is based on
the tradition in IESG/IETF of conservative design when it comes to questions
of congestion control, i.e., it is better to put something in there now that
has congestion control features than find out later, to our regret, that the
protocols are causing a congestion problem, even though they are
experimental and even though they are published with an applicability
statement warning people about the potential for a problem. This tradition
has served IETF well in the past, and I believe it makes a lot of sense now.
If it does turn out after much measurement and experimentation that
congestion is not a problem in wireless access networks, the transport
protocol can be changed when and if CTP ever goes to PS.

As a practical matter, we really do need to get this spec published, and we
cannot get it published (indeed it will not even be reviewed by the IESG)
until we satisfy Allison's concern about the transport protocol. Therefore,
I'd like to again propose that we use SCTP. I think we should also include a
paragraph in Section 3 which summarizes our discussion on this list, and
explicitly calls out the transport protocol as an area where more research
is needed, which I hope will satisfy your concerns about our current state
of knowlege in this area.

            jak