[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