Subject: [multipathtcp] A Suggestion for Address Selection

From: Aleksi Suhonen <[email-masked]>
Date: Mon, 15 Jun 2009 05:44:24 +0300

Hi,

This is a request for comments on a draft for an internet draft on a new 
address selection algorithm that I'm developing as part of the Finnish 
Future Internet project. I'm trying to find a home working group for it, 
but I'm not finding it easy since it seems to affect so many things.

Instead of sending the whole text on several mailing lists, I put the 
rough draft on the web:

http://www.axu.tm/2009/draft-axu-addr-sel-pre00.html

The motivation for this algorithm comes from multi-pathing protocols and 
the need for agile address re-selection when forced to reroute.

Readers of the multipathtcp list may be especially interested in 
commenting the connection pooling subsection of the draft, since it 
would add a sort of crude multi-pathing support to plain TCP protocols 
that open several connections.

Sincerely awaiting your constructive feedback,

--
	Aleksi Suhonen
	Department of Communications Engineering
	Tampere University of Technology

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 15 Jun 2009 15:45:43 +0200

> http://www.axu.tm/2009/draft-axu-addr-sel-pre00.html

Section 2: for hosts that only have a default route this doesn't seem  
to do much...

I don't understand the text in 2.1.

In 2.2 you assume multiple routing tables. I don't think that's a  
reasonable expectation. (But I agree that using an address with the  
router that provided the RA is a good goal.)

Not entirely sure about 2.3, but I probably disagree.

We tried to tackle some of these issues in the early work on the shim6  
reap protocol and I know there is (has been?) work going on on a new  
version of RFC 3484. Having something useful in this area would be  
very good, but I'm not seeing much of practical use in your draft as  
it is now. You may want to start filling in some of those "TBD"s.

I think a discussion of a single routing table vs a multiple routing  
table vs a hybrid model would be useful, and probably an address  
_ordering_ rather than filtering.

Iljitsch