Re: [Seamoby] Comment on CTP-09

"James Kempf" <kempf@docomolabs-usa.com> Wed, 05 May 2004 01:46 UTC

Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA14111 for <seamoby-archive@odin.ietf.org>; Tue, 4 May 2004 21:46:48 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLBTC-0007iH-PN for seamoby-archive@odin.ietf.org; Tue, 04 May 2004 21:45:11 -0400
Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i451jAG3029649 for seamoby-archive@odin.ietf.org; Tue, 4 May 2004 21:45:10 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLBPI-0006rb-9h for seamoby-web-archive@optimus.ietf.org; Tue, 04 May 2004 21:41:08 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA13907 for <seamoby-web-archive@ietf.org>; Tue, 4 May 2004 21:41:05 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BLBPF-0003iG-Fp for seamoby-web-archive@ietf.org; Tue, 04 May 2004 21:41:05 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLBOF-0003ad-00 for seamoby-web-archive@ietf.org; Tue, 04 May 2004 21:40:03 -0400
Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BLBNL-0003TB-00 for seamoby-web-archive@ietf.org; Tue, 04 May 2004 21:39:07 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLBIP-0004mu-Sk; Tue, 04 May 2004 21:34:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLBC5-00031r-0h for seamoby@optimus.ietf.org; Tue, 04 May 2004 21:27:29 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA13219 for <seamoby@ietf.org>; Tue, 4 May 2004 21:27:25 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BLBC2-0001d2-70 for seamoby@ietf.org; Tue, 04 May 2004 21:27:26 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLBBG-0001TL-00 for seamoby@ietf.org; Tue, 04 May 2004 21:26:39 -0400
Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx with esmtp (Exim 4.12) id 1BLBAK-0001Ie-00 for seamoby@ietf.org; Tue, 04 May 2004 21:25:40 -0400
Message-ID: <025001c4323f$f41323c0$366115ac@dcml.docomolabsusa.com>
From: James Kempf <kempf@docomolabs-usa.com>
To: Nakhjiri Madjid-MNAKHJI1 <Madjid.Nakhjiri@motorola.com>, hannu.flinck@nokia.com, seamoby@ietf.org
References: <EBF631554F9CD7118D0B00065BF34DCB03D2AB35@il27exm03.cig.mot.com>
Subject: Re: [Seamoby] Comment on CTP-09
Date: Tue, 04 May 2004 18:26:11 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: seamoby-admin@ietf.org
Errors-To: seamoby-admin@ietf.org
X-BeenThere: seamoby@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/seamoby>, <mailto:seamoby-request@ietf.org?subject=unsubscribe>
List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting <seamoby.ietf.org>
List-Post: <mailto:seamoby@ietf.org>
List-Help: <mailto:seamoby-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/seamoby>, <mailto:seamoby-request@ietf.org?subject=subscribe>
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org
X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

Madjid,

As John Loughney mentioned, unless there is at least one transport protocol
that is a MUST, there is a risk of an interoperability problem. Some people
don't care about transport and just want to use something that will give
them interoperability, so they can do experiments in other areas. The MUST
is for them.

In addition, the document says MAY for other transport protocols, for those
people who want to experiment specifically with transport protocols. Maybe
this needs to be made clearer?

Would that be sufficient to address your concerns?

            jak

----- Original Message ----- 
From: "Nakhjiri Madjid-MNAKHJI1" <Madjid.Nakhjiri@motorola.com>
To: <hannu.flinck@nokia.com>; <seamoby@ietf.org>
Sent: Tuesday, May 04, 2004 1:45 PM
Subject: RE: [Seamoby] Comment on CTP-09


> I don't think implementing CTP over ICMP should be a MUST.
>  None of the transport protocols were supposed to MUSTs.
>
> Madjid
>
> -----Original Message-----
> From: seamoby-admin@ietf.org [mailto:seamoby-admin@ietf.org]On Behalf Of
> hannu.flinck@nokia.com
> Sent: Monday, May 03, 2004 5:18 AM
> To: seamoby@ietf.org
> Subject: [Seamoby] Comment on CTP-09
>
>
> Hello
>
> As the final reviewed period is ongoing, I would like to provide following
comments to the CTP spec.
> The CTP draft states about the MN-AR transport the following:
>
> Comment 1:
>
> "3.2 MN-AR Transport
>
> The MN-AR interface MUST implement and SHOULD use ICMP for transport of
the CTAR and CTAA messages.
>   :
>   :
> Because ICMP contains no provisions for retransmitting packets if
signaling is lost, the CARD protocol incorporates
> provisions for improving transport performance on the MN-AR interface...."
>
> It is unclear to the reader why CARD protocol is referenced at this point?
Is the intention to imply piggybacking of CTP and CARD over this interface?
Plane provision of retransmission doesn't seem to be the motivation since
the CTP draft contains already similar retransmission enhancement to CARD:
>
> " CTAR messages for which a response is requested which fail to elicit a
response are retransmitted.  The initial retransmission
>    occurs after a CTP_REQUEST_RETRY wait period. Retransmissions MUST be
made with exponentially increasing wait intervals (doubling the
>    wait each time).  CTAR messages should be retransmitted until ether a
response (which might be an error) has been obtained, or
>    for CTP_RETRY_MAX seconds occurs."
>
> In  the CARD draft, section 4.4, there is identical method provided.
Hardly the intention is to run double retransmission scheme. So, it appears
that the CTP is self-contained regarding to the retransmission and doesn't
require any implementation of CARD to be functional. Right?
>
> Suggestion:
>
> - either to remove the reference to CARD, or add wording to explain what
is meant by the CARD reference.
>
> Comment 2 (minor/editorial) to section 2.5.1
>
> The MN MUST sent the sequence number to the same value for the message
sent on both pAR and nAR so pAR can determine whether to use a cached
message.
>
> change to
> => The MN MUST set the sequence number  ....
>
>
> Regards Hannu
>
> _______________________________________________
> Seamoby mailing list
> Seamoby@ietf.org
> https://www1.ietf.org/mailman/listinfo/seamoby
>
> _______________________________________________
> Seamoby mailing list
> Seamoby@ietf.org
> https://www1.ietf.org/mailman/listinfo/seamoby
>



_______________________________________________
Seamoby mailing list
Seamoby@ietf.org
https://www1.ietf.org/mailman/listinfo/seamoby