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

From: "James M. Polk" <[email-masked]>
Date: Wed, 10 May 2006 13:53:11 -0500

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:[email-masked]]
>Gesendet: Mittwoch, 10. Mai 2006 04:03
>An: IETF ML
>Cc: [email-masked]; [email-masked]; 
>[email-masked]; 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 <[email-masked]>
>Jouni Korhonen <jouni.korhonen@teliasonera>
>Hannes Tschofenig <[email-masked]>
>
>
>
>All comments are highly welcome....!
>
>
>Daniel (Soohong Daniel Park)
>Mobile Convergence Laboratory, SAMSUNG Electronics.

---

From: <[email-masked]>
Date: Wed, 10 May 2006 21:59:48 +0300

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

LINCIM? (LINk Characteristic Informamation for Mobility)?
´
>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

I think it is probably quite relevant for TSV; but it will have
strong connections to Internet area, due to the impact of mobility
events on congestion control mechanisms.

John

---

From: "James M. Polk" <[email-masked]>
Date: Wed, 10 May 2006 14:20:39 -0500

>LINCIM? (LINk Characteristic Informamation for Mobility)?

"link`em"...

I like how that sounds

>I think it is probably quite relevant for TSV;

I see the impact - but not the relevance yet - to Transport, and just want 
to hear more about why here (in Transport).  I'm not opposed to it (yet  ;-)

>but it will have

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 10 May 2006 22:24:28 +0200

Hi James,

James M. Polk wrote:
> Configuration Information by the Geopriv and DHC WGs, and 
> used/referenced by the ECRIT WG.

Nice that you mention this. I should have made sure that this acronym 
collision does not happen....

> 
> 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

I have also suggested todo this in the Internet Area.
But there are arguments for all three areas.

Ciao
Hannes

>> Betreff: Announcement of the new work : Link Characteristic 
>> Information for Mobility
>>
>> Hi
>>
>> thinkig of having a new BOF in the IETF-66 on this subject (Target 
>> Area is TBD, but presumably, TSV or RTA&Infra).
>>
>> 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...:-)
>>   Networks: Media Independent Handover Services (accessable via 
>> MIPSHOP chairs)
>>

---

From: Joe Touch <[email-masked]>
Date: Wed, 10 May 2006 14:15:33 -0700

> LINCIM? (LINk Characteristic Informamation for Mobility)?

Ick. _PATH_ characteristics maybe.

Unless you're moving _exclusively_ within a link instance, in which case
why is the network layer either involved or aware?

Joe

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 11 May 2006 00:00:32 +0200

You raised an important point.

We also tried to capture the different solution alternatives available 
particularly when it comes to local knowledge related to the link vs. 
path properties in the problem statement draft.

Ciao
Hannes

---

From: <[email-masked]>
Date: Thu, 11 May 2006 06:04:23 +0300

>Ick. _PATH_ characteristics maybe.

Path Implicatatations of Link Changes (PILC)?  (talk about namespace
collisions)

>Unless you're moving _exclusively_ within a link instance, in 
>which case why is the network layer either involved or aware?

Agreed.

To answer James why in TSV - the original PILC and the TRIGTRAN bof
were TSV; the mechanism for exchanging the link change info would
be end-to-end, most likely over some well-known transport protocol.

One could make a case for piggy-backing this information on MIPv6
route optimization, but my feeling is the proposed work area would
be more general than just MIPv6.

John

---

From: Soohong Daniel Park <[email-masked]>
Date: Thu, 11 May 2006 12:19:54 +0900

CCing LCI mailing list...

>Configuration Information by the Geopriv and DHC WGs, and used/referenced 

Oops, I didn't realize that...Anyway, thanks your notice.

---

From: Soohong Daniel Park <[email-masked]>
Date: Thu, 11 May 2006 14:01:50 +0900

>be more general than just MIPv6.

Absolutely and thanks John for your keen observation. Along with
MIP case, we can use some of protocols for piggybacking LCI such
as DCCP, SCTP, RTP and even SIP. However, our proposed work
is more general than these. In paralle, we are ananlzing and evaluating
candidates protocols as depicted in the BOF description. Remind that
LCI work is not for mobility enhancement itself but facilitating mobility
from the application (and user's voice) perspective.

For example; in case of DCCP+LCI, a new option is added 
into DCCP mobility framework. Link is composed of 100Mbps
and 10Mbps wireless. As result, we had outstanding results as follows;

Average time for stable end-2-end communication after DCCP 
congestion control schem and throughput :

100Mbps --> 10Mbps
- DCCP mobility : 3648 ms (throughput: 1.876Mbps)
- DCCP mobility + LCI : 255.6 ms (throughput: 6.646Mbps)

10Mbps --> 100Mbps
- DCCP mobility : 399.2 ms (throughput: 246.57Kbps)
- DCCP mobility + LCI : 133.8 ms (throughput: 59.74Mbps)

We will bring more details (other candidate protocols) to illustrate
why we should consider LCI concept at this stage (overapping
various wireless coverages around us...)

---

From: sksubha <[email-masked]>
Date: Mon, 15 May 2006 20:27:57 +0530

Hello,

   As per RFC 2960, the recommended values for Association Max. 
Retransmission and Path Max. Retransmission are 10 and 5 respectively. 
Are these values with the consideration of single path per association? 
What should be the values of these parameters, if there are 4 interfaces 
(paths) on the Multi-homed end point?

thanks,
Subhashini ...

---

From: sksubha <[email-masked]>
Date: Tue, 16 May 2006 17:43:59 +0530

Please ignore this mail.

thanks,
Subhashini ...

sksubha wrote:

> Are these values with the consideration of single path per 
> association? What should be the values of these parameters, if there 
> are 4 interfaces (paths) on the Multi-homed end point?
>
> thanks,
> Subhashini ...
>
>
>
>