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

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 <brian.e.carpenter@gmail.com>
> 
>> 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.

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

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

    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
>> mif@ietf.org
>> https://www.ietf.org/mailman/listinfo/mif
>>
> 