Subject: [mif] MIF at the application level

From: Marc Petit-Huguenin <[email-masked]>
Date: Sun, 15 Mar 2009 13:30:23 -0700

I read the 4 documents listed in the agenda for the MIF BOF, and I
am surprised to see very few discussion about the application
behavior in presence of multiple interfaces.  The documents talk
mostly about operating system configuration but, in the spirit of
the end to end argument, I do think that the final decision on what
network to choose (when there is a choice) should be made by the
application, with fallback to some automatic configuration when the
application is not smart enough to do this.  NICE
(draft-rosenberg-mmusic-ice-nonsip) is a very good example on how an
application can choose between different networks and perhaps this
draft, that does not seem to be maintained currently, could be part
of the deliverables of the future MIF WG.

-- 
Marc Petit-Huguenin
Home: [email-masked]
Work: [email-masked]

---

From: marcelo bagnulo braun <[email-masked]>
Date: Sun, 15 Mar 2009 22:23:26 +0100

but NICE is about how selecting address pairs, rather than just the 
local address, isn't it?

I mean, i would expect that selecting the local address to be a much 
simpler problem than selecting the address pair

regards, marcelo

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Sun, 15 Mar 2009 14:57:15 -0700

> simpler problem than selecting the address pair

The well known usage for NICE is to find the best route for NAT
traversal, but NICE is useful even without NAT.  In a MIF
environment without any NAT, NICE will find the correct local
address to use to reach a specific destination, and this without any
configuration.  Before NICE, people tried to find the best route by
trying to guess what type of NAT was in front of the host, which is
a problem that cannot be solved.  I feel that choosing the right
local address is a similar kind of problem that NICE can solve at
the application level.

The idea behind NICE is that the local address to use is the one
that have connectivity with the destination to reach.  That seems
obvious but that was kind of a new concept at the time (and kudos to
Jonathan for this work).

---

From: marcelo bagnulo braun <[email-masked]>
Date: Sun, 15 Mar 2009 23:12:25 +0100

Marc Petit-Huguenin escribió:
> traversal,

not route, but source destiantion address pair, if i remember correctly
>  but NICE is useful even without NAT.  In a MIF
> configuration.

agree, but at a high cost. I mean, if i remmeber correctly NICe tries 
the differnet address paris till it finds one that is working
that would certainy work, but i think we can do much better (i.e. less 
latentcy, less traffic) for the problem that you only need to figure out 
which local address to use

>   Before NICE, people tried to find the best route by

while the problem maybe similar, my take is that there are much simpler 
solutions that trying every address pair

> obvious but that was kind of a new concept at the time (and kudos to
well, seems to be very similar to ICE :-)

Regards, marcelo

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Sun, 15 Mar 2009 15:32:36 -0700

> not route, but source destiantion address pair, if i remember correctly

Yes, I didn't mean route as in routing.

> which local address to use

We'll see.

> solutions that trying every address pair

This is what people said for the discovery of NAT type, hence RFC
3489 - and it's subsequent deprecation - so, we'll see.

Do you have any pointer to this solutions?

> well, seems to be very similar to ICE :-)

NICE = ICE without SIP.  I said NICE and not ICE because the IETF is
full of literalists who would ask why I want to use SIP...

---

From: marcelo bagnulo braun <[email-masked]>
Date: Mon, 16 Mar 2009 08:55:49 +0100

> 3489 - and it's subsequent deprecation - so, we'll see.
fair enough

> Do you have any pointer to this solutions?

Well, since there are many problems related to multiple interfaces as 
described in blanchet's draft, i guess the solutions will be a set of tools.
I am still reading all the drafts on solutions, but what seems clear is 
that there are devices with multiple interfaces today and they seem to 
work somehow. So, imho the most interesting is to understand first how 
they currently do it and see if additional mechanisms are needed, or by 
simply documenting this, we are ok.
So, in this perspective a good place to start is 
draft-mrw-mif-current-practices-01

regards, marcelo