[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Dependency on mapping [Re: [RRG] Tunnel fragmentation/reassembly for RRG map-and-encaps architectures]
Hi Brian -
the importance of DNS for most of today's Internet traffic is IMO an
indication that a similar dependency on a mapping system -- which your
proposal would bring about -- may well be acceptable.
I don't think it's related to any specific proposal. [...]
Yes, absolutely right.
Avoiding a single trust anchor seems like a good thing, to
improve robustness. But I don't think the single root arguments
will be anything like as emotional or political as for the DNS.
We're not likely to see EIDs and RLOCs on the back of buses,
unlike URLs.
Hmm, I was more concerned about control over IP connectivity, not so
much about control over how your IDs will look like...
And control over IP connectivity is more powerful than control over
domain name resolution: If an edge network depends on a single mapping
anchor which, for aggregation purposes, is determined by its ID space,
then that mapping entity can deny IP connectivity to users in the edge
network. Also, and probably more importantly, the mapping anchor is in
a position to redirect users attempting to reach service X to service Y
instead -- and the users wouldn't recognize unless they do end-to-end
authentication.
As an example, if the government of a country controlled the country's
mapping anchor, it could redirect its citizens away from inconvenient
news Web sites towards fake Web sites with modified content.
BTW, Noel: This is a thought that I did not mention during our previous
discussion. I got the idea from a private discussion with Mikko Särelä.
I think the real difference is in response time expectations. We accept
that the time to resolve a human-readable name may be quite long and
occasionally fail, and the usage model takes account of that. We don't
expect that for IP addresses, so we don't know how robust the Internet
will be to significant waits for locator mapping. (Maybe somebody could
experiment with a stack that discards a random number of packets
at the beginning of each new flow?)
TCP would slow down quite significantly if there is packet loss during
start-up. Here is a brief analysis of what happens when TCP runs into
a retransmission timeout during the first RTT. (Mapping-lookup-related
packet loss happens always during the first RTT, so packet loss
during later RTTs is irrelevant here.)
During the first RTT, TCP's congestion window is set to 2 segments, and
only the SYN or SYN-ACK are in flight. If a retransmission timeout
happens now due to mapping-lookup-related packet loss, the congestion
window gets set to 1, and the slow-start threshold gets set to half of
the number of in-flight segments or 2, whatever is greater. This means
that the congestion window and the slow-start threshold end up being set
to 1 and 2 segments, respectively. In this situation, TCP cannot ramp
up its throughput in slow-start mode (which would be efficient), but
only in congestion avoidance mode (which is highly inefficient since you
start with a congestion window of 1).
The other thing that I still worry about as a matter of principle
is one of Jon Postel's contributions to RFC 1958:
" 3.11 Circular dependencies must be avoided.
For example, routing must not depend on look-ups in the Domain
Name System (DNS), since the updating of DNS servers depends on
successful routing."
That's a little simplistic as written but it seems to need some
thought - can the mapping system recover from a major routing
failure without manual intervention? If the answer is "no" or
"dont't know" we have a problem.
Right. More specifically, host X should always be able to get a mapping
for reaching host Y as long as there is a path from X to Y.
Apart from that, though, why should dependency on a map be
any more worrying than dependency on a globally distributed
routing table?
Because global distribution makes the routing table robust to forgery.
For forgery to work, it must be carried out jointly by all routers along
the bogus path. Forging on a single entity is not enough. However, if
routing depended on a single mapping entity, then this entity could set
up a bogus path on its own.
But again, I am not necessarily against mapping techniques that create a
dependency on a single entity. Just raising these points for
discussion, since I think we should be aware of them.
- Christian
--
to unsubscribe send a message to rrg-request@psg.com with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg