Subject: RE: [seamoby] Comments on draft-koodli-seamoby-ctv6-00.txt

From: <[email-masked]>
Date: Fri, 13 Jul 2001 18:22:33 -0500

hello Pat,

> 
> Actually, I have another comment. Figure 2, and the surrounding text,
> implies that each blob is targetted for a particular flow. However,
> what about state info that isn't flow specific? An example is some AAA
> information, which is "session based". Is that what the top "context"
> box implies? You may want to consider this in your next revision.

Indeed not all context is only flow-based. And, the top box is meant to
include all the contexts including flow-based contexts. Will add
clarification. 

Thanks for the input.

-Rajeev

> 
> PatC
> On Thu, Jul 12, 2001 at 01:47:52PM -0700, James Kempf wrote:
> > Hi Rajeev,
> > 
> > I looked over your draft and I have some comments.
> > 
> > 1) pg. 5 I like your charaterization of GTP (not the other 
> one) but the
> > idea that it consists of a type identifier and *state* variables
> > brings up a fundamental question w.r.t. context transfer. Protocols
> > usually define the interface between two different network elements.
> > State variables have to do with implementation. Isn't context
> > transfer basically asking for implementations to be exposed?
> > 
> > For example, suppose I am SuperWhizzy QoS Router manufacturer and
> > I have a router that supports the Diffserv  protocols just fine,
> > so it interoperates, but inside I have my proprietary algorithms
> > that make my router live up to its name. In order to provide state
> > transfer, would I need to expose the internals of my algorithms
> > so I could interoperate?
> > 
> > I'm not sure how to solve this problem, but I think you need to
> > clarify that these state variables aren't internals of the 
> implementation,
> > but rather protocol-specified state variables that are part of the
> > interface.
> > 
> > 2) pg. 5 What is the filter and handle alluded to in the 
> last paragraph?
> > There is not alot of detail as to what these are supposed to do.
> > 
> > 3) pg. 7 and the whole discussion of SHIN/SHAK header options. When
> > I first read this, I thought these were being defined for 
> the purpose
> > of having the MN do context transfer to the router, which 
> didn't make
> > any sense to me. After I got to Section 5, however, it became clear
> > that what you really mean is that the MN signals to the router that
> > it wants particular context to be transfered. I think you need to
> > rewrite it to make this clear (but see below for some comments on
> > the utility of the SHIN/SHAK in the first place).
> > 
> > 4) Section 4.3-4.5 I like the idea of the context transfer being an
> > extension to the HO messaging. Reduces the number of timers required
> > in the router. And it is possible in IPv6. The only issue here is
> > there has been some opinion expressed on the list that a reliable
> > transport might be a better idea for context transfer, which would
> > not be possible with ICMP extensions.
> > 
> > 5) pg. 12 - What happens if a router or MN asks for some context to
> > be transfered and it is not available?
> > 
> > 6) pg 12 - What is an unsolicited SHREP? Up until this 
> point, I don't
> > think it has been described. You may want to describe it in the
> > terminology section, or somehow earlier in the paper.
> > 
> > 7) pg. 13 Section 5.1 Actually, I think this scenario is pretty
> > unlikely for slow speed links, or, if it occurs at all, it 
> will probably occur 
> > when there is almost no traffic between the MN and the 
> network. I think
> > that any scenario where the MN has to trigger the context transfer
> > is not likely to occur when there is active traffic because 
> it will involve
> > messaging over the wireless link, which is the slowest. 
> > 
> > I think it more likely that context transfer occurs as part 
> of the HI/HACK
> > as described in Section 5.2. I don't think the MN needs to 
> signal over
> > the air to get the CT to happen (P-SHIN), I think that CT could be 
> > triggered by the need for a handover. The L2 triggers draft, which
> > should be out shortly, spells out requirements for L2 triggers to
> > support CT.
> > 
> > With faster wireless protocols, the over-the-air signaling 
> won't have
> > as much cost (but it will always have a higher cost than 
> over the wire),
> > so the option should probably be kept in, but I think for standard
> > 3G scenarios, triggering the context transfer as part of the need
> > for a handover without any over-the-air signalling is likely to be
> > much faster.
> > 
> > 		jak
> > 
> > 
>

---

From: <[email-masked]>
Date: Fri, 13 Jul 2001 19:27:42 -0500

Hello James,

thanks for your input. Got finished with this week's deadline. Please
see my comments in-line. 

Regards,

-Rajeev

> -----Original Message-----
> From: ext James Kempf [mailto:[email-masked]]
> Sent: Thursday, July 12, 2001 1:48 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Comments on draft-koodli-seamoby-ctv6-00.txt
> 
> 
> Hi Rajeev,
> 

Actually it is GPT: Generic Profile Type

> transfer basically asking for implementations to be exposed?

Well, by state variables we mean the parameters and their values that
constitute a context. For instance, header compression maintains the
Src, Dst addresses and port numbers which we refer to as state
variables.

> transfer, would I need to expose the internals of my algorithms

Obviously we do not require this. If you are willing to provide some
"additional information" we might accept it :-) (just kidding).
As I mentioned above, we only refer to those fields which are necessary
for inter-operability. In your example, the peak and committed
information rates for instance would qualify as context parameters. BTW,
we have QoS context relocation draft that we submitted to the seamoby
list that contains an enumeration of these "state variables".

> but rather protocol-specified state variables that are part of the

Ok. 

> 2) pg. 5 What is the filter and handle alluded to in the last 
> paragraph?

The filter is the [addr, port] pair perhaps with SPI. The text says
"..filter that identifies the packet stream..". The handle is an id that
identifies the particular context. For instance, the CID in HC.

> I first read this, I thought these were being defined for the purpose
> of having the MN do context transfer to the router, which didn't make

The current text mentions that these are for requesting context
transfers. If it is not clear, I will re-read it and try to revise. 

Note that SHAK is optional. The P-SHIN need not be sent at all. We think
that there is some value in including SHIN when there is a need for
explicit authorization of contexts. 
We have specified this in the idle-mode context transfer draft. We will
also revise the ctv6 draft and submit it next week.

> not be possible with ICMP extensions.

The idea is to separate context definitions from the signals that carry
the contexts. We have defined context definitions and shown how they
could be used with FMIPv6 signals, which as you know uses ICMP for HI
and HAck. 

It is entirely possible that the context definitions that we have
provided are used in other forms of messages as well. Indeed, we are
proposing that the contexts be carried in the paging message in our
recent draft.

> be transfered and it is not available?

For each context type, there is Subopt-type and Subopt-len fields. One
of the Subopt-type fields encodes that context is not available. See
draft-koodli-seamoby-hc-relocate-00.txt for details on how we do this
for HC.

We make the error known to the MN through SHAK.

> 6) pg 12 - What is an unsolicited SHREP? Up until this point, I don't

Good point. Will do.

> messaging over the wireless link, which is the slowest. 

Well, I agree to the extent that we should conserve air interface
bandwidth. If a MN attaches to the New Router which has no information
about the MN's Previous Router as well as its Previous IP address, how
can the New Router fetch the contexts ? I hope you would agree that it
is ok to send the Binding Update. SHIN, in its default form, includes
two IP addresses, and perhaps a 32-bit authentication field when
necessary and goes out along-with the BU. 

Also, what would you consider a slow-speed link ?

> as described in Section 5.2. I don't think the MN needs to signal over

We also think that P-SHIN is not required. We will revise the draft
appropriately. 
As per the CT trigger, any authentic indication to the Previous Router
should do. This indication could be network-generated. An MN-generated
indication is F-BU, and it will suffice to have a single bit in it to
trigger CT.

> With faster wireless protocols, the over-the-air signaling won't have
> as much cost (but it will always have a higher cost than over 
> the wire),

While designing IP protocols, it is good to define efficient IP messages
isn't it ? As I mentioned above, we allow for network-initiated CT which
does not require that the MN provide explicit trigger. However, if F-BU
were to be implemented, a single bit in it to trigger CT should not be
too expensive. 

Thanks for your input. We will use it in the next revision, which is due
next week!