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

[Ghyslain Pelletier <[e-mail]>]

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