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: [EMAIL PROTECTED]
Inicio mensaje reenviado:
De: [EMAIL PROTECTED]
Fecha: 15 de junio de 2006 22:50:01 GMT+03:00
Para: [email protected]
Cc: Asunto: I-D ACTION:draft-bagnulo-rfc3484-update-00.txt
Responder a: [EMAIL PROTECTED]
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 PROTECTED] 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 PROTECTED]
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 PROTECTED]>
_______________________________________________
I-D-Announce mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/i-d-announce
_______________________________________________
Int-area mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/int-area
_______________________________________________
Int-area mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/int-area
