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

[<[e-mail]>]

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

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?

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?

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.

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]<mailto:[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]<mailto:[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.