Re: Comments on draft-ietf-multi6-v4-multihoming-02

[Joe Touch <touch@ISI.EDU>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



Iljitsch van Beijnum wrote:
| On 18-nov-04, at 4:50, Joe Touch wrote:
|
|>>> How do we classify when the
|>>> connectivity is too poor to be useful - the application should be able
|>>> to determine this and ask for using a different address pair.
|
|
|>> This is an unsolved problem. I think at some point we need an
|>> interface for this, so that multi6-aware applications can influence
|>> certain aspects of multihoming operation.
|
| I'm assuming you're not disagreeing with this part?

Yes.

|>> I've always assumed that once basic multihoming is in the can the
|>> next step would be to make TCP multihoming-aware so that it can load
|>> balance over more than one address pair at a time in order to achieve
|>> x+y throughput rather than max(x,y) throughput, or worse
|
|
|> IMO, this is a very bad idea, despite its prevalence in certain
|> communities. If this is where you're going, you need TCP to know the
|> AGGREGATE of its window, and behave accordingly, but as to
|> load-balancing, that's building IP into TCP, and assumes that address
|> pairs are meaningful in this context
|
| I don't see the problem...?
|
|> (if there are 8 pairs on each end, are there 8 end-to-end pairs, or
|> 64? - there could be 64 unique routes, depending on what IP does).
|
| Obviously a pair can't be on one end.

(sorry - I meant 'addresses on each end')

| If one host has 4 addresses and
| the other 3, then there are 12 pairs. Communication can happen over one
| pair in both directions (12 possibilities) or different pairs in
| different directions (132 possibilities) for a total of 144 different
| ways to communicate between these hosts.
|
|> If you want to make a set of links look like one link, build a tunnel
|> with a loadbalancing demux in it, but don't go to TCP for that
|> functionality, IMO.
|
|
| So you propose an additional layer of functionality that massages the
| different properties of the different links such that TCP's assumptions
| about the link it runs over (reasonably stable RTT, packet loss =
| congestion) work?

No; I'm asserting that the additional functionality is going to be
needed, and we shouldn't step into that mess, since it has already been
stepped in before in the IETF.

| This is exactly how we always get into trouble: add
| protocols that break the assumptions of previous protocols. It would be
| much better to change TCP so it has all the information and can make the
| right decisions.

Er, well, that would argue that TCP should do the multihoming too, not a
shim layer. We already discussed why _that_ isn't the case. For similar
reasons, this is true here too. TCP is _NOT_ the muxing layer. IP is.

| Basically this would be like running several TCP
| sessions in parallel, except that we have to ensure in-order delivery.
| Unless this aspect turns out unexpectedly difficult, I see no problems.
|
|> We looked into it several times before (webmux, in particular), and it
|> ends up creating substantial problems with priority inversion, layered
|> multiplexing, etc.
|
| Do you have links to stuff I can look at in this area?

Check the IETF proceedings for webmux, HTTP-NG, and SOAP.

Joe
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFBnPy6E5f5cImnZrsRAtDpAKCGrKGKCZL9DnsctUGjt9cr0y92KwCgto/G
Tgg4DhTIbsDF3FwMBdstEXI=
=hJMa
-----END PGP SIGNATURE-----