Subject: RE: [seamoby] Issue #4: Clear, unambiguous definitions missing

From: "Gary Kenward" <[email-masked]>
Date: Wed, 4 Jul 2001 13:53:32 -0400

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

-----Original Message-----
From: Kulwinder Atwal [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]]
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 aiming
for 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 can provide 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

---

From: Cedric Westphal <[email-masked]>
Date: Thu, 05 Jul 2001 00:23:18 -0700

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.
>
>           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
>