Subject: [mif] next steps for MIF

From: Jari Arkko <[email-masked]>
Date: Thu, 02 Apr 2009 01:49:23 +0200

Based on the outcome of the BOF, my thoughts are that there's a lot of 
interest and existing implementation work in this space. We should 
address this problem space in a WG.

I have a bit of concern for partial overlap with some things that our 
existing WGs should address, and a lot of concern for trying to come 
with a perfect design that would require a lot of protocol machinery and 
configuration effort.

Given the above, I'd like to suggest that we charter a new WG that 
describes the problem from an overall IP host perspective, documents 
existing practice, and possibly describes best current practice.

The overall system perspective distinguishes this work from other IETF 
WGs dedicated to a particular slice of the problem, such as dealing with 
DHCP information, DNS recommendations, or address and default router 
selection. Documenting current practice is obviously a good thing, and 
will help other implementations to learn ways to deal with this problem. 
Describing current practice also keeps us from going too far in 
inventing new solutions. Once we have done everything listed above, we 
can make a more informed decision about continuing the WG for actual new 
work or distributing work to specialized WGs such as 6MAN or DHC.

Does this sound a reasonable way forward?

I have also attached a proposed charter based on the latest one from the 
list but heavily edited. The charter a very drafty version; comments 
appreciated.

Jari

--------
Multiple InterFaces (MIF)

Last Modified: 2009-04-02

Chair(s):
TBD

Internet Area Director(s):
Ralph Droms <[email-masked]>
Jari Arkko <[email-masked]>

Internet Area Advisor:
TBD

Mailing Lists:
General Discussion: [email-masked]
To Subscribe: https://www.ietf.org/mailman/listinfo/mif
Archive: http://www.ietf.org/mail-archive/web/mif

Description of Working Group:

Many hosts have the ability to connect to multiple networks 
simultaneously. This can happen over multiple physical network 
interfaces, a combination of physical and virtual interfaces (VPNs or 
tunnels), or even through multiple default routers being on the same 
link. For instance, current laptops and smartphones typically have 
multiple access network interfaces.

A host connected to multiple networks has to make decisions about 
default router selection, address selection, DNS server selection, 
choice of interface for packet transmission, and the treatment of 
configuration information received from the various networks. Some 
configuration objects are global to the node, some are local to the 
interface. Various issues arise when multiple configuration objects that 
are global to the node are received on different interfaces. At best, 
decisions about these matters have an efficiency effect. At worst, they 
have more significant effects such as security impacts, or even lead to 
communication not being possible at all.

A number of operating systems have implemented various techniques to 
deal with multiple interfaces. Some devices employ only one interface at 
a time and some allow per-host configuration of preferences between the 
interfaces but still use just one at a time. Other systems allow 
per-application preferences or implement sophisticated policy managers 
that can be configured by users or controlled externally.

The purpose of the MIF working group is to describe the issues 
surrounding the use of multiple interfaces on hosts, document existing 
practice, and make recommendations about best current practice. The WG 
shall employ and refer to existing IETF work in this area, including, 
for instance, strong/weak models (RFC 1122), address selection (RFC 
3484), DHCP mechanisms, Router Advertisement mechanisms, and DNS 
recommendations. The focus of the working group should be on documenting 
the system level effects to host IP stacks and identification of gaps 
between the existing IETF recommendations and existing practice. The 
working group shall address both IPv4 and IPv6 as well as stateless and 
stateful configuration.

Network discovery and selection on lower layers as defined by RFC 5113 
is out of scope. Also, the group shall not develop new protocol or 
policy mechanisms; recommendations and gap analysis from the group are 
solely based on existing solutions. The group shall not assume any 
software beyond basic IP protocol support on its peers or in network 
nodes. No work will be done to enable traffic flows to move from one 
interface to another.

Once the group has completed its work items, the IETF can make an 
informed decision about rechartering the working group to define new 
mechanisms or asking other, specialized working groups to deal with 
specific issues.  

Milestones:

May 2009 WG chartered
July 2009 Initial draft on problem statement adopted by the WG
September 2009 Initial draft on existing practices adopted by the WG
March 2010 Problem statement draft submitted to the IESG for publication 
as an Informational RFC
Jan 2010 Initial best current practices draft adopted by the WG
July 2010 Existing practices draft submitted to the IESG for publication 
as an Informational RFC
September 2010 Best current practices draft submitted to the IESG for 
publication as a BCP
October 2010 Recharter or close

---

From: Margaret Wasserman <[email-masked]>
Date: Wed, 1 Apr 2009 21:36:59 -0400

Hi Jari,

Yes, I think this sounds like a reasonable way forward.

A couple of comments on the charter portion of your message:

On Apr 1, 2009, at 7:49 PM, Jari Arkko wrote:
> interfaces, a combination of physical and virtual interfaces (VPNs  
> or tunnels), or even through multiple default routers being on the  
> same link. For instance, current laptops and smartphones typically  
> have multiple access network interfaces.
>
> interface.

There may also be some configuration information that is (or should  
be) done on a per-prefix basis.  This is most interesting in the  
"multiple default routers being on the same link" situation that you  
mentioned above.

I very much agree with the proposed scope of the group.

> March 2010 Problem statement draft submitted to the IESG for  
> publication as an Informational RFC
> July 2010 Existing practices draft submitted to the IESG for  
> publication as an Informational RFC
> September 2010 Best current practices draft submitted to the IESG  
> for publication as a BCP

You probably want to switch these milestones around so that they are  
in chronological order.  Other than that, they look fine.

Margaret

---

From: Marc Blanchet <[email-masked]>
Date: Wed, 01 Apr 2009 22:44:17 -0400

- agree with your proposal and the proposed charter.

Marc.

Jari Arkko a écrit :
> _______________________________________________
> mif mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mif

-- 
=========
IPv6 book: Migrating to IPv6, Wiley. http://www.ipv6book.ca
Stun/Turn server for VoIP NAT-FW traversal: http://numb.viagenie.ca
DTN news service: http://reeves.viagenie.ca

---

From: Daniel Park <[email-masked]>
Date: Thu, 2 Apr 2009 12:17:54 +0900

Thanks your charter proposal.

As you mention, there are already several non-standard implementations
in their own devices and software. Hence, this WG should try to
coordinate with them. Otherwise, I don't think this effort will be
success.. In IETF, someone spoke about IEEE 802.21 on mic and
collaboration with IETF. 802.21 STD is completed and being implemented
to the devices. That is one example.

One more comment to the WG is how to deal with the different ISP
domain. It's not a technical issue but sort of political in the
market. Practically, our Samsung device has two wirleess interfaces
and even more and one interface is connected to A-ISP and the other
interface is connected to B-ISP. In that situation, no seamless
connectivy and problem occur since each interface has its own opeation
in a separated mode. I don't know if this is a beyond scope of IETF
though...

Finally, in charter: "Many hosts have the ability to connect to
multiple networks simultaneously". That's true, but practially, there
are few real use cases to turn on the ability for the multiple
connectivities simultaneously. We need more clear use cases for MIF
operation.

Daniel

-- 
Soohong Daniel Park
Standard Architect, http://blog.naver.com/natpt
DMC Business, Samsung Electronics, KOREA

On Thu, Apr 2, 2009 at 8:49 AM, Jari Arkko <[email-masked]> wrote:
> interest and existing implementation work in this space. We should address
> this problem space in a WG.
>
> existing WGs should address, and a lot of concern for trying to come with a
> perfect design that would require a lot of protocol machinery and
> configuration effort.
>
> Given the above, I'd like to suggest that we charter a new WG that describes
> the problem from an overall IP host perspective, documents existing
> practice, and possibly describes best current practice.
>
> The overall system perspective distinguishes this work from other IETF WGs
> dedicated to a particular slice of the problem, such as dealing with DHCP
> information, DNS recommendations, or address and default router selection.
> Documenting current practice is obviously a good thing, and will help other
> implementations to learn ways to deal with this problem. Describing current
> practice also keeps us from going too far in inventing new solutions. Once
> we have done everything listed above, we can make a more informed decision
> about continuing the WG for actual new work or distributing work to
> specialized WGs such as 6MAN or DHC.
>
> Many hosts have the ability to connect to multiple networks simultaneously.
> This can happen over multiple physical network interfaces, a combination of
> physical and virtual interfaces (VPNs or tunnels), or even through multiple
> default routers being on the same link. For instance, current laptops and
> smartphones typically have multiple access network interfaces.
>
> A host connected to multiple networks has to make decisions about default
> router selection, address selection, DNS server selection, choice of
> interface for packet transmission, and the treatment of configuration
> information received from the various networks. Some configuration objects
> are global to the node, some are local to the interface. Various issues
> arise when multiple configuration objects that are global to the node are
> received on different interfaces. At best, decisions about these matters
> have an efficiency effect. At worst, they have more significant effects such
> as security impacts, or even lead to communication not being possible at
> all.
>
> A number of operating systems have implemented various techniques to deal
> with multiple interfaces. Some devices employ only one interface at a time
> and some allow per-host configuration of preferences between the interfaces
> but still use just one at a time. Other systems allow per-application
> preferences or implement sophisticated policy managers that can be
> configured by users or controlled externally.
>
> The purpose of the MIF working group is to describe the issues surrounding
> the use of multiple interfaces on hosts, document existing practice, and
> make recommendations about best current practice. The WG shall employ and
> refer to existing IETF work in this area, including, for instance,
> strong/weak models (RFC 1122), address selection (RFC 3484), DHCP
> mechanisms, Router Advertisement mechanisms, and DNS recommendations. The
> focus of the working group should be on documenting the system level effects
> to host IP stacks and identification of gaps between the existing IETF
> recommendations and existing practice. The working group shall address both
> IPv4 and IPv6 as well as stateless and stateful configuration.
>
> Network discovery and selection on lower layers as defined by RFC 5113 is
> out of scope. Also, the group shall not develop new protocol or policy
> mechanisms; recommendations and gap analysis from the group are solely based
> on existing solutions. The group shall not assume any software beyond basic
> IP protocol support on its peers or in network nodes. No work will be done
> to enable traffic flows to move from one interface to another.
>
> Once the group has completed its work items, the IETF can make an informed
> decision about rechartering the working group to define new mechanisms or
> asking other, specialized working groups to deal with specific issues.
> Milestones:
>
> May 2009 WG chartered
> March 2010 Problem statement draft submitted to the IESG for publication as
> an Informational RFC
> July 2010 Existing practices draft submitted to the IESG for publication as
> an Informational RFC

---

From: Jari Arkko <[email-masked]>
Date: Thu, 02 Apr 2009 06:36:44 +0200

Thanks for your comments! A few responses:

> success.

Yes, though I think we are taking a three step approach. Step 1: 
describe the current practice. Step 2: recommend best practice. Step 3: 
develop new mechanisms if/when we see that this is needed (Step 3 needs 
a recharter).

> In IETF, someone spoke about IEEE 802.21 on mic and

OK. But I need to understand better how 802.21 relates to this problem. 
I know 802.21 base protocol has a lot of capabilities, but is it 
currently defined for doing some IP layer tasks, such as advising the 
host about choice of interface or DNS server? In my limited 
understanding of 802.21 it is more about access network selection, 
similar to what RFC 5113 talks about.

> in a separated mode. I don't know if this is a beyond scope of IETF

I think this arrangement is very common, and will continue to be common. 
That is, we need to assume that there will be interfaces that are 
uncoordinated and where no seamless mobility movements, for instance, 
can occur.

I think you case is fully within the MIF charter.

> connectivities simultaneously. We need more clear use cases for MIF

ability to use interfaces simultaneously != multiple interfaces being used

But the point is that you still have to choose which interface you use 
at this instant in time.

In any case, I think there are even uses case about simultaneous use. My 
phone can be configured to use the WLAN for web access, while still 
receiving SMS over the 3G interface.

Jari

---

From: Jari Arkko <[email-masked]>
Date: Thu, 02 Apr 2009 06:40:48 +0200

The second version, taking into account Margaret's feedback:

-------------

Chair(s):
TBD

Internet Area Advisor:
TBD

Mailing Lists:

A host connected to multiple networks has to make decisions about 
default router selection, address selection, DNS server selection, 
choice of interface for packet transmission, and the treatment of 
configuration information received from the various networks. Some 
configuration objects are global to the node, some are local to the 
interface, and some are related to a particular prefix. Various issues 
arise when multiple configuration objects that are global to the node 
are received on different interfaces. At best, decisions about these 
matters have an efficiency effect. At worst, they have more significant 
effects such as security impacts, or even lead to communication not 
being possible at all.

Milestones:

May 2009 WG chartered

---

From: Daniel Park <[email-masked]>
Date: Thu, 2 Apr 2009 15:57:28 +0900

On Thu, Apr 2, 2009 at 1:36 PM, Jari Arkko <[email-masked]> wrote:
> Yes, though I think we are taking a three step approach. Step 1: describe
> the current practice. Step 2: recommend best practice. Step 3: develop new
> mechanisms if/when we see that this is needed (Step 3 needs a recharter).
>
> OK. But I need to understand better how 802.21 relates to this problem. I
> know 802.21 base protocol has a lot of capabilities, but is it currently
> defined for doing some IP layer tasks, such as advising the host about
> choice of interface or DNS server? In my limited understanding of 802.21 it
> is more about access network selection, similar to what RFC 5113 talks
> about.

In fact, I do not insist on the 802.21 solution to be used to MIF.
Yes, it does not deal with IP layer tasks. That's why I tried to point
out *collaboration*. Presumably, 21 framework can may be expanded to
support MIF later on if necessary.

> uncoordinated and where no seamless mobility movements, for instance, can
> occur.
>

ditto,

> But the point is that you still have to choose which interface you use at
> this instant in time.
>

Why not sending and receiving SMS via WLAN ? and browsing web via 3G ?...:-)
My point is to clearly figure out what use cases and senarious might
be valuable in MIF.

Bye the way, I am a positive in this work...

---

From: marcelo bagnulo braun <[email-masked]>
Date: Thu, 02 Apr 2009 10:04:15 +0200

this looks good to me

Jari Arkko escribió:
> matters have an efficiency effect. At worst, they have more 
> significant effects such as security impacts, or even lead to 
> deal with multiple interfaces. Some devices employ only one interface 
> at a time and some allow per-host configuration of preferences between 
> the interfaces but still use just one at a time. Other systems allow 
> recommendations. The focus of the working group should be on 
> documenting the system level effects to host IP stacks and 
> identification of gaps between the existing IETF recommendations and 
> existing practice. The working group shall address both IPv4 and IPv6 
> as well as stateless and stateful configuration.
>

---

From: <[email-masked]>
Date: Thu, 2 Apr 2009 10:19:20 +0200

Hi all,

I agree with proposed charter and way forward.

Regarding 802.21, my understanding is that this framework provides valuable mechanisms for access selection (by managing selection triggers, exchanging parameters and information) which is out of MIF scope. Moreover, IMU, 802.21 brings more added-value for inter-system mobility management. So I don't think there is a tight relationship between MIF specific issues and 802.21. Just my opinion....

Regards,
Pierrick

> -----Message d'origine-----
> De : [email-masked] [mailto:[email-masked]] De la part de
> Daniel Park
> Envoyé : jeudi 2 avril 2009 08:57
> À : Jari Arkko
> Cc : Hui Deng; mif; Ralph Droms
> Objet : Re: [mif] next steps for MIF
> 
> describe
> I
> can
> at

---

From: George Tsirtsis <[email-masked]>
Date: Thu, 2 Apr 2009 08:22:54 -0400

I could not participate in the BOF, but the updated charter looks good
and like the focus on Informational and BCPs.

Thanks
George

On Thu, Apr 2, 2009 at 4:04 AM, marcelo bagnulo braun
<[email-masked]> wrote:
>> simultaneously. This can happen over multiple physical network interfaces, a
>> combination of physical and virtual interfaces (VPNs or tunnels), or even
>> through multiple default routers being on the same link. For instance,
>> current laptops and smartphones typically have multiple access network
>> interfaces.
>>
>> are global to the node, some are local to the interface, and some are
>> related to a particular prefix. Various issues arise when multiple
>> configuration objects that are global to the node are received on different
>> interfaces. At best, decisions about these matters have an efficiency
>> effect. At worst, they have more significant effects such as security
>> impacts, or even lead to communication not being possible at all.
>>

---

From: Lars Eggert <[email-masked]>
Date: Thu, 2 Apr 2009 16:26:54 +0300

Hi,

> My point is to clearly figure out what use cases and senarious might

I don't see the use cases as very critical. MIF is about getting the  
pieces in place such that a host can use multiple interfaces for IP  
communication at the same time.

*How* the host makes use of this is not something we need to  
standardize or even agree on. MIF should be able to support a variety  
of (very) different schemes.

Lars

---

From: "Giyeong Son" <[email-masked]>
Date: Thu, 2 Apr 2009 10:10:49 -0400

Hi,

I think mainly the host to be focused by MIF seems to be mobile device such as laptop or smart phone, mobility over multiple interfaces in the (near) future would be very crucial for the vendors, service providers and wireless carriers. 

Although MIF will not address/produce recommendations in terms of "mobility" for simultaneous use of multiple interfaces for packet transmission (but I think this feature may need to be addressed by an working group), it SHOULD not restrict to and severely impact on any other legacy or new coming mobility technologies or protocols. So, it would be worth to indicate this one in some place regarding mobility.

Best Regards,
Giyeong 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: April 2, 2009 4:19 AM
To: [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [mif] next steps for MIF

Hi all,

Regards,
Pierrick

> Daniel Park Envoyé : jeudi 2 avril 2009 08:57 À : Jari Arkko Cc : Hui 
> Deng; mif; Ralph Droms Objet : Re: [mif] next steps for MIF
> 
> >> As you mention, there are already several non-standard 
> >> implementations in their own devices and software. Hence, this WG 
> >> should try to coordinate with them. Otherwise, I don't think this 
> >> effort will be success.
> >
> > the current practice. Step 2: recommend best practice. Step 3: 
> > develop
> new
> >> In IETF, someone spoke about IEEE 802.21 on mic and collaboration 
> >> with IETF. 802.21 STD is completed and being implemented to the 
> >> devices. That is one example.
> >>
> >
> > know 802.21 base protocol has a lot of capabilities, but is it 
> > currently defined for doing some IP layer tasks, such as advising 
> > the host about choice of interface or DNS server? In my limited 
> > understanding of 802.21
> it
> > is more about access network selection, similar to what RFC 5113 
> > talks about.
> 
> >> connectivy and problem occur since each interface has its own 
> >> opeation in a separated mode. I don't know if this is a beyond 
> >> scope of IETF though...
> >>
> >
> >> multiple networks simultaneously". That's true, but practially, 
> >> there are few real use cases to turn on the ability for the 
> >> multiple connectivities simultaneously. We need more clear use 
> >> cases for MIF operation.
> >>
> >
> > ability to use interfaces simultaneously != multiple interfaces 
> > being
> used
> 
> ditto,
> 
> > In any case, I think there are even uses case about simultaneous 
> > use. My phone can be configured to use the WLAN for web access, 
> > while still receiving SMS over the 3G interface.
> 
> Why not sending and receiving SMS via WLAN ? and browsing web via 3G 
> ?...:-) My point is to clearly figure out what use cases and senarious 
> might be valuable in MIF.
> 
> 
> Standard Architect, http://blog.naver.com/natpt DMC Business, Samsung 
> Electronics, KOREA _______________________________________________
> mif mailing list
> [email-masked]

---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.

---

From: Jari Arkko <[email-masked]>
Date: Thu, 02 Apr 2009 16:56:39 +0200

Daniel,

> support MIF later on if necessary.

Ok -- that makes sense.

> Why not sending and receiving SMS via WLAN ?

Presumably because in most cases the SMS server is not accessible from 
the public Internet.

> and browsing web via 3G ?...:-)

Ok. But I'm not quite sure what we can do about that without going to 
very specific cases. Can you make a more specific suggestion on what 
document would be added to the charter?

> Bye the way, I am a positive in this work...
Great -- thats what I was assuming anyway!

Cheers,

Jari

---

From: marcelo bagnulo braun <[email-masked]>
Date: Thu, 02 Apr 2009 18:27:52 +0200

Giyeong Son escribió:
> Although MIF will not address/produce recommendations in terms of "mobility" for simultaneous use of multiple interfaces for packet transmission (but I think this feature may need to be addressed by an working group),
this is already being worked on in mext for instance, in relation with MIP
i am not sure i understand what do you think is needed in terms of mobility
can you expand?

Regards, marcelo

>  it SHOULD not restrict to and severely impact on any other legacy or new coming mobility technologies or protocols. So, it would be worth to indicate this one in some place regarding mobility.
>  
>
> Best Regards,
> Giyeong 
>

---

From: Jari Arkko <[email-masked]>
Date: Thu, 02 Apr 2009 22:30:40 +0200

Giyeong,

> Although MIF will not address/produce recommendations in terms of "mobility" for simultaneous use of multiple interfaces for packet transmission (but I think this feature may need to be addressed b…

That's right. However, we already have efforts in place where mobility 
technology can employ multiple interfaces. Draft-ietf-mext-multiplecoa 
and related specifications, for instance. Whatever we do in MIF must not 
break this or other existing features. I said something about this in 
the take 3 version of the charter.

Jari

---

From: Daniel Park <[email-masked]>
Date: Fri, 3 Apr 2009 12:14:11 +0900

On Thu, Apr 2, 2009 at 11:56 PM, Jari Arkko <[email-masked]> wrote:
> Presumably because in most cases the SMS server is not accessible from the
> public Internet.

It's not a critical matter at this stage, but we can via ISP portal
service for SMS access using public internet.

> Ok. But I'm not quite sure what we can do about that without going to very
> specific cases. Can you make a more specific suggestion on what document
> would be added to the charter?

I think *best current practice* can deal with this issue. Also, we can
work on *MIF use cases* in a separated one.

---

From: George Tsirtsis <[email-masked]>
Date: Fri, 3 Apr 2009 07:06:41 +0100

Hi Daniel et.al.,

I assume we are all in agreement with the following?

When we are talking about "multiple Interfaces" in the context of MIF,
we are talking about "multiple IP Interfaces". This obviously excludes
any considerations for proprietary vertical stacks that are not based
on IP (e.g., SMS over 3G)

Also, I am not a big fun of "use cases". Use cases are some times
useful in framing a problem and putting it in context, but often they
simply either over-complicate things by introducing many useless
theoretical scenarios, or completely loose generality which is vital
for a generic feature like the one of multiple interfaces.

Regards
George

---

From: gabriel montenegro <[email-masked]>
Date: Fri, 3 Apr 2009 00:02:39 -0700 (PDT)

Agree with George (and Lars?) who point out that we don't need a use case document on this.
In my mind, this is as basic and general as 1122 host requirements (don't think we need a use case for that).

I also don't see the relationship with 802.21 (it was Bob Moskowitz who mentioned it at the meeting).
That's about giving you info for your handoff. If anything, there is a relationship with mobility working groups
and that's why MIPSHOP has dealt with 802.21, but mobility is out of scope of MIF. But 802.21 is not the only
such mechanism being worked on in other SDOs. 3GPP uses ANDSF (and similar for WiMAX) instead of 
802.21, but likewise that has no bearing that I can see on MIF per our scope, and also because MIF is
general (again, similar to RFC1122).

The new charter looks much improved. I do have some minor comments:

"Many hosts have the ability to connect to multiple networks simultaneously. This can happen over multiple physical network interfaces, a combination of physical and virtual interfaces (VPNs or tunnels), or even through multiple default routers being on the same link. For instance, current laptops and smartphones typically have multiple access network interfaces."

The first sentence by itself would still allow the case of the virtual interface under which several different
networks are multiplexed. Even though it is clarified later on in the charter, I'd add a new sentence at 
the end of this paragraph to clarify:

    MIF deals with hosts that use multiple interfaces to connect to multiple networks.

...

"A number of operating systems have implemented various techniques to deal with multiple interfaces. Some devices employ only one interface at a time and some allow per-host configuration of preferences between the interfaces but still use just one at a time. Other systems allow per-application preferences or implement sophisticated policy managers that can be configured by users or controlled externally."

It sounds funny to say that a host can employ "per-host" configuration, since there is only 
one host (self). Here, I'd suggest we start consistently using the terminology that Marc used in his problem statement presentation related to scopes. So I'd suggest:

s/per-host/host-scoped/
s/per-application/application-scoped/

"The purpose of the MIF working group is to describe the issues surrounding the use of multiple interfaces on hosts, document existing practice, and make recommendations about best current practice. The WG shall employ and refer to existing IETF work in this area, including, for instance, strong/weak models (RFC 1122), address selection (RFC 3484), DHCP mechanisms, Router Advertisement mechanisms, and DNS recommendations. The focus of the working group should be on documenting the system level effects to host IP stacks and identification of gaps between the existing IETF recommendations and existing practice. The working group shall address both IPv4 and IPv6 as well as stateless and stateful configuration."

s/The focus of the working group should be on documenting/The working group will document/
s/system level/system-level/
s/identification of gaps/identify the gaps/

"Network discovery and selection on lower layers as defined by RFC 5113 is out of scope. Also, the group shall not develop new protocol or policy mechanisms; recommendations and gap analysis from the group are solely based on existing solutions. The group shall not assume any software beyond basic IP protocol support on its peers or in network nodes. No work will be done to enable traffic flows to move from one interface to another. The group recognizes existing work on mechanisms that require peer or network support for moving traffic flows such as RFC 5206, RFC 4980 and the use of multiple care-of addresses in Mobile IPv6. This group does not work on or impact such mechanisms."

s/on lower layers//
s/defined by RFC 5113/defined, for example, by RFC 5113/

thanks,

Gabriel

----- Original Message ----
> From: George Tsirtsis <[email-masked]>
> To: Daniel Park <[email-masked]>
> Cc: mif <[email-masked]>
> Sent: Thursday, April 2, 2009 11:06:41 PM
> On Fri, Apr 3, 2009 at 4:14 AM, Daniel Park wrote:
> > On Thu, Apr 2, 2009 at 11:56 PM, Jari Arkko wrote:
> >> Daniel,
> >>

---

From: "Giyeong Son" <[email-masked]>
Date: Fri, 3 Apr 2009 10:47:18 -0400

I agree on George's and Gabriel's opinions. The working group may not need to present a use case document. However, as you know, use case is also helpful for problem/system/protocol analysis and design. It also brings the result of work being practical, accurate and reliable at the end so that the implementers and the users can easily find out the value of and the benefits from the work in a practical manner. Therefore, I suggest the working group can still utilize the methodology during the work, especially during discussions.

BTW, I'd like clarify an issue Gabriel addressed in her email regarding "multiple interfaces to connect to multiple networks". So, does the working group not exclude the use case of a (virtual) interface associated with multiple access networks? Or, it does?

In addition, I also want to understand one thing in the charter. The charter indicates that it does not address "mobility of packet flows over multiple interfaces for packet transmission". According to the sentence, the work from the working group may not implicitly allow a TCP connection with a (virtual) IP address/port over multiple interfaces? Or, can a TCP connection run over multiple interfaces with the work, so a packet transmission on the TCP connection can select an interface dynamically on fly?  

Giyeong  

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of gabriel montenegro
Sent: April 3, 2009 3:03 AM
To: George Tsirtsis; Daniel Park
Cc: mif
Subject: Re: [mif] next steps for MIF

I also don't see the relationship with 802.21 (it was Bob Moskowitz who mentioned it at the meeting).
That's about giving you info for your handoff. If anything, there is a relationship with mobility working groups and that's why MIPSHOP has dealt with 802.21, but mobility is out of scope of MIF. But 802.21 is not the only such mechanism being worked on in other SDOs. 3GPP uses ANDSF (and similar for WiMAX) instead of 802.21, but likewise that has no bearing that I can see on MIF per our scope, and also because MIF is general (again, similar to RFC1122).

The first sentence by itself would still allow the case of the virtual interface under which several different networks are multiplexed. Even though it is clarified later on in the charter, I'd add a new sentence at the end of this paragraph to clarify:

...

It sounds funny to say that a host can employ "per-host" configuration, since there is only one host (self). Here, I'd suggest we start consistently using the terminology that Marc used in his problem statement presentation related to scopes. So I'd suggest:

s/per-host/host-scoped/

s/The focus of the working group should be on documenting/The working group will document/ s/system level/system-level/ s/identification of gaps/identify the gaps/

s/on lower layers//

thanks,

Gabriel

----- Original Message ----
> >>> Yes, it does not deal with IP layer tasks. That's why I tried to 
> >>> point out *collaboration*. Presumably, 21 framework can may be 
> >>> expanded to support MIF later on if necessary.
> >>>
> >>
> >> Ok -- that makes sense.
> >>
> >> Presumably because in most cases the SMS server is not accessible 
> >> from the public Internet.
> >
> >>> My point is to clearly figure out what use cases and senarious 
> >> Ok. But I'm not quite sure what we can do about that without going 
> >> to very specific cases. Can you make a more specific suggestion on 
> >> what document would be added to the charter?
> >
> > I think *best current practice* can deal with this issue. Also, we 
> > can work on *MIF use cases* in a separated one.
> >
> >>
> > Standard Architect, http://blog.naver.com/natpt DMC Business, 
> > Samsung Electronics, KOREA

---

From: "Carl Williams" <[email-masked]>
Date: Fri, 3 Apr 2009 10:58:45 -0400

I can understand George's opinion on use cases. Some of these use case
documents I have see - for example in 6lowpan - are theoretical and it is
hard to distinguish what is of concern now.   When scenarios or use cases
are presented in such a way that we can see the problem scope more clearly -
what we are ready to engineer and what is out of scope, then this may be a
helpful aid for problem statement direction and scope.

I have had conversations about this at SF meeting with Marc & Margaret and I
think that if it is possible to have a few classes of scenarios to solve
that are generic that use cases can fit into, then this may be desirable for
problem statement definition.

Carl

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Giyeong Son
Sent: Friday, April 03, 2009 10:47 AM
To: gabriel montenegro; George Tsirtsis; Daniel Park
Cc: mif
Subject: Re: [mif] next steps for MIF

I agree on George's and Gabriel's opinions. The working group may not need
to present a use case document. However, as you know, use case is also
helpful for problem/system/protocol analysis and design. It also brings the
result of work being practical, accurate and reliable at the end so that the
implementers and the users can easily find out the value of and the benefits
from the work in a practical manner. Therefore, I suggest the working group
can still utilize the methodology during the work, especially during
discussions.

BTW, I'd like clarify an issue Gabriel addressed in her email regarding
"multiple interfaces to connect to multiple networks". So, does the working
group not exclude the use case of a (virtual) interface associated with
multiple access networks? Or, it does?

In addition, I also want to understand one thing in the charter. The charter
indicates that it does not address "mobility of packet flows over multiple
interfaces for packet transmission". According to the sentence, the work
from the working group may not implicitly allow a TCP connection with a
(virtual) IP address/port over multiple interfaces? Or, can a TCP connection
run over multiple interfaces with the work, so a packet transmission on the
TCP connection can select an interface dynamically on fly?  

Giyeong  

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
gabriel montenegro
Sent: April 3, 2009 3:03 AM
To: George Tsirtsis; Daniel Park
Cc: mif
Subject: Re: [mif] next steps for MIF

Agree with George (and Lars?) who point out that we don't need a use case
document on this.
In my mind, this is as basic and general as 1122 host requirements (don't
think we need a use case for that).

I also don't see the relationship with 802.21 (it was Bob Moskowitz who
mentioned it at the meeting).
That's about giving you info for your handoff. If anything, there is a
relationship with mobility working groups and that's why MIPSHOP has dealt
with 802.21, but mobility is out of scope of MIF. But 802.21 is not the only
such mechanism being worked on in other SDOs. 3GPP uses ANDSF (and similar
for WiMAX) instead of 802.21, but likewise that has no bearing that I can
see on MIF per our scope, and also because MIF is general (again, similar to
RFC1122).

"Many hosts have the ability to connect to multiple networks simultaneously.
This can happen over multiple physical network interfaces, a combination of
physical and virtual interfaces (VPNs or tunnels), or even through multiple
default routers being on the same link. For instance, current laptops and
smartphones typically have multiple access network interfaces."

The first sentence by itself would still allow the case of the virtual
interface under which several different networks are multiplexed. Even
though it is clarified later on in the charter, I'd add a new sentence at
the end of this paragraph to clarify:

    MIF deals with hosts that use multiple interfaces to connect to multiple
networks.

...

"A number of operating systems have implemented various techniques to deal
with multiple interfaces. Some devices employ only one interface at a time
and some allow per-host configuration of preferences between the interfaces
but still use just one at a time. Other systems allow per-application
preferences or implement sophisticated policy managers that can be
configured by users or controlled externally."

It sounds funny to say that a host can employ "per-host" configuration,
since there is only one host (self). Here, I'd suggest we start consistently
using the terminology that Marc used in his problem statement presentation
related to scopes. So I'd suggest:

s/per-host/host-scoped/

"The purpose of the MIF working group is to describe the issues surrounding
IPv4 and IPv6 as well as stateless and stateful configuration."

s/The focus of the working group should be on documenting/The working group
will document/ s/system level/system-level/ s/identification of
gaps/identify the gaps/

"Network discovery and selection on lower layers as defined by RFC 5113 is
out of scope. Also, the group shall not develop new protocol or policy
mechanisms; recommendations and gap analysis from the group are solely based
on existing solutions. The group shall not assume any software beyond basic
IP protocol support on its peers or in network nodes. No work will be done
to enable traffic flows to move from one interface to another. The group
recognizes existing work on mechanisms that require peer or network support
for moving traffic flows such as RFC 5206, RFC 4980 and the use of multiple
care-of addresses in Mobile IPv6. This group does not work on or impact such
mechanisms."

s/on lower layers//

thanks,

Gabriel

----- Original Message ----

---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential
information, privileged material (including material protected by the
solicitor-client or other applicable privileges), or constitute non-public
information. Any use of this information by anyone other than the intended
recipient is prohibited. If you have received this transmission in error,
please immediately reply to the sender and delete this information from your
system. Use, dissemination, distribution, or reproduction of this
transmission by unintended recipients is not authorized and may be unlawful.
_______________________________________________
mif mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mif

---

From: gabriel montenegro <[email-masked]>
Date: Fri, 3 Apr 2009 08:14:38 -0700 (PDT)

Just one comment on Giyeong's message, on this paragraph:

...
> group not exclude the use case of a (virtual) interface associated with multiple 
> access networks? Or, it does?

I believe the working group deals with the case of multiple interfaces of any kind,
virtual, physical, etc. The point is that an interface may hide further complexity underneath
(e.g., it may multiplex many other interfaces to different networks), but from the point of view of the stack it
is just one interface, and any complexity hidden under it is out of scope of MIF.  

MIF deals with the issues arising from more than one interface (of any type) visible to the stack.

You said: "..a TCP connection run over multiple interfaces with the work, so a packet transmission on the TCP connection can select an interface dynamically on fly..."

All that, if hidden under a virtual interface is not visible to MIF. So if that virtual interface is the only 
interface on the system, then there is nothing in scope for MIF. If in addition to that virtual interface you
had another interface, for example, a real ethernet interface, then MIF has something to say.

Gabriel

---

From: "Giyeong Son" <[email-masked]>
Date: Fri, 3 Apr 2009 11:33:56 -0400

So in your email, I think, if the TCP connection is based on a virtual interface, it is out of scope for MIF since MIF considers it as single interface. However, if the TCP connection is based on multiple IP addresses associated with a (virtual) IP address, it is in scope for MIF. MIF may need to be involved in handling multiple interfaces for the TCP connection in some way. I guess, MIF may address this problem.

Giyeong

-----Original Message-----
From: gabriel montenegro [mailto:[email-masked]] 
Sent: April 3, 2009 11:15 AM
To: Giyeong Son; George Tsirtsis; Daniel Park
Cc: mif
Subject: Re: [mif] next steps for MIF

...
> "multiple interfaces to connect to multiple networks". So, does the 
> working group not exclude the use case of a (virtual) interface 
> associated with multiple access networks? Or, it does?

I believe the working group deals with the case of multiple interfaces of any kind, virtual, physical, etc. The point is that an interface may hide further complexity underneath (e.g., it may multiplex many other interfaces to different networks), but from the point of view of the stack it is just one interface, and any complexity hidden under it is out of scope of MIF.  

All that, if hidden under a virtual interface is not visible to MIF. So if that virtual interface is the only interface on the system, then there is nothing in scope for MIF. If in addition to that virtual interface you had another interface, for example, a real ethernet interface, then MIF has something to say.

Gabriel

---

From: Lars Eggert <[email-masked]>
Date: Fri, 3 Apr 2009 18:42:52 +0300

Hi,

On 2009-4-3, at 18:33, Giyeong Son wrote:
> So in your email, I think, if the TCP connection is based on a  
> virtual interface, it is out of scope for MIF since MIF considers it  
> as single interface. However, if the TCP connection is based on  
> multiple IP addresses associated with a (virtual) IP address, it is  
> in scope for MIF. MIF may need to be involved in handling multiple  
> interfaces for the TCP connection in some way. I guess, MIF may  
> address this problem.

I don't agree. Neither is in scope of MIF in my opinion - MIF isn't  
working on session continuity.

Lars

---

From: George Tsirtsis <[email-masked]>
Date: Fri, 3 Apr 2009 11:50:10 -0400

Maybe a different way of looking at this is that MIF should look at
the problem of multiple interfaces from the point of view of the IP
stack looking down. From this point of view the IPStack sees one, or
more interfaces and MIF should document best current practices in how
the IP stack should handle multiple such interfaces.

Things like "virtual Interfaces" are about looking at this issue from
the bottom up i.e., attempting to hide complexity at physical
interface level by presenting a simpler interface structure (e.g.,
just one IF) to the IPstack. MIP does exactly that, while many
proprietary device implementation also crete the same effect. All this
IMO is out of scope of MIF.

Does this help?
George

---

From: "Giyeong Son" <[email-masked]>
Date: Fri, 3 Apr 2009 11:57:59 -0400

I think the implementation of TCP or virtual IP address is responsible
for session continuity. However, I'd like to see if MIF will address
group of a number of interfaces among all the available interfaces
limited (or scoped) by the upper layer or other. For instance, the TCP
connection may select a number of interfaces among all the available
interfaces in the host. In this case, will MIF be responsible for pakcet
transmission over multiple interface handling within the group scoped by
the TCP connection? 

Giyeong

-----Original Message-----
From: Lars Eggert [mailto:[email-masked]] 
Sent: April 3, 2009 11:43 AM
To: Giyeong Son
Cc: gabriel montenegro; George Tsirtsis; Daniel Park; mif
Subject: Re: [mif] next steps for MIF

Hi,

On 2009-4-3, at 18:33, Giyeong Son wrote:
> So in your email, I think, if the TCP connection is based on a virtual

> interface, it is out of scope for MIF since MIF considers it as single

> interface. However, if the TCP connection is based on multiple IP 
> addresses associated with a (virtual) IP address, it is in scope for 
> MIF. MIF may need to be involved in handling multiple interfaces for 
> the TCP connection in some way. I guess, MIF may address this problem.

Lars

---

From: Lars Eggert <[email-masked]>
Date: Fri, 3 Apr 2009 19:16:15 +0300

On 2009-4-3, at 18:57, Giyeong Son wrote:
> For instance, the TCP
> interfaces in the host.

A local TCP connection endpoint is a socket, which is an <IP address,  
port> pair. Currently standardized TCP has no mechanism for using or  
understanding sockets that contain more than one IP address/interface.

Sticking with your example, what MIF is about is allowing a TCP  
connection to use *any one* of the interfaces/IP addresses, by  
aligning the possibly conflicting host and network configuration  
information related to the set of interfaces.

It's up to TCP or the application to then decide which interface/IP  
address to use.

> In this case, will MIF be responsible for pakcet

See above, that question doesn't make sense. Standard TCP doesn't  
transmit over multiple interfaces.

Lars

---

From: Scott Brim <[email-masked]>
Date: Fri, 3 Apr 2009 12:21:04 -0400

> working on session continuity.

It seems to me that MIF should work on what is needed for that TCP
connection to be established, but not on things like selection out of
a set of interfaces.  IMHO MIF's purpose is to set the stage.  I don't
think it matters whether the transport protocol that uses the
decisions MIF makes is TCP, multipath TCP or anything else.  

Scott

---

From: Lars Eggert <[email-masked]>
Date: Fri, 3 Apr 2009 20:02:20 +0300

> decisions MIF makes is TCP, multipath TCP or anything else.

Fully agree.

Lars

---

From: gabriel montenegro <[email-masked]>
Date: Fri, 3 Apr 2009 13:05:14 -0700 (PDT)

I'm not entirely clear as to your particular scenario here. The key thing to remember is this
line in Jari's most recent charter:

"The group shall not assume any software beyond basic IP protocol support on its peers or in network nodes. "

This precludes fancy acrobatics that extend TCP to handle more than one source address, for example.

But perhaps your scenario is the following:

    - host with multiple interfaces, each with its own separate IP address and configuration (as usual), e.g.:
        - interface intA with address addrA
        - interface intB with address addrB
        - interface intC with address addrC

    - a TCP session from this host to a peer is started:
        - source address is chosen from among the addresses assigned to its interfaces, say
            addrA
        - destination address is addrP on the peer

Packets for this TCP session will always have addrA and addrP as the endpoints. 
Is this your scenario?

If you're thinking of varying the endpoints to anything other than addrA and addrP, then
you're outside of MIF.  Or is this your scenario?

Now, assuming you don't change those endpoints, a separate question is which interface 
you'll use to send and receive packets for that TCP session. The choice of interface is in
MIF scope, but RFC1122 etc already have something to say here (e.g., weak vs strong host).

----- Original Message ----
> From: Lars Eggert <[email-masked]>
> To: Giyeong Son <[email-masked]>
> Cc: gabriel montenegro <[email-masked]>; George Tsirtsis <[email-masked]>; Daniel Park <[email-masked]>; mif <[email-masked]>
> Sent: Friday, April 3, 2009 9:16:15 AM
> A local TCP connection endpoint is a socket, which is an 
> pair. Currently standardized TCP has no mechanism for using or understanding 
> sockets that contain more than one IP address/interface.
> 
> Sticking with your example, what MIF is about is allowing a TCP connection to 
> use *any one* of the interfaces/IP addresses, by aligning the possibly 
> conflicting host and network configuration information related to the set of 
> interfaces.
> 
> It's up to TCP or the application to then decide which interface/IP address to 
> use.
> 
> See above, that question doesn't make sense. Standard TCP doesn't transmit over 
> multiple interfaces.
> 
> Lars

---

From: "Giyeong Son" <[email-masked]>
Date: Fri, 3 Apr 2009 16:07:58 -0400

Then, I'd like to clearly understand the scope of MIF. 

I guess, the working group does not address selection of the best
suitable interface based on a routing policy, e.g. least cost (given by
the upper layer or other), for packet transmissin(s) of a service
transaction. Only the way, in terms of interface selection for packet
transmission, done by the upper layer. So, with MIF the upper layer may
obtain the current states and/or static info of all the available
interfaces in an efficient and easy way, but the upper layer selects a
best suitable interface among the available interfaces. An IP stack
instance per each interface seems to be an assumption. And IMF enables
multiple IP instances to run in active so that applications can use them
dynamically. Am I right?

Giyeong  

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Scott Brim
Sent: April 3, 2009 12:21 PM
To: [email-masked]
Subject: Re: [mif] next steps for MIF

address this problem.

It seems to me that MIF should work on what is needed for that TCP
connection to be established, but not on things like selection out of a
set of interfaces.  IMHO MIF's purpose is to set the stage.  I don't
think it matters whether the transport protocol that uses the decisions
MIF makes is TCP, multipath TCP or anything else.  

Scott

---

From: "Giyeong Son" <[email-masked]>
Date: Fri, 3 Apr 2009 17:00:37 -0400

Let's assume that there is a multiple interface handling proxy available in the network for the peer. Then, the host and the proxy are responsible to resolve a virtual address with a real IP address based on a routing policy given by an upper layer, let's say application.

With the system environment, let's move to your example. App_a creates a TCP connection with a virtual address, v_addr, as the source and a destination address addrP for the peer. During the creation, App_a provided a group that contains addrA and addrB for v_addr as the available access networks for the peer and sets the routing policy as "least cost". Then, the App_a sends an outbound packet down. A multi-interface handling component in the host manages the IP address mapping table. TCP stack requests the multiple-interface handling component to return the best suitable IP address for v_ddr based on the routing policy, "least cost". The multi-interface handling component selects the best suitable IP address addrA in the group for v_addr. The host sends the packet to addrA, and then the proxy in the network receives the packet to the peer with v_addr. For the other direction, the proxy resolves the destination address, v_addr, to addrB based on the routing policy, and the host receives the packet through addr_b. The application receives the packet, but it knows that it received the packet with v_addr. This may be a scenario based on your example. 

I do not want to argue whether this is feasible with the current technologies or not. But let's assumpt that it works. Then, in this example, I'd like to see how MIF can contribute to the host to handle simultaneous use of multiple interfaces?

Giyeong

-----Original Message-----
From: gabriel montenegro [mailto:[email-masked]] 
Sent: April 3, 2009 4:05 PM
To: Lars Eggert; Giyeong Son
Cc: George Tsirtsis; Daniel Park; mif
Subject: Re: [mif] next steps for MIF

I'm not entirely clear as to your particular scenario here. The key thing to remember is this line in Jari's most recent charter:

If you're thinking of varying the endpoints to anything other than addrA and addrP, then you're outside of MIF.  Or is this your scenario?

Now, assuming you don't change those endpoints, a separate question is which interface you'll use to send and receive packets for that TCP session. The choice of interface is in MIF scope, but RFC1122 etc already have something to say here (e.g., weak vs strong host).

---

From: gabriel montenegro <[email-masked]>
Date: Fri, 3 Apr 2009 15:04:15 -0700 (PDT)

I think there's some issues with your scenario that put it outside of MIF. You require way
too many modification both in the host and in the network:

You say: "Let's assume that there is a multiple interface handling proxy available in the 
network for the peer"

And: "During the creation, App_a provided a group that  contains addrA and addrB for v_addr "

And: "A multi-interface handling component in the host manages the IP address mapping table"

All this is out of MIF as the charter clarifies: "The group shall not assume any software beyond basic IP protocol support on its peers or in network nodes. "

There are plenty other such modifications in the host or in the network. Other such
efforts were mentioned in: http://www.ietf.org/proceedings/09mar/slides/mif-3.pdf

Gabriel

----- Original Message ----
> From: Giyeong Son <[email-masked]>
> To: gabriel montenegro <[email-masked]>; Lars Eggert <[email-masked]>
> Cc: George Tsirtsis <[email-masked]>; Daniel Park <[email-masked]>; mif <[email-masked]>
> Sent: Friday, April 3, 2009 2:00:37 PM
> Subject: RE: [mif] next steps for MIF
> 
> Let's assume that there is a multiple interface handling proxy available in the 
> network for the peer. Then, the host and the proxy are responsible to resolve a 
> virtual address with a real IP address based on a routing policy given by an 
> upper layer, let's say application.
> 
> With the system environment, let's move to your example. App_a creates a TCP 
> connection with a virtual address, v_addr, as the source and a destination 
> address addrP for the peer. During the creation, App_a provided a group that 
> contains addrA and addrB for v_addr as the available access networks for the 
> peer and sets the routing policy as "least cost". Then, the App_a sends an 
> outbound packet down. A multi-interface handling component in the host manages 
> the IP address mapping table. TCP stack requests the multiple-interface handling 
> component to return the best suitable IP address for v_ddr based on the routing 
> policy, "least cost". The multi-interface handling component selects the best 
> suitable IP address addrA in the group for v_addr. The host sends the packet to 
> addrA, and then the proxy in the network receives the packet to the peer with 
> v_addr. For the other direction, the proxy resolves the destination address, 
> v_addr, to addrB based on the routing policy, and the host receives the packet 
> through addr_b. The application receives the packet, but it knows that it 
> received the packet with v_addr. This may be a scenario based on your example.
> 
> I do not want to argue whether this is feasible with the current technologies or 
> not. But let's assumpt that it works. Then, in this example, I'd like to see how 
> MIF can contribute to the host to handle simultaneous use of multiple 
> interfaces?
> 
> 
> Giyeong
> 
> I'm not entirely clear as to your particular scenario here. The key thing to 
> remember is this line in Jari's most recent charter:
> 
> If you're thinking of varying the endpoints to anything other than addrA and 
> addrP, then you're outside of MIF.  Or is this your scenario?
> 
> Now, assuming you don't change those endpoints, a separate question is which 
> interface you'll use to send and receive packets for that TCP session. The 
> choice of interface is in MIF scope, but RFC1122 etc already have something to 
> say here (e.g., weak vs strong host).
> 
> 
> 
> > From: Lars Eggert 
> > Cc: gabriel montenegro ; George Tsirtsis 
> ; Daniel Park ; mif 
> recipient is prohibited. If you have received this transmission in error, please 
> immediately reply to the sender and delete this information from your system. 
> Use, dissemination, distribution, or reproduction of this transmission by 
> unintended recipients is not authorized and may be unlawful.

---

From: "Giyeong Son" <[email-masked]>
Date: Fri, 3 Apr 2009 18:29:18 -0400

Hi Gabriel,

The host does not need to know the proxy, but it knows that the available IP addresses (e.g. addrA and addrB) can reach to addr_p. 

In your email, if a TCP connection is established over multiple interfaces (IP addresses for all the interfaces in the host) by having a IP address reprehensive (one of the IP addresses or a virtual IP address), TCP can obtain IP address of a suitable interface from MIF at a time. And MIF can determine which interface is suitable one among all the interfaces maybe based on the current states of the interfaces (with a routing policy -?)?

Giyeong 

-----Original Message-----
From: gabriel montenegro [mailto:[email-masked]] 
Sent: April 3, 2009 6:04 PM
To: Giyeong Son; Lars Eggert
Cc: George Tsirtsis; Daniel Park; mif
Subject: Re: [mif] next steps for MIF

I think there's some issues with your scenario that put it outside of MIF. You require way too many modification both in the host and in the network:

You say: "Let's assume that there is a multiple interface handling proxy available in the network for the peer"

There are plenty other such modifications in the host or in the network. Other such efforts were mentioned in: http://www.ietf.org/proceedings/09mar/slides/mif-3.pdf

Gabriel

----- Original Message ----
> Let's assume that there is a multiple interface handling proxy 
> available in the network for the peer. Then, the host and the proxy 
> are responsible to resolve a virtual address with a real IP address 
> based on a routing policy given by an upper layer, let's say application.
> 
> With the system environment, let's move to your example. App_a creates 
> a TCP connection with a virtual address, v_addr, as the source and a 
> destination address addrP for the peer. During the creation, App_a 
> provided a group that contains addrA and addrB for v_addr as the 
> available access networks for the peer and sets the routing policy as 
> "least cost". Then, the App_a sends an outbound packet down. A 
> multi-interface handling component in the host manages the IP address 
> mapping table. TCP stack requests the multiple-interface handling 
> component to return the best suitable IP address for v_ddr based on 
> the routing policy, "least cost". The multi-interface handling 
> component selects the best suitable IP address addrA in the group for 
> v_addr. The host sends the packet to addrA, and then the proxy in the 
> network receives the packet to the peer with v_addr. For the other 
> direction, the proxy resolves the destination address, v_addr, to 
> addrB based on the routing policy, and the host receives the packet through addr_b. The application receives the packet, but it knows that it received the packet with v_addr. This may be a scenario based on your example.
> 
> I do not want to argue whether this is feasible with the current 
> technologies or not. But let's assumpt that it works. Then, in this 
> example, I'd like to see how MIF can contribute to the host to handle 
> simultaneous use of multiple interfaces?
> 
> 
> Giyeong
> 
> I'm not entirely clear as to your particular scenario here. The key 
> thing to remember is this line in Jari's most recent charter:
> 
> "The group shall not assume any software beyond basic IP protocol 
> support on its peers or in network nodes. "
> 
>     - host with multiple interfaces, each with its own separate IP 
> address and configuration (as usual), e.g.:
> If you're thinking of varying the endpoints to anything other than 
> addrA and addrP, then you're outside of MIF.  Or is this your scenario?
> 
> Now, assuming you don't change those endpoints, a separate question is 
> which interface you'll use to send and receive packets for that TCP 
> session. The choice of interface is in MIF scope, but RFC1122 etc 
> already have something to say here (e.g., weak vs strong host).
> 
> 
> 
> > > connection may select a number of interfaces among all the 
> > > available interfaces in the host.
> >
> > A local TCP connection endpoint is a socket, which is an pair. 
> > Currently standardized TCP has no mechanism for using or 
> > > In this case, will MIF be responsible for pakcet transmission over 
> > > multiple interface handling within the group scoped by the TCP 
> > > connection?
> >
> > transmit
> over
> solicitor-client or other applicable privileges), or constitute 
> non-public information. Any use of this information by anyone other 
> than the intended recipient is prohibited. If you have received this 
> transmission in error, please immediately reply to the sender and delete this information from your system.
> Use, dissemination, distribution, or reproduction of this transmission 
> by unintended recipients is not authorized and may be unlawful.

---

From: gabriel montenegro <[email-masked]>
Date: Fri, 3 Apr 2009 18:12:16 -0700 (PDT)

> The host does not need to know the proxy, but it knows that the available IP 
> addresses (e.g. addrA and addrB) can reach to addr_p.

It doesn't matter if the host does not know the proxy, nor that there is even a proxy.
The wording in the charter leaves out cases in which some such specific support
is expected in the network (e.g., PMIP support in the network to enable some
scenario).
 
> In your email, if a TCP connection is established over multiple interfaces (IP 

A TCP connection is never established over multiple interfaces.

> addresses for all the interfaces in the host) by having a IP address 
> reprehensive (one of the IP addresses or a virtual IP address), TCP can obtain 
> IP address of a suitable interface from MIF at a time. And MIF can determine 

TCP as usual yes: one source and one destination address for the session.

> which interface is suitable one among all the interfaces maybe based on the 
> current states of the interfaces (with a routing policy -?)?

Choosing that one source and destination address when there may be several
to choose from for TCP is something that MIF does, yes, mainly by reusing stuff
in 3484 (and future revisions). What the slides said is that this part of the problem 
may  be common with other approaches like SHIM6 or HIP, or your scheme. But
beyond the default src/dst address selection which may be common with MIF, such
schemes probably want to depart from the default anyways, just because they have
other software or network support that allows them to fit their scenarios better than
the vanilla 3484 would allow them to. Seems like this would apply to your scheme as
well.

> I think there's some issues with your scenario that put it outside of MIF. You 
> require way too many modification both in the host and in the network:
> 
> All this is out of MIF as the charter clarifies: "The group shall not assume any 
> software beyond basic IP protocol support on its peers or in network nodes. "
> 
> There are plenty other such modifications in the host or in the network. Other 
> such efforts were mentioned in: 
> http://www.ietf.org/proceedings/09mar/slides/mif-3.pdf
> 
> Gabriel
> 
> > From: Giyeong Son 
> > To: gabriel montenegro ; Lars Eggert
> > 
> > Cc: George Tsirtsis ; Daniel Park
> > ; mif 
> > addrB based on the routing policy, and the host receives the packet through 
> addr_b. The application receives the packet, but it knows that it received the 
> packet with v_addr. This may be a scenario based on your example.
> >

---

From: George Tsirtsis <[email-masked]>
Date: Sat, 4 Apr 2009 19:15:41 +0100

> TCP as usual yes: one source and one destination address for the session.

GT> Right, so if I am understanding what Giyeong is talking about, it
would probably require TCP changes...which would make it similar to
SCTP in some respects. Sounds like beyond MIF scope at this point.

George

---

From: "Giyeong Son" <[email-masked]>
Date: Mon, 6 Apr 2009 11:26:21 -0400

Hi all,

Thanks for the responses from many of you on my question in regard to
the scope and the role of MIF. I think that I may not question to you
accurately and properly. 

The reason I brought a TCP scenario (or use case) for simultaneous use
of multiple interfaces is NOT TO DISCUSS ABOUT an implementation or an
enabling architecture of the scenario. 

I wanted to clearly understand the SCOPE and the ROLE of that MIF
pursues described in the charter from system perspective, by utilizing a
scenario with TCP as clearly indicated that "The focus of the working
group should be on documenting the system level effects to host IP
stacks and identification of gaps between the existing IETF
recommendations and existing practice". 

I fully understand that MIF is not an enabling solution for this TCP
scenario. I brought the TCP scenario since TCP would be one of the upper
layers above the multi-interface network environment and I felt that it
might be helpful to clearly understand the scope and the role of MIF
from user perspective. Definitely, discussions about the enabling
solution for the scenario is out of MIF's scope.

And as the charter indicated that "the group shall not assume any
software beyond basic IP protocol support on its peers or in network
nodes", the shape of the network based on multi-interface network
environment and how to implement and deploy it are up to the implementer
based on the features or feasibility supported by MIF if the network is
based on MIF. For sure that MIF does not know about TCP, may not be a
peer and a complementary solution to support of simultaneous use of
multiple interfaces at TCP level. 

As I understand how much simultaneous use of multiple interfaces are
crucial in the (near) future in various ways from the perspective of
technology and business, I'd like to contribute to identifying and
addressing of the problems with multiple interfaces in the standard
bodies. That is why I'd like to clearly understand the scope and the
role of MIF.  

Again, I really appreciate your valuable responses on my question with
the TCP use case. Hopefully, with this email nobody misunderstands and
is confused on my question.

Best Regards,
Giyeong

-----Original Message-----
From: George Tsirtsis [mailto:[email-masked]] 
Sent: April 4, 2009 2:16 PM
To: gabriel montenegro
Cc: Giyeong Son; Lars Eggert; Daniel Park; mif
Subject: Re: [mif] next steps for MIF

On Sat, Apr 4, 2009 at 2:12 AM, gabriel montenegro
<[email-masked]> wrote:
>
>> The host does not need to know the proxy, but it knows that the 
>> available IP addresses (e.g. addrA and addrB) can reach to addr_p.
>
> The wording in the charter leaves out cases in which some such 
> specific support is expected in the network (e.g., PMIP support in the

> network to enable some scenario).
>
>> reprehensive (one of the IP addresses or a virtual IP address), TCP 
>> can obtain IP address of a suitable interface from MIF at a time. And

>> MIF can determine

GT> Right, so if I am understanding what Giyeong is talking about, it
would probably require TCP changes...which would make it similar to SCTP
in some respects. Sounds like beyond MIF scope at this point.

George

---

From: Hui Deng <[email-masked]>
Date: Tue, 7 Apr 2009 08:41:53 +0800

Thanks Giyeong, looking forward to your future contribution.
Thanks for the discussion to clarify the scope

-Hui