Subject: Comments on draft-crocker-mast-proposal-00.txt

From: "Spencer Dawkins" <[email-masked]>
Date: Fri, 5 Sep 2003 18:45:17 -0500

Dear Dave,

As you requested - the following are my comments on MAST,
revectored to multi6.

Rather than send detailed comments (which I can do, if you think it
would be helpful), I'd like to start at 50,000 feet...

- I like the possibility of using MAST with IPv4. I took a quick look
at LIN6, after Masataka's note on MULTI6. There were things I liked
about LIN6, but the IP version number in the acronym was not a
feature.

- I like your awareness of NATs in IPv4 networks as a deployment
issue.

- I understand why you are thinking "end hosts only". You might also
want to think about MAST proxies to allow MAST mobility against an
unmodified correspondent host (to use the MIP term). If I learned
anything in TRIGTRAN, it was to think about who had the incentives to
deploy something - in wireless mobility, a service provider may have
an incentive to deploy client-side software (if needed) and a server
somewhere in the access network, but the correspondent hosts usually
don't have an incentive to deploy anything.

- MAST seems to be very agnostic about the "bootstrap" IP address. It
happens that I am working on a product that has some MASTish
functionality. We started out being agnostic, too. I'm arguing that we
really need a more useful host identifier (note the use of the
lower-case "h" and "i"). You are explicitly punting on the question of
rendezvous in 4.2.5. There's a lot of prior art that assumes one host
is mobile (WAP had this focus) and that all application exchanges are
mobile-initiated, but much less on how two mobile hosts find each
other. I'm not sure how we do this without HIP-DNS, an LIN6 mapping
agent, or something else within the network.

- One HIP issue I've wondered about, but have not mentioned in public,
is how an application might make of "whatever it THINKS is the IP
address" (because a mobile address/identifier looks like any other
address). What happens if an application expects to do a reverse DNS
lookup of a HIP HI, for instance? Per your 8.1, I THINK any IP
addresses your transports/applications see are really IP addresses,
but they may not be routable or reachable at any given moment... I'm
not the application guy here, I'm just wondering out loud.

- I agree with Matataka's note that selecting an interface is not an
easy problem. When I've asked about this in places like DNA, the
pushback is that this decision is internal to a host, and need
not/should not be standardized in IETF. You might want to think about
this, and mention your position on this explicitly.

- I'm wondering if you have looked at RSIP lately (Experimental
protocol), re: NAT traversal, or at STUN - it looks like you're
including some STUN functionality in PROBE.

- I'm wondering how much you have thought about the use of PROBEs to
verify path connectivity from time to time. The transport view of the
world is that this is really an application-level responsibility,
because the transport (hence, the MAST) doesn't know how often to
verify path connectivity - too often risks punting on paths that are
broken now but will be healed before they are needed, and too seldom
forces the application to probe, anyway. Coming from my particular
part of the world, I think hosts really do see access link failures
(for some values of "see" and "failures"), that hosts can send "Now
I'm at this address" when access links fail, and that connection path
failures for inactive paths beyond the access links are likely to be
resolved before the path is needed (think, "core network routing
update").

- The feedback I got in TRIGTRAN was that it was OK for transports to
ignore path changes when they are doing congestion control, because
all we know is that at least part of the connection path has changed;
Slow Start wouldn't be WRONG, but it might be unnecessary - we could
also see if we can sustain the current rate, and perform congestion
avoidance based on losses (as transports do today), not notification
of path change (today's transports ignore subnetwork path changes
within a single IP hop, right?). You might want to mention your
position on this point explicitly, because we're still having the
"where is the right place for this functionality?" discussion that
includes "but transport does its thing on a single connection path
today".

- When you get to scenario-playing, the hard questions happen when
both hosts move simultaneously. But you know this, of course.

- When you're moving forward from proposal to specification, you'll
need someone smarter than I am about security on the design team.

Hope this helps! Have a great weekend.

Spencer

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Sat, 6 Sep 2003 11:16:48 +0200

On zaterdag, sep 6, 2003, at 01:45 Europe/Amsterdam, Spencer Dawkins 

> about LIN6, but the IP version number in the acronym was not a

But is it realistic to expect to deploy a technology in IPv4 that uses 
up additional address space?

> unmodified correspondent host (to use the MIP term).

Always high on my list of desirable features because it makes 
deployment a lot easier.

> not/should not be standardized in IETF.

Yeah right. See RFC 3484.

> verify path connectivity from time to time.

I've tried to convince the SCTP folks that this is a bad idea right on 
this here list, but unfortunately they weren't convinced. Just checking 
path availability is mostly useless and wastes bandwidth.

If you only have two paths you're going to try the second one anyway 
when the first fails because there is no reasonable alternative course 
of action. If you have more paths there is a signicant chance that 
several of them will fail because of the same underlying problem.

If you really want to be cool, _use_ the different paths concurrently. 
I'm convinced that as soon as we've got the basic multiadressing 
mechanisms in place, load balancing single TCP sessions over multiple 
paths will be the next big thing.

Iljitsch

---

From: "Spencer Dawkins" <[email-masked]>
Date: Sat, 6 Sep 2003 07:32:16 -0500

Dear Iljitsch,

Thank you for your comments on my comments. I did have two notes back.

Spencer

> up additional address space?

Dave keeps saying "a proposal, not a specification", but as I read the
MAST proposal, it doesn't use up additional address space - Dave,
can you give me a clue here? What I THOUGHT I saw was that we
start out with one IP address (that already exists) and then add
others
(that already exist). I may have been blinded - this was where I
started
out on my current project.

But this was one of the differences, I thought, between MAST and LIN6.

[deleted down to]

> path availability is mostly useless and wastes bandwidth.

"If a connection path fails on the Internet, and no host sees data
transfer
fail as a result of the failure, was there really a failure?"

> several of them will fail because of the same underlying problem.

A good point, which I should have thought of, but hadn't yet.

> paths will be the next big thing.

In principle, I agree.

The problem I have is that I'm working with orders-of-magnitude
nominal
bandwidth differences between interfaces in my application (50 Kb/s
for GPRS, to 11 Mb/s for 802.11, to 100 Mb/s for 802.3). The increase
in throughput from using two different interfaces simultaneously gets
lost
in the noise.

If you have a box with three gig-E interfaces, doing a transfer to
another
box with a 10-gig-E interface, using three interfaces simultaneously
could be pretty noticeable, of course. And pretty phat.

For critical environments, I could see loadbalancing as a way of
providing
better feedback about alternative path failures ("you're down to one
path,
which is still working, but if that path fails, it's all over"). Maybe
some of
nice OPS people could express an opinion about whether real
customers need this capability?

Thanks again,

Spencer Dawkins

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Sat, 6 Sep 2003 15:32:52 +0200

On zaterdag, sep 6, 2003, at 14:32 Europe/Amsterdam, Spencer Dawkins 
wrote:

>> But is it realistic to expect to deploy a technology in IPv4 that
>> usesup additional address space?

> can you give me a clue here?

Wouldn't a host need two or more addresses to use MAST? (I must admit I 
haven't read it in detail but the general principles are similar to 
several earlier proposals.) Anyway, I would hate to see IPv4-specific 
problems (NAT...) get in the way of an IPv6 solution.

>> If you really want to be cool, _use_ the different paths
>> concurrently. I'm convinced that as soon as we've got the basic 
>> multiadressing mechanisms in place, load balancing single TCP 
>> sessions over multiple paths will be the next big thing.

> nominal bandwidth differences between interfaces in my application (50 
> Kb/s for GPRS, to 11 Mb/s for 802.11, to 100 Mb/s for 802.3).

You encapsulate IP in 802.3? How does that work for you?

PS.  :-)

> The increase in throughput from using two different interfaces 
> simultaneously gets lost in the noise.

Right. That is, unless someone else does the same thing and talks to 
your ethernet address using her GPRS address and the other way around...

For applications that want/need more than 10 or 100 Mbps, running over 
50 kbps is useless most of the time anyway. So when you fire up the 
microwave but forget to close the door and the wireless stops 
functioning, you really don't want your download to continue over GRPS, 
which is both to slow to be useful and too expensive.

> another box with a 10-gig-E interface, using three interfaces 
> simultaneously could be pretty noticeable, of course. And pretty phat.

Well, I was thinking more along the lines of a cable + ADSL setup, but 
I'll take 3 x GE if I can get it.  :-)

If you track the RTTs and queue sizes carefully, you should be able to 
select the path with the lowest delay for a certain packet size if you 
have a low bandwidth, low delay line and a high bandwidth, high delay 
one. This would be very useful in setups that include a satellite path.

I was involved in a project where we needed to deliver real time 
traffic of different speeds (ranging from a single packet a second to 
upwards of 10 Mbps) to three remote systems over TCP. (Don't ask.) We 
were supposed to load balance over the three remote systems for 
resiliency reasons. So we implemented a system that distributed the 
data in round robin fashion. This was pretty bad because it was fairly 
common for one system to become very slow for a while. In this case our 
performance went down compared to using only a single system! So we 
started fiddling with all socket options known to man and on each write 
selected the destination for which the least amount of data was still 
buffered for transmission. This worked amazingly well, we could now use 
all three destinations to the full capacity and react to changes almost 
instantly. (At the cost of some end-to-end reordering of the data.)

> providing better feedback about alternative path failures ("you're 
> down to one path, which is still working, but if that path fails, it's 
> all over"). Maybe some of nice OPS people could express an opinion 
> about whether real

I consider myself mostly an ops person and the thing I like about this 
is that it takes the "pick an address and pray" factor out of the 
equation: you always get the full available speed. If you want more 
input on this, you may want to ask the SCTP crowd, they have 
requirements along the lines you mention but I don't think they 
implement load balancing.

Iljitsch

---

From: "Spencer Dawkins" <[email-masked]>
Date: Sat, 6 Sep 2003 15:44:52 -0500

Dear Iljitsch,

I'm not sure we're talking about the same "additional" address -
I'm thinking that a device with two interfaces now already needs
two addresses (so the second address isn't "additional"), and
you're thinking that a device that has only one interface and
one address now would need an "additional" address to do
MAST.

I think.

Spencer

---

From: Masataka Ohta <[email-masked]>
Date: Mon, 8 Sep 2003 04:54:40 +0859 ()

Spencer;

> about LIN6, but the IP version number in the acronym was not a

It must be IPv6 to avoid all the MTU problems with 8+8.

Moreover, with IPv6 with proper multihoming, we can assume
the global routing table is small and almost all hosts have it,
which is helpful for address selection from multiple candidates,
which is necessary for multihoming without scalability problem
on routing table size.

It should also be noted that, no one really need another way of
IPv4 multihoming.

							Masataka Ohta