[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: IETF multihoming powder: just add IPv6 and stir

On zaterdag, mei 3, 2003, at 01:22 Europe/Amsterdam, David Conrad wrote:


1) Rewriting addresses in the site exit routers deprives smart hosts
from the capacity to select their preferred return path;



To be sure I understand, you are saying that my laptop should have the 
ability to make a decision as to what ISP Microsoft uses to route 
packets back to me?



Just because that's the way it's done today doesn't mean it has to 
continue to be done like that in the future. Consider:



 +-- ISP B --- ISP C --+

DC         \ /         |

 |         / \         MS

 +-- ISP A --- ISP D --+



This makes for four possible paths from you to Microsoft:



DC -> B -> C -> MS

DC -> B -> D -> MS

DC -> A -> C -> MS

DC -> A -> D -> MS



Conversely, there are four paths back. If we get to choose paths on a 
per-session basis, this makes for no less than sixteen possible 
permutations. (Of course this assumes transport sessions don't care 
about the source and/or destination addresses.)



This makes for an interesting problem. On the one hand, we want to be 
able to take advantage of whathever capacity is available. On the other 
hand, managing n^2*m^2 paths (where n and m are the number of 
ISPs/addresses on each end) isn't an attractive proposition.




In fact, if we really want to go towards this independent identifier
path, I believe we should make it a session identifier, used by some
form of TCP++.





While I think TCP++ would be a lovely idea, I don't believe it is 
realistic unless it incorporates backwards compatibility and if it 
incorporates backwards compatibility, I don't see how you can get 
multi-homing without either NAT or rewriting.



I don't see much of a problem here. In order to be compatible, the 
first packet must comply with existing TCP semantics but in a way that 
signals that the session initiator supports the ++ extensions. Then 
either the receiver answers with a regular SYN/ACK and we do regular 
TCP, or the receiver answers with a TCP++ session init packet and we 
don't have to be compatible any more. (Middleboxes won't like this, 
though.)