headers
Yuri Ismailov (KI/EAB | 1 Sep 11:07
Picon
Favicon

RE: where the indirection layer belongs


>No matter where the stabilization layer(s) live, using DNS as a
>means to map from identity to locations simply won't work.  It might be
>good enough for initial connection (assuming that if a service exists on
>multiple hosts, any of them will do), but it's not good enough for
>re-establishing an already-open connection, because you might get a
>different host the next time.

This is exactly the point!

>> But the real question here is: does this new "thing" have to be a 
>> layer? 

>It depends on which "thing" you are talking about.  For the L3-L4 thing,
>it's either a new layer or a change to an existing layer.  If you
>have both the L4-L7 thing and the L3-L4 thing, the former is either a
>new layer or (my personal opinion) a new API that knowledgable apps
>call explicitly.

If L4-L7 thing is an API on top of the "socket" in its current form, then I believe that all limitations are
still there.
This is implemented and shown to be the fact.

/Yuri
Permalink | Reply | 1 comment |
headers
Pekka Nikander | 2 Sep 09:25

Re: Multiple Address Service for Transport (MAST)

(Discussing TCP vs. wedge approaches)

Dave Crocker wrote:
> Three other arguments worth considering:
> 
>           c) working with mobility, as well as multi-homing
> 
>           d) not incurring the per-packet option overhead with a larger
>           packet and with option processing.
> 
>           e) moving the multi-homing/mobility negotiations out of the
>           critical path to transport activity; hence it does not impose
>           any start-of-connection delays. on the other hand, my
>           impression is that the tcp option approach does not impose a
>           delay, either.

There are a couple of other issues worth consider, too:

             f) transport layer implementation requires more signalling,
             i.e., separately for each connection, than a wedge one,
             which is basically host-to-host (or end-point-to-end-point)

             g) a wedge implementation will have interesting interplay
             with transport layer RTT and throughput estimates.  OTOH,
             that information is actually more host-to-host (or path
             related) in nature than connection related.

--Pekka Nikander
(Continue reading)

Permalink | Reply | 2 comments |
headers
Spencer Dawkins | 2 Sep 21:22
Favicon

Re: Multiple Address Service for Transport (MAST)

Dear Pekka,

> (Discussing TCP vs. wedge approaches)

>              g) a wedge implementation will have interesting
interplay
>              with transport layer RTT and throughput estimates.
OTOH,
>              that information is actually more host-to-host (or path
>              related) in nature than connection related.

You'd think so, but I sure haven't heard of a lot of people doing
ftp://ftp.rfc-editor.org/in-notes/rfc2140.txt in production TCPs...

Maybe the wedge approach would provide an incentive here?

Spencer
Permalink | Reply | 1 comment |
headers
Pekka Nikander | 3 Sep 08:16

Re: Multiple Address Service for Transport (MAST)

Spencer,

>>(Discussing TCP vs. wedge approaches)
> 
>> g) a wedge implementation will have interesting interplay
>>    with transport layer RTT and throughput estimates.
>>    OTOH, that information is actually more host-to-host (or path
>>    related) in nature than connection related.
> 
> You'd think so, but I sure haven't heard of a lot of people doing
> ftp://ftp.rfc-editor.org/in-notes/rfc2140.txt in production TCPs...

I haven't really checked the BSD stack code recently, but
it does keep the RTT and throughput estimates in routing
table entries and not in tcb entries.  In fact, it has a cloned
routing table entry for each active host, and that entry carries
the RTT and throughput estimates over consequent TCP connections.

I would need to study to source code more closely to be able
to say anything more.

> Maybe the wedge approach would provide an incentive here?

Maybe.

--Pekka Nikander
Permalink | Reply | 0 comments |
headers
Masataka Ohta | 3 Sep 15:41
Picon

Re: Multiple Address Service for Transport (MAST)

Dave;

MAST is another form of (original) LIN6.

While you say:

	It requires no change to the IP infrastructure, and no change
	to IP modules or transport modules in the end-systems.

	It requires no change to existing transport protocols and
	no changes to IP. Instead, it defines a wedge layer between
	IP and transport.

	In contrast, the current proposal provides support that
	requires no new infrastructure and no changes to existing
	protocols.

	The service should require no changes to the IP network
	infrastructure, to the IP layer in end-systems, or to the
	transport layer in the end-systems.

They are all wrong.

First, a transport protocol is defined on the wire, not at the
API. So, if, on the wire, packets with different pairs of
source/destination addresses belong to the same connection,
it is not TCP but a new protocol.

Second, while you don't have to modify existing transport
code, you must add something to the transport module. That is,
(Continue reading)

Permalink | Reply | 0 comments |
headers
Spencer Dawkins | 6 Sep 01:45
Favicon

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

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
(Continue reading)

Permalink | Reply | 5 comments |
headers
Iljitsch van Beijnum | 6 Sep 11:16
Favicon

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

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?

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

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

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

Yeah right. See RFC 3484.

> - 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
(Continue reading)

Permalink | Reply | 3 comments |
headers
Spencer Dawkins | 6 Sep 14:32
Favicon

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

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.
(Continue reading)

Permalink | Reply | 2 comments |
headers
Iljitsch van Beijnum | 6 Sep 15:32
Favicon

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

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?

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

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.

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

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

PS.  :-)
(Continue reading)

Permalink | Reply | 1 comment |
headers
Spencer Dawkins | 6 Sep 22:44
Favicon

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

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

----- Original Message ----- 
From: "Iljitsch van Beijnum" <iljitsch <at> muada.com>
To: "Spencer Dawkins" <spencer <at> mcsr-labs.org>
Cc: "Multi6 Mailing List" <multi6 <at> ops.ietf.org>
Sent: Saturday, September 06, 2003 8:32 AM
Subject: Re: Comments on draft-crocker-mast-proposal-00.txt

> 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?
>
> > 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?
(Continue reading)

Permalink | Reply | 0 comments |

Gmane