Re: [mif] Happy Eyeballs Extension for MIF

Hi,

Just a brief comment on happy eyeballs I-D. Basically, I'll second Scott on complexity for choosing an interface.

I agree that interface selection can be made using an interface weighting method. However, weight computation needs to take into account various criteria: obviously network access condition, but also the type of application (applications may have different QoS requirements), user preferences and operator policies, interface cost, L2/L3 authentication/security capabilities, and so on... Interface weight must be computed in advance but also be recomputed during session; network condition may change during the session and interface reselection triggered (if mobility supported). IMHO, the proposed algorithm is too simplistic with regards to interface selection problem in MIF context. Usually, interface selection is performed by a connection manager having interfaces to different layers.

I'm also concerned with DNS requests sent over all interfaces. IMHO, this is a waste of resource; besides draft-ietf-mif-dns-server-selection clearly states that this practice should be avoided. 

Pierrick

> -----Message d'origine-----
> De : mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] De la part de
> GangChen
> Envoyé : mardi 5 avril 2011 17:39
> À : Scott Brim
> Cc : mif@ietf.org
> Objet : Re: [mif] Happy Eyeballs Extension for MIF
> 
> Hello Scott,
> 
> Please see my reply inline.
> 
> 2011/3/28, Scott Brim <scott.brim@gmail.com>:
> > First, there are a lot of issues that go into making a choice between
> > interfaces. The ones I can think of immediately are interface cost,
> policy
> > rules, higher layer services sought, and real goodput measurement over
> time.
> > A simple integer preference for using a particular interface to reach a
> > particular prefix, based only on how fast a SYNACK comes back, cannot
> > reflect those.
> 
> [Gang] Agree. The different interfaces may have different policies, so
> it is not only the connectivity but also policy.
> 
> > I suspect that it would be better do this in two stages: first choose a
> set
> > of interfaces based on other criteria (like those listed above), and
> then
> > run this draft's mechanism on that set.
> 
> [Gang] Yes. In first stage, multiple preconditions should be taken
> into account.
> The problem is how to formulate a function to accurately reflect these
> impacts.
> 
> >
> > Second, I can't resist pointing out that goodput over time is more
> > significant than initial connectivity so in the long run we're better
> off
> > with MPTCP or SCTP and using real data packets on those interfaces.
> 
> [Gang] I guess this goes beyond the scope of this draft.
> 
> > Thanks...  Scott
> >
> > - use multipathing (SCTP CMT, MPTCP) to determine
> >
> > I have concerns about the usefulness. I like Happy Eyeballs very much in
> its
> > original context. However, in the original context of Happy Eyeballs
> (IPv4
> > vs IPv6, TCP vs SCTP), the goals are clear, the choices are clear, and
> the
> > metrics for the decision are clear. It's purely a problem of devising a
> good
> > mechanism to enable making a technical choice. However, in this case, t
> 
> [Gang] Regarding the usefulness, Happy Eyeballs Extension could allow
> traffic falls back to suboptimal interface, when there are accidental
> problems happened on the optimal interface.
> 
> Best Regards
> 
> Gang
> _______________________________________________
> mif mailing list
> mif@ietf.org
> https://www.ietf.org/mailman/listinfo/mif