Re: [RRG] Why delaying initial packets matters

[Stig Venaas <stig.venaas@uninett.no>]

Olivier Bonaventure wrote:
> Robin,
>> In "Re: [RRG] Re: Aggregation Implies Provider Dependence (LISP-ALT)
>> & Ivip dependencies too", Brian Carpenter wrote:
>>
>>> However, user expectations are of a noticeable delay between
>>> dialling a phone number and hearing the ringing tone. So e2e
>>> lookup solutions to both number portability and roaming are
>>> tolerable. If we're prepared to tolerate such a delay in initial
>>> identifier-to-locator lookup, why are we having this
>>> conversation? (And note that Mobile IP effectively *does* use
>>> such a solution.)
>>
>> A scheme such as ALT will also delay some of the DNS (identifier to
>> locator) lookups, since some DNS servers will be on EID space which
>> the ITR has no mapping for.
>>
>> I think there at at least two reasons we should be concerned about
>> the delay problems inherent in a map-encap scheme which depends on
>> any kind of global query server network (LISP-CONS, LISP-ALT or Bill
>> Herrin's TRRP):
>>
>> 1 - Great reluctance to introduce or impose any new architecture
>>     which further delays the establishment of communications.
> 
> I completely disagree for two reasons. First, applications are used to
> have a small delay before the first packet flows, this delay has been
> introduced by the DNS a long time ago. I guess that some people were
> worried by the added delay at that time, but the benefits of the DNS are
> clearly more important than this additional second. Second, the delay is
> only encountered for the *first packet* that needs a mapping. With a
> router based solution such as LISP, many flows will benefit from the
> mapping learned from previous flows on the routers.
> 
>> 2 - Concern that if the new kind of address space involves
>>     extra delays of any measurable kind - especially when they
>>     are perceptible by end-users - that this will be a serious
>>     and perhaps fatal barrier to the widespread adoption of the
>>     new kind of address space.
> 
> A new architecture will bring new benefits and some costs in terms of
> delays for a minor fraction of the packets (0.01% or fewer ?) and somme
> added overhead due to encapsulation. This added costs must be compared
> to the benefits of the new architecture.

I'm not so worried about the delay itself, but rather how it might
affect transport protocols. The DNS delay is not much of an issue since
the application does not try to exchange any actual data until DNS is
completed.

One solution, which is a bit of a kludge, could be to have some kind of
interaction between DNS and the mapping system, where the necessary
mappings can be installed (based on DNS replies), before the DNS reply
is given to the application. I don't really like this though.

Another possibility could be to add some kind of signalling where hosts
more or less signal that they want to communicate with this other host
before they actual do the application parts like say TCP. E.g., you
could imagine that when a TCP application makes a connect() call to some
destination, the stack will signal to the network that it wishes to
communicate with this destination, and not send TCP SYN until it has got
an ACK back that it's okay.

I'm sure there could be other ways. Anyway, I believe such delays will
require changes in applications and/or host stacks.

Stig

> 
> Olivier
> 


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