Re: I-D ACTION:draft-huitema-v6ops-teredo-00.txt

["EricLKlein" <ericlklein@softhome.net>]

> I am not sure that I like the idea that traffic originating as IPv4 TCP
> traffic will be transported by UDP across tunnels to obtain IPv6
> connectivity.
>
> This requires that the tredo "server" will know to ask for retransmits
> should anything fail to reach it's destination.

From: "Christian Huitema"
Did you actually read the draft? The stack would be
(transport)/IPv6/UDP/IPv4, which gives by and large the same kind of
reliability as (transport)/IPv6/IPv4, i.e. the other form of tunneling.
Also, only a small fraction of the packets actually go through the
server.

Yes i did read through the RFC, but as pointed out by Robert Elz :
> Reachability is one thing, but you may have to wait for TCP timeouts.
> RFC1122, section 4.2.3.5  TCP Connection Failures
> Says that the initial SYN has to wait at least 3 minutes...
> Note that I've seen some implementation ignoring this
> MUST and setting the timer to 12 or 25 seconds,
> but never to 100ms.

If I am running a TCP connection over IPv4 the retransmit functionality is
built into the TCP protocol stack. But if I am then transporting this across
a UDP tunnel who handles the TCP retransmits on timeout? The originating TCP
application is expecting a response from the distant end host, as that host
sees only the UDP it will never know to retransmit.

Thus you have a few possibilities:
  1. The packets are never acknowledged by the end host so are retransmitted
even if they got through and then you get low through put and high bandwidth
consumption as everything is always retransmitted.
  2. The teredo server handles the acknowledgement as it puts the packet in
the tunnel and then you never know if it really made it or not, i.e. your
TCP is now really acting as UDP.
  3. The end host sends the acknowledgement and thus your UDP is acting like
TCP (unlikely option as it is UDP transport).
  4. All applications that will use this will have at the application layer
acknowledgement / retransmit functionality built into them as the protocol
stack by definition does not (also unlikely as it would mean rewriting all
applications to check the transport to know if they need to acknowledge or
would double acknowledge when using true TCP).

Again looking at the applications of this I am most concerned with those
applications that are very time sensitive. Think about the problems related
voice over IP, it is by default UDP. So if a packet is lost you get a pause
or dead air in the conversation. This is fine, but as we start to add more
complex applications over IP we will have interconnections between IPv4 and
IPv6 (as described in this draft) for quite a while. I would hate to have a
telemedicine application running over TCP crossing one of these tunnels.
Eric