the small stuff

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

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.