ietf
[Top] [All Lists]

Re: runumbering (was: Re: IPv6: Past mistakes repeated?)

2000-04-27 04:10:02
Ok,

I will stop being a lurker and chime in since our draft was
mentioned :->

Stephen Sprunk wrote:

draft-xie-stewart-sigtran-ddp-00 addresses redundancy and failover of
sessions within a server pool, where uncoordinated failover of sessions from
one endpoint to another is a requirement.  There is signifcant overheard and
indirection added to the session to achieve this.

Yes, I think you sum up what DDP attempts to do but I strongly
disagree with your "signifcant overhead" argument. Qiaobing and I
have been playing with DDP now for quite a number of years. It has
some overhead on the wire (not much) since the overhead is mainly
upfront i.e. when you want to go hold a talk to someone you
may need to do a query to find out where it is and where all
its redundant pools are. This drops in to a cache in any sensible
implementation and then within some period will need to expire
or be updated. Even when the cache is updated it does NOT interfere
with the ongoing communication (its done in parrallel). So basically
the delay overhead to talk to a peer is possibly one round trip to
the local ENRP server (of course local is not necessarrily on the
machine you are on but it could be :-0). In some cases there may
be no delay. In particular, the ability to send to a address (pre-known)
and then do a parrallel query to the ENRP deamon. We did not
get this one in the draft but I am sure future updates will have
this ...

The point is I can't see what your "signifcant overhead" is. Yes
it will take a query to get some redundancy but after 5 years of
work I think we have the overhead as slim as we can... of course
perhaps the working group will show us a way to reduce it further
but we will see....

We seem to be discussing a simpler requirement: coordinated movement of a
session from one ip:port pair on a single endpoint to a different ip:port
pair on the same endpoint.  Windows, buffer states, sequence numbers, etc.
could all remain the same.

In its basic state this is what DDP does do.. i.e. if you don't have
multiple peers. But of course if the route fails between you and
your peer, the conversations over.. until the path is back up.


I would think the latter requirement could be implemented as a simple TCP
"forward me" option.  For ESP/AH-protected sessions, no TCP-level
anti-hijacking protection seems necessary.  This could even be performed if
the original IP is suddenly not available and the other endpoint hasn't
given up on the connection yet; you send a "forward me" packet sourced from
the first IP, then listen for an ACK on the new IP.

I can think of no simple way (ie. without recreating IKE&AH inside TCP) to
do this for unprotected sessions; I'm not sure it's worth the effort to
solve either.

I'm sure there's something I'm missing here, or else this would have been
implemented 15 years ago...  Thoughts?

Yes, having worked at solving this problem for 5 years you are missing
some of the subtle nature of where the different state is. You really
must have a seperate state around, unless the "new IP" is attached to
the same machine. In that case you end up with something that looks
like SCTP to provide the redundancy, i.e. use the "new IP" address.

R



S

     |          |         Stephen Sprunk, K5SSS, CCIE #3723
    :|:        :|:        Network Consulting Engineer, NSA
   :|||:      :|||:       14875 Landmark Blvd #400; Dallas, TX
.:|||||||:..:|||||||:.    Email: ssprunk(_at_)cisco(_dot_)com

----- Original Message -----
From: ned(_dot_)freed(_at_)innosoft(_dot_)com
To: Karl Auerbach
Cc: IETF
Sent: Wednesday, April 26, 2000 16:48
Subject: RE: runumbering (was: Re: IPv6: Past mistakes repeated?)

Turn it any way you want, TCP sessions can only survive renumbering
through
end to end mechanisms...

Which raises the interesting (to me anyway) question: Is there value in
considering a new protocol, layered on top of TCP, but beneath new
applications, that provides an "association" the life of which transcends
the TCP transports upon which it is constructed?

I believe that if we had such a protocol that it would be a useful tool to
solve many of the juggling acts that transpire under the heading of
"mobile networking" as well as providing a way to continue (or
"resume") connectivity after IP address changes.

(I will, of course, be suitably embarrassed if someone points out that
work is already going on to do this.)

  draft-xie-stewart-sigtran-ddp-00.txt

ned

-- 
Randall R. Stewart
Member Technical Staff
Network Architecture and Technology (NAT)
847-632-7438 fax:847-632-6733