[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: apps people?



There is one point you're missing.
When an apps cycle through the list of potential src/dst addresses,
it does not fail over from one to the other immediately, especially
when the destination is remote and ICMP unreachable message may or may 
not
be received. TCP time out kicks in and RFC1123 says that an app MUST 
wait
at least 3 minutes in SYN state before timing out
(of course not all TCP implementation implement this MUST)

Anyway, my point is that if this trial/error process of walking through
the list of possible destination before finding a correct one can be
extremely time consuming. So, if the "routing view" of the world
is not in sync with the "DNS view" of the world, unacceptable delays
may/will occur.

	- Alain.

On Wednesday, August 6, 2003, at 06:31  PM, Andrew White wrote:

> Unless I'm missing something, the 'apps' problem can be neatly divided 
> into
> two issues:
>
> (1) If there are multiple addresses per node, then the application 
> needs to
> somehow iterate through the various src/dest combos until it finds one 
> that
> works.  If multiple ones would work, how does it choose the best combo?
>
> (2) If there are filters in place, then addresses that work from one 
> node
> attached at one point may not work from a different node or a different
> location.
>
> If we agree to remove filters and have one address per node, then we 
> can
> continue to write simplistic apps.  If not, then applications need to 
> use
> techniques that allow them to cope with these issues.
>
> Notice that if an application only creates connections using a single 
> pair
> of endpoints then (assuming no mobility) it only has to deal with 
> issue #1.
> Issue #2 only comes into play when applications forward IP address to 
> other
> applications and expect them to keep working.  Sending DNS addresses 
> instead
> may be a solution for some applications.  Manual configuration is the 
> other
> option.
>
> This discussion is only relevant to 'local' addresses in as much as 
> local
> addresses are one class of filtered address.  As soon as you introduce
> filters you MUST consider #2, regardless of your address 'scope'.
>
>
> Christian's point about apps not wanting to deal with scope ids to 
> resolve
> overlapping mutually ambiguous scopes is taken, but I think most of us 
> agree
> with that aspect.
>
>
> Network ambiguity is largely irrelevant - the connection succeeds or it
> doesn't (remember that most nodes have a unique interface id).  Rather,
> ambiguity is a big bugbear for network merging.
>
> -- 
> Andrew White
> --------------------------------------------------------------------
> IETF IPng Working Group Mailing List
> IPng Home Page:                      http://playground.sun.com/ipng
> FTP archive:                      ftp://playground.sun.com/pub/ipng
> Direct all administrative requests to majordomo@sunroof.eng.sun.com
> --------------------------------------------------------------------

--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------