Subject: Dependency on mapping [Re: [RRG] Tunnel fragmentation/reassembly for RRG map-and-encaps architectures]

From: Brian E Carpenter <[email-masked]>
Date: Fri, 18 Jan 2008 08:25:26 +1300

On 2008-01-18 00:32, Christian Vogt wrote:
>> So, let me know what you think about the 'multiple independent
>> signing authorities' concept as a way to deal with the sole (per
>> zone) global trust anchor issue you raised; if that doesn't work,
>> I'll see if I can come up with something better.
> 
> Noel,
> 
> 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. As far as I can
see, any proposal that separates locally-significant addressing from
globally-significant addressing, but retains e2e identifiers,
requires complete dependency on a map.

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.

> 
> It is certainly true that a dependency on DNS is less critical than a
> dependency on an address mapping system because the former does not
> directly affect IP connectivity.  (I brought up this argument myself.)
> But this difference in criticality may be negligible given that most of
> today's use of the Internet would still fail if DNS misbehaved.

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?)

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.

Apart from that, though, why should dependency on a map be
any more worrying than dependency on a globally distributed
routing table?

     Brian

--
to unsubscribe send a message to [email-masked] 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

---

From: Tony Li <[email-masked]>
Date: Thu, 17 Jan 2008 12:25:34 -0800

> "dont't know" we have a problem.

It would seem to me that if the mapping system did not itself have a  
recursive dependency, we should be ok.  Of course, resolving this is  
not particularly hard.  We simply have to have every entity in the  
mapping system have both the id and locator of its parent.

Tony

---

From: Christian Vogt <[email-masked]>
Date: Thu, 17 Jan 2008 22:46:53 +0200

Hi Brian -

> I don't think it's related to any specific proposal. [...]

Yes, absolutely right.

> We're not likely to see EIDs and RLOCs on the back of buses,

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ä.

> 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).

> "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.

> any more worrying than dependency on a globally distributed

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

---

From: Luigi Iannone <[email-masked]>
Date: Fri, 18 Jan 2008 10:50:43 +0100

Hi,

> during later RTTs is irrelevant here.)

I agree with Christian. Yet....

If we are going to introduce a big change in  the Internet  
Architecture (and Loc/ID split -is- a big change) to think that  
todays protocol will work with the same degree of efficiency is kind  
of utopia.

Once loc/ID is introduced, probably something like a future TCP-Vegas+ 
+ or TCP-New-New-New-Reno will fix the inefficiencies.

In other words, we should aim not at preserving top performances, but  
to not "degrade them too much".

Luigi Iannone

[email-masked]