On 3-jul-2006, at 14:33, Brian E Carpenter wrote:
The author is of the opinion that such an increase in overhead on top ofthe increase in overhead incurred by IPv6 in general over IPv4, makes the shim6 multihoming solution less attractive, so it's worthwhile to try and suppress the shim6 header where possible.
Has anyone looked at shim6/rohc interaction?
I haven't, but I'd assume that it would be relatively simple to compress the shim header too in cases where other headers are being compressed.
Also, has anyone estimated what fraction of traffic would carry shim6 headers, on reasonable assumptions about the prevalence of multihoming events?
Generally, outages are fairly rare (don't forget that many people don't even multihome...), based on common SLA targets I'd say that at any given time about 1 - 3 out of a thousand last mile links are down. Although very short outages are more frequent than longer ones, long ones account for the majority of the downtime. In these cases, a shim6 enabled host will only use addresses associated with the links that are down if it had already established a context before the outage. So in practice, the number of packets that are shimmed because of outages will likely be something well below 1 in 1000, say around 1 in 10,000 to 1 in 100,000.
However, shim6 has the potential to make outages visible that are hidden today. For instance, if I sit between major exchange locations A and B, and my ISP gives me addresses that are routed over A and addresses that are routed over B (even though I may not be multihomed), I could end up with non-working addresses part of the time where such an outage would be invisible today. Doing this allows the user to "see" the two different paths and use whichever works best, as opposed to the current situation where a routing protocol selects one of the paths and the other is ignored.
But the clincher would be shimming for traffic engineering. Since it's hard to get people to connect to the "right" address at the beginning of a context, it's likely that some content suppliers will want to rehome a context immediately after it has been set up for traffic engineering purposes. This has the potential to generate a LOT of shimmed traffic so this is the main reason I wrote the draft.