[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: the small stuff
El 12/10/2005, a las 14:39, Iljitsch van Beijnum escribió:
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.
right, this seems a possible option indeed
OTOH, my last understanding of what forking was (the concept seemed to
change quite rapidly during the meeting :-) was simply the possibility
to create multiple context with the same ULID pair. Those context would
have different context tags, so no problem with distinguish among them.
So, i think that if, this is what we are talking when we say forking, i
don't see that it would be to complicated, since having different
context tags would deal with it fairly easily
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.
Well, my understanding of the proposed approach and the reasons for it
was somehow different:
first of all, RTT time measured in one or two packets (i.e. path
exploration packets) didn't seem to be representative of the real RTT
of the path.
Second, there are other metrics that seemed at least as relevant than
the RTT
third and most important, using the RTT for selecting paths does not
requires coordination from both ends, and can be adopted unilaterally.
Clearly, having the RTT measured and taken into account into address
pair selection would indeed be more complex. So, the approach proposed
was to include simpler path selection mechanisms in the core spec, but
allow extensions for taking RTT into account for selecting paths in
other documents
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.
Not sure about this...
the context tag is assigned by the receiver, so i would argue that the
context tag is unique for that receiver (i.e. for all the incoming
packets)
This is easy because since the context tag is now quite big, no problem
with running out of them
so in this case, the context tag is enough to identify the context at
the receiver.
then we verify that the addresses are valid for that context, but this
is for security, rather than because we need that info for demux.
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.)
right, but the problem with this is about security. An attacker could
send packets with its own source address and insert them inside a shim
communication, by just guessing the context tag.
This would result in additional vulnerabilities because it would allow
the attacker to workaround ingress filters i.e. no need to send a
spoofed source address, which could be difficult for the attacker
because ingress filters.
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.
as i understood, the goal that you were after when proposing using
hostids was recognized as important (allowing to share path exploration
messages through multiple contexts)
The problem with hostids is that we need to define them with the
correspondent complexity of defining a new name for the host. So
alternatives mechanisms to achieve the goal that you proposed were
explored.
Not really a problem with hostids, just looking if there are simpler
options to achieve the same without defining a new name
regards, marcelo