[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Opportunistic Tunneling



-- Thursday, February 26, 2004 10:03:16 -0800 Fred Templin
<ftemplin@iprg.nokia.com> wrote/a ecrit:

> Hello Marc,
> 
> Marc Blanchet wrote:
> 
>> However, I don't understand where you are going to.
>> 
> 
> I have also been struggling to understand this distinction.
> 
>> To me, the different
>> tools we are talking about are similar to that respect: isatap, 6to4,
>> teredo, TSP are all, from the user point of view (i.e. the cell phone
>> user), a "driver" in the operating system: i.e. they don't care and don't
>> have to manage it. And the infrastructure and services to make them
>> usable are provided by some downstream providers, either the direct one,
>> or another one  downstream.
>> 
> 
> I agree, however it seems that TSP takes the "high road" and negotiates
> tunnel configuration via TCP connections

or UDP. for nat traversal, it does tsp over udp.

> and XML exchanges while the
> other mechanisms take the "low road" and use, e.g., IPv6 ND messages.
> Under TSP, the number of messages involved 

one "request" message in XML, one "reply" message in XML.

>in setting up and tearing
> down TCP connections, sending the XML, etc. can seemingly become
> quite high.

- udp is pretty light.

- define high?. XML takes more bytes than binary. But XML is more
extensible. TSP/XML gives you the ability to negociate things that are
useful/required for some scenarios, such as DNS names, dns delegation,
prefix delegation, etc.. Pros and cons. 

> 
> So, if nodes require short-lived tunnels and/or many tunnels to many
> different endpoints there could be a significant efficiency advantage
> in using the "low road" mechanisms. Whether this can be seen as
> a measure of "opportunism" I cannot say?

looks more as how many bytes you care about consuming for your control
connection. Remember that TSP is only involved at the setup of the tunnel.
So the cost is pretty low compared with the traffic itself.

Marc.

> 
> Fred
> ftemplin@iprg.nokia.com
>