[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [More] Session Mobility
James,
With regards to moving IP traffic from one device to another and maintaining the
session, could you give some examples of potential applications that may require
this functionality?
Data type applications (e.g. ftp, http, database transactions, telnet) may not
be possible because the applications need to maintain transaction state
information. To move the session to a new device would require the application
to be moved including transport layer protocol's state information. I don't
think "Mobile Applications" exist as yet - but the concept has potential. Next
time the message "Low on Virtual Memory" pops-up transfer some apps to another
computer. ;-)
For streaming services, some minimal state information may have to transferred,
e.g. authentication keys. This information could be transferred by IR or
bluetooth between the devices. Session transfer could be accomplished during
this process. Not impossible, but requires some capabilites on the devices.
Just some ideas.
Amish
James Kempf <James.Kempf@Sun.COM> on 20/09/2001 16:55:12
Please respond to James Kempf <James.Kempf@Sun.COM>
To: more@psg.com
Amish CHANA/EN/HTLUK@HTLUK
cc:
Subject: RE: [More] Session Mobility
Amish,
>
>By session mobility I am refering to all possible types of user sessions. This
>section in the draft certainly does not focus on one type of service, e.g. SIP
>telephony, but applies to all Internet sessions. The draft is also worded such
>that session mobility has to be the responsibility of the network.
>
>I mentioned in my previous email that session mobility "depending on the type
of
>service" does not need to be the responsibility of the network and multi-homing
>could address some of the session mobility issues.
>
>Managing session mobility on the network would be advantageous for streaming
>delay-sensitive data. Delay tolerant data could be better served by
multi-homing
>where buffering of data that arrives out-of-order and retransmissions are
>considered acceptable (e.g. http and ftp type sessions).
>
>I think the requirements need to be a little flexible, such that session
>mobility is not only the network's responsibility. Any objections?
>
No objections, but I still don't see a distinction here between:
1) Moving IP traffic, perhaps selectively (e.g. just http and not ftp), from
one interface to another on the same device.
2) Moving IP traffic, perhaps selectively, from one device to another.
The first seems fairly straightforward to implement, and discussion about
how is well underway in the IETF. I believe there is even a draft
about how to move selective IP flows from one interface to another.
The second seems fairly difficult to implement, since it requires a case
by case examination of the application protocols. Most application
protocols don't allow changing from one device to another, and I
suspect there will be a fair amount of resistence on the part of
some application protocol groups to providing support for it.
jak
*******************************************************************************
Important. This E-mail is intended for the above named person and may be
confidential and/or legally privileged. If this has come to you in error you
must take no action based on it, nor must you copy or show it to anyone; please
inform the sender immediately.
*******************************************************************************