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:
On 08/07/2010 17:40 EDT, Brian E Carpenter wrote:
Ran,
On 2010-08-08 04:26, RJ Atkinson wrote:
...
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).
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
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.
_______________________________________________
rrg mailing list
[email protected]
http://www.irtf.org/mailman/listinfo/rrg
_______________________________________________
rrg mailing list
[email protected]
http://www.irtf.org/mailman/listinfo/rrg
