Re: [mif] draft-deng-mif-api-session-continuity-guide-02

["Hui Deng" <[e-mail]>]

Hi Pierrick,

 

Thanks for your comments, excuse me for late reply, inline please,

 

From: [e-mail] [mailto:[e-mail]] On Behalf Of
[e-mail]
Sent: Wednesday, July 25, 2012 11:01 PM
To: 'Hui Deng'; Brian E Carpenter
Cc: [e-mail]
Subject: Re: [mif] draft-deng-mif-api-session-continuity-guide-02

 

Hi Hui,

 

I’ve just gone through this draft and I think it is a good start. In this
I-D, the MIF just exposes the list of available IP connection to the
application which is supposed to make the selection of the preferred
interface. Triggers for selection process are IP connectivity coming up or
going down. That’s one valid use-case, but I guess there are another which
would be worth to cover.

For example, it is said that the application can switch over interface
without disrupting communications. Here I guess that, implicitly, we assume
an IP address change ant that the application can survive to this IP address
change. That’s ok, but not all applications can switch over interface
without disrupting communication, and additional mechanisms may come into
play (e.g. IP mobility management).

== > You are right, not all of them, it depends on what’s the definition of
session continuity, IP mobility use virtual interface to guarantee the
session continuity should be mention in this document, thanks for pointing
out.

 

Also, in steps 5/section 4, it is said that the application could make the
decision to turn off the interface. But sometimes it cannot be as simple as
this; for example, what if another application is using the interface at the
same time… kind of coordination is required here. So, maybe it would be
useful to identify concrete use-cases and describe the use of MIF API with
respect to these use-cases. 

== > I think your point is valid, application should not switch off the
interface, we may prompt to the user check whether it need to be switched
off?

 

Then, the text refers to the decision process for selecting a new interface
based on policy or user preferences. I agree that the decision process is
not part of the MIF API; typically it may be in the scope of the high-level
API we have sometimes evoked (typically, in the OMA workshop during last IEF
meeting ). If I remember well, during IETF83, we said that it would be good
to document such high-level API as well; is it still in the TODO list of the
WG? 

== > MIF wg  is open for new submission like high level api

 

Another thing that comes to my mind: mapping dynamically an IP flow to an
interface, as suggested in the draft,  might have an impact on the terminal
policy table. IMHO, it could be a function of the MIF API to update routing
table according to application decision, what do you think?

== > I thought the status of interface information could update the routing
table, other MIF API itself, you may comment on the MIF API draft

 

BTW, I’d suggest to swap steps #1 and #2 in both sections 4 and 5. It is
better to subscribe to MIF API notifications before attaching to an
interface; so that the application can fetch the  list of available
interfaces before selecting one.

== > Would like to hear the comments from WG. Will see.

 

Thanks a lot for your kind review

 

Best regards,

 

-Hui

 

Br,

Pierrick

 

De : [e-mail] [mailto:[e-mail]] De la part de Hui
Deng
Envoyé : mercredi 18 juillet 2012 08:33
À : Brian E Carpenter
Cc : [e-mail]
Objet : Re: [mif] draft-deng-mif-api-session-continuity-guide-02

 

Hi Brian

 

Thanks for your review this draft, inline please,

2012/7/17 Brian E Carpenter <[e-mail]>

Hi,

If the interface changes I can understand how this works from the
application's point of view: it discovers experimentally whether it has
a working path via the new interface. Nothing new there, really.

There is small percentage of applications know about this experimentation
which lead 

to some poor user experience.

 


If the host's address changes too, I don't find the discussion in
section 3 very helpful. Saying that the application ought to be able
to handle this really says nothing. And of course there are other
approaches possible, by having either the transport layer or the
network layer handle it. We have at least three existence proofs for
such solutions (SCTP, MPTCP and shim6). They all need tweaking for the
case of a brand-new address being added, and 6renum needs that tweak
too.

Application use MIF api to handel this is useful information for the
application.

and section 4 and 5 clarify detail how to help this. today many
OS/connection manager's

concrete API already provide such MIF API, if use those API, it really help
applications.

 

SCTP/MPTCP/shim6 are more adding additional intelligent to Mobile/OS, the
document

discussed here could work together with MIF/CM API by not tweaking the OS
stack

 

A related point is that load balancers at the server end are part
of the problem too, if you want to preserve sessions across a
re-addressing event.

this document doesn't talk about load balancer, because re-connect means a
create a new session

which load balance will treat this is a normal new session without need to
keep the state.

 

Thanks  again for the discussion

 

Best regards,

 

-Hui 

I think section 3 is just the tip of a very complicated iceberg.

Regards
   Brian


_______________________________________________
mif mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/mif

 

____________________________________________________________________________
_____________________________________________
 
Ce message et ses pieces jointes peuvent contenir des informations
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu
ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
electroniques etant susceptibles d'alteration,
France Telecom - Orange decline toute responsabilite si ce message a ete
altere, deforme ou falsifie. Merci.
 
This message and its attachments may contain confidential or privileged
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and
delete this message and its attachments.
As emails may be altered, France Telecom - Orange is not liable for messages
that have been modified, changed or falsified.
Thank you.