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

From: "Gary Kenward" <[email-masked]>
Date: Fri, 9 Aug 2002 10:33:19 -0400

Rajeev:

  Actually, I my point had nothing to do with the text, which I have
no problem with. I do have problems with some of the transport protocol
statements and requirements that have been put forth. The main issue is
that I see a tendency towards having a different transport for every 
feature context, with potentially different mappings for each combination 
of context and transport protocol combination. Admittedly, this is a worse
case scenario, but entropy is strong force in the internet, and if we adopt
James' view of the feature context specifications as it is written, we open
up the opportunity for CT to drift towards the worst case. 

 I understand what James was trying to do, I think, but in reading over the
proposed 5.8 requirements, I came to realize that 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. This *may* be the best approach, but this would mean
that CT is actually a suit of protocols, one for each feature. Designing and
standardizing on a collection of protocols will be more difficult, and
fraught
with risk, then designing and standardizing one protocol, at least for CT.
Implementation of a collection of protocols, feature CT and each associated
transport
protocol, would also be problematical. 

  Obviously, I believe that it is possible to convey all feature contexts
with 
one CT protocol, running over one (to be determined) transport. It may be
that
people will want the option to chose the transport protocol, but there still
only
should be one transport per network (obviously, this impacts the
interworking
capability of CT, but the wg seems to have very diverse opinions on the
appropriate
transport, and so be it).

Gary 

> -----Original Message-----
> From: Rajeev Koodli [mailto:[email-masked]]
> Sent: August 8, 2002 18:48
> To: Kenward, Gary [WDLN2:AN10:EXCH]
> Cc: 'Nakhjiri Madjid-MNAKHJI1'; 'James Kempf'; [email-masked]
> Subject: Re: [Seamoby] New Section 5.8 - Requirements on 
> Feature Context
> Sspecifications
> 
> 
> 
> Hello,
> 
> I don't know if we are debating James' intent or
> the text in 5.81. I hope it is the latter, with no disrespect
> intended. And, I think the text is fine. I see no coupling to
> specific transport protocols or option formats as Gary seems
> to be referring to. The purpose of the IANA types
> is to uniquely identify each feature context, which
> facilitates inter-operability (for instance, a receiver
> knows before it begins parsing the data fields _what_
> context it is looking at, and _how_ to process it).
> So, I am in favor of text in 5.8.1.
> 
> Regards,
> 
> -Rajeev
> 
> 
> 
> Gary Kenward wrote:
> 
> >
> >
> > Madjid:
> >
> >  I snip because the back and forth replies become long, and 
> the email
> > rejects messages over 40K (which is not as big as it might seem).
> >
> >  The text you quote does not address my concern. James used the
> > particular
> > phrase "standard option format" in a paragraph discussing context
> > transport,
> > not type codes. It is possible I misinterpreted his intent, but that
> > is
> > why I asked the question.
> >
> >  Even so, I would question the rationale of standardizing 
> the mapping
> > of type codes into option format fields of specific transport
> > protocols.
> > It implies that each transport protocol could have 
> different mappings.
> >
> > I see no advantage, and much risk in such an approach.
> >
> > Gary
> >
> > > -----Original Message-----
> > > From: Nakhjiri Madjid-MNAKHJI1 
> [mailto:[email-masked]]
> >
> > > Sent: August 8, 2002 16:57
> > > To: Kenward, Gary [WDLN2:AN10:EXCH]; Nakhjiri Madjid-MNAKHJI1;
> > 'James
> > > Kempf'; [email-masked]
> > > Subject: RE: [Seamoby] New Section 5.8 - Requirements on
> > > Feature Context
> > > S pecifications
> > >
> > >
> > > Gary,
> > >
> > > I am sorry, I think you took the "context" out of the
> > > discussion by snipping
> > > the rest of the comments :)
> > > The following text suggested by James captures the issue:
> > >
> > > Madjid
> > >
> > > > 5.8.1 A feature context specification MUST contain an IANA
> > > assigned type
> > > code
> > > > for the particular feature context. If an experimental
> > > feature context
> > > protocol
> > > > is being developed, a type code from the context transfer
> > protocol's
> > > > experimental range SHOULD be used. The type code is used in
> > > the context
> > > transfer
> > > > container to identify the feature context.
> > >
> > >
> > >
> > > -----Original Message-----
> > > From: Gary Kenward [mailto:[email-masked]]
> > > Sent: Tuesday, August 06, 2002 12:32 PM
> > > To: 'Nakhjiri Madjid-MNAKHJI1'; 'James Kempf'; [email-masked]
> > > Subject: RE: [Seamoby] New Section 5.8 - Requirements on
> > > Feature Context S
> > > pecifications
> > >
> > >
> > > Madjid:
> > > > -----Original Message-----
> > > > From: Nakhjiri Madjid-MNAKHJI1
> > > [mailto:[email-masked]]
> > > > Sent: July 22, 2002 18:56
> > > > To: 'James Kempf'; [email-masked]
> > > > Subject: RE: [Seamoby] New Section 5.8 - Requirements on
> > > > Feature Context
> > > > S pecifications
> > > >
> > > >
> > > *snip*
> > > >
> > > > If the feature context is transferred as an
> > > > option on another IETF protocol, then the feature context
> > > > specification MUST
> > > > define the mapping of the context transfer container into the
> > > > other protocol's
> > > > standard option format. If the feature context is transferred
> > > What did you mean by "standard option format"? CT, as we have
> > > been discussing it, is a container protocol, defined around
> > > context "chunks". Are you implying that it should also allow
> > > for encoding of context into the option fields of other 
> protocols???
> >
> > > Gary
> > > *snip*
> > >
> 
>

---

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

Hello Gary,

I'd like to represent another viewpoint.

>                                                The main issue is
> feature context,

How about a mapping of feature contexts into a small number of
transport protocols (e.g., UDP, TCP, SCTP, ICMP)?

>                   with potentially different mappings for each combination
> of context and transport protocol combination.

Can you be more specific about what you mean here?

>          ........                       there would be little to the
> 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.

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

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.

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

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 09:07:01 -0700

Hello Gary,

Regards,
Charlie P.