Subject: RE: [seamoby] L2 API (WAS: Ext. for FMIPv6 - comments)

From: "Gary Kenward" <[email-masked]>
Date: Tue, 10 Jul 2001 15:50:11 -0400

Cedric:

  So, I think here that you are agreeing with the original point,
which is that there is no requirement for two versions of ctp,
but there is a requirement for early and almost late (proactive
and reactive) ct.

  That there is no requirement simply means that we should not
embed this concept into the reqs draft. It does not prohibit
tailoring the ct protocol during the design phase for different
modes of operation.

Gary

> -----Original Message-----
> From: Cedric Westphal [mailto:[email-masked]]
> Sent: Tuesday, July 10, 2001 2:54 PM
> To: Pat Calhoun; [email-masked]
> Subject: Re: [seamoby] L2 API (WAS: Ext. for FMIPv6 - comments)
> 
> 
> 
> 
> Pat Calhoun wrote:
> 
> > On Tue, Jul 10, 2001 at 10:25:14AM -0700, Cedric Westphal wrote:
> > >
> > >
> > > Pat Calhoun wrote:
> > >
> > > > On Tue, Jul 10, 2001 at 08:26:29AM -0700, Cedric Westphal wrote:
> > > > > > This really comes down to the triggers available 
> for CTP, and is not
> > > > > > a CTP protocol issue.
> > > > > I do not agree with this. Let me give you an example: 
> MN wants to use
> > > > > proactive
> > > > > CT for header compression state relocation. MN moves 
> to new access router.
> > > > > If the ctp is same for proactive and reactive, then 
> MN can only _hope_ that
> > > > > the header compression state is in place. So it 
> transmits with a full header,
> > > > > and loses
> > > > > some of the benefit of the context transfer.
> > > > > If proactive and reactive ct are different (and they 
> don't necessarily have to
> > > > > be very
> > > > > different, consider just an Ack from newAR to MN via 
> oldAR that context is in
> > > > > place, or whatever, this is solution space) then MN 
> can distinguish and use
> > > > > compressed
> > > > > header right away.
> > > >
> > > > so a bit set in the CTP would inform the receiver that 
> the packet's
> > > > IP header is compressed? I'm not sure that I follow 
> your example :(
> > >
> > > Well, I did not elaborate the example since, as I said, 
> it is solution space.
> > > All I am trying to convey is that there is value in 
> knowing before, say, releasing
> > > connection
> > > to oldAR, that the C is T'ed. And thus there is a 
> difference (at least in the
> > > requirement) between proactive and reactive.
> > >
> > > >
> > > >
> > > > The MN can initiate a CTP in proactive or reactive 
> mode, but I still
> > > > think that the packet format would be identical.
> > >
> > > I agree with that. Packet format should be the same. But 
> is the ctp only a matter of
> > > defining a packet format? Or is it a ct protocol?
> > > In my little example:
> > > MN                                            oldAR
> > > newAR
> > >     will handoff to new AR-->                      
> transfer ct---->
> > >                                                           
>        <-------Ack, ct
> > > received
> > >     <----------------Ack ct there
> > >
> > > If MN is still connected to oldAR when the Ack gets back, 
> then it is proactive, and
> > > it knows it
> > > can use, say compressed header right away.
> > > If MN is not connected to oldAR when the Ack gets back, 
> then MN knows it has not
> > > received
> > > it, and by default, it is reactive, and it uses full 
> header with newAR.
> > >
> > > I agree with you that the arrow    'transfer ct---->' 
> should be the same, whether
> > > it's proactive or
> > > reactive. Now,  I am not sure it is the only arrow that is needed.
> >
> > Good, I think we are making progress.
> >
> > So, the main difference above between proactive and reactive is the
> > presence of the header compression state blob. We couldn't, however,
> > mandate that particular blobs be present in proactive vs. reactive,
> > but as we discussed earlier, could require that certain blobs be
> > defined as high priority, which would be used in the 
> initial CTP message
> > (in a multi-phasic sense) - the equivalent of proactive.
> >
> > PatC
> 
> Pat,
> 
> sorry for using a header compression example, I think it is 
> getting more confusing
> that anything. The difference between proactive vs. reactive 
> is not one of presence
> of particular blobs.
> What you mean here is a _relative_ timing of the different 
> context establishments at
> new AR, higher priority blobs arriving before lower priority 
> blobs. This is not what
> proactive vs. reactive is.
> The way I see proactive, it is an _absolute_ timing of the 
> event with respect to a time
> reference outside of the context transfer. MN wants context 
> to be in place before
> MN's packets arrive at newAR, so MN requests proactive ct. MN 
> needs to know whether
> proactive has succeeded (be it by some acknowledgement, or 
> whatever, solution space,
> later). If not, then MN can make use of this information (by 
> not getting the
> acknowledgement,
> or whatever).
> If you can do everything, proactive and reactive, with the 
> same protocol, it is fine with
> me, but
> this is a requirement phase, and I think you have a solution  
> in mind (and a
> prioritization of
> phases is only a solution to the relative ct timing problem).
> 
> Cheers,
> 
> Cedric.
> 
>

---

From: Cedric Westphal <[email-masked]>
Date: Wed, 11 Jul 2001 00:41:12 -0700

> but there is a requirement for early and almost late (proactive

Gary,

I think we agree, but I want to rephrase it just to make sure I
understand.
First, I lost track of the original point you mention. Also, I agree
that
the requirement is not on 'versions of ctp', but on the 'proactive' and
'reactive' ct. How these different requirements on 'proactive' and
'reactive'
play out when designing a protocol that satisfies these requirements is
a design issue.

> tailoring the ct protocol during the design phase for different

Then again, I think I agree, but just for clarity: I don't think the
concept of
different versions of ctp should be embedded in the draft. I do think
the
requirement on proactive and reactive should. I agree with you that
these requirements can be satisfied by different modes of operation of
the
ctp.

Here is the executive summary. Gary: yes.
Cheers,

C.