Subject: RE: [Seamoby] New Section 5.8 - Requirements on Feature Context Specifications

From: "Gary Kenward" <[email-masked]>
Date: Mon, 12 Aug 2002 14:18:42 -0400

Hello again Charlie:

> -----Original Message-----
> From: Charlie Perkins [mailto:[email-masked]]
> Sent: August 12, 2002 11:54
> To: Kenward, Gary [WDLN2:AN10:EXCH]
> Cc: [email-masked]
> Subject: Re: [Seamoby] New Section 5.8 - Requirements on 
> Feature Context
> Specifications
> 
> 
> 
> Hello Gary,
> 
> It seems to me that we're finally getting to the heart
> of the discussion...
> 
> Gary Kenward wrote:
> 

*snip*

> 
> > I do not really believe that there is much to be gained in creating
> > yet
> > another transport protocol. My point is that if you are going to
> > transfer
> > come of the context with TCP, for example, then you might as well
> > transfer
> > all of the context with TCP.
> 
> But this either implies that one keeps TCP sessions open
> with "neighbouring" access routers (as you mention later),
> or that one accepts more latency.  This "nearly" places a
> dependency on the future "access router discovery"
> protocol, which I think would be a serious mistake.
> Otherwise, no contexts could be transferred in less
> time than it takes to start up TCP, which would also
> be a mistake, it seems to me.

I agree. TCP has limitations for short bursts of traffic such as CT.
*Except* for the cases of an ad-hoc network, or a network with mobile
routers, I do not see any reason why a TCP connection cannot be simply 
opened and kept open.

I have never understood the rationale for "discovering" a new wireless
network and then requesting a handover and thus a transfer. I have outlined
my reasons in other emails, so I won't get into it here. 

*snip*

> The problem isn't MTU, it's startup latency for TCP, which
> could get into quite a few milliseconds.  All of this detracts
> from the overall delay budget for real-time applications
> which can have quite stringent bounds.  The more we push
> those bounds out towards longer delays, the fewer applications
> will experience "smooth" handovers.  Even if TCP can handle
> voice handovers in some restricted domains, are you confident
> it can handle future voice/video synchronized streams?

See above. Any overhead introduced during a handover takes us away
from seamlessness.

And so, following your logic, I question the rational with doing CARD => 
CT => handover with a video stream.

> 
> 
> > At this point, may I suggest that we clarify the requirements to
> > remove the
> > implication that each feature context must have a separate transport
> > protocol.
> > I think that each feature context analysis should outline the ideal
> > and
> > adequate transport requirements, and choice of one or more then one
> > transport
> > should be left to the network designer.
> 
> The actual requirement for some contexts is low latency, not
> separate transports.  The other actual requirement (for other
> contexts) is reliability (again, not separate transports).  I do not
> have confidence that TCP can meet _both_ requirements.

You are presuming here that the handover can proceed without the
second context. Otherwise, the TCP based CT still has to complete before
the handover can be completed (e.g. the packets can be forwarded at
the new AR with the same services and service characteristics). And,
if the "fast CT" completes before the "reliable CT", how does the
target AR incorporate the late context, given that, by definition,
the "fast CT" is being used to forward packets (if it is not
being used, then it clearly didn't need to be at the destination AR
so quickly).

I have a feeling, a strong feeling that this is all moot. I do not
know of any context that can be transferred unreliably - that is,
there has to be a reasonable assurance that CT will succeed in order
for it to "enhance" handover. If a CT fails as a consequence of an
unrealizable transport being used, what is the result?

By reasonable assurance, I go back to what I stated in reply to James:
handovers will fail. However, handovers failures due to CT failures
must not be relatively insignificant (e.g. <<1%).

*snip*

> >
> > Why not? I agree if the intent were to set up a TCP connection every
> > time you wanted to perform CT, but at least for networks where the
> > ARs are wired together, a single TCP connection between two 
> ARs can be
> >
> > established and kept open, can it not, to handle all CTs.
> 
> Are you really willing to make the restriction that [seamoby]
> only deals with such networks that satisfy this criterion?

It would be preferable if we had a protocol that was both fast
and reliable - e.g. one that optimized for very short bursts of
data. However, we (seamoby) are not going to be defining that protocol,
as far as I can tell.

I'm still waiting for a practical description of a wired network or group
of wired networks where this "restriction" is impractical. For a handover
to occur seamlessly between two networks, many, many facilities have to
be pre-established. It would seem to me that requiring a tunnel for CT
between the two is a very small additional requirement.

> 
> > >    with the most urgent other contexts that will fit, and 
> which are
> > >    compatible with the chosen transport.  If the chosen transport
> > >    is not a reliable transport, schedule a retransmission if any
> > >    context transfer requires acknowledgement.
> >
> > I seem to sense a proposal here to layer an ACK/retransmission
> > protocol
> > on top of ICMP. Seems like you are really back to creating 
> XCTCP, but
> > with the (possible erroneous) assumption that ICMP is an appropriate
> > starting point.
> 
> I'm not so particular as that.

Regardless, the idea of defining an ack/retx capability on top of UDP/ICMP
is still transport protocol design. Arguably, TCP is simply UDP with
ack/retx
and window flow control (and a pile of other stuff designed to make it all
work in various situations). 

*snip again*

> > Why not simply put all feature contexts into one transport exchange?
> > Which hopefully means, one IP packet.
> 
> That's what my "program" does!  Please have another look.

No it doesn't. It puts each context into it's own transport protocol. That's
not, in my view, one transport exchange (each protocol sets up it's own 
exchange), and not one IP packet, in anyone's view.
> 
> > BTW: if the goal here is to merge CT with the HI/HACK mechanism for
> > MobileIP, then the intent is misguided. CT is supposed to work in
> > scenarios where MobileIP is not present. Certainly requiring the
> > network to implement HI/HACK simply to allow part of the CT to occur
> > is wrong.
> 
> This is in no way the intention of what I wrote.  However,

Good to know. But then, I am confused over the relevance of HI/HAck to
the discussion. 

> I also believe that any reasonable solution SHOULD work
> with fast handovers.  Otherwise, what's the point?  Even so,

The critical phrase here is "work with" - CT MUST work with
MobileIP (it's in the charter I believe). However, how it works
is another issue.

> there may be other protocols that achieve similar goals, and
> in those cases the CT design should still work fine.
> 
> > See comments. I am beginning to believe that this debate is more
> > around
> > trying to incorporate HI/HACK into CT then it is about what 
> transport
> > protocol CT needs. Please tell me why am mistaken.
> 
> I hope by now it is obvious!  Nothing I said should be
> interpreted to draw that conclusion.  Do you see now?

I guess I shall remain confused. You introduced HI/HAck as a mechanism
for CT. I don't see the relevance. If the *only* context I have to
transfer fits into HI/HAck and HI/HAck provides the necessary transport
characteristics, then yes, it would be nice if CT could run over Hi/HAck.
Does this mean that CT should be tailored so that it runs over Hi/HAck?
I guess it should be shown that tailoring CT for this purpose is
significantly
superior then running CT in parallel (or before, as with in "proactively").

I have no idea how to proceed from here. 

John L. is right, we are back in the same rat-hole we were in more then a
year
ago. There is little agreement as to what the transport service requirements
are,
whether they are feature context specific, mutually exclusive, available in
existing
protocols, etc., etc., etc. Those that do not pay attention to history, are
doomed
to repeat it.

Perhaps John can come up with a set of requirements for transport. How this
can be
done without going through the requirements for each feature context will be
a 
challenge, for the debate always returns to the (perceived) differences in
transport
service requirements, and the (perceived) exclusiveness of those
differences.

Onwards and downwards,
Gary

> Regards,
> Charlie P.

---

From: Charlie Perkins <[email-masked]>
Date: Mon, 12 Aug 2002 19:49:09 -0700

Hello Gary,

Continuing...

> routers, I do not see any reason why a TCP connection cannot be simply

I agree this would be possible, and would provide
reasonable performance in a lot of cases.  It would
penalize mobile nodes moving to "uninitialized"
access routers that do not need reliable transfers,
and for that reason seems to be unnecessarily heavy
handed.  So, I'd say it's not the best approach.

> CT => handover with a video stream.

How about "Handover + CT"?  That would work.

> second context.

Not exactly.  In my opinion, we MUST arrange it so
that all handovers can complete even if all context
transfers fail.  Successful context transfers will have
the effect of improving performance.

Thus, one effect of this is that, yes, the handover could
complete without the second (or any other) context.

> unrealizable transport being used, what is the result?

How about header compression?  If the state does
not make it, then it can be re-established.

How about QoS?  If the state does not make it, the
mobile node could renegotiate.

In fact, I think this is true for _all_ contexts: if the
transfer fails, the mobile node has to be robust
enough to renegotiate, re-establish, or request
retransmission of data.

> must not be relatively insignificant (e.g. <<1%).

It's probably a great goal, but I can't see why you would
want to restrict context transfers to only those scenarios
offering high reliability.

> between the two is a very small additional requirement.

Your statement is not true for the prototype implementation
we have.  Requiring another tunnel for CT is just not
necessary, and isn't such a trivial requirement anyway.

> work in various situations).

A pile here, a pile there, and pretty soon you're talking
about real protocol.

Well, with apologies to others, here is what I said:

> 1. Find the most urgent context.  Encapsulate it using the transport
>    it specifies (which won't be TCP, I reckon, for extremely urgent
>    contexts).   Fill the rest of the context feature data structure
>    with the most urgent other contexts that will fit, and which are

The third sentence refutes your characterization.  How many
transports do you think there are, anyway?

Typically, there would be one packet per transport type, and
that's unlikely to be more than two packets.

> Good to know. But then, I am confused over the relevance of HI/HAck to

They are one good place to put context feature data, but
not the only good place.

Put another way, if the old access router is already sending
HI to the new access router, there's no reason that urgent
context feature data should not be included with the base
handover information.

> characteristics, then yes, it would be nice if CT could run over

That's all I meant.

> Does this mean that CT should be tailored so that it runs over

Of course not -- depending on what you meant by "tailored".
I think it should be convenient to do it either way.

> superior then running CT in parallel (or before, as with in

Two packets takes longer than one.

> Gary

Somehow that means you are unlikely to welcome this response.
But I'm trying to be constructive.

Regards,
Charlie P.

_______________________________________________
Seamoby mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/seamoby

---

From: Charlie Perkins <[email-masked]>
Date: Mon, 12 Aug 2002 19:49:09 -0700

Hello Gary,

Continuing...

That's all I meant.

Regards,
Charlie P.