[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [RRG] thoughts on the design space 1: the space
Be warned: long message.
Jari: I largely agree with your conclusion on the solution direction.
However, I think the NERD data format can significantly improved.
On 24 jul 2008, at 13:18, Jari Arkko wrote:
The next choice in the aggregatable branch is whether the identifier-
locator separation goes all the way to the host or not. If it goes
all the way to the host, we can see different solutions based on
which layer the design is at. Shim6, Six/One, and HIP are IP layer
solutions
One issue with these solutions, and presumably with any solutions that
exposes the locators to the hosts, is that it doesn't solve the
renumbering issue.
We probably want to avoid exposing locators to the end-user site in
any shape or form to make sure that the end-users won't be tempted to
put locators in their configurations and thus make it hard to renumber
locators, requiring us to come up with an id-loc-loc split in the
future.
whereas multipath TCP would be a transport layer solution.
Note that multipath TCP doesn't necessarily have to know the actual
locators: it could be good enough to just indicate "please use path 1
for this packet" vs "please use path 2 for this packet".
On 24 jul 2008, at 13:21, Jari Arkko wrote:
The caching design has a number of issues:
- If packets are dropped while cache entries are being fetched,
there may be deterministic loss
- If packets are routed through a secondary path while cache entries
are being fetched, there may be deterministic delay
Unfortunately, the loss isn't deterministic in its timing so the
sending host doesn't know when to resend its packets. There are also
not any RTT measurements that could provide guidance with that
decision. So the choice is between relatively long delays or sending a
large number of packets, creating a SYN flood of sorts on the
destination.
When routing initial packets through the mapping system, this would
allow for denial of service against the mapping system. This can be
remedied for the most part with rate limiting, but this increases the
average delay before a mapping can be optained; possibly to the degree
of unusability.
On 24 jul 2008, at 13:23, Jari Arkko wrote:
First, I am not at all convinced that we actually HAVE to employ a
cache for the forwarding lookup.
I think we tend to operate under the unstated assumption that a single
router must be able to resolve mappings for the full set of
destinations. I don't think that's necessary. If one big box is
expensive to build, it makes sense to use multiple smaller ones, that
each handle part of the destination name space. As long as we build
the mapping system such that it's easy to direct different mappings to
the appropriate router or encapsulating device, we should be able to
get parallelism benefits when scaling up.
On 24 jul 2008, at 14:20, William Herrin wrote:
But we already know negative acknowledgments can't be made to generate
and return reliably during an outage event. In any operational system,
we get unexpected routing loops or a firewall blocks the way or a
router malfunctions or the network is congested or something else
happens so that the packet is silently dropped without a NAK.
That's why we detect outages through the absence of positive
acknowledgment instead.
Right. So we apply a positive acknowledgment mechanism between the
tunnel/translation endpoints. Perhaps you can ask Jari if he has
designed one in recent years. :-)
In other words: I think that the shim6 REAP protocol can be applied
here. REAP is very light-weight when there is either no data or
bidirectional data. In shim6 it runs between the hosts in question,
but it could be made to run on the translators or encapsulator/
decapsulator.
I.e., we do push for the static information and pull for the volatile
information.
On 25 jul 2008, at 19:39, Olivier Bonaventure wrote:
The only case where you would detect problems with mapping are when
a single host is opening a single TCP connection. In this case, the
SYN packet will be delayed by the mapping. Note that using the DNS
also causes such a delay...
No, in the normal case you shoot off a DNS request and then you
continue when you get the reply. So there is a delay, but you get to
proceed immediately when the required information is available. With a
cache miss in the data plane, you lose a packet and then you have to
retransmit at some point. There is no way to determine what the right
time is to retransmit, so either you'll be retransmitting too
aggressively, which means the destination gets multiple copies of the
packet, or you wait longer than necessary and the user experience
suffers.
--
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