[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

the small stuff



Then there are some other issues that I don't want to spend too much text on:

Forking

Somehow the assumption crept in that we need to support "context forking". The trouble with this is that there are two or more context for communication between the same ULID pair. This is problematic because now packets must somehow be tagged on their way through the stack from the application to the shim so the shim knows which context to apply, based on the wishes of the application.

I don't really see the advantages here. The idea is that this is useful so different applications can take different paths through the networks. I have no problem with that, but doing it inside the shim is a rathole: applications should just select the ULIDs associated with the desired path. The shim mechanism can then be relegated to repairing failures, and maybe provide some coarse traffic engineering at the most.

It might be useful to add a shim exchange that can support selecting the right ULIDs in this case, though: that would be fairly light-weight.

RTTs

We had a discussion on whether measuring round trip times and basing decisions on the measurements is useful. I think it is. Delay is easy to measure, and all things being equal, a path with a long delay is less desireable than a path with a long delay. As I wrote last week, the queuing delay part in end-to-end delay is getting less and less important as bandwidth goes up.

And one of the main goals of being smart about reachability detection is avoid the really bad paths. As such continuing the reachability detection a bit longer if the delay looks worse than the previously looking path is an easy way to do this in many cases.

The argument that we shouldn't duplicate transport work doesn't convince me as we're lower in the stack and as such we get to see things (locator info) that is invisible to TCP and the like.

Length fields

I'm not happy with 16 bit length fields or length fields expressed in 64-bit/8-byte units because of padding issues. In the latter case, padding to an even 8 bytes will always be required which is very inconvenient for fields with variable length content. Also, a 16-bit field would either require padding or sometimes straddle 16-bit boundaries, which means the two bytes must be extracted individually and then be glued together to form a 16-bit field again.

If we only need longer fields for a very small number of variables, it's easier to redefine these variables so that they are broken in 255-byte chunks and put in two or more fields.

Checksums

We didn't get a chance to discuss the issues surrounding the upper layer checksum. As I've said before, I think we're best off rewriting the TCP/UDP checksums along with the addresses. If we don't do this, transport checksum calculation offloading will be a big problem in IPv6. The potential for harmful actions from firewalls and such that don't see a valid checksum is also significant. Howevever, this is somewhat related to the suppressing of the shim header issue.

Demux on source with shim header

A question we also didn't get to explore is on which fields we use to recognize a shim context when the shim header is present. I think the assumption has been source/context tag/dest. Since the number of destination addresses is very small and the sets are going to overlap, we may as well toss out the destination address. If we also throw out the source address and do demux on just the context, this means we don't have to synchronize knowledge of the source locators on both ends. (I.e., without this the source can only successfully use a locator when the destination knows it should expect this locator.) And it allows source address rewriting by routers. The protocol number for the shim header should be enough to tell the router that this is ok, so there is no ambiguity in this decision. On the other hand this means attackers can try to spoof the context tag without needing to get source address right. So essentially we're giving up on ingress filtering for the most part.

Hostid

We had a long discussion on having a hostid in the meeting. I don't think this was really resolved, either why we need it or why we wouldn't want it. I'll keep an eye open for these issues when I go over the details of the reachability protocol I proposed to see whether it needs a hostid, but it would be useful if someone could outline the reasons we should avoid having one.