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

From: Brian E Carpenter <[email-masked]>
Date: Tue, 17 Jul 2012 14:11:13 +0100

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.

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.

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.

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

Regards
   Brian

---

From: Hui Deng <[email-masked]>
Date: Wed, 18 Jul 2012 14:33:25 +0800

Hi Brian

Thanks for your review this draft, inline please,

2012/7/17 Brian E Carpenter <[email-masked]>

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

> case of a brand-new address being added, and 6renum needs that tweak
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

> of the problem too, if you want to preserve sessions across a
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

> _______________________________________________
> mif mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mif
>

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 18 Jul 2012 08:37:27 +0100

Hi,

> to some poor user experience.

Generally applications don't know about interfaces, but the stack
and the routing table do know. All the application knows is how to
retransmit when there is a missing ACK. I don't really understand
the argument for pushing the problem up to the app if there is
no change of IP address.

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

But that requires a complicated update to every app instead of one
update to the stack. It should be easier to fix the stack.

> which load balance will treat this is a normal new session without need to

That's exactly the problem. If you break the session, the user loses
their transaction. We should try to maintain the session.
(The problems are discussed in draft-tarreau-extend-flow-label-balancing).

    Brian

---

From: Hui Deng <[email-masked]>
Date: Wed, 18 Jul 2012 16:05:09 +0800

Hi

Inline again please,

2012/7/18 Brian E Carpenter <[email-masked]>

> the argument for pushing the problem up to the app if there is
This is my fault being not clear, here we are discussing the change
interface without virtual Interface support.
that means it changes IP address.

> update to the stack. It should be easier to fix the stack.
For my observation, today Mobile vendor is hectic about their Eco-system,
fix the stack become more challenging for their short term mission.
I guess it's time for the application should be aware of multiple
interfaces.
that's the motivation for this document.

> (The problems are discussed in draft-tarreau-extend-flow-label-balancing).
Today most Internet application would be able to tolerate the lose their
transaction
by application layer session continuity.  this is also supported by MIF's
work here.

Only some realtime communication should not break the session, but they
have their own
solution to fix this.

Best,

-Hui

---

From: <[email-masked]>
Date: Wed, 25 Jul 2012 15:01:14 +0000

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 : [email-masked] [mailto:[email-masked]] De la part de Hui Deng
Envoyé : mercredi 18 juillet 2012 08:33
À : Brian E Carpenter
Cc : [email-masked]
Objet : Re: [mif] draft-deng-mif-api-session-continuity-guide-02

Hi Brian

2012/7/17 Brian E Carpenter <[email-masked]<mailto:[email-masked]>>
Hi,

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

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.

Best regards,

-Hui

Regards
   Brian

_______________________________________________
mif mailing list
[email-masked]<mailto:[email-masked]>
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.