Subject: RE: [seamoby] Timing characteristics Re: [seamoby] Issue #4: Clea r, unambiguous definitions missing

From: "Gary Kenward" <[email-masked]>
Date: Thu, 5 Jul 2001 10:58:13 -0400

Cedric:
 
  I like the idea of using a "best effort ct" definition, simply because I
think it
will be intuitively appealing to all. The "timing aware" aspect seems less
crisp.
Perhaps "expedited ct" would be better? ;^} - I'm only half joking: the
problem
spaces are similar, in that we want to optimize timing without being
prohibitively constrained.
 
I must say that I lumped all this behaviour together in my interpretation of
the current definitions, and clearly this is insufficient for others. 
 
So let's both work on some text and see what we can each come up with and
compare
notes. Hopefully we will converge.
 
One last comment: the problem with the wording of issue #4 has to do with
the particular event used. For many networks, this is not the first event
available when a
handover is activated. Once handover is in process, the network can only
react to the
situation, and the ct performance is limited by this condition. 
 
Let me try and clarify with an example: say for a specific network, handover
is accomplished by first establishing a new data path at the link layer to
the new AP, in a 
make-before break scenario; in this scenario, the network can know that a
handover is 
happening, some  time before the MN's traffic starts to be moved to the
newAR. This only an single example, and it presumes that L2 events are used
to trigger ct, but this is not an unusual approach. The significant points
of this example are: the event that causes the network to react to the
handover and initiated a ct is not the first IP packet
arrival at the AR; second, this is clearly not proactive ct, for the network
had no time to
prepare the newAR for the handover, for whatever reasons, and is put in a
mode where 
it must transfer the essential forwarding context as soon as possible. The
difference here in terms of time may only be milliseconds or tens of
milliseconds, but it is a significant difference in terms of the design of
ct.
 
Cheers,
Gary
 
BTW: just to be sure, I don't get to introduce text into the draft on my
own. The
current process is for the text into the issues list. I edit the draft, but
only after
an issue has been raised and a consensus reached. I apologize for being
pedantic,
but with all the important debates going on, I do not want anyone to get the
false
impression that text sent to me should be put into the draft.

-----Original Message-----
From: Cedric Westphal [mailto:[email-masked]]
Sent: Thursday, July 05, 2001 3:23 AM
To: Kenward, Gary [WDLN2:AN10:EXCH]
Cc: 'Kulwinder Atwal'; 'seamoby'
Subject: [seamoby] Timing characteristics Re: [seamoby] Issue #4: Clear,
unambiguous definitions missing

Gary, 

with respect to your last comment, please do submit an issue about the
timing characteristics 
of the ctp. 
The sticky point of the other thread (neither pro nor reac thread) is
exactly this, so you can count 
it as support for change. Let me explain: proactive/reactive as defined in
Issue#4 (whether 
or not this will be integrated in the draft aside, many people, myself
included, liked these 
crisp and clear definitions) do imply a time frame. Stuff happens _before_
or _after_ some event, 
so it situates them on the time axis compared to the event. The draft as
well, even though it 
is more vaguely, situates the pro/reac ct on this axis. 
This is useful in many/most situations, and IMO MUST be supported. Let's say
that proactive 
and reactive belong to a class of ct that we could definitely use, the
timing aware ct (TACT). 
Before anybody jumps on me, this is aware, not constrained. 
The kiddies I mentioned earlier do not have a strict timing constraint, more
of a best effort 
constraint. Call it in-tact, as a symmetric to tact, in being either a
negation (after pro and 
re, latin prefixes are edgy nowadays) or indifferent/neutral wrt timing
(asynchronous transfer 
mode was already taken :-).  Would you allow me to provide some text in this
direction? 
If I may go further, the ct itself could be neither tactful nor intact as a
whole, each phase could 
have a different characteristic. I'd elaborate on this but I'd like to see
first how the multiphase 
support requirement is going to end up wordsmithed. 
Cheers, 

Cedric. 

Gary Kenward wrote: 

 Kulwinder:  Sorry if I missed your point in the previous posting, some
comments below. 

-----Original Message----- 
From: Kulwinder Atwal [ mailto:[email-masked]
<mailto:[email-masked]> ] 
Sent: Wednesday, July 04, 2001 12:01 PM 
To: Kenward, Gary [WDLN2:AN10:EXCH] 
Cc: 'seamoby' 
Subject: RE: [seamoby] Issue #4: Clear, unambiguous definitions missing 

-----Original Message----- 
From: Gary Kenward [ mailto:[email-masked]
<mailto:[email-masked]> ] 
Sent: Wednesday, July 04, 2001 11:28 AM 
To: 'Kulwinder Atwal' 
Cc: 'seamoby' 
Subject: RE: [seamoby] Issue #4: Clear, unambiguous definitions missing 
 
Well, no, CT does not arrive after the first packet. Not if your aimingfor
seamlessness and you attempt to be proactive. This concept of a "ParentAR"
is new to me, as far as I know, it is not required for ct. Regardless, ct
can start as soon as the network determines[KA] My point is that it is the
network that determines when to start CT.  It is a network's responsibility
to determine when to start CT.  And, it is the network's responsibility to
ensure that Handover and CT complete near the same time.  It is NOT the CT
protocol's responsibility to ensure this, therefore instisting that CT must
complete before Handover is not a valid requirement.  We could just as
easily for a particular network say that we want Handover to complete before
CT, and put the requirement into the Handover Protocol.  The End-User would
be just as satisfied.  The ordering is inconsequential.> I didn't see this
point in your previous posting.> We do agree.> My only caveat is that I am
concerned that if we do not tie ct completion somehow to handover >
completion, there will be proposals ctp that have no time limit. We all
believe ct should finish quickly, > and the essential forwarding context
should be installed at the newAR before handover completion in > order to
achieve the best possible handover performance. I think we all agree that we
have to be> very careful about the exceptions to this "ideal" situation. Do
we not?It seems that the greatest difficulty we are experiencing is in
capturing the exceptions without losing the preferred "ideal".[KA]  It is
network specific whether to start CT first, or Handover first.  It
absolutely does not matter which finishes first.  Just as you can provide
examples of when Handover happens first, I canprovide examples where the
reverse is true.> It does matter which completes first. If handover
"completes" first (e.g. packets are sitting in a queue > at the newAR) but
the encryption context has not arrived, then the newAR cannot forward those
> packets. They will incur an additional delay. > Does it matter if the
packets are delayed by 0.0001 seconds waiting for context? Clearly not, but>
somehow we must capture the fact that a 100 ms delay does matter.[KA]
Rather than have people say, " Oh, but we really need CT to happen before
handover.  So much so, that we must have it as a MUST requirement",  I would
like these same people to show what terrible thing would happen if the order
were reversed by a few milliseconds.> A few milliseconds, no. A 100 ms yes.
As an example, a 100 ms additional delay incurred by > G.729 voice frames in
a conversational voice session, and you might as well drop the frames. >
Dropping 4-5 sequential voice frames is *very* noticeable to a user, and is
clearly not "seamless".[KA] We are all interested in having CT happen
quickly, so I really don't see the reason for this unnecessary sequential
linkage in a requirements document.> Well, I do not either. I am trying to
come up with some definition that preserves the flexibility> of the current
definition, but answers some peoples concerns. I would, at this point, like>
to toss "proactive" and "reactive" and replace it with a description of the
desirable > timing characteristics of the ct process - something similar to
the concepts you and> I are talking about here. I would submit an issue, if
there was any hint of support for> this change.Cheers,Gary