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

[marcelo bagnulo braun <[e-mail]>]

Hi Arifumi,

thanks for the feedback,
some comments inline...

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

> Hi marcelo,
>
> marcelo bagnulo braun wrote:
>> 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
>
>
> 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.

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,
>  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.
>

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

>
> * 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.

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 :-)

>   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.

ok

>  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.
>

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


> Best regards,
>
> -- 
> Arifumi Matsumoto
>    Ubiquitous Computing Project
>    NTT Information Sharing Platform Laboratories
>    E-mail: [e-mail]
>
>
>
>> Inicio mensaje reenviado:
>>> De: [e-mail]
>>> Fecha: 15 de junio de 2006 22:50:01 GMT+03:00
>>> Para: [e-mail]
>>> Cc: Asunto: I-D ACTION:draft-bagnulo-rfc3484-update-00.txt
>>> Responder a: [e-mail]
>>>
>>> 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
>>> [e-mail] 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:
>>>     [e-mail].
>>> 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: <[e-mail]>
>>>
>>> _______________________________________________
>>> I-D-Announce mailing list
>>> [e-mail]
>>> https://www1.ietf.org/mailman/listinfo/i-d-announce
>> _______________________________________________
>> Int-area mailing list
>> [e-mail]
>> https://www1.ietf.org/mailman/listinfo/int-area
>


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