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

[Arifumi Matsumoto <[e-mail]>]

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