Re: [RRG] Are we solving the wrong problem?

["Mark Handley" <M.Handley@cs.ucl.ac.uk>]

On Feb 19, 2008 11:41 AM, Scott Brim <swb@employees.org> wrote:
> Mark, a few thoughts ...
>
> First there's the problem of discovery of multiple ways to address a
> destination.  Do I assume correctly you would build on DNS?  TE is
> more than load balancing.  Sometimes policy rears its head, and
> sometimes policy is specific to traffic type, not just IP layer info.
> This needs to be factored in somehow, and DNS can't support it.  We
> could also do an initial discovery handshake between endpoints once
> they reach each other at any address.  That would also allow policy to
> influence negotiation, and possibly policy intermediaries (a la
> NUTSS).  Of course, it would introduce delay :-p.

You could use DNS, but I'm not convinced this is the best way because
it doesn't fit well with using the same mechanisms to support
mobility.  Better I think to simply add the extra addresses as part of
the TCP sync handshake.

I agree policy is very important.  These mechanisms actually enable a
whole load of local policy tools that are not currently possible by
shaping one path to move traffic to other paths.

> > each provider's aggregated prefix.  Now we modify TCP to use both
> > addresses *simultaneously* - this isn't the same as SCTP, which
> > switches between the two.  The client sets up a connection to one
> > address, but in the handshake learns about the other address too.  Now
> > it runs two congestion control loops, one with each of the server's IP
> > addresses.  Packets are shared between the two addresses by the two
> > congestion control loops - if one congestion-controlled path goes
> > twice as fast as the other, twice as many packets go that way.
>
> What about (1) synchronization of oscillations and (2) packets
> arriving very out of order, since the source will continually be
> testing every allowed path.

Synchronization should be no worse than we get with current TCP flows.
 RED is good for these issues.

The TCP connection will have to put packets back in order, but since
TCP is aware of the subflows, it shouldn't be making the wrong
deductions (as it currently does with reordering).  This does of
course require TCP protocol changes, but they're incrementally
deployable and can be negotiated on a per-connection basis.

> What about multicast? :-)

That's one of the things I don't have a clue about :-)

- Mark

--
to unsubscribe send a message to rrg-request@psg.com with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg