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

["Spencer Dawkins" <spencer@mcsr-labs.org>]

Dear Iljitsch,

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

Spencer


> On zaterdag, sep 6, 2003, at 01:45 Europe/Amsterdam, Spencer Dawkins
> wrote:
>
> > - 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.
>
> But is it realistic to expect to deploy a technology in IPv4 that
uses
> 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]

>
> > - I'm wondering how much you have thought about the use of PROBEs
to
> > 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 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?"

>
> 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.

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

>
> 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.

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