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

[Hui Deng <[e-mail]>]

Hi

Inline again please,

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

> Hi,
>
> On 18/07/2012 07:33, Hui Deng wrote:
> > 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.
>
> 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.
>
This is my fault being not clear, here we are discussing the change
interface without virtual Interface support.
that means it changes IP address.


>
> >
> >
> >> 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
>
> But that requires a complicated update to every app instead of one
> 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.


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


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