Re: [Tsvwg] WG: Announcement of the new work : Link Characteristic Information for Mobility

["James M. Polk" <[e-mail]>]

another acronym collision.... LCI is already defined as Location 
Configuration Information by the Geopriv and DHC WGs, and used/referenced 
by the ECRIT WG.

This reference ID below talks of link layer congestion as a target, various 
802 technologies and Cable/DSL - I would like to hear more of how this fits 
into a Transport Area space, and not the Internet Area.  I personally don't 
believe it fits RAI, except through APIs in various nodes/endsystems

At 09:10 AM 5/10/2006 +0200, Tschofenig, Hannes wrote:
>Fyi,
>
>this subject might be relevant for the Transport Area.
>
>Ciao
>Hannes
>
>-----Ursprüngliche Nachricht-----
>Von: Soohong Daniel Park [mailto:[e-mail]]
>Gesendet: Mittwoch, 10. Mai 2006 04:03
>An: IETF ML
>Cc: [e-mail]; [e-mail]; 
>[e-mail]; Tschofenig, Hannes
>Betreff: Announcement of the new work : Link Characteristic Information 
>for Mobility
>
>Hi
>
>The following is the work description of LCI (Link Characteristic 
>Information for Mobility). Jouni Korhonen, Hannes Tschofenig and I are 
>thinkig of having a new BOF in the IETF-66 on this subject (Target Area is 
>TBD, but presumably, TSV or RTA&Infra).
>
>The problem statement is available via the link below before IETF repository.
>http://daniel.vsix.net/lci/draft-korhonen-lci-link-characteristics-ps-00.txt
>
>
>Tip: To illustrate what we are trying to achieve in conjunction with LCI, 
>a simple flash demo is attached below. Look at the undesirable disruption 
>of Non-LCI mobile terminal comparing with LCI mobile terminal (service 
>quality is scalable) carefully. Note: It is JUST for your information, so 
>please don't consider it seriously...:-)
>http://daniel.vsix.net/lci/lci_concept.html
>
>
>Our mailing list is http://eeca16.sogang.ac.kr/mailman/listinfo/lci
>
>
>==================================
>Link Characteristic Information for Mobility (LCI)
>
>Updated: 2006-05-10
>Version: 0.9
>
>Description:
>
>Recently more and more mobile terminals are equipped with multiple
>interfaces for different L2 technologies. These mobile terminals make
>it possible to communicate through different wireless networks at
>the same time, or allow the most appropriate interface to be selected
>according to current conditions. In the latter case, transitions
>between heterogeneous links (vertical handovers) occur. Vertical
>handovers often cause an ongoing connection to experience sudden
>path characteristic changes (e.g. available bandwidth and delay).
>
>Although some transport protocols and application mechanisms provide
>congestion/flow control mechanisms, they are unable to detect and adapt
>quickly, and require to send a number of probes to determine the new
>network characteristics some time after the handover. The network
>capacity may have already been misused during the probing process,
>and the user experience can be disrupted. In some cases, handovers
>between the same type of links (horizontal handovers) may also lead
>to abrupt link characteristic changes, due to the different traffic
>loads on the old and the new networks. Moreover, even if handovers
>do not occur, the access link characteristics may change significantly
>due to the variations of the traffic load on current link. Both of
>these situations can lead to similar adverse effects as those on
>vertical handovers.
>
>As a matter of fact, the wireless access links are most likely the
>bottlenecks for wireless internet connections. Therefore, it would
>be ideal for mobile terminals to have the capability of sharing their
>access link characteristic information (LCI) with their relevant
>remote network nodes (including remote peers, mobility agents, and
>any other network nodes that may consider this information useful
>for optimizing network capacity usage and user experience). In case
>the bottleneck of a peer-to-peer connection locates in the middle
>of its path rather than its wireless access link (e.g. in the WLAN+ADSL
>access scenario, the ADSL link can be the bottleneck, instead of the
>WLAN), the access LCI would still be informational and the access LCI
>delivery mechansim can be extended to support path characteristics
>discovery. Sometimes, mobile terminals may have difficulties to obtain
>precise access LCI at any time, however, it is also important and
>heuristic to know the magnitude of change even without exact values,
>since this can act as a timely trigger to other mechansims at the
>relevant network nodes to re-investigate and renew their network
>capacity usage status.
>
>Existing IP mobility enabling technologies, however, do not provide a
>method to deliver the access LCI to the relevant remote network nodes.
>The principal objective of this work is to explore the possible
>signaling solutions for delivering the access LCI at the IP layer or
>above. Apparently, existing IP mobility protocols and transport protocols
>could be extended to support this useful feature, while the potential
>benefits and limitations need serious investigation. A new generic
>lightweight signaling protocol may need to be designed for carrying the
>LCI to tackle the limitations caused by using other protocol extensions.
>Importantly, the adoptable LCI delivery mechanism(s) must be secured,
>middlebox traversable, and must avoid significantly increasing the amount
>of signaling traffic load, especially over wireless links. At the same
>time, the tradeoff between the added LCI delivery and computation load
>and gained advantages is also an issue that needs careful examination.
>
>In multihoming scenarios, when multiple interfaces on the mobile terminal
>are used for one application for load sharing, it is desired that the
>LCI of each interface can be delivered simultaneously to the relevant
>remote network nodes. However, the methods of collecting the access LCI
>as accurate and timely as possible are out of the scope of this work.
>
>The proposed work will also cooperate with the working groups that may
>consider the access LCI useful, in order to facilitate the LCI utilization
>by them. Especially, it is expected that the transport area may benefit
>from the LCI delivery. It is also expected that real-time streaming
>services can be enhanced based on the availability of the LCI signaling.
>For example, SVC (Scalable Video Coding or H.264 Extended Profile) and
>BSAC-Bit Sliced Arithmetic Coding are designed to support a flexible
>control in terms of video and audio coder respectively following the
>receiver's network qualities, while their functions are limited at the
>moment due to the lack of dynamic signaling from the receiver when the
>link characteristic changes.
>
>Goals:
>
>- Produce "Link Characteristic Information for Mobility Problem
>   Statement" to describe the problem and limitation of the current
>   mobility solutions without link characteristic information delivery,
>   and clarify the motivation of designing the LCI signaling.
>
>- Produce "Link Characteristic Information Description" to describe the
>   required link characteristic information for delivery.
>
>- Evaluate a set of candidate proposals for Link Characteristic Information
>   Delivery (probably multiple documents required).
>
>- Produce "A lightweight signaling protocol for carrying Link Characteristic
>   Information" to design a new signaling mechanism for carrying Link
>   Characteristic Information including middlebox traversal and security
>   soluctions.
>
>Related Documents:
>
>- Link Characteristic Information for Mobility Problem Statement
>ID: draft-korhonen-lci-link-characteristics-ps-00
>
>- Link Characteristics Information for Mobile IP
>ID: draft-daniel-mip-link-characteristic-02
>
>- Link Characteristic Information Delivery Analysis
>ID: In progress
>
>- Quick-Start for TCP and IP
>ID: draft-ietf-tsvwg-quickstart-01
>
>- Datagram Congestion Control Protocol Mobility and Multihoming
>ID: draft-kohler-dccp-mobility-01
>
>- Mobile SCTP (mSCTP) for IP Handover Support
>ID: draft-sjkoh-msctp-01
>
>- IEEE P802.21/D01.00 Draft IEEE Standard for Local and Metropolitan Area
>   Networks: Media Independent Handover Services (accessable via MIPSHOP 
> chairs)
>
>- Architectural Implications of Link Indications
>ID: draft-iab-link-indications-04
>
>==================================
>
>Questions about this work can also be directed to the:
>
>Soohong Daniel Park <[e-mail]>
>Jouni Korhonen <jouni.korhonen@teliasonera>
>Hannes Tschofenig <[e-mail]>
>
>
>
>All comments are highly welcome....!
>
>
>Daniel (Soohong Daniel Park)
>Mobile Convergence Laboratory, SAMSUNG Electronics.