Re: Locator Pool Reference ID

["Spencer Dawkins" <spencer@mcsr-labs.org>]

From: "Masataka Ohta" <mohta@necom830.hpcl.titech.ac.jp>
To: <dcrocker@brandenburg.com>
Cc: <multi6@ops.ietf.org>
Sent: Saturday, November 15, 2003 8:35 AM
Subject: Re: Locator Pool Reference ID


>
> As I already noted, path change without locator change also changes
> congenstion characteristics that it is a problem of transport not
> specific to multi6.

Yes - for example, when 802.17 rings "change directions" - the ring is
one IP hop, but with destination-stripping, your cross-traffic can
vary considerably when you go "the other way" around a ring.

>
> On the other hand, it is a protection agaist redirecting burst
> attack to slow start at locator changes.
>
> However, slow start costs performance.

This is consistent with the feedback I was getting from TSV maevens
about transport-level notifications for path changes/path
characteristics changes.

Slow-start would be safe (how could it not be?), but may be more than
what is needed. The logic seems to go something like

- if my path changes and I'm competing with a lot less traffic, I
shouldn't slow down

- if my path changes and I'm competing with a lot more traffic, I'll
lose something, and TCP-ish transport protocols will slow down
appropriately within a couple of RTTs, using Fast Retransmit/Fast
Recovery

- so I should either do nothing, or do what I would have done anyway
within an RTT or two, without additional transport
protocol/implementation complexity

Not a multi6 issue - the same issue comes up today when a routing
update changes part of a connection path between two single-homed
networks.

Spencer