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