Subject: Re: [rrg] multi-homed site issues

From: Patrick Frejborg <[email-masked]>
Date: Thu, 5 Aug 2010 13:34:37 +0300

On Fri, Jul 2, 2010 at 2:55 PM, RJ Atkinson <[email-masked]> wrote:
>
> However, it is important first to note that ILNP *by itself*
> enables a multi-path TCP implementation -- without requiring
> any TCP protocol extensions/options.  Further, ILNP's approach
> also enables any other transport-layer protocol to instantly
> become multi-path capable.

Interesting!

Could you explain in more details or point me to a paper how this is
achieved - couldn't find it described in
http://tools.ietf.org/html/draft-rja-ilnp-intro-03, thanks!

>
> To provide a single example of how ILNP can enhance existing
> proposals for MP/TCP, combining ILNP with MP/TCP enables one
> to use a single IPsec session with a multi-path TCP connection.
> By contrast, with current IPsec, one would need to have a
> separate IPsec session for each pair of TCP endpoints.  So
> the key management complexity associated with MP/TCP
> would be reduced from O(M * N) to O(1) -- which is a very
> significant benefit and quite complementary to existing work
> within the MP/TCP area.

True, since the IPsec session is "anchored" to the identifier and thus
agnostic to transport protocol changes.
But IPsec is not much used today, SSL/TLS has become the major player
except in site-to-site VPN solutions.
tcpcrypt is an interesting approach - but it is only for TCP

-- patte

---

From: RJ Atkinson <[email-masked]>
Date: Thu, 5 Aug 2010 07:18:31 -0400

> http://tools.ietf.org/html/draft-rja-ilnp-intro-03, thanks!

A starting point is that I-D, Sections 2, 3, and 4.

Because a node, at any time, with any ILNP session, can use 
(1) all valid local locators and (2) all valid correspodent 
locators, therefore any session can use (A) any path 
at any time or (B) any combination of paths at any time.

Also see, for example, MILCOM 2009 paper.  Also
discussed, for example, in the MILCOM 2006 paper,
in the context of a Coalition Peering Domain.

> True, since the IPsec session is "anchored" to the identifier
> and thus agnostic to transport protocol changes.

Right.

Yours,

Ran

---

From: Patrick Frejborg <[email-masked]>
Date: Thu, 5 Aug 2010 15:26:49 +0300

> at any time or (B) any combination of paths at any time.

So to achieve multi-pathing you need two separate interfaces with own
locators on the node - unless BRDP is used for egress traffic of the
initiator to solve the exit routing (that I have called first mile
routing).
It is unclear for me how BRDP works at the responder site, e.g.
subflow A is arriving at border router 1 - locator value is rewritten
and packet is forwarded to the responder. Subflow B is arriving at
border router 2, locator value is rewritten and forwarded to the
responder. How does the responder know to which border routers subflow
A and B belongs in order to achieve separate and symmetric paths?
BRDP is replacing default gateway mechanism, it seems that something
should be added for the first packets of a subflow at the border
router so that the responder can "setup" the returning subflows to the
correct border routers.

Also which component  is applying  muxing of packets from the
application level and concurrently load-balance packets between the
paths?
I.e. two first packets are sent on path A and following packets are
sent on path B, then following on path A etc

> in the context of a Coalition Peering Domain.

Will do

-- patte

---

From: RJ Atkinson <[email-masked]>
Date: Thu, 5 Aug 2010 10:34:19 -0400

> initiator to solve the exit routing (that I have called first mile

No.  

There are multiple counter-examples.  I'll briefly list a few, 
deliberately in summary form because time is scarce.  Other
counter-examples also exist.

A) As you suggest, BRDP can be very helpful in some situations.
   (I am quite keen for Teco Boot to continue his work on BRDP.)
   However, BRDP is not necessary to support either multi-homing 
   or multi-path.

B) If one considers a session between two correspondents, 
   if either node has more than one valid Locator value 
   (e.g. in the DNS, multiple L64 or L32 records), then 
   multi-pathing and multi-homing are each supportable.  

C) The MILCOM 2009 paper about Site-Controlled Multi-Homing 
   provides an example where a node can have multiple Locator values 
   (or 1 ore more LP records that in turn point to multiple 
   Locator records) in the DNS, but where that node only has 
   1 Locator value configured inside the stack of that node.
   In such a scenario, the site has multiple upstream links 
   with at least 1 distinct Locator value for each upstream link.

One imagines that different users/sites will make different
deployment decisions.  ILNP supports multiple deployment models,
leaving it up to the users/sites to select one that is appropriate
for that user/site.

> How does the responder know to which border routers subflow
> A and B belongs in order to achieve separate and symmetric paths ?

There are multiple deployment scenarios that work fine.
I'll list two, in summary form due to lack of time, but
others also exist.  The MILCOM 2009 on Site-Controlled
Multi-homing describes at least one scenario in some detail.

W) The responder does not need to know if the responder's
   site is using the deployment approach from the above
   MILCOM 2009 paper.  The site border routers can be 
   configured with whatever multi-homing (and/or multi-path)
   policy that the site wishes.

X) The responder either knows or can learn that the initiator
   has multiple Locator values (or 1 or more LP records pointing 
   to multiple Locator values).  The responder simply sends the
   packet out to the different Destination Locator values.
   Provided that those different Locator values are on different
   subnetworks, ordinary LPM routing will cause the packets
   to travel down (entirely, partly, or slightly -- depending on
   how much topological variance exists in the Locators used) 
   different paths.

There are no guarantees of symmetric routing in today's Internet.
Similarly, there are no guarantees of symmetric routing in ILNP.
The path taken in one direction might or might not be the inverse
of the path taken in the other direction.  Ignoring other issues, 
the deployed BGP routing system means that guarantees about 
symmetric routing cannot be made.

> BRDP is replacing default gateway mechanism, ...

I would say that BRDP can be used to supplement/enhance the
usual default gateway mechanism.  I would not say "replace".

> it seems that something should be added for the first packets
> of a subflow at the border router so that the responder can
> "setup" the returning subflows to the correct border routers.

I don't understand those words.  

> sent on path B, then following on path A etc

I also don't understand those words.

If one considers TCP as an example, then the TCP instance simply
sees the information as it arrives at the node.  Because ILNP means
that the TCP instance is not bound to any particular Locator, the
TCP instance is oblivious about which path a particular received
TCP segment might have travelled.  Similarly, the transmitting
TCP instance is oblivious about whether multiple paths are in use
xor a single path is in use -- and also oblivious about which
transmitted TCP segment might travel which path.

The ordinary TCP operation will handle the information that arrived,
perform the usual TCP operations (reassembling TCP segments, sending
TCP ACKs, etc) and will pass the received information up to the
application using the existing APIs.  So no application changes are
needed either.

Yours,

Ran

---

From: Patrick Frejborg <[email-masked]>
Date: Fri, 6 Aug 2010 11:40:35 +0300

>   with at least 1 distinct Locator value for each upstream link.

And this is my point - if a node have several locator values you might
need to have
- two separate networks between the node and the  border routers
- some routing mechanism in the node, when should the node use locator
1 and when should it use locator 2?
Outcome is that the operational expenditures becomes too high and I
guess that is one reason we haven't seen SCTP becoming mainstream

> symmetric routing cannot be made.

It is very true that Internet is far from symmetric but there exist
use cases where symmetric paths is a major requirement. But wouldn't
it be nice to have e.g. symmetric concurrent multipaths (as described
in the introduction of draft-ietf-mptcp-architecture-01) from your
workstations to the data center - for one session?
Attaching a presentation for another use case. Hope this helps
understanding what I'm trying to explain here.
And this mechanism (locator header) can be added to ILNP, would take
another 128 bits and create a 64bit x 64bit locator space

--patte

---

From: RJ Atkinson <[email-masked]>
Date: Fri, 6 Aug 2010 08:51:20 -0400

> - two separate networks between the node and the  border routers

That is a confusion.

1) Those assumptions are never true when one deploys using (C) above.

2) Further, a node never needs "two separate networks between the 
   node and the border routers" to have two (or more) Locator 
   values.  The trivial example here is multi-netting; other 
   examples also exist.

3) A node doesn't even need to have more than 1 network interface
   in order to have more than 1 Locator value at the same time.
   Multi-netting is again a trivial example here; other examples
   also exist.

> 1 and when should it use locator 2?

The node may choose any valid Locator value for itself,
among the set of valid Locators.  This is a local policy matter.

Similarly, the node may choose any valid Locator value for the
correspondent, among the set of valid Locators.  This is also
a local policy matter.

Kindly recall that Locator records in the DNS have Preference
values.  An obvious use for those Preference values is to
signal the Locator frequency preference of the node associated
with those Locator records.  It could, for example, have multiple
Locator records with equal preference, indicating a suggestion
that remote nodes alternate which Locator value is used with
each packet (among the equal set).  ILNP doesn't require that
Preference values be used this way, should a site or node 
prefer not to do so, but ILNP certainly does enable Preference 
values be used this way.

No.

Even if the node always chooses one of those locators, that 
node can still have multi-path transport benefits, because 
the site border routers are allowed to rewrite Locator values.  

So a site could have a policy to enable multi-path session -- 
where that policy exists solely within its site border routers.  
This eliminates any need to put any multi-path policy configuration 
on nodes within the site.

Since this multi-path policy is really ultimately a routing
policy, something which router administrators routinely do 
today (e.g. "weights" in IGP link-state routing protocols, 
"local pref" or "AS prepending" in BGP), there is substantial 
operational experience indicating that this is quite 
reasonable and not burdensome.

ILNP is about providing choices to users/operators/sites.
ILNP can be deployed quickly if desired, without bothering
with node-specific or site-specific configuration items.  
Later on, if desired, nodes or routers can have additional 
configuration, again if and only if the site admin or 
node admin wishes to do so.

> workstations to the data center - for one session?

ILNP does nothing to prevent symmetric routing.  
ILNP does not require symmetric routing.

Folks who have an interior routing deployment that provides
symmetry (e.g. between workstation & local data centre) 
can continue to have one with ILNP.  Nothing in the ILNP
specifications prevents that from continuing to work.

Yours,

Ran

---

From: Patrick Frejborg <[email-masked]>
Date: Fri, 6 Aug 2010 17:09:44 +0300

> 1) Those assumptions are never true when one deploys using (C) above.

Had again a look on the paper, think you are referring section D.
Mobile networks with ILNP, right?
That is a handover scenario from L1 to L3 described - what I'm looking
for to have MPTCP having two concurrent subflows traversing over both
L1 and L3 simultaneously

>   values.  The trivial example here is multi-netting; other

Sorry, I should have used two logical networks, so you have configure
multi-netting (secondary addresses) on the hosts, routers, firewalls
etc

>   Multi-netting is again a trivial example here; other examples

To me that is two logical networks with two separate 0/0 routes

> among the set of valid Locators.  This is a local policy matter.

Right

> correspondent, among the set of valid Locators.  This is also

And how do you ensure that there are symmetric paths between nodes
when local policies are applied on the nodes - the node policies
should be in sync

> prefer not to do so, but ILNP certainly does enable Preference

Understood, but DNS do not tell the initaitor that for the returned
locator A value the initiator should use local locator 1, for returned
locator B the initiator should use local locator 2. If it do then the
subflows are always established as

             locator1 -----subflow1-------locatorA
initiator                                                              responder
             locator2------subflow2------locatorB

> the site border routers are allowed to rewrite Locator values.

True - but you might end up with asymmetric paths between two
multi-homed sites - if you are setting different preference values in
DNS one path is preferred and with equal values then the nodes choose
randomly (?) which locator is used unless there is some local policy
at the node (that are in sync)

> on nodes within the site.

Agreed - but to ensure that there is always symmetric multipath the
egress border router 1 (the router in front of the responder) should
follow up incoming flows so it can decide if this flow arrived via
router 1 or not. If not then most likely the flow was established over
the other egress border router 2 - then policy route the response flow
from the responder via border router 2 (in case the responder uses
border router 1 as the 0/0 path).

> reasonable and not burdensome.

True, but many enterprises would be happy to get rid of the BGP tuning
- with the locator header&MPTCP you just connect your multi-homed site
to Internet, announce your attachment point (ALOC1, ALOC2) together
with ELOC values in DNS - let the transport protocol do the
load-balance tuning (which is reacting instantly to the traffic
situation). BGP tuning is usually done after somebody have suffered
and complained....your services has already suffered...

So with MPTCP & locator header  you have reached a better service
level with less cost than current multi-homing implementation.

> specifications prevents that from continuing to work.
Right,  but ILNP do nothing to better support MPTCP or SCTP than what
we have today  - it is a status quo form their perspective

-- patte

---

From: Shane Amante <[email-masked]>
Date: Fri, 6 Aug 2010 10:52:41 -0600

Patrick,

> On Fri, Aug 6, 2010 at 3:51 PM, RJ Atkinson <[email-masked]> wrote:

[--snip--]

>             locator2------subflow2------locatorB

I would note:
a)  This is no different than what happens in today's deployment of IPv4 and IPv6.
b)  You may be asking ILNP to do something it isn't necessarily designed to do out of the gate -- or, perhaps, won't do without assistance from something like BRDP or an equivalent mechanism that, I believe, Tony Li may have pointed out on the mailing list last month.
    On a related note, at least wrt IPv6, I would also point out that there are discussions occurring in 6MAN right now wrt how to accomplish distribution of address selection policy on hosts within an "organization".  Please refer to slide 6 of the following given at IETF 78:
http://tools.ietf.org/agenda/78/slides/6man-5.pdf

In summary, it may be best to avoid "boiling the ocean" with respect to "v1" of ILNP (or, for that matter, any other protocol in any IETF WG), but keep in mind a few things:
a)  Other WG's in the IETF may already be looking at and/or working on solving for these scenarios, (cf: 6MAN + address selection policy),
b)  In the IETF, new WG's /may/ get formed[1] or I-D's adopted by existing WG's that are unrelated to ILNP, since some of the scenarios you (and, others) point out /aren't unique to ILNP/;
c)  Other work related to ILNP may get deferred until a later time, depending on the usual variety of factors: complexity of the problem to be solved, volunteer's time to do the work, urgency to solve the problem to meet certain deployment scenarios, etc.

IPv4 wasn't perfected in one "go" and, instead, it took a multi-decade process of incremental improvements to get to where it's at today.  (Hopefully, ILNP doesn't take that same amount of time).  We shouldn't underestimate that there are a variety of scenarios/deployments (please note I didn't use the word "all") where ILNP can be used, today, that are no worse (and, in some cases better) than today's deployments.  If the IETF were to take up work on ILNP, hopefully a ILNP WG (or, more specifically, it's charter) would coordinate (but, not necessarily take over) these related efforts, where appropriate, to reasonably maximize the number of deployment scenarios that ILNP can be considered for.

Just my USD $0.02,

-shane

[1] Perhaps not particularly good examples, but:
http://tools.ietf.org/html/draft-carpenter-referral-ps-00
http://tools.ietf.org/html/draft-mrw-behave-nat66-02

---

From: Tony Li <[email-masked]>
Date: Fri, 6 Aug 2010 09:58:09 -1000

> when local policies are applied on the nodes - the node policies

It should be noted that symmetric paths are not available anywhere in the Internet today.  Transit domain policies can basically do anything to traffic patterns, so even symmetric use of locators (or even a restricted case of only a single locator per host) cannot guarantee symmetry today.

Symmetry would require that return packets either be source routed along the path of the ingress packets, or some form of symmetric path setup in a connection oriented network.

Tony

---

From: RJ Atkinson <[email-masked]>
Date: Fri, 6 Aug 2010 21:27:32 -0400

First, I'll note that I concur with what Shane and Tony have
already said.  I can't improve on their words, so this note
will seek to address some specific different topics.

> when local policies are applied on the nodes - the node policies

Given 2 arbitrary sites, there can be no guarantee that the 
site/node operational policies will be compatible in a way 
that permits symmetric paths.  For example, site A might desire 
symmetric paths as its highest policy preference, but site B 
quite commonly might desire the lowest-cost egress path 
as its highest priority.

(Please also recall tli's comments about how transit-domain 
policy impacts things.)

> border router 1 as the 0/0 path).

As noted above, that operational practice might well violate the
preferred operational policy of the site.  In the most obvious case,
many sites today always prefer the lowest-cost egress path
for all packets leaving that site.

ILNP enables various things not enabled in the deployed IP 
Internet, and provides user options about their deployment models.  
However, no network-layer protocol can force all operational sites 
to adopt particular operational policies; that simply is beyond 
the scope of an IRTF (or even IETF) protocol specification. 

> level with less cost than current multi-homing implementation.

It is not obvious to me that the above claim is correct.
(e.g. consider tli's previous comment about how transit domain 
routing policy impacts the path taken by transit packets, etc.)

> we have today  - it is a status quo form their perspective

I think we disagree there.  

I believe ILNP enables a set of operational policy options 
and deployment model options that are either impractical today
or not possible today.

For example, ILNP's Locator rewriting is a native capability
that doesn't break end-to-end sessions, unlike IPv4 NAT, 
which tends to break TCP/UDP/SCTP in various ways -- and 
requires special TCP/UDP pseudo-header checksum modification 
code inside the NAT device in any event).  I think that can 
combine with the MP/TCP work proposed by others (e.g. Mark
Handley) in constructive ways.

Separately, using ILNP with today's already universally deployed
TCP/UDP can enable multi-path connectivity -- without requiring
the TCP or UDP upgrades/modifications that are required (e.g.
work by Mark Handley and others) for multi-path to work with
deployed IPv4 or IPv6.  

(CAVEAT:  Of course, support for ILNP is its own stack upgrade; 
different folks within the Routing RG have various opinions 
about the practicality of various sorts of stack upgrade.)

Yours,

Ran

---

From: Patrick Frejborg <[email-masked]>
Date: Sat, 7 Aug 2010 10:29:45 +0300

> (Please also recall tli's comments about how transit-domain

Yes - but I'm not asking for symmetric paths through Internet, asking
for a simple tool to have symmetric paths across the border routers.
What is happening in Internet and in the VPN are out of scope, they
have their own policies. But let drop this issue for time being, we
can "boil" on that in the future.

> I think we disagree there.

Actually, not so much

> Handley) in constructive ways.

True, the responder must have a global locator in order to be reached
but the initiator can be behind NAT (as it is today). NAT has been a
show stopper for SCTP, MPTCP folks have taken into account the
existent of NAT.
E.g. in tcpcrypt they have changed pseudo-header checksum calculation
for encryption in order to traverse NAT, see section 3.3 at "The case
for ubiquitous transport-level encryption".

> work by Mark Handley and others) for multi-path to work with

This is the most important and interesting new discovery for me,
unfortunately I do not understand how it works. My guess is that
multi-path connectivity for vanilla TCP&UDP is that the node have one
identifier attached with several locators so you can have several
transport connections available, even simultaneously (wondering how
the application asks to setup several transport connections). But
there is no demultiplexing/multiplexing of packets at the stack, the
stack chose one path at the time - if one fails the stack switches to
the another path. Or how should I understand your statement of
multi-path connectivity for vanilla TCP/UDP??
I can't find the answer in papers you pointed out, but as you probably
know from the past I'm a slow learner :-)

> about the practicality of various sorts of stack upgrade.)

I have no problem with that, think it is a good place to start with
upgrading some network devices to get the transition started but not
stop there - a stack will be upgraded when there are good enough
incentives.

-- patte

---

From: RJ Atkinson <[email-masked]>
Date: Sat, 7 Aug 2010 12:26:01 -0400

On 07  Aug 2010, at 03:29 , Patrick Frejborg wrote:
> My guess is that
> transport connections available,

There is only one transport-layer session, 
but multiple paths can be used concurrently by the
ILNP packets handling that one transport-layer session.  

> even simultaneously (wondering how
> the application asks to setup several transport connections).

When ILNP is in use, then the transport-layer is decoupled 
from the Locator.  For example, the transport-layer pseudo-header
checksum only includes the Identifier values, never the Locator
values.  Hence, a single transport-layer session can be 
carried in ILNP packets using multiple Locators concurrently
(obviously: one Locator pair in any single given packet).

> But there is no demultiplexing/multiplexing of packets at the stack,
> the stack chose one path at the time - if one fails the stack
> switches to the another path.

I am not sure what you mean above.  

The ILNP implementation can send TCP segments (or TCP ACKs, 
or other TCP information) using different Locator pairs.

As an example, if one considers TCP with an originator using 
Locators (A, B, C) and a responder using Locators (W, X, Y),
then the originator can choose which Source Locators to use
and also which Destination Locators on a packet-by-packet
basis.  

Again, purely as an example, the originator could send
packets using these Locator values in this simple sequence:
	(A, W)
	(B, X)
	(C, Y)
or any other sequence that it wishes to.  Similarly, the
responder can use any valid combination of Locators that it
wishes to use.

In any case, the TCP implementations at either end are unaware 
that multiple Locators are being used (i.e. because the
transport-layer pseudo-header checksum only includes Identifiers,
never Locators).   In turn, this is why not special multi-path
TCP (or UDP or SCTP or other) transport-layer modifications 
are required.  (Caveat: Of course, the ILNP stack upgrade is
needed in the first place.)

The same concepts apply to UDP and/or SCTP.

I will look over the ILNP I-Ds and try to clarify this a bit;
apparently they aren't clear enough right now in this area.

Yours,

Ran

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 08 Aug 2010 09:40:09 +1200

Ran,

On 2010-08-08 04:26, RJ Atkinson wrote:
...
> (obviously: one Locator pair in any single given packet).

That's interesting. Have you studied the relationship between this
and the MPTCP work, not to mention co-existence of ILNP and SCTP?

http://datatracker.ietf.org/wg/mptcp/charter/

    Brian

---

From: Patrick Frejborg <[email-masked]>
Date: Sun, 8 Aug 2010 20:13:24 +0300

> I am not sure what you mean above.

Exactly what you are describing below, i.e. the session is established
between the identifiers and you have three simultaneously paths
between identifiers

> apparently they aren't clear enough right now in this area.

There are some challenges ahead though
a) if e.g. A-W path gets congested, how to detect the congestion and
switch load over to the other paths, see
http://datatracker.ietf.org/doc/draft-ietf-mptcp-congestion/
b) A, B, C and W,X,Y are describing where the border routers are
installed between the edge and core networks. If there are middleboxes
in some of the paths then some mechanism is needed (e.g. multi-homed
hosts) to ensure you have symmetric flows through the border routers
(it is likely the middlebox is installed close to the border router).
c) should this multipathing feature belong to the network layer, i.e.
creating e.g. a generic congestion mechanism for all transport
protocols or is multipathing something that the transport protocol
layer should take care of?

It might be valuable to have some discussion around c) before you
spend your time on updating your I-Ds

Also, many thanks for the clarification!

-- patte

---

From: Scott Brim <[email-masked]>
Date: Mon, 09 Aug 2010 10:39:29 -0400

> http://datatracker.ietf.org/wg/mptcp/charter/

Upper layer multihoming/multipathing (e.g. SCTP concurrent multipath
transport) works fine as long as lower layer shims or encapsulations
don't hide the information it needs, i.e. the prefixes to use.  In the
case where an endpoint is singly connected with two PA prefixes, as long
as the transport layer can use both prefixes MPTCP or SCTP can work.
This begs the question of how routing is done through the site network
so that those prefixes go out the right upstream interfaces.
Source-based routing?  Tony Hain's ICMP?  Anyway, ILNP per se doesn't
need to interfere.

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 09 Aug 2010 14:07:59 -0400

There is an interesting question of how to handle congestion management 
when we move the multi-pathing down to the network layer.
On the one hand, architecturally it seems appropriate for network layer 
to be managing the path selection.

On the other hand, the congestion behavior of the various paths is 
likely to be quite different, and congestion response is definitely NOT 
the network layer's responsibility.

The correct balance is not obvious to me.  (This is similar to, but not 
the same as, the path selection policy issues that the MIF working group 
is trying to understand.

Yours,
Joel

Scott Brim wrote:
> _______________________________________________
> rrg mailing list
> [email-masked]
> http://www.irtf.org/mailman/listinfo/rrg
>

---

From: Tony Li <[email-masked]>
Date: Mon, 9 Aug 2010 20:31:48 -1000

On Aug 9, 2010, at 8:07 AM, Joel M. Halpern wrote:

> There is an interesting question of how to handle congestion management when we move the multi-pathing down to the network layer.
> On the one hand, architecturally it seems appropriate for network layer to be managing the path selection.
> 
> On the other hand, the congestion behavior of the various paths is likely to be quite different, and congestion response is definitely NOT the network layer's responsibility.
> 
> The correct balance is not obvious to me.  (This is similar to, but not the same as, the path selection policy issues that the MIF working group is trying to understand.

I'd recommend that we also consider locator selection as another degree of freedom.  I agree with Joel that flow control belongs to the transport layer, and that path selection is part of the network layer.

Is locator selection a transport function?  It would seem that having it be a unilaterally network layer function is over constraining the architecture.  Yet, transport cannot perform intelligent locator selection without network layer input.

Tony

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 11 Aug 2010 09:25:33 +1200

On 2010-08-10 18:31, Tony Li wrote:
...
> Is locator selection a transport function?  It would seem that having it be a unilaterally network layer function is over constraining the architecture.  Yet, transport cannot perform intelligent l…

I can't speak for MPTCP, but is seems to me that MPTCP is based on the
assumption that it *can* perform intelligent locator selection based on
feedback from transport layer ACKs (or their absence). That's if your
definition of intelligence is 'get the most out of the network layer
without caring about path selection.'

   Brian

---

From: Tony Li <[email-masked]>
Date: Tue, 10 Aug 2010 14:37:32 -0700

> without caring about path selection.'

Brian,

At least as I understood it, MPTCP can consider the full cross product of locators and make use of dynamic feedback for adjustments.  The question I'm raising is whether that's sufficient.  

For example, if transport got feedback about path selection and congestion from the network layer, then perhaps transport could be more intelligent.  For example, if multiple locator pairs all result in paths that coincide on a particular congested link, then the benefits of multi-pathing could be extremely limited.

More information is available, if transport is willing to increase its interaction with the network layer.

Regards,
Tony

---

From: Tony Li <[email-masked]>
Date: Tue, 10 Aug 2010 14:53:42 -0700

Brian,

Regards,
Tony

---

From: Scott Brim <[email-masked]>
Date: Wed, 11 Aug 2010 17:32:43 -0400

On 08/10/2010 02:31 EDT, Tony Li wrote:
> I'd recommend that we also consider locator selection as another
> degree of freedom.  I agree with Joel that flow control belongs to
> the transport layer, and that path selection is part of the network
> layer.
> 
> Is locator selection a transport function?  It would seem that having
> it be a unilaterally network layer function is over constraining the
> architecture.  Yet, transport cannot perform intelligent locator
> selection without network layer input.

The problem is that the layer-to-layer API is constrained, i.e. there
almost isn't any!  It's like in many protocols: you want the other end
(of a protocol, an API, any communication) to do something, but you have
no way of telling him what you want.  However, you know that if you
tweak the information he gets that he will probably do what you want, so
you overload an existing mechanism.  We've done it for years with BGP
for example e.g. the way AS paths are used.

So yes I agree completely that a higher layer shouldn't be communicating
its path wishes using src/dst pairs but it has no other globally
implemented mechanism ... and I don't think we're going to get one for
years.  One of the points of MIF is to get L3 and below to be more
predictable in their behavior, which will make L4's problem easier and
lessen the need to do anything else.

> without caring about path selection.'

It treats the network layer as a black box: if it gives L3 input X
(source and destination), a particular outcome happens and it does it
more, or less, depending on whether it likes that outcome.

On 08/10/2010 17:37 EDT, Tony Li wrote:
> At least as I understood it, MPTCP can consider the full cross
> product of locators and make use of dynamic feedback for adjustments.
> The question I'm raising is whether that's sufficient.
> 
> For example, if transport got feedback about path selection and
> congestion from the network layer, then perhaps transport could be
> more intelligent.  For example, if multiple locator pairs all result
> in paths that coincide on a particular congested link, then the
> benefits of multi-pathing could be extremely limited.
> 

All true.

Scott