Re: soft state (was Re: shim6 and bit errors in data packet headers

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

On 14-mei-2005, at 16:58, marcelo bagnulo braun wrote:

> > The thing is, that you need some kind of semi-reliable  
> > communication to accomplish all of this, and to do the negotiation  
> > too. (In the case of the reasability testing, it would be useful  
> > if the receiver of a probe would have a semi-reliable way of  
> > telling the sender that the probe was received.) There is also  
> > some circularity: you need connectivity to negotiate locators, but  
> > you need to know the locators already to discover connectivity.

> Well, i was thinking in retrying a couple of times, just to keep it  
> simple. I don't know yet if this would provide all that we need though

Even with the minimum number of locators (2 on one side, 1 on the  
other), there are two paths in each direction, making for four  
possibilities for two-way communication. We really need to be smart  
here rather than simple in order to get results fast...

> > I'm thinking we could come up with a kind of "UDP on steroids"  
> > that similarly to SCTP works over multiple addresses. Such a semi- 
> > reliable multi-address datagram protocol would be very useful for  
> > the negotiations and similar exchanges, and it would supply  
> > reachability information as sort of a by-product.

> this sounds quite more complex that what i was thinking about...  
> (maybe it only sounds complex though :-)

You haven't even heard about all the heuristics and optimizations I  
want to implement.  :-)  But apart from that, the way I see it, we  
need this functionality one way or another. Splitting it off and  
making a separate protocol for it will actually make things less  
complex.

> > > :-)
> > > Context state AND path failure AND unidirectional  
> > > connectivity.... this seems amusing enough

> > Since the situations where context state doesn't exist (= before  
> > the start of a session) and unidirectional reachability (caused by  
> > ingress filtering) will be very common, we really need to cover  
> > this case.

> I guess this depends on what solution for ingress filtering  
> compatibility is available i guess

I'm not very hopeful in this area: I think we'll have to make do with  
source address based routing for smaller networks and ingress  
filtering exceptions for larger networks, and possibly make only one  
set of addresses available for non-shim hosts.

Alternatively, we could look into creating a protocol that allows  
users to signal their address blocks to an ISP so the ISP can  
automatically open up ingress filtering. But I'm sure many ISPs won't  
do this for home user-grade service as a means to push multihomers  
towards more expensive services.