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

From: "Gary Kenward" <[email-masked]>
Date: Fri, 9 Aug 2002 12:59:16 -0400

Charlie:

> -----Original Message-----
> From: Charles E. Perkins [mailto:[email-masked]]
> Sent: August 9, 2002 12:07
> To: Kenward, Gary [WDLN2:AN10:EXCH]
> Cc: [email-masked]
> Subject: Re: [Seamoby] New Section 5.8 - Requirements on 
> Feature Context
> Specifications
> 
> 
> 
> Hello Gary,
> 
> I'd like to represent another viewpoint.

Certainly.

> 
> > Gary Kenward wrote:
> 
> >                                                The main issue is
> > that I see a tendency towards having a different transport for every
> > feature context,
> 
> How about a mapping of feature contexts into a small number of
> transport protocols (e.g., UDP, TCP, SCTP, ICMP)?

May happen. Why make it a requirement, or imply that this is the best
solution within the requirements document? There is a debate to take
place over this issue, and we should have it, when the we start discussing
solutions. But let us not presume that it is part of the solution.

> 
> >                   with potentially different mappings for 
> each combination
> > of context and transport protocol combination.
> 
> Can you be more specific about what you mean here?

If all context is transfer as data chunks in the payload, then there really
isn't
a problem. However, if one starts mapping ct information into option fields
of various
protocols, the mappings will very likely change due to the differences in
protocol
syntax. IPv4 vs. IPv6 seems to be the most pronounced example.

> 
> >          ........                       there would be little to the
> > actual CT protocol except for a specification of the feature context
> > encapsulation format, and possibly the rules for 
> multiplexing multiple
> > feature contexts onto a give transport frame.
> 
> But that would already be quite valuable, from my perspective.

A necessary component of the total solution for CT, but definitely
only part of the answer. The real issue here is whether the CT capability is
fulfilled with a single protocol or a suite of protocols. I believe the
former is
a preferable solution, if the protocol complexity is manageable, which I
believe it
is. 

We have pretty well decided that CT capability involves at least two
protocols (above IP):
a CT containerizing protocol, and a transport protocol. Two is still better
then a gaggle
of protocols, IMHO.

> 
> > Implementation of a collection of protocols, feature CT and 
> each associated
> > transport protocol, would also be problematical.
> 
> If the transport protocols are UDP, TCP, SCTP, and ICMP, there isn't
> much problem with implementation.  Or maybe I missed your point...

Well, this assumes that the ARs have end-point stacks for all of the
transport
protocols, and management interfaces, etc. Most routers have ICMP/UDP
support.
Not sure about TCP, and I doubt SCTP.

Technically, supporting 4+/- protocols is perhaps not that big of a
deal...but
where's the value?

> 
> I think that HI and HAck from [mobile-ip] fast handovers would be
> a very suitable transport for some contexts that do not require
> rock-solid reliability, for those cases where they are available.
> I think that TCP or SCTP would be just fine for a lot of contexts
> that do require high reliability.  If we don't have HI and HAck
> available, but we have contexts with requirement for very low
> latency, then we can decide whether the contexts should be 
> encapsulated
> in ICMP, UDP, or some IP-level option.

Again, I have no problem ( at least at this point) with saying that the 
designer can run CT over one of a number of protocols, say they are UDP,
SCTP, ICMP, TCP - I do have a problem with the idea that each feature CT
will
run over different protocols. Now, instead of one context transfer, you have
at least one for each transport protocol used (assuming feature CTs that use
the same transport can be multiplexed onto one frame). This exacerbates many

issues such as transfer delay, ordering, updates synchronization, etc.

> 
> >   Obviously, I believe that it is possible to convey all 
> feature contexts with
> > one CT protocol, running over one (to be determined) transport.
> 
> I can't see this.  Some contexts have to be transferred with very
> low latency, and have low reliability requirement.  Some contexts
> have much more relaxed latency requirements, but have high reliability
> requirements.  The same transport protocol is unlikely to work for
> both.

The only reason you would separate the transports in this case is if there
was an advantage to optimizing for the "low performance" requirements. That
is,
what is the problem with delivering a feature context with a lower latency
or
higher reliability? 

There is certainly more overhead in adding a second, higher latency or lower

reliability exchange then there is in putting all the context on a transport
that met the most demanding requirements.

Usually, achieving low latency is in opposition to high reliability either
because
of the processing overhead with FEC, or the loop response latency of a BEC
(backward
error control). The total context is relatively small in terms of the number
of bytes, and the latency requirements are not sensitive to the microseconds
required
to encode and decode FEC (particularly if for proactive CT).

A number of ideas kicked around lately almost seem imply the use of CT for
state 
synchronization between ARs. I really hope this is not the case. If so, it
really
does not jibe with the vision I have of what CT is trying to accomplish,
with is a
loose, best effort approach to improving the seamlessness of handover. 

State synchronization can be done much more effectively below L3, without
the overheads
of IP+transport.

Gary

> Regards,
> Charlie P.

---

From: "Charles E. Perkins" <[email-masked]>
Date: Fri, 09 Aug 2002 16:49:03 -0700

Hello Gary,

> solution within the requirements document?

O.K.  I agree that it's not a requirement to use those protocols.
But I think that we should _expect_ that the eventual solution may
require that we make use of multiple transport protocols.

> isn't a problem. However, if one starts mapping ct information into option
> fields of various protocols, the mappings will very likely change due to the
> differences in protocol syntax. IPv4 vs. IPv6 seems to be the most pronounced
> example.

I'm happy to model context as data, not option fields.
However, it could be (e.g., in the case of QoS) that the
context affects the fields of various protocols.  In fact,
taken abstractly, all the cases I care about can be modeled
as affecting some fields of some protocol's data fields.
This is even true for buffering, and security contexts, right?

>                     The real issue here is whether the CT capability is
> fulfilled with a single protocol or a suite of protocols. I believe the former
> is a preferable solution, if the protocol complexity is manageable, which I
> believe it is.

Again, I'm happy if there can be a single solution.  But, if I were
given the choice of ICMP for some contexts, and TCP for others, vs.
waiting two more years for XCTTP (unknown context transfer transport
protocol), I'd go for using two transports.

> We have pretty well decided that CT capability involves at least two protocols
> (above IP): a CT containerizing protocol, and a transport protocol.
> Two is still better then a gaggle of protocols, IMHO.

What's a containerizing protocol?  Can't we just have data formats
without having to do distributing processing to collect the data?
Gaggle is, by the way, a great word.  Is ICMP plus TCP approximately
equal to, or less than, a gaggle?

> Well, this assumes that the ARs have end-point stacks for all of the transport
> protocols, and management interfaces, etc. Most routers have ICMP/UDP support.

> Technically, supporting 4+/- protocols is perhaps not that big of a deal...but
> where's the value?

As I mentioned above, if you can make a single protocol do it, I'll
be happy (still wondering about that containerizing, though).

>> encapsulated in ICMP, UDP, or some IP-level option.
> 
> SCTP, ICMP, TCP - I do have a problem with the idea that each feature CT will

I can see a simple solution for this:

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
   compatible with the chosen transport.  If the chosen transport
   is not a reliable transport, schedule a retransmission if any
   context transfer requires acknowledgement.

2. If there are any contexts left, goto (1).

timeout(retransmission_timer) {
	retransmit the packet;
	if (not-enough-retries-yet) {
		schedule_another_retransmission();
	}
}

process_ack {
	delete_retransmission_timeout();
}

> is, what is the problem with delivering a feature context with a lower
> latency or higher reliability?

How do you like my high-level example above?   It's an example, not an
attempt to enforce a particular solution.  Of course there are a huge
number of details omitted, like what the receving AR does with the
various kinds of features, but those are straightforward details.

Regards,
Charlie P.

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

---

From: "Charles E. Perkins" <[email-masked]>
Date: Fri, 09 Aug 2002 16:49:03 -0700

Hello Gary,

process_ack {

Regards,
Charlie P.