re: celp draft

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

On 12-feb-04, at 1:06, Dave Crocker wrote:

> > http://www.ietf.org/internet-drafts/draft-crocker-celp-00.txt

Still catching up...

Let me start by strongly disagreeing with:

"The basic goal, then, is to find a method for multiaddressing that 
makes the smallest possible change"

IF a change is necessary, it would be stupid to optimize for a small 
change, as the difference in deployment effort between nog change and a 
small change is HUGE while the difference between a small change and a 
larger change isn't very substantial. If changes are necessary, we must 
make sure we get it right the first time if at all possible. A good 
example is the change to the socket API when IPv6 was introduced. This 
change was kept as small as possible, but despite that 5 years later 
only a fraction of all applications have been updated. And now that 
we're talking about multihoming we may have to change this API again, 
or bend over backwards to avoid it.

I also disagree with the assertion that transport-based solutions would 
save on the number of packets exchanged. A wedge solution can monitor 
transport interactions to see whether there is still connectivity. And 
the currently existing transport solution, SCTP, adds lots of extra 
packets by periodically probing connectivity on all paths. In cases 
where there are two or more backup paths this can save a little on 
recovery time after a rehoming event, but I think the cure is worse 
than the illness here and in the case of only one backup path it 
doesn't help anyway: if the primary path fails the only possible course 
of action is to use the backup path, regardless of whether we "know" 
that it works or not. (Obviously when one path fails changes to the 
other paths at the same time aren't unthinkable so all existing 
knowledge is suspect.)

Also, on the ipv6mh list we had extensive discussions about keepalives 
and I think I made a good case for taking advantage of path overlap 
between different destinations, making it possible to reduce the number 
of keepalives to each individual destination while retaining the 
desired average failure detection times.

"Enhanced transport services access the pool directly. Legacy transport 
services access the pool via the IP wedge layer service."

Ok, this is the part I like. However, this reads like you expect the 
enhanced transports and the wedge mechanism to live together without 
sharing any mechanisms. I think that would be a missed opportunity.

And I think you're right there is lots of stuff that overlaps with what 
we're doing in multi6 going on, we need to figure out how to handle 
this. The fact that there hasn't been significant interaction with the 
mobility people yet despite the general recognition that there is 
overlap that has existed for years, isn't a good sign here.

One problem: how do we know that different addresses point to the same 
entity? Within a protocol this could probably be implied, but between 
protocols this can easily become problematic. For instance, some 
protocols may not care that a set of addresses points to different 
hosts providing the same service, while for other protocols switching 
hosts isn't likely to work. It also works the other way around: if we 
don't recognize two addresses belong to the same entity we may lose an 
opportunity to switch between those addresses later. Maybe having 
identifiers isn't such a bad thing after all...

Later:

"From my own sense of the net and from the responses so far, I believe
that a host can maintain an address pool based solely on a simple list
of the destination's addresses. That is, for the near term, the
combinatorial complexities of considering local/remote address pairs can
be deferred. Of course, the implications (that is, the limitations) of
this simplifying assumption need to be stated."

Again: we have to do it right the first time if we possibly can. 
Deferring this also doesn't make sense as ingress filtering by ISPs 
makes source address problems too common to be able to ignore safely 
even if ignoring failures in the middle of a path would be considered a 
good idea.