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

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

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" <[e-mail]>
To: "James Kempf" <[e-mail]>; "Carsten Bormann"
<[e-mail]>; "Lars-Erik Jonsson (EPL)" <[e-mail]>;
<[e-mail]>
Cc: <[e-mail]>
Sent: Tuesday, March 23, 2004 5:27 AM
Subject: Re: [Seamoby] AD Review Issues with draft-ietf-seamoby-ctp-08.txt


> 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
>
> James Kempf wrote:
> >
> > 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
>
> -- 
> 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 : [phone]
> Mobile: [phone]
> [e-mail]
> http://www.ericsson.com
>
> I have a new mail address: [e-mail]
> 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.
>


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