Re: Move forward

[Iljitsch van Beijnum <iljitsch@muada.com>]

On 16 Mar 2003, marcelo bagnulo wrote:

> > - Why don't you look at the return traffic to see if the path is still
> >   viable? If you keep (re)sending data but there is no reply from the
> >   other side, something must be broken. This probably needs per-session
> >   state, though.

> A proposed extension for MIPv6 is the piggybacking of mobility messages
> in regular traffic. In this case you would use return traffic to
> transport signaling data. This kind of optimizations can be done.

I didn't mean including explicit signaling in the normal traffic, but
just _looking_ at the normal traffic to see if everything still works.
This could work by having a list of destination hosts we're
communicating with. Each time a normal-looking packet (ie non-ICMP,
non-tunnel, non-multicast, big enough so it's not just an ACK) goes out,
some session state is saved and a timer is started. When the timer
elapses (after 5 or 10 seconds or so)  without any return traffic, we do
a "real" reachability check. So during normal traffic flow, there is no
need for explicit or piggy-backed reachability checks. This probably
needs some more heuristics, but I think it could work well.

> However this mechanism allows the it is used also in unidirectional
> traffic, which i guess is a good feature

All regular unicast protocols need some form of acknowledgement in order
to keep the traffic flowing. Without this, traffic would continue to
flow long after the receiver has disappeared. That would be extremely
bad.

> > - "If a failure   has occurred along the path, the attempt to initiate
> >   the communication will fail and the CN will try again with another
> >   address. Eventually, a packet from CN will reach MHH." As this is
> >   application-dependent you can't count on this. Worse: the all-time
> >   most popular networked application typically chokes if the first address
> >   tried doesn't work.

> Good point. I do not have much data about how applications normally
> behave in this case. But if this is the case, this is an issue. However,
> AFAIK this is probably the case for IPv4 where interfaces usually have
> only one address configured.

The number of addresses per interface isn't really an issue, I would
think. In v4 having several addresses for a DNS name isn't all that
unusual:

> host www.cnn.com
www.cnn.com is a nickname for cnn.com
cnn.com has address 64.236.24.28
cnn.com has address 64.236.16.20
cnn.com has address 64.236.16.52
cnn.com has address 64.236.16.84
cnn.com has address 64.236.16.116
cnn.com has address 64.236.24.4
cnn.com has address 64.236.24.12
cnn.com has address 64.236.24.20

> However in IPv6, considering "Default
> Address Selection mechanism" i was hoping that application used the list
> of addresses generated by the mechanism and try to use them to
> communicate

Actually this may make it worse, as the "best" address is always
selected. If the "best" address is unreachable, no dice. At least with
random or round robin you can hit reload to try again.

Iljitsch