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

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  

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
> [email-masked]
> 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 : +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.

_______________________________________________
Rohc mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rohc

---

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.