[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