Subject: [Int-area] Fwd: I-D ACTION:draft-bagnulo-rfc3484-update-00.txt

From: marcelo bagnulo braun <[email-masked]>
Date: Fri, 16 Jun 2006 09:19:08 +0300

Hi,

We have submitted the attached draft describing the problems with 
RFC3484 when selecting source addresses in multihomed environments 
after outages.

The identified problems imply that a RFC3484 compliant host placed in a 
multihomed site may not be able to initiate new communications when one 
of the isps is down, even if there are alternative paths available 
through other isps.

Considering that  this affects rfc3484, its scope was deemed wider than 
the shim6 wg, hence this may be the appropriate forum for discussing 
these issues.

The draft also suggests some possible approaches to deal with this, but 
new ideas are really appreciated in this space.

Comments are welcome

Thanks, marcelo

Inicio mensaje reenviado:

> De: [email-masked]
> Fecha: 15 de junio de 2006 22:50:01 GMT+03:00
> Para: [email-masked]
> Cc: Asunto: I-D ACTION:draft-bagnulo-rfc3484-update-00.txt
> Responder a: [email-masked]
>
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
>
>
> 	Title		: Updating RFC 3484 for multihoming support
> 	Author(s)	: M. Bagnulo
> 	Filename	: draft-bagnulo-rfc3484-update-00.txt
> 	Pages		: 12
> 	Date		: 2006-6-15
> 	
> This note describes the limitations of RFC 3484 in multihomed
>    environments and proposes possible updates to the default address
>    selection mechanisms in order to cope with the identified
>    limitations.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-bagnulo-rfc3484-update-00.txt
>
> To remove yourself from the I-D Announcement list, send a message to
> [email-masked] with the word unsubscribe in the body of 
> the message.
> You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
> to change your subscription settings.
>
>
> Internet-Drafts are also available by anonymous FTP. Login with the 
> username
> "anonymous" and a password of your e-mail address. After logging in,
> type "cd internet-drafts" and then
> 	"get draft-bagnulo-rfc3484-update-00.txt".
>
> A list of Internet-Drafts directories can be found in
> http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
>
> Internet-Drafts can also be obtained by e-mail.
>
> Send a message to:
> 	[email-masked].
> In the body type:
> 	"FILE /internet-drafts/draft-bagnulo-rfc3484-update-00.txt".
> 	
> NOTE:	The mail server at ietf.org can return the document in
> 	MIME-encoded form by using the "mpack" utility.  To use this
> 	feature, insert the command "ENCODING mime" before the "FILE"
> 	command.  To decode the response(s), you will need "munpack" or
> 	a MIME-compliant mail reader.  Different MIME-compliant mail readers
> 	exhibit different behavior, especially when dealing with
> 	"multipart" MIME messages (i.e. documents which have been split
> 	up into multiple messages), so check your local documentation on
> 	how to manipulate these messages.
> 		
> 		
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
> Content-Type: text/plain
> Content-ID: <[email-masked]>
>
> _______________________________________________
> I-D-Announce mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/i-d-announce

_______________________________________________
Int-area mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/int-area

---

From: Arifumi Matsumoto <[email-masked]>
Date: Tue, 20 Jun 2006 20:03:17 +0900

Hi marcelo,

marcelo bagnulo braun wrote:
> RFC3484 when selecting source addresses in multihomed environments after 
> outages.
> 

I re-read your draft, and I found that I misunderstood
your draft. The word "IP layer re-transmission" 
made me feel that it proposes both TCP and UDP re-transmission
using difference src address.

Several comments below.

* About TCP

  I have implemented this kind of TCP(TCP-MH) before,
  so I know it's very useful to have this kind of feature
  for TCP.

  The problem is about implementation. Your proposal seems to
  say this should be implemented in IP layer just like NAT or
  ip-filtering software. This means TCP doesn't care about
  address change at all. Though this is surely an advantage,
  IMO you should make TCP take care about path(address) change.

  For example, TCP should have a retransmission counter and
  RTO value for each path to try more than 3 or 4 paths.

* About Address Availability Cache

  The biggest concern is whether you can create such an
  algorithm that is effective and harmless in real environment.

  One accidental connection failure must not block out other
  applications forever.
  
  Also, this should not be too complicated or resource consuming
  considering small IPv6 devices like censors.

  We need much practice and statistics before implementing
  it in every IPv6 nodes.

* Application Layer Approach

  Other than the APIs in your document, there already exists
  an all-in-one API, such as WSAConnectByName in WinSock2.
  You only have to tell FQDN and port# to this API, and this
  API tries every possible pair of dst and src addresses.

  This API is available in Windows Vista.
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/winsock/winsock/wsaconnectbyname_2.asp

  This approach seems to be fair and symmetric in that
  dst-trying-loop and src-trying-loop are implemented 
  at the same layer.
  About TCP approach, dst-trying-loop is in application
  and src-trying-loop is in L4 or L3.
  
  Moreover, this approach has an advantage that it can
  manipulate *address-pair*. It can try the best address-pair,
  then second best address-pair...
  In TCP approach, the dst address is given by the upper layer,
  so it cannot be changed until after all the src addresses are
  tried.
  I don't yet know the details of this API's implementation
  details though.

Best regards,

-- 
Arifumi Matsumoto
    Ubiquitous Computing Project
    NTT Information Sharing Platform Laboratories
    E-mail: [email-masked]

---

From: marcelo bagnulo braun <[email-masked]>
Date: Thu, 22 Jun 2006 12:37:31 +0300

Hi Arifumi,

thanks for the feedback,
some comments inline...

El 20/06/2006, a las 14:03, Arifumi Matsumoto escribió:

>> The identified problems imply that a RFC3484 compliant host placed in  
>> a multihomed site may not be able to initiate new communications when  
>> one of the isps is down, even if there are alternative paths  
>> available through other isps.
>> Considering that  this affects rfc3484, its scope was deemed wider  
>> than the shim6 wg, hence this may be the appropriate forum for  
>> discussing these issues.
>> The draft also suggests some possible approaches to deal with this,  
>> but new ideas are really appreciated in this space.
>> Comments are welcome
>> Thanks, marcelo
>
>
> your draft. The word "IP layer re-transmission" made me feel that it  
> proposes both TCP and UDP re-transmission
>  ip-filtering software.

not sure why do you consider this to be similar to nat or ip  
filtering...
but the proposal is NOT to change the source address but rather to  
select a source address tat is working among the different source  
addresses available. After a working source address is found, this is  
the one used. The source address perceived by TCP and UDP is the one  
actually used in the data packets in the wire, so no similarity to nat  
here...

>  This means TCP doesn't care about
>  address change at all.

no, this means that in many cases, TCP do not specify the source  
address and leaves that decision to the IP layer. In this case, the ip  
layer needs to select the source address and the proposed mechanisms  
allow the ip layer to select a working source address for that tcp  
connection

of course if tcp wants to specify the source address, of course this  
source address is honoured...

bottom line is that the proposed solution would be perfectly compatible  
with tcp based solutions as the one you suggest...

>  Though this is surely an advantage,

again, it would be indeed possible to solve the particular case of TCP  
at the tcp layer
this is indeed an option to consider

>  One accidental connection failure must not block out other

agree but i guess that if the mechanisms are well designed this  
shouldn't be the case. i mean, we should be able to do this :-)

>  an all-in-one API, such as WSAConnectByName in WinSock2.

ok

>  dst-trying-loop and src-trying-loop are implemented  at the same  
> layer.

yes, i think this is a very useful tool
however, this is in a somehow different level, since it is based in  
FQDN... i wonder if we also need a mechanism based on the IP level,  
i.e. not relying on the exsitance of fqdn. I mean, there are two  
different sceanrions, AFAICT:

In one hand, you have an app that wants to connect to a given fqdn. at  
this point it performs the connect by name and then the fqdn is  
resolved to a set of ip address. Then all the src,dst address pairs are  
tried until a working pair is found.
This is good because it provides fault tolerance support for both  
source and destination addresses. However, this requires updating all  
the apps to use connect by name

On the other hand we have the case that the application has already  
selected one dst address and want to establish a communication. At this  
point the IP layer needs to select a src address, so that the src,dst  
address pair works. The IP layer can then try with different src  
addresses until a working address pair is found. The nice thing here is  
that this is transparent to the app, meaning that the app do not need  
to be changed to support this.

I guess that both are useful since each of them apply in a different  
scenario

regards, marcelo

>>> [email-masked] with the word unsubscribe in the body  
>>> of the message.
>>> You can also visit  
>>> https://www1.ietf.org/mailman/listinfo/I-D-announce