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

I'm fairly close to declaring this conversation out of
scope. Maybe you can come back to the list when you have
reached a mutual consensus?

    Brian
    with co-chair hat

Joe Touch wrote:
> -----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-----
>