From mailman-owner@ietf.org Mon Jul 1 06:03:02 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA18119 for ; Mon, 1 Jul 2002 06:03:02 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA28402 for ; Mon, 1 Jul 2002 06:03:49 -0400 (EDT) Date: Mon, 1 Jul 2002 06:03:49 -0400 (EDT) Message-Id: <200207011003.GAA28402@optimus.ietf.org> From: mailman-owner@ietf.org Subject: ietf.org mailing list memberships reminder To: seamoby-archive@ietf.org X-No-Archive: yes Precedence: bulk X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol This is a reminder, sent out once a month, about your ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, seamoby-request@ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. ****************************************************************** Note Well All statements related to the activities of the IETF and addressed to the IETF are subject to all provisions of Section 10 of RFC 2026, which grants to the IETF and its participants certain licenses and rights in such statements. Such statements include verbal statements in IETF meetings, as well as written and electronic communications made at any time or place, which are addressed to * the IETF plenary session, * any IETF working group or portion thereof, * the IESG, or any member thereof on behalf of the IESG, * the IAB or any member thereof on behalf of the IAB, * any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, * the RFC Editor or the Internet-Drafts function Statements made outside of an IETF meeting, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not subject to these provisions. ****************************************************************** If you have questions, problems, comments, etc, send them to mailman-owner@ietf.org. Thanks! Passwords for seamoby-archive@lists.ietf.org: List Password // URL ---- -------- seamoby@ietf.org Zzch https://www1.ietf.org/mailman/options/seamoby/seamoby-archive@lists.ietf.org From seamoby-admin@ietf.org Mon Jul 1 15:06:58 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26800 for ; Mon, 1 Jul 2002 15:06:58 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA00748; Mon, 1 Jul 2002 14:57:08 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA00707 for ; Mon, 1 Jul 2002 14:57:05 -0400 (EDT) Received: from sender ([218.2.158.75]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA26005 for ; Mon, 1 Jul 2002 14:56:15 -0400 (EDT) From: cbonus@europe.com Message-Id: <200207011856.OAA26005@ietf.org> Reply-To: cbonus@europe.com To: seamoby@ietf.org Mime-Version: 1.0 Content-Type: text/html; charset="GB2312_CHARSET" Date: Tue, 2 Jul 2002 02:53:37 +0800 Subject: [Seamoby] 83 million mega lotto could hit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Mon Jul 1 15:06:59 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26812 for ; Mon, 1 Jul 2002 15:06:58 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA02392 for seamoby-archive@odin.ietf.org; Mon, 1 Jul 2002 15:07:47 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA00748; Mon, 1 Jul 2002 14:57:08 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA00707 for ; Mon, 1 Jul 2002 14:57:05 -0400 (EDT) Received: from sender ([218.2.158.75]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA26005 for ; Mon, 1 Jul 2002 14:56:15 -0400 (EDT) From: cbonus@europe.com Message-Id: <200207011856.OAA26005@ietf.org> Reply-To: cbonus@europe.com To: seamoby@ietf.org Mime-Version: 1.0 Content-Type: text/html; charset="GB2312_CHARSET" Date: Tue, 2 Jul 2002 02:53:37 +0800 Subject: [Seamoby] 83 million mega lotto could hit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Tue Jul 2 09:03:42 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07274 for ; Tue, 2 Jul 2002 09:03:42 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA08763; Tue, 2 Jul 2002 08:59:30 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA08727 for ; Tue, 2 Jul 2002 08:59:28 -0400 (EDT) Received: from server1.chicagoline.com (162.mufc.chcg.chcgil24.dsl.att.net [12.100.5.162]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07033; Tue, 2 Jul 2002 08:58:37 -0400 (EDT) Message-Id: <200207021258.IAA07033@ietf.org> Received: from smtp0532.mail.yahoo.com (MAZQNH-HQ [61.142.238.123]) by server1.chicagoline.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id L50FHV1T; Tue, 2 Jul 2002 07:47:34 -0500 Date: Tue, 2 Jul 2002 21:01:13 +0800 From: "Connie Kondo" X-Priority: 3 To: seamo27@yahoo.com CC: seamoby-request@ietf.org, seamoby@ietf.org Mime-Version: 1.0 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Seamoby] seamo27,Fibromyalgia? We can help! Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit
Hello, seamo27@yahoo.com

Human Growth Hormone Therapy

Lose weight while building lean muscle mass
and reversing the ravages of aging all at once.
Remarkable discoveries about Human Growth Hormones (HGH)
are changing the way we think about aging and weight loss.

Lose Weight
Build Muscle Tone
Reverse Aging
Increased Libido
Duration Of Penile Erection

Healthier Bones
Improved Memory
Improved skin
New Hair Growth
Wrinkle Disappearance

Visit Our Web Site and Learn The Facts : Click Here

OR Here


You are receiving this email as a subscriber
to the Opt-In America Mailing List.
To remove yourself from all related maillists,
just Click Here
_______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Tue Jul 2 09:03:43 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07286 for ; Tue, 2 Jul 2002 09:03:43 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA09514 for seamoby-archive@odin.ietf.org; Tue, 2 Jul 2002 09:04:33 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA08763; Tue, 2 Jul 2002 08:59:30 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA08727 for ; Tue, 2 Jul 2002 08:59:28 -0400 (EDT) Received: from server1.chicagoline.com (162.mufc.chcg.chcgil24.dsl.att.net [12.100.5.162]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07033; Tue, 2 Jul 2002 08:58:37 -0400 (EDT) Message-Id: <200207021258.IAA07033@ietf.org> Received: from smtp0532.mail.yahoo.com (MAZQNH-HQ [61.142.238.123]) by server1.chicagoline.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id L50FHV1T; Tue, 2 Jul 2002 07:47:34 -0500 Date: Tue, 2 Jul 2002 21:01:13 +0800 From: "Connie Kondo" X-Priority: 3 To: seamo27@yahoo.com CC: seamoby-request@ietf.org, seamoby@ietf.org Mime-Version: 1.0 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Seamoby] seamo27,Fibromyalgia? We can help! Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit
Hello, seamo27@yahoo.com

Human Growth Hormone Therapy

Lose weight while building lean muscle mass
and reversing the ravages of aging all at once.
Remarkable discoveries about Human Growth Hormones (HGH)
are changing the way we think about aging and weight loss.

Lose Weight
Build Muscle Tone
Reverse Aging
Increased Libido
Duration Of Penile Erection

Healthier Bones
Improved Memory
Improved skin
New Hair Growth
Wrinkle Disappearance

Visit Our Web Site and Learn The Facts : Click Here

OR Here


You are receiving this email as a subscriber
to the Opt-In America Mailing List.
To remove yourself from all related maillists,
just Click Here
_______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Jul 3 06:35:07 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04284 for ; Wed, 3 Jul 2002 06:35:07 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA26218; Wed, 3 Jul 2002 06:29:48 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA26191 for ; Wed, 3 Jul 2002 06:29:45 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03487; Wed, 3 Jul 2002 06:28:55 -0400 (EDT) Message-Id: <200207031028.GAA03487@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: seamoby@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Wed, 03 Jul 2002 06:28:55 -0400 Subject: [Seamoby] I-D ACTION:draft-funato-seamoby-gaard-01.txt Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Geographically Adjacent Access Router Discovery Protocol Author(s) : D. Funato et al. Filename : draft-funato-seamoby-gaard-01.txt Pages : 18 Date : 02-Jul-02 This document describes a scheme that allows a node to determine an IP address corresponding to a given link-layer id. The node performing the query doesn't need to be on the same link or subnet of the node associated with the link-layer id. This scheme was designed for the handoff candidate access router discovery in wireless networks, but may also be applied to other networks with similar behavior. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-funato-seamoby-gaard-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-funato-seamoby-gaard-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-funato-seamoby-gaard-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020702151205.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-funato-seamoby-gaard-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-funato-seamoby-gaard-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020702151205.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Wed Jul 3 06:35:08 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04293 for ; Wed, 3 Jul 2002 06:35:08 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id GAA28172 for seamoby-archive@odin.ietf.org; Wed, 3 Jul 2002 06:35:56 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA26218; Wed, 3 Jul 2002 06:29:48 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA26191 for ; Wed, 3 Jul 2002 06:29:45 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03487; Wed, 3 Jul 2002 06:28:55 -0400 (EDT) Message-Id: <200207031028.GAA03487@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: seamoby@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Wed, 03 Jul 2002 06:28:55 -0400 Subject: [Seamoby] I-D ACTION:draft-funato-seamoby-gaard-01.txt Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Geographically Adjacent Access Router Discovery Protocol Author(s) : D. Funato et al. Filename : draft-funato-seamoby-gaard-01.txt Pages : 18 Date : 02-Jul-02 This document describes a scheme that allows a node to determine an IP address corresponding to a given link-layer id. The node performing the query doesn't need to be on the same link or subnet of the node associated with the link-layer id. This scheme was designed for the handoff candidate access router discovery in wireless networks, but may also be applied to other networks with similar behavior. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-funato-seamoby-gaard-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-funato-seamoby-gaard-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-funato-seamoby-gaard-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020702151205.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-funato-seamoby-gaard-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-funato-seamoby-gaard-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020702151205.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Fri Jul 5 08:28:59 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21729 for ; Fri, 5 Jul 2002 08:28:59 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA28507; Fri, 5 Jul 2002 08:27:08 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA28477 for ; Fri, 5 Jul 2002 08:27:06 -0400 (EDT) Received: from ab17c1758.com (63-109-249-162.newskies.net [63.109.249.162] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA21582 for ; Fri, 5 Jul 2002 08:26:12 -0400 (EDT) Message-Id: <200207051226.IAA21582@ietf.org> From: "Pedro Savimbi" Reply-To: pedroangola2002@netscape.net To: seamoby@ietf.org Date: Fri, 5 Jul 2002 13:27:54 +0200 X-Mailer: Microsoft Outlook Express 5.00.2919.6900 DM MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id IAA28478 Subject: [Seamoby] My family needs help Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 8bit From: Pedro Savimbi This letter may come to you as a surprise due to the fact that we have not yet met. The message could be strange but real if you pay some attention to it. I could have notified you about it at least for the sake of your integrity. Please accept my sincere apologies. In bringing this message of goodwill to you, I have to say that I have no intentions of causing you any pains. I am Mr. Pedro Savimbi, son of the late rebel leader Jonas Savimbi of Angola who was killed on the 22nd of February 2002 . I managed to get your contact details through the internet myself Time is of the importance and I was desperately looking for a person to assist me in this confidential business. My late father, Jonas Savimbi was able to deposit a large sum of money in different security firms in Europe and Ghana. My father is presently death and the movement of his family members (including me) is restricted. We are forbidden to either travel abroad or out of our localities. Presently our movement are monitored. Right now there is a rush for all my Father's wealth but home and Abroad by the Government who are claiming that most of the wealth was got by Arms smuggling and therefore illegal and by my father,s extended family and relations. You can know more about my father by checking his profile at URL below: www.kwacha.com/edoc2.htm His wealth has been estimated to be $500 million to over $1 billion and being close to my father I happen to be in possession of documents and information of some of the wealth.Approx. $250 million and only my trusted mother knows that I have this information. Presently, the US$100,000,000.00 (One Hundred Million Dollars) cash and precious materials my father moved to Ghana before his death is deposited with some security firm . Before you can get access to it I have to give you the some hits. I am therefore soliciting your help to travel to Ghana in west Africa to recieve this money and transfer into your account before my government get wind of this fund .You know my father was a rebel leader in Angola before his death. My reason for doing this is because it will be difficult for the Angolan government to trace my father's money to an individual's account, especially when such an individual has no relationship,I decided to keep that money for my family use. At present the money is kept with some Security Companies in Ghana I am currently and temporarily living in Angola and as refugee status,I intend to communication with you as regards this transaction on a satellite phone to avoid intervention by anybody. Moreover, the political climate in Angola at the moment being so sensitive and unstable.With this password and information and I will send you a power of attorney to the security firm, When you are ready I will give you the information needed before you can get access to 7,000kg of AU gold dust, 8500kg of pure Diamond and raw cash of USD100 million America dollars. you will then proceed to Ghana for collection. PLEASE YOUR CONFIDENTIALITY IN THIS TRANSACTION IS HIGHLY REQUIRED. Yours sincerely, Pedro Savimbi. _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Fri Jul 5 08:29:00 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21738 for ; Fri, 5 Jul 2002 08:29:00 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA28594 for seamoby-archive@odin.ietf.org; Fri, 5 Jul 2002 08:29:50 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA28507; Fri, 5 Jul 2002 08:27:08 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA28477 for ; Fri, 5 Jul 2002 08:27:06 -0400 (EDT) Received: from ab17c1758.com (63-109-249-162.newskies.net [63.109.249.162] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA21582 for ; Fri, 5 Jul 2002 08:26:12 -0400 (EDT) Message-Id: <200207051226.IAA21582@ietf.org> From: "Pedro Savimbi" Reply-To: pedroangola2002@netscape.net To: seamoby@ietf.org Date: Fri, 5 Jul 2002 13:27:54 +0200 X-Mailer: Microsoft Outlook Express 5.00.2919.6900 DM MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id IAA28478 Subject: [Seamoby] My family needs help Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 8bit From: Pedro Savimbi This letter may come to you as a surprise due to the fact that we have not yet met. The message could be strange but real if you pay some attention to it. I could have notified you about it at least for the sake of your integrity. Please accept my sincere apologies. In bringing this message of goodwill to you, I have to say that I have no intentions of causing you any pains. I am Mr. Pedro Savimbi, son of the late rebel leader Jonas Savimbi of Angola who was killed on the 22nd of February 2002 . I managed to get your contact details through the internet myself Time is of the importance and I was desperately looking for a person to assist me in this confidential business. My late father, Jonas Savimbi was able to deposit a large sum of money in different security firms in Europe and Ghana. My father is presently death and the movement of his family members (including me) is restricted. We are forbidden to either travel abroad or out of our localities. Presently our movement are monitored. Right now there is a rush for all my Father's wealth but home and Abroad by the Government who are claiming that most of the wealth was got by Arms smuggling and therefore illegal and by my father,s extended family and relations. You can know more about my father by checking his profile at URL below: www.kwacha.com/edoc2.htm His wealth has been estimated to be $500 million to over $1 billion and being close to my father I happen to be in possession of documents and information of some of the wealth.Approx. $250 million and only my trusted mother knows that I have this information. Presently, the US$100,000,000.00 (One Hundred Million Dollars) cash and precious materials my father moved to Ghana before his death is deposited with some security firm . Before you can get access to it I have to give you the some hits. I am therefore soliciting your help to travel to Ghana in west Africa to recieve this money and transfer into your account before my government get wind of this fund .You know my father was a rebel leader in Angola before his death. My reason for doing this is because it will be difficult for the Angolan government to trace my father's money to an individual's account, especially when such an individual has no relationship,I decided to keep that money for my family use. At present the money is kept with some Security Companies in Ghana I am currently and temporarily living in Angola and as refugee status,I intend to communication with you as regards this transaction on a satellite phone to avoid intervention by anybody. Moreover, the political climate in Angola at the moment being so sensitive and unstable.With this password and information and I will send you a power of attorney to the security firm, When you are ready I will give you the information needed before you can get access to 7,000kg of AU gold dust, 8500kg of pure Diamond and raw cash of USD100 million America dollars. you will then proceed to Ghana for collection. PLEASE YOUR CONFIDENTIALITY IN THIS TRANSACTION IS HIGHLY REQUIRED. Yours sincerely, Pedro Savimbi. _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Fri Jul 5 10:45:23 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27606 for ; Fri, 5 Jul 2002 10:45:23 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA05744; Fri, 5 Jul 2002 10:39:30 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA05678 for ; Fri, 5 Jul 2002 10:39:25 -0400 (EDT) Received: from zcars04f.ca.nortel.com (zcars04f.nortelnetworks.com [47.129.242.57]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27359; Fri, 5 Jul 2002 10:38:29 -0400 (EDT) Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04f.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g65EYc306653; Fri, 5 Jul 2002 10:34:38 -0400 (EDT) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 5 Jul 2002 10:34:37 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA4BDA@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'Hancock, Robert'" , "'brunner@ccrle.nec.de'" , john.loughney@nokia.com, cedric@iprg.nokia.com, erafodo@ESEALNT448.al.sw.ericsson.se Cc: nsis@ietf.org, Hemant.Chaskar@nokia.com, "'seamoby@ietf.org'" Date: Fri, 5 Jul 2002 10:34:34 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C22431.15039930" Subject: [Seamoby] RE: what is edge signalling? (was: RE: [NSIS] Re: Comments on dra ft-westphal-nsis-qos-mobileip-00.txt) Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C22431.15039930 Content-Type: text/plain; charset="iso-8859-1" Robert: In your discussion of CT, you are presupposing a wg solution for CT that does not exist. The work on the CT protocol has not begun in Seamoby. Indeed, if you examine the CT requirements, signalling from the MN to the access network is prohibited. The reason being is that the sole purpose of CT is to enable a fast, smooth, seamless handover. Signalling over the air simply takes too much time, and the value of signalling from MN to AR has never been clearly identified. This issue was debated extensively in the CT design group and on the Seamoby list. I understand that there are people who feel otherwise, and please, let's not regurgitate the arguments here. As the requirements currently stand, CT is an AR to AR protocol. One source of confusion might be the work on the discovery protocol. It is my, admittedly minority opinion, that the use of MN to AR signalling to perform CT was moved into the discovery solution. And again, nothing can be done between the MN and an AR that cannot be done more efficiently, and faster, between two ARs. The way I see the directions of the two solutions lining up so far, NSIS and CT have little interaction. NSIS could be invoked if a CT attempt fails, but the restriction to have NSIS along the path implies that some path must exist before NSIS can be invoked. Thus, NSIS can be used only *after* a handover has completed, and thus there is no opportunity for interaction. Of course, all of this depends on what you define as a "path" - I am assuming that it is the IP forwarding path for the MNs bearer traffic. gary > -----Original Message----- > From: Hancock, Robert [mailto:robert.hancock@roke.co.uk] > Sent: July 5, 2002 05:35 > To: 'brunner@ccrle.nec.de'; john.loughney@nokia.com; > cedric@iprg.nokia.com; erafodo@ESEALNT448.al.sw.ericsson.se > Cc: nsis@ietf.org; Hemant.Chaskar@nokia.com > Subject: RE: what is edge signalling? (was: RE: [NSIS] Re: Comments on > dra ft-westphal-nsis-qos-mobileip-00.txt) > > > Hi all, > > I don't think there's any disagreement that CT is a tool that > NSIS could use (as an optimisation). > > What's entirely unclear to me is what sort of tool CT is: is > it a hammer or a screwdriver or a combination of the two? I > guess this is more a question for the seamoby people, but we > need to know the answer to know how to use it. > > More formally, there seem to be two extremes: > > a) NSIS is used for MN-AR resource (QoS) signalling, and > AR-rest of world signalling; CT can be used to transfer state > (both resource state and NSIS protocol state) between ARs at > handover, but if this involves any MN-AR messages (e.g. CTIN) > they aren't QoS related. NSIS-CT interaction can occur at the > ARs to do state transfer at handover time. > > b) CT messages (e.g. CIN) can be used by the MN to set up QoS > context in the AR, which it can then later transfer to a new > AR. NSIS is used to signal QoS for AR-rest of network. > NSIS-CT interaction takes place at the AR to interwork flow > setup and resource descriptions, and this interaction takes > place at flow setup time. (Essentially, CT provides a QoS > signalling protocol for the edge of the network, which NSIS > would have to interwork with, in the same way that it has to > interwork with RSVP/Intserv.) > > our framework draft-hancock-nsis-fw-00.txt basically assumes (a). > this draft-westphal-nsis-qos-mobileip-00.txt basically > assumes (b) so far as I can tell. > > I'm not trying to argue which of (a) or (b) is 'correct' at > this stage, just establish that they are not the same. (And > so we probably have to make a choice, although I suppose you > could allow both models...) > > Cheers, > > Robert H. > > > -----Original Message----- > > From: Marcus Brunner [mailto:brunner@ccrle.nec.de] > > Sent: 05 July 2002 10:05 > > To: john.loughney@nokia.com; Hancock, Robert; cedric@iprg.nokia.com; > > erafodo@ESEALNT448.al.sw.ericsson.se > > Cc: nsis@ietf.org; Hemant.Chaskar@nokia.com > > Subject: RE: what is edge signalling? (was: RE: [NSIS] Re: > Comments on > > draft-westphal-nsis-qos-mobileip-00.txt) > > > > > > I see CT as an optimization only and not required for NSIS. > > However, since > > there is a tendency to support only on-path signaling, this > > would not work > > anyway (because CT would need off-path signaling for at least > > some time). > > > > Marcus > > > > --On Donnerstag, 4. Juli 2002 11:33 +0300 > > john.loughney@nokia.com wrote: > > > > > Hi Robert, > > > > > >> On the 'edge signalling' case, I guess the main point is that > > >> I'm confused about the scope of seamoby CT. Specifically > > >> regarding MN-AR signalling (no issue about the AR-AR part): > > > > > > From my viewpoint, CT is not required for NSIS. I view CT as > > > one tool that an NSIS solution could use. So, I definately think > > > that at some point, we will need some sort of applicability > > > statement describing how to use CT for NSIS. > > > > > > John > > > > > > _______________________________________________ > > > nsis mailing list > > > nsis@ietf.org > > > https://www1.ietf.org/mailman/listinfo/nsis > > > > > > > > -------------------------------------- > > Dr. Marcus Brunner > > Network Laboratories > > NEC Europe Ltd. > > > > E-Mail: brunner@ccrle.nec.de > > WWW: http://www.ccrle.nec.de/ > > personal home page: http://www.brubers.org/marcus > > > > > ============================================================== > ========================== > Permission is hereby granted to pass the contents of this > communication to third parties and any restrictions regarding > confidentiality do not apply. > ------_=_NextPart_001_01C22431.15039930 Content-Type: text/html; charset="iso-8859-1" RE: what is edge signalling? (was: RE: [NSIS] Re: Comments on dra ft-westphal-nsis-qos-mobileip-00.txt)

Robert:

  In your discussion of CT, you are presupposing a wg solution
for CT that does not exist. The work on the CT protocol has not begun
in Seamoby. Indeed, if you examine the CT requirements,
signalling from the MN to the access network is prohibited. The
reason being is that the sole purpose of CT is to enable a fast, smooth,
seamless handover. Signalling over the air simply takes too much time,
and the value of signalling from MN to AR has never been clearly identified.

  This issue was debated extensively in the CT design group and on
the Seamoby list. I understand that there are people who feel otherwise,
and please, let's not regurgitate the arguments here. As the requirements
currently stand, CT is an AR to AR protocol.

  One source of confusion might be the work on the discovery protocol.
It is my, admittedly minority opinion, that the use of MN to AR signalling
to perform CT was moved into the discovery solution. And again, nothing
can be done between the MN and an AR that cannot be done more efficiently,
and faster, between two ARs.

  The way I see the directions of the two solutions lining up so far,
NSIS and CT have little interaction. NSIS could be invoked if a CT attempt
fails, but the restriction to have NSIS along the path implies that some
path must exist before NSIS can be invoked. Thus, NSIS can be used only
*after* a handover has completed, and thus there is no opportunity for
interaction. Of course, all of this depends on what you define as a "path"
- I am assuming that it is the IP forwarding path for the MNs bearer traffic.


gary

> -----Original Message-----
> From: Hancock, Robert [mailto:robert.hancock@roke.co.uk]
> Sent: July 5, 2002 05:35
> To: 'brunner@ccrle.nec.de'; john.loughney@nokia.com;
> cedric@iprg.nokia.com; erafodo@ESEALNT448.al.sw.ericsson.se
> Cc: nsis@ietf.org; Hemant.Chaskar@nokia.com
> Subject: RE: what is edge signalling? (was: RE: [NSIS] Re: Comments on
> dra ft-westphal-nsis-qos-mobileip-00.txt)
>
>
> Hi all,
>
> I don't think there's any disagreement that CT is a tool that
> NSIS could use (as an optimisation).
>
> What's entirely unclear to me is what sort of tool CT is: is
> it a hammer or a screwdriver or a combination of the two? I
> guess this is more a question for the seamoby people, but we
> need to know the answer to know how to use it.
>
> More formally, there seem to be two extremes:
>
> a) NSIS is used for MN-AR resource (QoS) signalling, and
> AR-rest of world signalling; CT can be used to transfer state
> (both resource state and NSIS protocol state) between ARs at
> handover, but if this involves any MN-AR messages (e.g. CTIN)
> they aren't QoS related. NSIS-CT interaction can occur at the
> ARs to do state transfer at handover time.
>
> b) CT messages (e.g. CIN) can be used by the MN to set up QoS
> context in the AR, which it can then later transfer to a new
> AR. NSIS is used to signal QoS for AR-rest of network.
> NSIS-CT interaction takes place at the AR to interwork flow
> setup and resource descriptions, and this interaction takes
> place at flow setup time. (Essentially, CT provides a QoS
> signalling protocol for the edge of the network, which NSIS
> would have to interwork with, in the same way that it has to
> interwork with RSVP/Intserv.)
>
> our framework draft-hancock-nsis-fw-00.txt basically assumes (a).
> this draft-westphal-nsis-qos-mobileip-00.txt basically
> assumes (b) so far as I can tell.
>
> I'm not trying to argue which of (a) or (b) is 'correct' at
> this stage, just establish that they are not the same. (And
> so we probably have to make a choice, although I suppose you
> could allow both models...)
>
> Cheers,
>
> Robert H.
>
> > -----Original Message-----
> > From: Marcus Brunner [mailto:brunner@ccrle.nec.de]
> > Sent: 05 July 2002 10:05
> > To: john.loughney@nokia.com; Hancock, Robert; cedric@iprg.nokia.com;
> > erafodo@ESEALNT448.al.sw.ericsson.se
> > Cc: nsis@ietf.org; Hemant.Chaskar@nokia.com
> > Subject: RE: what is edge signalling? (was: RE: [NSIS] Re:
> Comments on
> > draft-westphal-nsis-qos-mobileip-00.txt)
> >
> >
> > I see CT as an optimization only and not required for NSIS.
> > However, since
> > there is a tendency to support only on-path signaling, this
> > would not work
> > anyway (because CT would need off-path signaling for at least
> > some time).
> >
> > Marcus
> >
> > --On Donnerstag, 4. Juli 2002 11:33 +0300
> > john.loughney@nokia.com wrote:
> >
> > > Hi Robert,
> > >
> > >> On the 'edge signalling' case, I guess the main point is that
> > >> I'm confused about the scope of seamoby CT. Specifically
> > >> regarding MN-AR signalling (no issue about the AR-AR part):
> > >
> > > From my viewpoint, CT is not required for NSIS. I view CT as
> > > one tool that an NSIS solution could use.  So, I definately think
> > > that at some point, we will need some sort of applicability
> > > statement describing how to use CT for NSIS.
> > >
> > > John
> > >
> > > _______________________________________________
> > > nsis mailing list
> > > nsis@ietf.org
> > > https://www1.ietf.org/mailman/listinfo/nsis
> >
> >
> >
> > --------------------------------------
> > Dr. Marcus Brunner
> > Network Laboratories
> > NEC Europe Ltd.
> >
> > E-Mail: brunner@ccrle.nec.de
> > WWW:    http://www.ccrle.nec.de/
> > personal home page: http://www.brubers.org/marcus
> >
> >
> ==============================================================
> ==========================
> Permission is hereby granted to pass the contents of this
> communication to third parties and any restrictions regarding
> confidentiality do not apply.
>

------_=_NextPart_001_01C22431.15039930-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Fri Jul 5 10:45:24 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27614 for ; Fri, 5 Jul 2002 10:45:23 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA05962 for seamoby-archive@odin.ietf.org; Fri, 5 Jul 2002 10:46:15 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA05744; Fri, 5 Jul 2002 10:39:30 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA05678 for ; Fri, 5 Jul 2002 10:39:25 -0400 (EDT) Received: from zcars04f.ca.nortel.com (zcars04f.nortelnetworks.com [47.129.242.57]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27359; Fri, 5 Jul 2002 10:38:29 -0400 (EDT) Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04f.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g65EYc306653; Fri, 5 Jul 2002 10:34:38 -0400 (EDT) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 5 Jul 2002 10:34:37 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA4BDA@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'Hancock, Robert'" , "'brunner@ccrle.nec.de'" , john.loughney@nokia.com, cedric@iprg.nokia.com, erafodo@ESEALNT448.al.sw.ericsson.se Cc: nsis@ietf.org, Hemant.Chaskar@nokia.com, "'seamoby@ietf.org'" Date: Fri, 5 Jul 2002 10:34:34 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C22431.15039930" Subject: [Seamoby] RE: what is edge signalling? (was: RE: [NSIS] Re: Comments on dra ft-westphal-nsis-qos-mobileip-00.txt) Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C22431.15039930 Content-Type: text/plain; charset="iso-8859-1" Robert: In your discussion of CT, you are presupposing a wg solution for CT that does not exist. The work on the CT protocol has not begun in Seamoby. Indeed, if you examine the CT requirements, signalling from the MN to the access network is prohibited. The reason being is that the sole purpose of CT is to enable a fast, smooth, seamless handover. Signalling over the air simply takes too much time, and the value of signalling from MN to AR has never been clearly identified. This issue was debated extensively in the CT design group and on the Seamoby list. I understand that there are people who feel otherwise, and please, let's not regurgitate the arguments here. As the requirements currently stand, CT is an AR to AR protocol. One source of confusion might be the work on the discovery protocol. It is my, admittedly minority opinion, that the use of MN to AR signalling to perform CT was moved into the discovery solution. And again, nothing can be done between the MN and an AR that cannot be done more efficiently, and faster, between two ARs. The way I see the directions of the two solutions lining up so far, NSIS and CT have little interaction. NSIS could be invoked if a CT attempt fails, but the restriction to have NSIS along the path implies that some path must exist before NSIS can be invoked. Thus, NSIS can be used only *after* a handover has completed, and thus there is no opportunity for interaction. Of course, all of this depends on what you define as a "path" - I am assuming that it is the IP forwarding path for the MNs bearer traffic. gary > -----Original Message----- > From: Hancock, Robert [mailto:robert.hancock@roke.co.uk] > Sent: July 5, 2002 05:35 > To: 'brunner@ccrle.nec.de'; john.loughney@nokia.com; > cedric@iprg.nokia.com; erafodo@ESEALNT448.al.sw.ericsson.se > Cc: nsis@ietf.org; Hemant.Chaskar@nokia.com > Subject: RE: what is edge signalling? (was: RE: [NSIS] Re: Comments on > dra ft-westphal-nsis-qos-mobileip-00.txt) > > > Hi all, > > I don't think there's any disagreement that CT is a tool that > NSIS could use (as an optimisation). > > What's entirely unclear to me is what sort of tool CT is: is > it a hammer or a screwdriver or a combination of the two? I > guess this is more a question for the seamoby people, but we > need to know the answer to know how to use it. > > More formally, there seem to be two extremes: > > a) NSIS is used for MN-AR resource (QoS) signalling, and > AR-rest of world signalling; CT can be used to transfer state > (both resource state and NSIS protocol state) between ARs at > handover, but if this involves any MN-AR messages (e.g. CTIN) > they aren't QoS related. NSIS-CT interaction can occur at the > ARs to do state transfer at handover time. > > b) CT messages (e.g. CIN) can be used by the MN to set up QoS > context in the AR, which it can then later transfer to a new > AR. NSIS is used to signal QoS for AR-rest of network. > NSIS-CT interaction takes place at the AR to interwork flow > setup and resource descriptions, and this interaction takes > place at flow setup time. (Essentially, CT provides a QoS > signalling protocol for the edge of the network, which NSIS > would have to interwork with, in the same way that it has to > interwork with RSVP/Intserv.) > > our framework draft-hancock-nsis-fw-00.txt basically assumes (a). > this draft-westphal-nsis-qos-mobileip-00.txt basically > assumes (b) so far as I can tell. > > I'm not trying to argue which of (a) or (b) is 'correct' at > this stage, just establish that they are not the same. (And > so we probably have to make a choice, although I suppose you > could allow both models...) > > Cheers, > > Robert H. > > > -----Original Message----- > > From: Marcus Brunner [mailto:brunner@ccrle.nec.de] > > Sent: 05 July 2002 10:05 > > To: john.loughney@nokia.com; Hancock, Robert; cedric@iprg.nokia.com; > > erafodo@ESEALNT448.al.sw.ericsson.se > > Cc: nsis@ietf.org; Hemant.Chaskar@nokia.com > > Subject: RE: what is edge signalling? (was: RE: [NSIS] Re: > Comments on > > draft-westphal-nsis-qos-mobileip-00.txt) > > > > > > I see CT as an optimization only and not required for NSIS. > > However, since > > there is a tendency to support only on-path signaling, this > > would not work > > anyway (because CT would need off-path signaling for at least > > some time). > > > > Marcus > > > > --On Donnerstag, 4. Juli 2002 11:33 +0300 > > john.loughney@nokia.com wrote: > > > > > Hi Robert, > > > > > >> On the 'edge signalling' case, I guess the main point is that > > >> I'm confused about the scope of seamoby CT. Specifically > > >> regarding MN-AR signalling (no issue about the AR-AR part): > > > > > > From my viewpoint, CT is not required for NSIS. I view CT as > > > one tool that an NSIS solution could use. So, I definately think > > > that at some point, we will need some sort of applicability > > > statement describing how to use CT for NSIS. > > > > > > John > > > > > > _______________________________________________ > > > nsis mailing list > > > nsis@ietf.org > > > https://www1.ietf.org/mailman/listinfo/nsis > > > > > > > > -------------------------------------- > > Dr. Marcus Brunner > > Network Laboratories > > NEC Europe Ltd. > > > > E-Mail: brunner@ccrle.nec.de > > WWW: http://www.ccrle.nec.de/ > > personal home page: http://www.brubers.org/marcus > > > > > ============================================================== > ========================== > Permission is hereby granted to pass the contents of this > communication to third parties and any restrictions regarding > confidentiality do not apply. > ------_=_NextPart_001_01C22431.15039930 Content-Type: text/html; charset="iso-8859-1" RE: what is edge signalling? (was: RE: [NSIS] Re: Comments on dra ft-westphal-nsis-qos-mobileip-00.txt)

Robert:

  In your discussion of CT, you are presupposing a wg solution
for CT that does not exist. The work on the CT protocol has not begun
in Seamoby. Indeed, if you examine the CT requirements,
signalling from the MN to the access network is prohibited. The
reason being is that the sole purpose of CT is to enable a fast, smooth,
seamless handover. Signalling over the air simply takes too much time,
and the value of signalling from MN to AR has never been clearly identified.

  This issue was debated extensively in the CT design group and on
the Seamoby list. I understand that there are people who feel otherwise,
and please, let's not regurgitate the arguments here. As the requirements
currently stand, CT is an AR to AR protocol.

  One source of confusion might be the work on the discovery protocol.
It is my, admittedly minority opinion, that the use of MN to AR signalling
to perform CT was moved into the discovery solution. And again, nothing
can be done between the MN and an AR that cannot be done more efficiently,
and faster, between two ARs.

  The way I see the directions of the two solutions lining up so far,
NSIS and CT have little interaction. NSIS could be invoked if a CT attempt
fails, but the restriction to have NSIS along the path implies that some
path must exist before NSIS can be invoked. Thus, NSIS can be used only
*after* a handover has completed, and thus there is no opportunity for
interaction. Of course, all of this depends on what you define as a "path"
- I am assuming that it is the IP forwarding path for the MNs bearer traffic.


gary

> -----Original Message-----
> From: Hancock, Robert [mailto:robert.hancock@roke.co.uk]
> Sent: July 5, 2002 05:35
> To: 'brunner@ccrle.nec.de'; john.loughney@nokia.com;
> cedric@iprg.nokia.com; erafodo@ESEALNT448.al.sw.ericsson.se
> Cc: nsis@ietf.org; Hemant.Chaskar@nokia.com
> Subject: RE: what is edge signalling? (was: RE: [NSIS] Re: Comments on
> dra ft-westphal-nsis-qos-mobileip-00.txt)
>
>
> Hi all,
>
> I don't think there's any disagreement that CT is a tool that
> NSIS could use (as an optimisation).
>
> What's entirely unclear to me is what sort of tool CT is: is
> it a hammer or a screwdriver or a combination of the two? I
> guess this is more a question for the seamoby people, but we
> need to know the answer to know how to use it.
>
> More formally, there seem to be two extremes:
>
> a) NSIS is used for MN-AR resource (QoS) signalling, and
> AR-rest of world signalling; CT can be used to transfer state
> (both resource state and NSIS protocol state) between ARs at
> handover, but if this involves any MN-AR messages (e.g. CTIN)
> they aren't QoS related. NSIS-CT interaction can occur at the
> ARs to do state transfer at handover time.
>
> b) CT messages (e.g. CIN) can be used by the MN to set up QoS
> context in the AR, which it can then later transfer to a new
> AR. NSIS is used to signal QoS for AR-rest of network.
> NSIS-CT interaction takes place at the AR to interwork flow
> setup and resource descriptions, and this interaction takes
> place at flow setup time. (Essentially, CT provides a QoS
> signalling protocol for the edge of the network, which NSIS
> would have to interwork with, in the same way that it has to
> interwork with RSVP/Intserv.)
>
> our framework draft-hancock-nsis-fw-00.txt basically assumes (a).
> this draft-westphal-nsis-qos-mobileip-00.txt basically
> assumes (b) so far as I can tell.
>
> I'm not trying to argue which of (a) or (b) is 'correct' at
> this stage, just establish that they are not the same. (And
> so we probably have to make a choice, although I suppose you
> could allow both models...)
>
> Cheers,
>
> Robert H.
>
> > -----Original Message-----
> > From: Marcus Brunner [mailto:brunner@ccrle.nec.de]
> > Sent: 05 July 2002 10:05
> > To: john.loughney@nokia.com; Hancock, Robert; cedric@iprg.nokia.com;
> > erafodo@ESEALNT448.al.sw.ericsson.se
> > Cc: nsis@ietf.org; Hemant.Chaskar@nokia.com
> > Subject: RE: what is edge signalling? (was: RE: [NSIS] Re:
> Comments on
> > draft-westphal-nsis-qos-mobileip-00.txt)
> >
> >
> > I see CT as an optimization only and not required for NSIS.
> > However, since
> > there is a tendency to support only on-path signaling, this
> > would not work
> > anyway (because CT would need off-path signaling for at least
> > some time).
> >
> > Marcus
> >
> > --On Donnerstag, 4. Juli 2002 11:33 +0300
> > john.loughney@nokia.com wrote:
> >
> > > Hi Robert,
> > >
> > >> On the 'edge signalling' case, I guess the main point is that
> > >> I'm confused about the scope of seamoby CT. Specifically
> > >> regarding MN-AR signalling (no issue about the AR-AR part):
> > >
> > > From my viewpoint, CT is not required for NSIS. I view CT as
> > > one tool that an NSIS solution could use.  So, I definately think
> > > that at some point, we will need some sort of applicability
> > > statement describing how to use CT for NSIS.
> > >
> > > John
> > >
> > > _______________________________________________
> > > nsis mailing list
> > > nsis@ietf.org
> > > https://www1.ietf.org/mailman/listinfo/nsis
> >
> >
> >
> > --------------------------------------
> > Dr. Marcus Brunner
> > Network Laboratories
> > NEC Europe Ltd.
> >
> > E-Mail: brunner@ccrle.nec.de
> > WWW:    http://www.ccrle.nec.de/
> > personal home page: http://www.brubers.org/marcus
> >
> >
> ==============================================================
> ==========================
> Permission is hereby granted to pass the contents of this
> communication to third parties and any restrictions regarding
> confidentiality do not apply.
>

------_=_NextPart_001_01C22431.15039930-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Fri Jul 5 11:01:41 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28376 for ; Fri, 5 Jul 2002 11:01:40 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA06584; Fri, 5 Jul 2002 10:59:21 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA06432 for ; Fri, 5 Jul 2002 10:59:14 -0400 (EDT) Received: from rsys000a.roke.co.uk (rsys000a.roke.co.uk [193.118.201.102]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA28226; Fri, 5 Jul 2002 10:58:20 -0400 (EDT) Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Fri, 5 Jul 2002 15:58:54 +0100 Message-ID: <76C92FBBFB58D411AE760090271ED4181EA43D@rsys002a.roke.co.uk> From: "Hancock, Robert" To: "'Gary Kenward'" , "'brunner@ccrle.nec.de'" , john.loughney@nokia.com, cedric@iprg.nokia.com, erafodo@ESEALNT448.al.sw.ericsson.se Cc: nsis@ietf.org, Hemant.Chaskar@nokia.com, "'seamoby@ietf.org'" Date: Fri, 5 Jul 2002 15:58:53 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="------------InterScan_NT_MIME_Boundary" Subject: [Seamoby] RE: what is edge signalling? (was: RE: [NSIS] Re: Comments on dra ft-westphal-nsis-qos-mobileip-00.txt) Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --------------InterScan_NT_MIME_Boundary Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C22434.7ABEC65C" ------_=_NextPart_001_01C22434.7ABEC65C Content-Type: text/plain; charset="iso-8859-1" hi gary, my comments are purely on draft-westphal-nsis-qos-mobileip and associated email discussions (since that's been the only input I have seen recently which explicitly discusses the relationship between CT and NSIS, and which I had worries about). in particular, any comments I make about MN-AR signalling are really to emphasise the difference between the cases of a) not having CT signalling that carries QoS information MN-AR (if there is or isn't other CT signalling I don't really care), and b) having CT signalling that does carry QoS information MN-AR, which seems to be the assumption of the mentioned draft. our recent framework activities assumed (a). if you're saying that the seamoby w.g. requirements also impose (a), that's fine by me. i also don't want to re-open old discussions (certainly not on the nsis list, anyway). i suspect we're basically in agreement about NSIS/CT relationships: after a handover, if CT happened, it should be possible to have less NSIS signalling on the on-path segment which goes over the air. cheers, robert h. PS referring to a previous email, i think the view that NSIS is "likely to be of limited use in mobility situations" is rather pessimistic. i would rather say that if you want the resources signalled for by NSIS to be available seamlessly over handovers, you'll need something else as well, which could be CT. the basic point seems to be that NSIS shouldn't try to solve the cross-path context/state transfer problem - any more than CT should try to solve the along-path context/state establishment problem. -----Original Message----- From: Gary Kenward [mailto:gkenward@nortelnetworks.com] Sent: 05 July 2002 15:35 To: Hancock, Robert; 'brunner@ccrle.nec.de'; john.loughney@nokia.com; cedric@iprg.nokia.com; erafodo@ESEALNT448.al.sw.ericsson.se Cc: nsis@ietf.org; Hemant.Chaskar@nokia.com; 'seamoby@ietf.org' Subject: RE: what is edge signalling? (was: RE: [NSIS] Re: Comments on dra ft-westphal-nsis-qos-mobileip-00.txt) Robert: In your discussion of CT, you are presupposing a wg solution for CT that does not exist. The work on the CT protocol has not begun in Seamoby. Indeed, if you examine the CT requirements, signalling from the MN to the access network is prohibited. The reason being is that the sole purpose of CT is to enable a fast, smooth, seamless handover. Signalling over the air simply takes too much time, and the value of signalling from MN to AR has never been clearly identified. This issue was debated extensively in the CT design group and on the Seamoby list. I understand that there are people who feel otherwise, and please, let's not regurgitate the arguments here. As the requirements currently stand, CT is an AR to AR protocol. One source of confusion might be the work on the discovery protocol. It is my, admittedly minority opinion, that the use of MN to AR signalling to perform CT was moved into the discovery solution. And again, nothing can be done between the MN and an AR that cannot be done more efficiently, and faster, between two ARs. The way I see the directions of the two solutions lining up so far, NSIS and CT have little interaction. NSIS could be invoked if a CT attempt fails, but the restriction to have NSIS along the path implies that some path must exist before NSIS can be invoked. Thus, NSIS can be used only *after* a handover has completed, and thus there is no opportunity for interaction. Of course, all of this depends on what you define as a "path" - I am assuming that it is the IP forwarding path for the MNs bearer traffic. gary > -----Original Message----- > From: Hancock, Robert [ mailto:robert.hancock@roke.co.uk ] > Sent: July 5, 2002 05:35 > To: 'brunner@ccrle.nec.de'; john.loughney@nokia.com; > cedric@iprg.nokia.com; erafodo@ESEALNT448.al.sw.ericsson.se > Cc: nsis@ietf.org; Hemant.Chaskar@nokia.com > Subject: RE: what is edge signalling? (was: RE: [NSIS] Re: Comments on > dra ft-westphal-nsis-qos-mobileip-00.txt) > > > Hi all, > > I don't think there's any disagreement that CT is a tool that > NSIS could use (as an optimisation). > > What's entirely unclear to me is what sort of tool CT is: is > it a hammer or a screwdriver or a combination of the two? I > guess this is more a question for the seamoby people, but we > need to know the answer to know how to use it. > > More formally, there seem to be two extremes: > > a) NSIS is used for MN-AR resource (QoS) signalling, and > AR-rest of world signalling; CT can be used to transfer state > (both resource state and NSIS protocol state) between ARs at > handover, but if this involves any MN-AR messages (e.g. CTIN) > they aren't QoS related. NSIS-CT interaction can occur at the > ARs to do state transfer at handover time. > > b) CT messages (e.g. CIN) can be used by the MN to set up QoS > context in the AR, which it can then later transfer to a new > AR. NSIS is used to signal QoS for AR-rest of network. > NSIS-CT interaction takes place at the AR to interwork flow > setup and resource descriptions, and this interaction takes > place at flow setup time. (Essentially, CT provides a QoS > signalling protocol for the edge of the network, which NSIS > would have to interwork with, in the same way that it has to > interwork with RSVP/Intserv.) > > our framework draft-hancock-nsis-fw-00.txt basically assumes (a). > this draft-westphal-nsis-qos-mobileip-00.txt basically > assumes (b) so far as I can tell. > > I'm not trying to argue which of (a) or (b) is 'correct' at > this stage, just establish that they are not the same. (And > so we probably have to make a choice, although I suppose you > could allow both models...) > > Cheers, > > Robert H. > > > -----Original Message----- > > From: Marcus Brunner [ mailto:brunner@ccrle.nec.de ] > > Sent: 05 July 2002 10:05 > > To: john.loughney@nokia.com; Hancock, Robert; cedric@iprg.nokia.com; > > erafodo@ESEALNT448.al.sw.ericsson.se > > Cc: nsis@ietf.org; Hemant.Chaskar@nokia.com > > Subject: RE: what is edge signalling? (was: RE: [NSIS] Re: > Comments on > > draft-westphal-nsis-qos-mobileip-00.txt) > > > > > > I see CT as an optimization only and not required for NSIS. > > However, since > > there is a tendency to support only on-path signaling, this > > would not work > > anyway (because CT would need off-path signaling for at least > > some time). > > > > Marcus > > > > --On Donnerstag, 4. Juli 2002 11:33 +0300 > > john.loughney@nokia.com wrote: > > > > > Hi Robert, > > > > > >> On the 'edge signalling' case, I guess the main point is that > > >> I'm confused about the scope of seamoby CT. Specifically > > >> regarding MN-AR signalling (no issue about the AR-AR part): > > > > > > From my viewpoint, CT is not required for NSIS. I view CT as > > > one tool that an NSIS solution could use. So, I definately think > > > that at some point, we will need some sort of applicability > > > statement describing how to use CT for NSIS. > > > > > > John > > > > > > _______________________________________________ > > > nsis mailing list > > > nsis@ietf.org > > > https://www1.ietf.org/mailman/listinfo/nsis > > > > > > > > -------------------------------------- > > Dr. Marcus Brunner > > Network Laboratories > > NEC Europe Ltd. > > > > E-Mail: brunner@ccrle.nec.de > > WWW: http://www.ccrle.nec.de/ > > personal home page: http://www.brubers.org/marcus > > > > ============================================================== ========================== Permission is hereby granted to pass the contents of this communication to third parties and any restrictions regarding confidentiality do not apply. ------_=_NextPart_001_01C22434.7ABEC65C Content-Type: text/html; charset="iso-8859-1" RE: what is edge signalling? (was: RE: [NSIS] Re: Comments on dra ft-westphal-nsis-qos-mobileip-00.txt)
hi gary,
 
my comments are purely on draft-westphal-nsis-qos-mobileip and associated email discussions (since that's been the only input I have seen recently which explicitly discusses the relationship between CT and NSIS, and which I had worries about).
in particular, any comments I make about MN-AR signalling are really to emphasise the difference between the cases of
a) not having CT signalling that carries QoS information MN-AR (if there is or isn't other CT signalling I don't really care), and
b) having CT signalling that does carry QoS information MN-AR, which seems to be the assumption of the mentioned draft.
 
our recent framework activities assumed (a). if you're saying that the seamoby w.g. requirements also impose (a), that's fine by me. i also don't want to re-open old discussions (certainly not on the nsis list, anyway).
 
i suspect we're basically in agreement about NSIS/CT relationships: after a handover, if CT happened, it should be possible to have less NSIS signalling on the on-path segment which goes over the air.
 
cheers,
 
robert h.
 
PS referring to a previous email, i think the view that NSIS is "likely to be of limited use in mobility situations" is rather pessimistic. i would rather say that if you want the resources signalled for by NSIS to be available seamlessly over handovers, you'll need something else as well, which could be CT. the basic point seems to be that NSIS shouldn't try to solve the cross-path context/state transfer problem - any more than CT should try to solve the along-path context/state establishment problem.
-----Original Message-----
From: Gary Kenward [mailto:gkenward@nortelnetworks.com]
Sent: 05 July 2002 15:35
To: Hancock, Robert; 'brunner@ccrle.nec.de'; john.loughney@nokia.com; cedric@iprg.nokia.com; erafodo@ESEALNT448.al.sw.ericsson.se
Cc: nsis@ietf.org; Hemant.Chaskar@nokia.com; 'seamoby@ietf.org'
Subject: RE: what is edge signalling? (was: RE: [NSIS] Re: Comments on dra ft-westphal-nsis-qos-mobileip-00.txt)

Robert:

  In your discussion of CT, you are presupposing a wg solution
for CT that does not exist. The work on the CT protocol has not begun
in Seamoby. Indeed, if you examine the CT requirements,
signalling from the MN to the access network is prohibited. The
reason being is that the sole purpose of CT is to enable a fast, smooth,
seamless handover. Signalling over the air simply takes too much time,
and the value of signalling from MN to AR has never been clearly identified.

  This issue was debated extensively in the CT design group and on
the Seamoby list. I understand that there are people who feel otherwise,
and please, let's not regurgitate the arguments here. As the requirements
currently stand, CT is an AR to AR protocol.

  One source of confusion might be the work on the discovery protocol.
It is my, admittedly minority opinion, that the use of MN to AR signalling
to perform CT was moved into the discovery solution. And again, nothing
can be done between the MN and an AR that cannot be done more efficiently,
and faster, between two ARs.

  The way I see the directions of the two solutions lining up so far,
NSIS and CT have little interaction. NSIS could be invoked if a CT attempt
fails, but the restriction to have NSIS along the path implies that some
path must exist before NSIS can be invoked. Thus, NSIS can be used only
*after* a handover has completed, and thus there is no opportunity for
interaction. Of course, all of this depends on what you define as a "path"
- I am assuming that it is the IP forwarding path for the MNs bearer traffic.


gary

> -----Original Message-----
> From: Hancock, Robert [mailto:robert.hancock@roke.co.uk]
> Sent: July 5, 2002 05:35
> To: 'brunner@ccrle.nec.de'; john.loughney@nokia.com;
> cedric@iprg.nokia.com; erafodo@ESEALNT448.al.sw.ericsson.se
> Cc: nsis@ietf.org; Hemant.Chaskar@nokia.com
> Subject: RE: what is edge signalling? (was: RE: [NSIS] Re: Comments on
> dra ft-westphal-nsis-qos-mobileip-00.txt)
>
>
> Hi all,
>
> I don't think there's any disagreement that CT is a tool that
> NSIS could use (as an optimisation).
>
> What's entirely unclear to me is what sort of tool CT is: is
> it a hammer or a screwdriver or a combination of the two? I
> guess this is more a question for the seamoby people, but we
> need to know the answer to know how to use it.
>
> More formally, there seem to be two extremes:
>
> a) NSIS is used for MN-AR resource (QoS) signalling, and
> AR-rest of world signalling; CT can be used to transfer state
> (both resource state and NSIS protocol state) between ARs at
> handover, but if this involves any MN-AR messages (e.g. CTIN)
> they aren't QoS related. NSIS-CT interaction can occur at the
> ARs to do state transfer at handover time.
>
> b) CT messages (e.g. CIN) can be used by the MN to set up QoS
> context in the AR, which it can then later transfer to a new
> AR. NSIS is used to signal QoS for AR-rest of network.
> NSIS-CT interaction takes place at the AR to interwork flow
> setup and resource descriptions, and this interaction takes
> place at flow setup time. (Essentially, CT provides a QoS
> signalling protocol for the edge of the network, which NSIS
> would have to interwork with, in the same way that it has to
> interwork with RSVP/Intserv.)
>
> our framework draft-hancock-nsis-fw-00.txt basically assumes (a).
> this draft-westphal-nsis-qos-mobileip-00.txt basically
> assumes (b) so far as I can tell.
>
> I'm not trying to argue which of (a) or (b) is 'correct' at
> this stage, just establish that they are not the same. (And
> so we probably have to make a choice, although I suppose you
> could allow both models...)
>
> Cheers,
>
> Robert H.
>
> > -----Original Message-----
> > From: Marcus Brunner [mailto:brunner@ccrle.nec.de]
> > Sent: 05 July 2002 10:05
> > To: john.loughney@nokia.com; Hancock, Robert; cedric@iprg.nokia.com;
> > erafodo@ESEALNT448.al.sw.ericsson.se
> > Cc: nsis@ietf.org; Hemant.Chaskar@nokia.com
> > Subject: RE: what is edge signalling? (was: RE: [NSIS] Re:
> Comments on
> > draft-westphal-nsis-qos-mobileip-00.txt)
> >
> >
> > I see CT as an optimization only and not required for NSIS.
> > However, since
> > there is a tendency to support only on-path signaling, this
> > would not work
> > anyway (because CT would need off-path signaling for at least
> > some time).
> >
> > Marcus
> >
> > --On Donnerstag, 4. Juli 2002 11:33 +0300
> > john.loughney@nokia.com wrote:
> >
> > > Hi Robert,
> > >
> > >> On the 'edge signalling' case, I guess the main point is that
> > >> I'm confused about the scope of seamoby CT. Specifically
> > >> regarding MN-AR signalling (no issue about the AR-AR part):
> > >
> > > From my viewpoint, CT is not required for NSIS. I view CT as
> > > one tool that an NSIS solution could use.  So, I definately think
> > > that at some point, we will need some sort of applicability
> > > statement describing how to use CT for NSIS.
> > >
> > > John
> > >
> > > _______________________________________________
> > > nsis mailing list
> > > nsis@ietf.org
> > > https://www1.ietf.org/mailman/listinfo/nsis
> >
> >
> >
> > --------------------------------------
> > Dr. Marcus Brunner
> > Network Laboratories
> > NEC Europe Ltd.
> >
> > E-Mail: brunner@ccrle.nec.de
> > WWW:    http://www.ccrle.nec.de/
> > personal home page: http://www.brubers.org/marcus
> >
> >
============================================================== 
========================== 
Permission is hereby granted to pass the contents of this 
communication to third parties and any restrictions regarding 
confidentiality do not apply.   

------_=_NextPart_001_01C22434.7ABEC65C-- --------------InterScan_NT_MIME_Boundary Content-Type: text/plain; name="RMRL-Disclaimer.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="RMRL-Disclaimer.txt" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit The information contained in this e-mail and any attachments is confidential to Roke Manor Research Ltd and must not be passed to any third party without permission. This communication is for information only and shall not create or change any contractual relationship. --------------InterScan_NT_MIME_Boundary-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Fri Jul 5 11:01:42 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28389 for ; Fri, 5 Jul 2002 11:01:41 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA07197 for seamoby-archive@odin.ietf.org; Fri, 5 Jul 2002 11:02:33 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA06584; Fri, 5 Jul 2002 10:59:21 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA06432 for ; Fri, 5 Jul 2002 10:59:14 -0400 (EDT) Received: from rsys000a.roke.co.uk (rsys000a.roke.co.uk [193.118.201.102]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA28226; Fri, 5 Jul 2002 10:58:20 -0400 (EDT) Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Fri, 5 Jul 2002 15:58:54 +0100 Message-ID: <76C92FBBFB58D411AE760090271ED4181EA43D@rsys002a.roke.co.uk> From: "Hancock, Robert" To: "'Gary Kenward'" , "'brunner@ccrle.nec.de'" , john.loughney@nokia.com, cedric@iprg.nokia.com, erafodo@ESEALNT448.al.sw.ericsson.se Cc: nsis@ietf.org, Hemant.Chaskar@nokia.com, "'seamoby@ietf.org'" Date: Fri, 5 Jul 2002 15:58:53 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="------------InterScan_NT_MIME_Boundary" Subject: [Seamoby] RE: what is edge signalling? (was: RE: [NSIS] Re: Comments on dra ft-westphal-nsis-qos-mobileip-00.txt) Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --------------InterScan_NT_MIME_Boundary Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C22434.7ABEC65C" ------_=_NextPart_001_01C22434.7ABEC65C Content-Type: text/plain; charset="iso-8859-1" hi gary, my comments are purely on draft-westphal-nsis-qos-mobileip and associated email discussions (since that's been the only input I have seen recently which explicitly discusses the relationship between CT and NSIS, and which I had worries about). in particular, any comments I make about MN-AR signalling are really to emphasise the difference between the cases of a) not having CT signalling that carries QoS information MN-AR (if there is or isn't other CT signalling I don't really care), and b) having CT signalling that does carry QoS information MN-AR, which seems to be the assumption of the mentioned draft. our recent framework activities assumed (a). if you're saying that the seamoby w.g. requirements also impose (a), that's fine by me. i also don't want to re-open old discussions (certainly not on the nsis list, anyway). i suspect we're basically in agreement about NSIS/CT relationships: after a handover, if CT happened, it should be possible to have less NSIS signalling on the on-path segment which goes over the air. cheers, robert h. PS referring to a previous email, i think the view that NSIS is "likely to be of limited use in mobility situations" is rather pessimistic. i would rather say that if you want the resources signalled for by NSIS to be available seamlessly over handovers, you'll need something else as well, which could be CT. the basic point seems to be that NSIS shouldn't try to solve the cross-path context/state transfer problem - any more than CT should try to solve the along-path context/state establishment problem. -----Original Message----- From: Gary Kenward [mailto:gkenward@nortelnetworks.com] Sent: 05 July 2002 15:35 To: Hancock, Robert; 'brunner@ccrle.nec.de'; john.loughney@nokia.com; cedric@iprg.nokia.com; erafodo@ESEALNT448.al.sw.ericsson.se Cc: nsis@ietf.org; Hemant.Chaskar@nokia.com; 'seamoby@ietf.org' Subject: RE: what is edge signalling? (was: RE: [NSIS] Re: Comments on dra ft-westphal-nsis-qos-mobileip-00.txt) Robert: In your discussion of CT, you are presupposing a wg solution for CT that does not exist. The work on the CT protocol has not begun in Seamoby. Indeed, if you examine the CT requirements, signalling from the MN to the access network is prohibited. The reason being is that the sole purpose of CT is to enable a fast, smooth, seamless handover. Signalling over the air simply takes too much time, and the value of signalling from MN to AR has never been clearly identified. This issue was debated extensively in the CT design group and on the Seamoby list. I understand that there are people who feel otherwise, and please, let's not regurgitate the arguments here. As the requirements currently stand, CT is an AR to AR protocol. One source of confusion might be the work on the discovery protocol. It is my, admittedly minority opinion, that the use of MN to AR signalling to perform CT was moved into the discovery solution. And again, nothing can be done between the MN and an AR that cannot be done more efficiently, and faster, between two ARs. The way I see the directions of the two solutions lining up so far, NSIS and CT have little interaction. NSIS could be invoked if a CT attempt fails, but the restriction to have NSIS along the path implies that some path must exist before NSIS can be invoked. Thus, NSIS can be used only *after* a handover has completed, and thus there is no opportunity for interaction. Of course, all of this depends on what you define as a "path" - I am assuming that it is the IP forwarding path for the MNs bearer traffic. gary > -----Original Message----- > From: Hancock, Robert [ mailto:robert.hancock@roke.co.uk ] > Sent: July 5, 2002 05:35 > To: 'brunner@ccrle.nec.de'; john.loughney@nokia.com; > cedric@iprg.nokia.com; erafodo@ESEALNT448.al.sw.ericsson.se > Cc: nsis@ietf.org; Hemant.Chaskar@nokia.com > Subject: RE: what is edge signalling? (was: RE: [NSIS] Re: Comments on > dra ft-westphal-nsis-qos-mobileip-00.txt) > > > Hi all, > > I don't think there's any disagreement that CT is a tool that > NSIS could use (as an optimisation). > > What's entirely unclear to me is what sort of tool CT is: is > it a hammer or a screwdriver or a combination of the two? I > guess this is more a question for the seamoby people, but we > need to know the answer to know how to use it. > > More formally, there seem to be two extremes: > > a) NSIS is used for MN-AR resource (QoS) signalling, and > AR-rest of world signalling; CT can be used to transfer state > (both resource state and NSIS protocol state) between ARs at > handover, but if this involves any MN-AR messages (e.g. CTIN) > they aren't QoS related. NSIS-CT interaction can occur at the > ARs to do state transfer at handover time. > > b) CT messages (e.g. CIN) can be used by the MN to set up QoS > context in the AR, which it can then later transfer to a new > AR. NSIS is used to signal QoS for AR-rest of network. > NSIS-CT interaction takes place at the AR to interwork flow > setup and resource descriptions, and this interaction takes > place at flow setup time. (Essentially, CT provides a QoS > signalling protocol for the edge of the network, which NSIS > would have to interwork with, in the same way that it has to > interwork with RSVP/Intserv.) > > our framework draft-hancock-nsis-fw-00.txt basically assumes (a). > this draft-westphal-nsis-qos-mobileip-00.txt basically > assumes (b) so far as I can tell. > > I'm not trying to argue which of (a) or (b) is 'correct' at > this stage, just establish that they are not the same. (And > so we probably have to make a choice, although I suppose you > could allow both models...) > > Cheers, > > Robert H. > > > -----Original Message----- > > From: Marcus Brunner [ mailto:brunner@ccrle.nec.de ] > > Sent: 05 July 2002 10:05 > > To: john.loughney@nokia.com; Hancock, Robert; cedric@iprg.nokia.com; > > erafodo@ESEALNT448.al.sw.ericsson.se > > Cc: nsis@ietf.org; Hemant.Chaskar@nokia.com > > Subject: RE: what is edge signalling? (was: RE: [NSIS] Re: > Comments on > > draft-westphal-nsis-qos-mobileip-00.txt) > > > > > > I see CT as an optimization only and not required for NSIS. > > However, since > > there is a tendency to support only on-path signaling, this > > would not work > > anyway (because CT would need off-path signaling for at least > > some time). > > > > Marcus > > > > --On Donnerstag, 4. Juli 2002 11:33 +0300 > > john.loughney@nokia.com wrote: > > > > > Hi Robert, > > > > > >> On the 'edge signalling' case, I guess the main point is that > > >> I'm confused about the scope of seamoby CT. Specifically > > >> regarding MN-AR signalling (no issue about the AR-AR part): > > > > > > From my viewpoint, CT is not required for NSIS. I view CT as > > > one tool that an NSIS solution could use. So, I definately think > > > that at some point, we will need some sort of applicability > > > statement describing how to use CT for NSIS. > > > > > > John > > > > > > _______________________________________________ > > > nsis mailing list > > > nsis@ietf.org > > > https://www1.ietf.org/mailman/listinfo/nsis > > > > > > > > -------------------------------------- > > Dr. Marcus Brunner > > Network Laboratories > > NEC Europe Ltd. > > > > E-Mail: brunner@ccrle.nec.de > > WWW: http://www.ccrle.nec.de/ > > personal home page: http://www.brubers.org/marcus > > > > ============================================================== ========================== Permission is hereby granted to pass the contents of this communication to third parties and any restrictions regarding confidentiality do not apply. ------_=_NextPart_001_01C22434.7ABEC65C Content-Type: text/html; charset="iso-8859-1" RE: what is edge signalling? (was: RE: [NSIS] Re: Comments on dra ft-westphal-nsis-qos-mobileip-00.txt)
hi gary,
 
my comments are purely on draft-westphal-nsis-qos-mobileip and associated email discussions (since that's been the only input I have seen recently which explicitly discusses the relationship between CT and NSIS, and which I had worries about).
in particular, any comments I make about MN-AR signalling are really to emphasise the difference between the cases of
a) not having CT signalling that carries QoS information MN-AR (if there is or isn't other CT signalling I don't really care), and
b) having CT signalling that does carry QoS information MN-AR, which seems to be the assumption of the mentioned draft.
 
our recent framework activities assumed (a). if you're saying that the seamoby w.g. requirements also impose (a), that's fine by me. i also don't want to re-open old discussions (certainly not on the nsis list, anyway).
 
i suspect we're basically in agreement about NSIS/CT relationships: after a handover, if CT happened, it should be possible to have less NSIS signalling on the on-path segment which goes over the air.
 
cheers,
 
robert h.
 
PS referring to a previous email, i think the view that NSIS is "likely to be of limited use in mobility situations" is rather pessimistic. i would rather say that if you want the resources signalled for by NSIS to be available seamlessly over handovers, you'll need something else as well, which could be CT. the basic point seems to be that NSIS shouldn't try to solve the cross-path context/state transfer problem - any more than CT should try to solve the along-path context/state establishment problem.
-----Original Message-----
From: Gary Kenward [mailto:gkenward@nortelnetworks.com]
Sent: 05 July 2002 15:35
To: Hancock, Robert; 'brunner@ccrle.nec.de'; john.loughney@nokia.com; cedric@iprg.nokia.com; erafodo@ESEALNT448.al.sw.ericsson.se
Cc: nsis@ietf.org; Hemant.Chaskar@nokia.com; 'seamoby@ietf.org'
Subject: RE: what is edge signalling? (was: RE: [NSIS] Re: Comments on dra ft-westphal-nsis-qos-mobileip-00.txt)

Robert:

  In your discussion of CT, you are presupposing a wg solution
for CT that does not exist. The work on the CT protocol has not begun
in Seamoby. Indeed, if you examine the CT requirements,
signalling from the MN to the access network is prohibited. The
reason being is that the sole purpose of CT is to enable a fast, smooth,
seamless handover. Signalling over the air simply takes too much time,
and the value of signalling from MN to AR has never been clearly identified.

  This issue was debated extensively in the CT design group and on
the Seamoby list. I understand that there are people who feel otherwise,
and please, let's not regurgitate the arguments here. As the requirements
currently stand, CT is an AR to AR protocol.

  One source of confusion might be the work on the discovery protocol.
It is my, admittedly minority opinion, that the use of MN to AR signalling
to perform CT was moved into the discovery solution. And again, nothing
can be done between the MN and an AR that cannot be done more efficiently,
and faster, between two ARs.

  The way I see the directions of the two solutions lining up so far,
NSIS and CT have little interaction. NSIS could be invoked if a CT attempt
fails, but the restriction to have NSIS along the path implies that some
path must exist before NSIS can be invoked. Thus, NSIS can be used only
*after* a handover has completed, and thus there is no opportunity for
interaction. Of course, all of this depends on what you define as a "path"
- I am assuming that it is the IP forwarding path for the MNs bearer traffic.


gary

> -----Original Message-----
> From: Hancock, Robert [mailto:robert.hancock@roke.co.uk]
> Sent: July 5, 2002 05:35
> To: 'brunner@ccrle.nec.de'; john.loughney@nokia.com;
> cedric@iprg.nokia.com; erafodo@ESEALNT448.al.sw.ericsson.se
> Cc: nsis@ietf.org; Hemant.Chaskar@nokia.com
> Subject: RE: what is edge signalling? (was: RE: [NSIS] Re: Comments on
> dra ft-westphal-nsis-qos-mobileip-00.txt)
>
>
> Hi all,
>
> I don't think there's any disagreement that CT is a tool that
> NSIS could use (as an optimisation).
>
> What's entirely unclear to me is what sort of tool CT is: is
> it a hammer or a screwdriver or a combination of the two? I
> guess this is more a question for the seamoby people, but we
> need to know the answer to know how to use it.
>
> More formally, there seem to be two extremes:
>
> a) NSIS is used for MN-AR resource (QoS) signalling, and
> AR-rest of world signalling; CT can be used to transfer state
> (both resource state and NSIS protocol state) between ARs at
> handover, but if this involves any MN-AR messages (e.g. CTIN)
> they aren't QoS related. NSIS-CT interaction can occur at the
> ARs to do state transfer at handover time.
>
> b) CT messages (e.g. CIN) can be used by the MN to set up QoS
> context in the AR, which it can then later transfer to a new
> AR. NSIS is used to signal QoS for AR-rest of network.
> NSIS-CT interaction takes place at the AR to interwork flow
> setup and resource descriptions, and this interaction takes
> place at flow setup time. (Essentially, CT provides a QoS
> signalling protocol for the edge of the network, which NSIS
> would have to interwork with, in the same way that it has to
> interwork with RSVP/Intserv.)
>
> our framework draft-hancock-nsis-fw-00.txt basically assumes (a).
> this draft-westphal-nsis-qos-mobileip-00.txt basically
> assumes (b) so far as I can tell.
>
> I'm not trying to argue which of (a) or (b) is 'correct' at
> this stage, just establish that they are not the same. (And
> so we probably have to make a choice, although I suppose you
> could allow both models...)
>
> Cheers,
>
> Robert H.
>
> > -----Original Message-----
> > From: Marcus Brunner [mailto:brunner@ccrle.nec.de]
> > Sent: 05 July 2002 10:05
> > To: john.loughney@nokia.com; Hancock, Robert; cedric@iprg.nokia.com;
> > erafodo@ESEALNT448.al.sw.ericsson.se
> > Cc: nsis@ietf.org; Hemant.Chaskar@nokia.com
> > Subject: RE: what is edge signalling? (was: RE: [NSIS] Re:
> Comments on
> > draft-westphal-nsis-qos-mobileip-00.txt)
> >
> >
> > I see CT as an optimization only and not required for NSIS.
> > However, since
> > there is a tendency to support only on-path signaling, this
> > would not work
> > anyway (because CT would need off-path signaling for at least
> > some time).
> >
> > Marcus
> >
> > --On Donnerstag, 4. Juli 2002 11:33 +0300
> > john.loughney@nokia.com wrote:
> >
> > > Hi Robert,
> > >
> > >> On the 'edge signalling' case, I guess the main point is that
> > >> I'm confused about the scope of seamoby CT. Specifically
> > >> regarding MN-AR signalling (no issue about the AR-AR part):
> > >
> > > From my viewpoint, CT is not required for NSIS. I view CT as
> > > one tool that an NSIS solution could use.  So, I definately think
> > > that at some point, we will need some sort of applicability
> > > statement describing how to use CT for NSIS.
> > >
> > > John
> > >
> > > _______________________________________________
> > > nsis mailing list
> > > nsis@ietf.org
> > > https://www1.ietf.org/mailman/listinfo/nsis
> >
> >
> >
> > --------------------------------------
> > Dr. Marcus Brunner
> > Network Laboratories
> > NEC Europe Ltd.
> >
> > E-Mail: brunner@ccrle.nec.de
> > WWW:    http://www.ccrle.nec.de/
> > personal home page: http://www.brubers.org/marcus
> >
> >
============================================================== 
========================== 
Permission is hereby granted to pass the contents of this 
communication to third parties and any restrictions regarding 
confidentiality do not apply.   

------_=_NextPart_001_01C22434.7ABEC65C-- --------------InterScan_NT_MIME_Boundary Content-Type: text/plain; name="RMRL-Disclaimer.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="RMRL-Disclaimer.txt" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit The information contained in this e-mail and any attachments is confidential to Roke Manor Research Ltd and must not be passed to any third party without permission. This communication is for information only and shall not create or change any contractual relationship. --------------InterScan_NT_MIME_Boundary-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Fri Jul 5 11:45:17 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00289 for ; Fri, 5 Jul 2002 11:45:17 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA08669; Fri, 5 Jul 2002 11:33:48 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA08605 for ; Fri, 5 Jul 2002 11:33:44 -0400 (EDT) Received: from zcars04f.ca.nortel.com (zcars04f.nortelnetworks.com [47.129.242.57]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29806; Fri, 5 Jul 2002 11:32:53 -0400 (EDT) Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04f.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g65FWl311631; Fri, 5 Jul 2002 11:32:47 -0400 (EDT) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 5 Jul 2002 11:32:47 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA4BDC@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'Hancock, Robert'" , "'brunner@ccrle.nec.de'" , john.loughney@nokia.com, cedric@iprg.nokia.com, erafodo@ESEALNT448.al.sw.ericsson.se Cc: nsis@ietf.org, Hemant.Chaskar@nokia.com, "'seamoby@ietf.org'" Date: Fri, 5 Jul 2002 11:32:46 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C22439.366620D6" Subject: [Seamoby] RE: what is edge signalling? (was: RE: [NSIS] Re: Comments on dra ft-westphal-nsis-qos-mobileip-00.txt) Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C22439.366620D6 Content-Type: text/plain; charset="iso-8859-1" Robert: I will have to read Cedric's draft. I wasn't aware that it discussed CT. With deference to Cedric, and what I am sure is a thoughtful analysis, it seems to me that understanding the relationship between CT and NSIS would require, at the very least, a CT solution, or something close to a CT solution. Clearly there is a difference of opinion as to what CT should be (the requirements draft is apparently going to go through another revision, so who knows?). In my view, if CT is in place, then NSIS should not be invoked as a result of a handover. A pretty simple relationship. The only exception that I can imagine is if there is some impact on a service that is not provided at an ANR (i.e. an AR or an internal router), then NSIS may be required to maintain that service. However, I could not name this service at this point. -----Original Message----- From: Hancock, Robert [mailto:robert.hancock@roke.co.uk] Sent: July 5, 2002 10:59 To: Kenward, Gary [WDLN2:AN10:EXCH]; 'brunner@ccrle.nec.de'; john.loughney@nokia.com; cedric@iprg.nokia.com; erafodo@ESEALNT448.al.sw.ericsson.se Cc: nsis@ietf.org; Hemant.Chaskar@nokia.com; 'seamoby@ietf.org' Subject: RE: what is edge signalling? (was: RE: [NSIS] Re: Comments on dra ft-westphal-nsis-qos-mobileip-00.txt) hi gary, my comments are purely on draft-westphal-nsis-qos-mobileip and associated email discussions (since that's been the only input I have seen recently which explicitly discusses the relationship between CT and NSIS, and which I had worries about). in particular, any comments I make about MN-AR signalling are really to emphasise the difference between the cases of a) not having CT signalling that carries QoS information MN-AR (if there is or isn't other CT signalling I don't really care), and b) having CT signalling that does carry QoS information MN-AR, which seems to be the assumption of the mentioned draft. our recent framework activities assumed (a). if you're saying that the seamoby w.g. requirements also impose (a), that's fine by me. i also don't want to re-open old discussions (certainly not on the nsis list, anyway). i suspect we're basically in agreement about NSIS/CT relationships: after a handover, if CT happened, it should be possible to have less NSIS signalling on the on-path segment which goes over the air. cheers, robert h. PS referring to a previous email, i think the view that NSIS is "likely to be of limited use in mobility situations" is rather pessimistic. i would rather say that if you want the resources signalled for by NSIS to be available seamlessly over handovers, you'll need something else as well, which could be CT. the basic point seems to be that NSIS shouldn't try to solve the cross-path context/state transfer problem - any more than CT should try to solve the along-path context/state establishment problem. [gwk] I agree. I was not trying to be as much pessimistic, as I was pushing back against this concept that NSIS + LMM => Seamless Mobility. To be more precise, if it takes longer then a few 10s of ms to set up the new, conditioned path, then the handover will likely not be seamless in 3G. Signalling, particularly over the air (again, 3G), takes relatively significant amount of time to complete. 10s of ms is a rough approximation, but if you are running voice frames, more then, say 20ms of additional handover delay will start impinging on the service requirements for the voice - i.e. either frames have to be dropped or delayed beyond the performance constraint. It is difficult to pin down these numbers, particularly in an IETF email list, but any delay budget analysis that I have seen usually yields numbers in the stated range (keep in mind that delay/drop allowances have to be budgeted for other components of the access network and for the link layer handover). NSIS + LMM (or some variant of MIP) might be one approach to mobility. Fine, but given what I understand about what NSIS is, and is not, it can never be any where near as seamless as a solution that incorporates CT. Is CT simply an "optimization" - well, that depends on how much service disruption the user can tolerate. Usually, there is a threshold where the service is simply considered unusable. Cheers, Gary ------_=_NextPart_001_01C22439.366620D6 Content-Type: text/html; charset="iso-8859-1" RE: what is edge signalling? (was: RE: [NSIS] Re: Comments on dra ft-westphal-nsis-qos-mobileip-00.txt)
Robert:
 
  I will have to read Cedric's draft. I wasn't aware that it discussed CT. With deference to Cedric, and what I am sure is a thoughtful
analysis, it seems to me that understanding the relationship between CT and NSIS would require, at the very least, a CT solution, or
something close to a CT solution. Clearly there is a difference of opinion as to what CT should be (the requirements draft is apparently
going to go through another revision, so who knows?).
 
  In my view, if CT is in place, then NSIS should not be invoked as a result of a handover. A pretty simple relationship. The only exception
that I can imagine is if there is some impact on a service that is not provided at an ANR (i.e. an AR or an internal router), then NSIS may
be required to maintain that service. However, I could not name this service at this point.
-----Original Message-----
From: Hancock, Robert [mailto:robert.hancock@roke.co.uk]
Sent: July 5, 2002 10:59
To: Kenward, Gary [WDLN2:AN10:EXCH]; 'brunner@ccrle.nec.de'; john.loughney@nokia.com; cedric@iprg.nokia.com; erafodo@ESEALNT448.al.sw.ericsson.se
Cc: nsis@ietf.org; Hemant.Chaskar@nokia.com; 'seamoby@ietf.org'
Subject: RE: what is edge signalling? (was: RE: [NSIS] Re: Comments on dra ft-westphal-nsis-qos-mobileip-00.txt)

hi gary,
 
my comments are purely on draft-westphal-nsis-qos-mobileip and associated email discussions (since that's been the only input I have seen recently which explicitly discusses the relationship between CT and NSIS, and which I had worries about).
in particular, any comments I make about MN-AR signalling are really to emphasise the difference between the cases of
a) not having CT signalling that carries QoS information MN-AR (if there is or isn't other CT signalling I don't really care), and
b) having CT signalling that does carry QoS information MN-AR, which seems to be the assumption of the mentioned draft.
 
our recent framework activities assumed (a). if you're saying that the seamoby w.g. requirements also impose (a), that's fine by me. i also don't want to re-open old discussions (certainly not on the nsis list, anyway).
 
i suspect we're basically in agreement about NSIS/CT relationships: after a handover, if CT happened, it should be possible to have less NSIS signalling on the on-path segment which goes over the air.
 
cheers,
 
robert h.
 
PS referring to a previous email, i think the view that NSIS is "likely to be of limited use in mobility situations" is rather pessimistic. i would rather say that if you want the resources signalled for by NSIS to be available seamlessly over handovers, you'll need something else as well, which could be CT. the basic point seems to be that NSIS shouldn't try to solve the cross-path context/state transfer problem - any more than CT should try to solve the along-path context/state establishment problem.
[gwk] I agree. I was not trying to be as much pessimistic, as I was pushing back against this concept that NSIS + LMM => Seamless Mobility. To be more precise,
if it takes longer then a few 10s of ms to set up the new, conditioned path, then the handover will likely not be seamless in 3G. Signalling, particularly over the
air (again, 3G), takes relatively significant amount of time to complete. 10s of ms is a rough approximation, but if you are running voice frames, more then, say
20ms of additional handover delay will start  impinging on the service requirements for the voice - i.e. either frames have to be dropped or delayed beyond
the performance constraint. It is difficult to pin down these numbers, particularly in an IETF email list, but any delay budget analysis that I have seen usually
yields numbers in the stated range (keep in mind that delay/drop allowances have to be budgeted for other components of the access network and for the
link layer handover).
 
NSIS + LMM (or some variant of MIP) might be one approach to mobility. Fine, but given what I understand about what NSIS is, and is not, it can never be
any where near as seamless as a solution that incorporates CT. Is CT simply an "optimization" - well, that depends on how much service disruption the user
can tolerate. Usually, there is a threshold where the service is simply considered unusable.
 
Cheers,
Gary
------_=_NextPart_001_01C22439.366620D6-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Fri Jul 5 11:45:17 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00303 for ; Fri, 5 Jul 2002 11:45:17 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA09061 for seamoby-archive@odin.ietf.org; Fri, 5 Jul 2002 11:46:08 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA08669; Fri, 5 Jul 2002 11:33:48 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA08605 for ; Fri, 5 Jul 2002 11:33:44 -0400 (EDT) Received: from zcars04f.ca.nortel.com (zcars04f.nortelnetworks.com [47.129.242.57]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29806; Fri, 5 Jul 2002 11:32:53 -0400 (EDT) Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04f.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g65FWl311631; Fri, 5 Jul 2002 11:32:47 -0400 (EDT) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 5 Jul 2002 11:32:47 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA4BDC@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'Hancock, Robert'" , "'brunner@ccrle.nec.de'" , john.loughney@nokia.com, cedric@iprg.nokia.com, erafodo@ESEALNT448.al.sw.ericsson.se Cc: nsis@ietf.org, Hemant.Chaskar@nokia.com, "'seamoby@ietf.org'" Date: Fri, 5 Jul 2002 11:32:46 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C22439.366620D6" Subject: [Seamoby] RE: what is edge signalling? (was: RE: [NSIS] Re: Comments on dra ft-westphal-nsis-qos-mobileip-00.txt) Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C22439.366620D6 Content-Type: text/plain; charset="iso-8859-1" Robert: I will have to read Cedric's draft. I wasn't aware that it discussed CT. With deference to Cedric, and what I am sure is a thoughtful analysis, it seems to me that understanding the relationship between CT and NSIS would require, at the very least, a CT solution, or something close to a CT solution. Clearly there is a difference of opinion as to what CT should be (the requirements draft is apparently going to go through another revision, so who knows?). In my view, if CT is in place, then NSIS should not be invoked as a result of a handover. A pretty simple relationship. The only exception that I can imagine is if there is some impact on a service that is not provided at an ANR (i.e. an AR or an internal router), then NSIS may be required to maintain that service. However, I could not name this service at this point. -----Original Message----- From: Hancock, Robert [mailto:robert.hancock@roke.co.uk] Sent: July 5, 2002 10:59 To: Kenward, Gary [WDLN2:AN10:EXCH]; 'brunner@ccrle.nec.de'; john.loughney@nokia.com; cedric@iprg.nokia.com; erafodo@ESEALNT448.al.sw.ericsson.se Cc: nsis@ietf.org; Hemant.Chaskar@nokia.com; 'seamoby@ietf.org' Subject: RE: what is edge signalling? (was: RE: [NSIS] Re: Comments on dra ft-westphal-nsis-qos-mobileip-00.txt) hi gary, my comments are purely on draft-westphal-nsis-qos-mobileip and associated email discussions (since that's been the only input I have seen recently which explicitly discusses the relationship between CT and NSIS, and which I had worries about). in particular, any comments I make about MN-AR signalling are really to emphasise the difference between the cases of a) not having CT signalling that carries QoS information MN-AR (if there is or isn't other CT signalling I don't really care), and b) having CT signalling that does carry QoS information MN-AR, which seems to be the assumption of the mentioned draft. our recent framework activities assumed (a). if you're saying that the seamoby w.g. requirements also impose (a), that's fine by me. i also don't want to re-open old discussions (certainly not on the nsis list, anyway). i suspect we're basically in agreement about NSIS/CT relationships: after a handover, if CT happened, it should be possible to have less NSIS signalling on the on-path segment which goes over the air. cheers, robert h. PS referring to a previous email, i think the view that NSIS is "likely to be of limited use in mobility situations" is rather pessimistic. i would rather say that if you want the resources signalled for by NSIS to be available seamlessly over handovers, you'll need something else as well, which could be CT. the basic point seems to be that NSIS shouldn't try to solve the cross-path context/state transfer problem - any more than CT should try to solve the along-path context/state establishment problem. [gwk] I agree. I was not trying to be as much pessimistic, as I was pushing back against this concept that NSIS + LMM => Seamless Mobility. To be more precise, if it takes longer then a few 10s of ms to set up the new, conditioned path, then the handover will likely not be seamless in 3G. Signalling, particularly over the air (again, 3G), takes relatively significant amount of time to complete. 10s of ms is a rough approximation, but if you are running voice frames, more then, say 20ms of additional handover delay will start impinging on the service requirements for the voice - i.e. either frames have to be dropped or delayed beyond the performance constraint. It is difficult to pin down these numbers, particularly in an IETF email list, but any delay budget analysis that I have seen usually yields numbers in the stated range (keep in mind that delay/drop allowances have to be budgeted for other components of the access network and for the link layer handover). NSIS + LMM (or some variant of MIP) might be one approach to mobility. Fine, but given what I understand about what NSIS is, and is not, it can never be any where near as seamless as a solution that incorporates CT. Is CT simply an "optimization" - well, that depends on how much service disruption the user can tolerate. Usually, there is a threshold where the service is simply considered unusable. Cheers, Gary ------_=_NextPart_001_01C22439.366620D6 Content-Type: text/html; charset="iso-8859-1" RE: what is edge signalling? (was: RE: [NSIS] Re: Comments on dra ft-westphal-nsis-qos-mobileip-00.txt)
Robert:
 
  I will have to read Cedric's draft. I wasn't aware that it discussed CT. With deference to Cedric, and what I am sure is a thoughtful
analysis, it seems to me that understanding the relationship between CT and NSIS would require, at the very least, a CT solution, or
something close to a CT solution. Clearly there is a difference of opinion as to what CT should be (the requirements draft is apparently
going to go through another revision, so who knows?).
 
  In my view, if CT is in place, then NSIS should not be invoked as a result of a handover. A pretty simple relationship. The only exception
that I can imagine is if there is some impact on a service that is not provided at an ANR (i.e. an AR or an internal router), then NSIS may
be required to maintain that service. However, I could not name this service at this point.
-----Original Message-----
From: Hancock, Robert [mailto:robert.hancock@roke.co.uk]
Sent: July 5, 2002 10:59
To: Kenward, Gary [WDLN2:AN10:EXCH]; 'brunner@ccrle.nec.de'; john.loughney@nokia.com; cedric@iprg.nokia.com; erafodo@ESEALNT448.al.sw.ericsson.se
Cc: nsis@ietf.org; Hemant.Chaskar@nokia.com; 'seamoby@ietf.org'
Subject: RE: what is edge signalling? (was: RE: [NSIS] Re: Comments on dra ft-westphal-nsis-qos-mobileip-00.txt)

hi gary,
 
my comments are purely on draft-westphal-nsis-qos-mobileip and associated email discussions (since that's been the only input I have seen recently which explicitly discusses the relationship between CT and NSIS, and which I had worries about).
in particular, any comments I make about MN-AR signalling are really to emphasise the difference between the cases of
a) not having CT signalling that carries QoS information MN-AR (if there is or isn't other CT signalling I don't really care), and
b) having CT signalling that does carry QoS information MN-AR, which seems to be the assumption of the mentioned draft.
 
our recent framework activities assumed (a). if you're saying that the seamoby w.g. requirements also impose (a), that's fine by me. i also don't want to re-open old discussions (certainly not on the nsis list, anyway).
 
i suspect we're basically in agreement about NSIS/CT relationships: after a handover, if CT happened, it should be possible to have less NSIS signalling on the on-path segment which goes over the air.
 
cheers,
 
robert h.
 
PS referring to a previous email, i think the view that NSIS is "likely to be of limited use in mobility situations" is rather pessimistic. i would rather say that if you want the resources signalled for by NSIS to be available seamlessly over handovers, you'll need something else as well, which could be CT. the basic point seems to be that NSIS shouldn't try to solve the cross-path context/state transfer problem - any more than CT should try to solve the along-path context/state establishment problem.
[gwk] I agree. I was not trying to be as much pessimistic, as I was pushing back against this concept that NSIS + LMM => Seamless Mobility. To be more precise,
if it takes longer then a few 10s of ms to set up the new, conditioned path, then the handover will likely not be seamless in 3G. Signalling, particularly over the
air (again, 3G), takes relatively significant amount of time to complete. 10s of ms is a rough approximation, but if you are running voice frames, more then, say
20ms of additional handover delay will start  impinging on the service requirements for the voice - i.e. either frames have to be dropped or delayed beyond
the performance constraint. It is difficult to pin down these numbers, particularly in an IETF email list, but any delay budget analysis that I have seen usually
yields numbers in the stated range (keep in mind that delay/drop allowances have to be budgeted for other components of the access network and for the
link layer handover).
 
NSIS + LMM (or some variant of MIP) might be one approach to mobility. Fine, but given what I understand about what NSIS is, and is not, it can never be
any where near as seamless as a solution that incorporates CT. Is CT simply an "optimization" - well, that depends on how much service disruption the user
can tolerate. Usually, there is a threshold where the service is simply considered unusable.
 
Cheers,
Gary
------_=_NextPart_001_01C22439.366620D6-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Fri Jul 5 11:49:23 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00636 for ; Fri, 5 Jul 2002 11:49:23 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA08998; Fri, 5 Jul 2002 11:45:14 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA08969 for ; Fri, 5 Jul 2002 11:45:12 -0400 (EDT) Received: from fridge.docomolabs-usa.com (fwuser@key1.docomolabs-usa.com [216.98.102.225]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00205 for ; Fri, 5 Jul 2002 11:44:20 -0400 (EDT) Message-ID: <00cc01c2243a$b7f6e7b0$4f6015ac@T23KEMPF> From: "James Kempf" To: Date: Fri, 5 Jul 2002 08:43:33 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Seamoby] Conclusion of Last Call on draft-ietf-seamoby-cardiscovery-issues-03.txt Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit WG last call on draft-ietf-seamoby-cardiscovery-issues-03.txt has concluded with no WG comments. The draft will now be sent to the IESG. _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Fri Jul 5 11:49:24 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00643 for ; Fri, 5 Jul 2002 11:49:24 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA09159 for seamoby-archive@odin.ietf.org; Fri, 5 Jul 2002 11:50:14 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA08998; Fri, 5 Jul 2002 11:45:14 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA08969 for ; Fri, 5 Jul 2002 11:45:12 -0400 (EDT) Received: from fridge.docomolabs-usa.com (fwuser@key1.docomolabs-usa.com [216.98.102.225]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00205 for ; Fri, 5 Jul 2002 11:44:20 -0400 (EDT) Message-ID: <00cc01c2243a$b7f6e7b0$4f6015ac@T23KEMPF> From: "James Kempf" To: Date: Fri, 5 Jul 2002 08:43:33 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Seamoby] Conclusion of Last Call on draft-ietf-seamoby-cardiscovery-issues-03.txt Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit WG last call on draft-ietf-seamoby-cardiscovery-issues-03.txt has concluded with no WG comments. The draft will now be sent to the IESG. _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Fri Jul 5 12:11:15 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02053 for ; Fri, 5 Jul 2002 12:11:15 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA11066; Fri, 5 Jul 2002 12:06:03 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA11035 for ; Fri, 5 Jul 2002 12:06:01 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01650; Fri, 5 Jul 2002 12:05:08 -0400 (EDT) Message-Id: <200207051605.MAA01650@ietf.org> To: IETF-Announce: ; Cc: RFC Editor , Internet Architecture Board , seamoby@ietf.org From: The IESG Date: Fri, 05 Jul 2002 12:05:08 -0400 Subject: [Seamoby] Document Action: Problem Description: Reasons For Performing Context Transfers Between Nodes in an IP Access Network to Informational Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org The IESG has approved the Internet-Draft 'Problem Description: Reasons For Performing Context Transfers Between Nodes in an IP Access Network' for publiction as an Informational RFC. This document is the product of the Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting Working Group. The IESG contact persons are Allison Mankin and Scott Bradner. _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Fri Jul 5 12:11:16 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02062 for ; Fri, 5 Jul 2002 12:11:16 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA11373 for seamoby-archive@odin.ietf.org; Fri, 5 Jul 2002 12:12:05 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA11066; Fri, 5 Jul 2002 12:06:03 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA11035 for ; Fri, 5 Jul 2002 12:06:01 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01650; Fri, 5 Jul 2002 12:05:08 -0400 (EDT) Message-Id: <200207051605.MAA01650@ietf.org> To: IETF-Announce: ; Cc: RFC Editor , Internet Architecture Board , seamoby@ietf.org From: The IESG Date: Fri, 05 Jul 2002 12:05:08 -0400 Subject: [Seamoby] Document Action: Problem Description: Reasons For Performing Context Transfers Between Nodes in an IP Access Network to Informational Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org The IESG has approved the Internet-Draft 'Problem Description: Reasons For Performing Context Transfers Between Nodes in an IP Access Network' for publiction as an Informational RFC. This document is the product of the Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting Working Group. The IESG contact persons are Allison Mankin and Scott Bradner. _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Mon Jul 8 05:06:59 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08520 for ; Mon, 8 Jul 2002 05:06:59 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA03657; Mon, 8 Jul 2002 05:03:10 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA03602 for ; Mon, 8 Jul 2002 05:03:07 -0400 (EDT) Received: from tokyo.ccrle.nec.de ([195.37.70.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08447; Mon, 8 Jul 2002 05:02:13 -0400 (EDT) Received: from wallace.heidelberg.ccrle.nec.de (root@wallace.heidelberg.ccrle.nec.de [192.168.102.1]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id g688RwI96995; Mon, 8 Jul 2002 10:27:58 +0200 (CEST) (envelope-from brunner@ccrle.nec.de) Received: from imap.heidelberg.ccrle.nec.de (imap.heidelberg.ccrle.nec.de [192.168.102.11]) by wallace.heidelberg.ccrle.nec.de (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id KAA19353; Mon, 8 Jul 2002 10:28:16 +0200 Received: from [192.168.102.207] (marcus.heidelberg.ccrle.nec.de [192.168.102.207]) by imap.heidelberg.ccrle.nec.de (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id AFE0651C48; Mon, 8 Jul 2002 10:27:56 +0200 (CEST) Date: Mon, 08 Jul 2002 10:28:15 +0200 From: Marcus Brunner Reply-To: brunner@ccrle.nec.de To: Gary Kenward , "'Hancock, Robert'" , john.loughney@nokia.com, cedric@iprg.nokia.com, erafodo@ESEALNT448.al.sw.ericsson.se Cc: nsis@ietf.org, Hemant.Chaskar@nokia.com, "'seamoby@ietf.org'" Message-ID: <1534506.1026124095@[192.168.102.207]> In-Reply-To: <9FBD322B7824D511B36900508BF93C9C01AA4BDC@zcard031.ca.nortel.com> References: <9FBD322B7824D511B36900508BF93C9C01AA4BDC@zcard031.ca.nortel.com > X-Mailer: Mulberry/2.2.0 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit Subject: [Seamoby] RE: what is edge signalling? (was: RE: [NSIS] Re: Comments on dra ft-westphal-nsis-qos-mobileip-00.txt) Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit > In my view, if CT is in place, then NSIS should not be invoked as a > result of a handover. A pretty simple relationship. The only exception > that I can imagine is if there is some impact on a service that is not > provided at an ANR (i.e. an AR or an internal router), then NSIS may be > required to maintain that service. However, I could not name this service > at this point. I don't see how CT can work without NSIS in the general case. If all your AR are connected to the swame next hop router, it may work. Generally, you might need to signal to the far end after handover. Marcus > > > -----Original Message----- > From: Hancock, Robert [mailto:robert.hancock@roke.co.uk] > Sent: July 5, 2002 10:59 > To: Kenward, Gary [WDLN2:AN10:EXCH]; 'brunner@ccrle.nec.de'; > john.loughney@nokia.com; cedric@iprg.nokia.com; > erafodo@ESEALNT448.al.sw.ericsson.se Cc: nsis@ietf.org; > Hemant.Chaskar@nokia.com; 'seamoby@ietf.org' > Subject: RE: what is edge signalling? (was: RE: [NSIS] Re: Comments on > dra ft-westphal-nsis-qos-mobileip-00.txt) > > > hi gary, > > my comments are purely on draft-westphal-nsis-qos-mobileip and associated > email discussions (since that's been the only input I have seen recently > which explicitly discusses the relationship between CT and NSIS, and > which I had worries about). in particular, any comments I make about > MN-AR signalling are really to emphasise the difference between the cases > of a) not having CT signalling that carries QoS information MN-AR (if > there is or isn't other CT signalling I don't really care), and b) > having CT signalling that does carry QoS information MN-AR, which seems > to be the assumption of the mentioned draft. > our recent framework activities assumed (a). if you're saying that the > seamoby w.g. requirements also impose (a), that's fine by me. i also > don't want to re-open old discussions (certainly not on the nsis list, > anyway). > i suspect we're basically in agreement about NSIS/CT relationships: after > a handover, if CT happened, it should be possible to have less NSIS > signalling on the on-path segment which goes over the air. > cheers, > > robert h. > > PS referring to a previous email, i think the view that NSIS is "likely > to be of limited use in mobility situations" is rather pessimistic. i > would rather say that if you want the resources signalled for by NSIS to > be available seamlessly over handovers, you'll need something else as > well, which could be CT. the basic point seems to be that NSIS shouldn't > try to solve the cross-path context/state transfer problem - any more > than CT should try to solve the along-path context/state establishment > problem. [gwk] I agree. I was not trying to be as much pessimistic, as I > was pushing back against this concept that NSIS + LMM => Seamless > Mobility. To be more precise, if it takes longer then a few 10s of ms to > set up the new, conditioned path, then the handover will likely not be > seamless in 3G. Signalling, particularly over the air (again, 3G), takes > relatively significant amount of time to complete. 10s of ms is a rough > approximation, but if you are running voice frames, more then, say 20ms > of additional handover delay will start impinging on the service > requirements for the voice - i.e. either frames have to be dropped or > delayed beyond the performance constraint. It is difficult to pin down > these numbers, particularly in an IETF email list, but any delay budget > analysis that I have seen usually yields numbers in the stated range > (keep in mind that delay/drop allowances have to be budgeted for other > components of the access network and for the link layer handover). > > NSIS + LMM (or some variant of MIP) might be one approach to mobility. > Fine, but given what I understand about what NSIS is, and is not, it can > never be any where near as seamless as a solution that incorporates CT. > Is CT simply an "optimization" - well, that depends on how much service > disruption the user can tolerate. Usually, there is a threshold where > the service is simply considered unusable. > Cheers, > Gary > -------------------------------------- Dr. Marcus Brunner Network Laboratories NEC Europe Ltd. E-Mail: brunner@ccrle.nec.de WWW: http://www.ccrle.nec.de/ personal home page: http://www.brubers.org/marcus _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Mon Jul 8 05:06:59 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08528 for ; Mon, 8 Jul 2002 05:06:59 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id FAA03831 for seamoby-archive@odin.ietf.org; Mon, 8 Jul 2002 05:07:51 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA03657; Mon, 8 Jul 2002 05:03:10 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA03602 for ; Mon, 8 Jul 2002 05:03:07 -0400 (EDT) Received: from tokyo.ccrle.nec.de ([195.37.70.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08447; Mon, 8 Jul 2002 05:02:13 -0400 (EDT) Received: from wallace.heidelberg.ccrle.nec.de (root@wallace.heidelberg.ccrle.nec.de [192.168.102.1]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id g688RwI96995; Mon, 8 Jul 2002 10:27:58 +0200 (CEST) (envelope-from brunner@ccrle.nec.de) Received: from imap.heidelberg.ccrle.nec.de (imap.heidelberg.ccrle.nec.de [192.168.102.11]) by wallace.heidelberg.ccrle.nec.de (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id KAA19353; Mon, 8 Jul 2002 10:28:16 +0200 Received: from [192.168.102.207] (marcus.heidelberg.ccrle.nec.de [192.168.102.207]) by imap.heidelberg.ccrle.nec.de (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id AFE0651C48; Mon, 8 Jul 2002 10:27:56 +0200 (CEST) Date: Mon, 08 Jul 2002 10:28:15 +0200 From: Marcus Brunner Reply-To: brunner@ccrle.nec.de To: Gary Kenward , "'Hancock, Robert'" , john.loughney@nokia.com, cedric@iprg.nokia.com, erafodo@ESEALNT448.al.sw.ericsson.se Cc: nsis@ietf.org, Hemant.Chaskar@nokia.com, "'seamoby@ietf.org'" Message-ID: <1534506.1026124095@[192.168.102.207]> In-Reply-To: <9FBD322B7824D511B36900508BF93C9C01AA4BDC@zcard031.ca.nortel.com> References: <9FBD322B7824D511B36900508BF93C9C01AA4BDC@zcard031.ca.nortel.com > X-Mailer: Mulberry/2.2.0 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit Subject: [Seamoby] RE: what is edge signalling? (was: RE: [NSIS] Re: Comments on dra ft-westphal-nsis-qos-mobileip-00.txt) Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit > In my view, if CT is in place, then NSIS should not be invoked as a > result of a handover. A pretty simple relationship. The only exception > that I can imagine is if there is some impact on a service that is not > provided at an ANR (i.e. an AR or an internal router), then NSIS may be > required to maintain that service. However, I could not name this service > at this point. I don't see how CT can work without NSIS in the general case. If all your AR are connected to the swame next hop router, it may work. Generally, you might need to signal to the far end after handover. Marcus > > > -----Original Message----- > From: Hancock, Robert [mailto:robert.hancock@roke.co.uk] > Sent: July 5, 2002 10:59 > To: Kenward, Gary [WDLN2:AN10:EXCH]; 'brunner@ccrle.nec.de'; > john.loughney@nokia.com; cedric@iprg.nokia.com; > erafodo@ESEALNT448.al.sw.ericsson.se Cc: nsis@ietf.org; > Hemant.Chaskar@nokia.com; 'seamoby@ietf.org' > Subject: RE: what is edge signalling? (was: RE: [NSIS] Re: Comments on > dra ft-westphal-nsis-qos-mobileip-00.txt) > > > hi gary, > > my comments are purely on draft-westphal-nsis-qos-mobileip and associated > email discussions (since that's been the only input I have seen recently > which explicitly discusses the relationship between CT and NSIS, and > which I had worries about). in particular, any comments I make about > MN-AR signalling are really to emphasise the difference between the cases > of a) not having CT signalling that carries QoS information MN-AR (if > there is or isn't other CT signalling I don't really care), and b) > having CT signalling that does carry QoS information MN-AR, which seems > to be the assumption of the mentioned draft. > our recent framework activities assumed (a). if you're saying that the > seamoby w.g. requirements also impose (a), that's fine by me. i also > don't want to re-open old discussions (certainly not on the nsis list, > anyway). > i suspect we're basically in agreement about NSIS/CT relationships: after > a handover, if CT happened, it should be possible to have less NSIS > signalling on the on-path segment which goes over the air. > cheers, > > robert h. > > PS referring to a previous email, i think the view that NSIS is "likely > to be of limited use in mobility situations" is rather pessimistic. i > would rather say that if you want the resources signalled for by NSIS to > be available seamlessly over handovers, you'll need something else as > well, which could be CT. the basic point seems to be that NSIS shouldn't > try to solve the cross-path context/state transfer problem - any more > than CT should try to solve the along-path context/state establishment > problem. [gwk] I agree. I was not trying to be as much pessimistic, as I > was pushing back against this concept that NSIS + LMM => Seamless > Mobility. To be more precise, if it takes longer then a few 10s of ms to > set up the new, conditioned path, then the handover will likely not be > seamless in 3G. Signalling, particularly over the air (again, 3G), takes > relatively significant amount of time to complete. 10s of ms is a rough > approximation, but if you are running voice frames, more then, say 20ms > of additional handover delay will start impinging on the service > requirements for the voice - i.e. either frames have to be dropped or > delayed beyond the performance constraint. It is difficult to pin down > these numbers, particularly in an IETF email list, but any delay budget > analysis that I have seen usually yields numbers in the stated range > (keep in mind that delay/drop allowances have to be budgeted for other > components of the access network and for the link layer handover). > > NSIS + LMM (or some variant of MIP) might be one approach to mobility. > Fine, but given what I understand about what NSIS is, and is not, it can > never be any where near as seamless as a solution that incorporates CT. > Is CT simply an "optimization" - well, that depends on how much service > disruption the user can tolerate. Usually, there is a threshold where > the service is simply considered unusable. > Cheers, > Gary > -------------------------------------- Dr. Marcus Brunner Network Laboratories NEC Europe Ltd. E-Mail: brunner@ccrle.nec.de WWW: http://www.ccrle.nec.de/ personal home page: http://www.brubers.org/marcus _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Mon Jul 8 10:23:05 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16264 for ; Mon, 8 Jul 2002 10:23:05 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA19257; Mon, 8 Jul 2002 10:17:43 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA19198 for ; Mon, 8 Jul 2002 10:17:40 -0400 (EDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15923; Mon, 8 Jul 2002 10:16:47 -0400 (EDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id HAA15938; Mon, 8 Jul 2002 07:17:05 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g68EH4t26649; Mon, 8 Jul 2002 07:17:04 -0700 X-mProtect: <200207081417> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.22.18, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdxpq7Th; Mon, 08 Jul 2002 07:17:02 PDT Message-ID: <3D299E8D.9E31EFD2@iprg.nokia.com> Date: Mon, 08 Jul 2002 07:15:41 -0700 From: Charlie Perkins Organization: Nokia X-Mailer: Mozilla 4.75 [en]C-CCK-MCD {Nokia} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Gary Kenward CC: nsis@ietf.org, "'seamoby@ietf.org'" Subject: Re: [Seamoby] RE: what is edge signalling? (was: RE: [NSIS] Re: Comments on draft-westphal-nsis-qos-mobileip-00.txt) References: <9FBD322B7824D511B36900508BF93C9C01AA4BDC@zcard031.ca.nortel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit Hello Gary, I have a comment on another point in your earlier message. Gary Kenward wrote: > In my view, if CT is in place, then NSIS should not be invoked as a > result of a handover. Suppose a handover has occurred, and some QoS has been negotiated via CT between two access routers to support the mobile node at the new access routers. This could involve having the new router making sure it has sufficient capacity to support the mobile device, and making sure that the tunnel between the two routers can be managed with small enough delay. Then, after the handover is complete, it might be better to renegotiate QoS so that the previous access router no longer was required to maintain the excess capacity needed to serve the tunnel to the new access router. This could involve signaling so that packets are routed directly to the new access router, presumably with some QoS negotiation. This could involve NSIS. Thus, I don't agree with your statement above. But I am willing to agree that CT should not necessarily be intertwined with NSIS. Regards, Charlie P. > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Mon Jul 8 10:23:06 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16269 for ; Mon, 8 Jul 2002 10:23:06 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA19800 for seamoby-archive@odin.ietf.org; Mon, 8 Jul 2002 10:23:57 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA19257; Mon, 8 Jul 2002 10:17:43 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA19198 for ; Mon, 8 Jul 2002 10:17:40 -0400 (EDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15923; Mon, 8 Jul 2002 10:16:47 -0400 (EDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id HAA15938; Mon, 8 Jul 2002 07:17:05 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g68EH4t26649; Mon, 8 Jul 2002 07:17:04 -0700 X-mProtect: <200207081417> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.22.18, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdxpq7Th; Mon, 08 Jul 2002 07:17:02 PDT Message-ID: <3D299E8D.9E31EFD2@iprg.nokia.com> Date: Mon, 08 Jul 2002 07:15:41 -0700 From: Charlie Perkins Organization: Nokia X-Mailer: Mozilla 4.75 [en]C-CCK-MCD {Nokia} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Gary Kenward CC: nsis@ietf.org, "'seamoby@ietf.org'" Subject: Re: [Seamoby] RE: what is edge signalling? (was: RE: [NSIS] Re: Comments on draft-westphal-nsis-qos-mobileip-00.txt) References: <9FBD322B7824D511B36900508BF93C9C01AA4BDC@zcard031.ca.nortel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit Hello Gary, I have a comment on another point in your earlier message. Gary Kenward wrote: > In my view, if CT is in place, then NSIS should not be invoked as a > result of a handover. Suppose a handover has occurred, and some QoS has been negotiated via CT between two access routers to support the mobile node at the new access routers. This could involve having the new router making sure it has sufficient capacity to support the mobile device, and making sure that the tunnel between the two routers can be managed with small enough delay. Then, after the handover is complete, it might be better to renegotiate QoS so that the previous access router no longer was required to maintain the excess capacity needed to serve the tunnel to the new access router. This could involve signaling so that packets are routed directly to the new access router, presumably with some QoS negotiation. This could involve NSIS. Thus, I don't agree with your statement above. But I am willing to agree that CT should not necessarily be intertwined with NSIS. Regards, Charlie P. > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Mon Jul 8 10:42:08 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17202 for ; Mon, 8 Jul 2002 10:42:08 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA21129; Mon, 8 Jul 2002 10:38:00 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA21068 for ; Mon, 8 Jul 2002 10:37:57 -0400 (EDT) Received: from zcars04f.ca.nortel.com (zcars04f.nortelnetworks.com [47.129.242.57]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17001; Mon, 8 Jul 2002 10:37:04 -0400 (EDT) Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04f.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g68Eb3I09546; Mon, 8 Jul 2002 10:37:03 -0400 (EDT) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 8 Jul 2002 10:37:02 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA4BE9@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'Charlie Perkins'" Cc: nsis@ietf.org, "'seamoby@ietf.org'" Subject: RE: [Seamoby] RE: what is edge signalling? (was: RE: [NSIS] Re: C omments on draft-westphal-nsis-qos-mobileip-00.txt) Date: Mon, 8 Jul 2002 10:36:54 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2268C.E78AED56" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C2268C.E78AED56 Content-Type: text/plain; charset="iso-8859-1" Charlie: I guess the word "negotiate" really trips me up here. CT is a protocol for transferring forwarding service context, not for negotiating services between ARs. If service negotiation is required, then NSIS could be the protocol to be used. In my statement that you quote below, I used the words "should not": in the normal course of a handover, service negotiation must be rare. Negotiation, by definition, takes time, and anything that takes time will generally delay the service from being supported at the new AR. In the normal course of a handover, less signalling is always better. In wireless, of course, the exception is the rule, and so there must be contingencies for service negotiation. This would be NSIS' role. And so, I did not make my point clear. My main intent was to emphasize that if there is a link between CT and NSIS, it is a very simple one: if CT fails to provide a context that is useable by the new AR, then NSIS may be used to negotiate a suitable service with the network (and thus establish suitable context at the new AR). Cheers, Gary > -----Original Message----- > From: Charlie Perkins [mailto:charliep@iprg.nokia.com] > Sent: July 8, 2002 10:16 > To: Kenward, Gary [WDLN2:AN10:EXCH] > Cc: nsis@ietf.org; 'seamoby@ietf.org' > Subject: Re: [Seamoby] RE: what is edge signalling? (was: RE: > [NSIS] Re: > Comments on draft-westphal-nsis-qos-mobileip-00.txt) > > > > Hello Gary, > > I have a comment on another point in your earlier message. > > Gary Kenward wrote: > > > In my view, if CT is in place, then NSIS should not be invoked as a > > result of a handover. > > Suppose a handover has occurred, and some QoS has been negotiated > via CT between two access routers to support the mobile node > at the new > access routers. This could involve having the new router making sure > it has sufficient capacity to support the mobile device, and > making sure > > that the tunnel between the two routers can be managed with small > enough delay. > > Then, after the handover is complete, it might be better to > renegotiate > QoS so that the previous access router no longer was required to > maintain the excess capacity needed to serve the tunnel to the new > access router. This could involve signaling so that packets are > routed directly to the new access router, presumably with some QoS > negotiation. This could involve NSIS. > > Thus, I don't agree with your statement above. But I am willing to > agree > that CT should not necessarily be intertwined with NSIS. > > Regards, > Charlie P. > > > > > > > ------_=_NextPart_001_01C2268C.E78AED56 Content-Type: text/html; charset="iso-8859-1" RE: [Seamoby] RE: what is edge signalling? (was: RE: [NSIS] Re: Comments on draft-westphal-nsis-qos-mobileip-00.txt)

Charlie:

  I guess the word "negotiate" really trips me up here. CT is a
protocol for transferring forwarding service context, not for negotiating
services between ARs. If service negotiation is required, then NSIS could be
the protocol to be used.

  In my statement that you quote below, I used the words "should not": in
the normal course of a handover, service negotiation must be rare. Negotiation,
by definition, takes time, and anything that takes time will generally delay
the service from being supported at the new AR. In the normal course of a handover,
less signalling is always better.

  In wireless, of course, the exception is the rule, and so there must be
contingencies for service negotiation. This would be NSIS' role.

  And so, I did not make my point clear. My main intent was to emphasize that
if there is a link between CT and NSIS, it is a very simple one: if CT fails
to provide a context that is useable by the new AR, then NSIS may be used to
negotiate a suitable service with the network (and thus establish suitable
context at the new AR).

Cheers,
Gary


> -----Original Message-----
> From: Charlie Perkins [mailto:charliep@iprg.nokia.com]
> Sent: July 8, 2002 10:16
> To: Kenward, Gary [WDLN2:AN10:EXCH]
> Cc: nsis@ietf.org; 'seamoby@ietf.org'
> Subject: Re: [Seamoby] RE: what is edge signalling? (was: RE:
> [NSIS] Re:
> Comments on draft-westphal-nsis-qos-mobileip-00.txt)
>
>
>
> Hello Gary,
>
> I have a comment on another point in your earlier message.
>
> Gary Kenward wrote:
>
> > In my view, if CT is in place, then NSIS should not be invoked as a
> > result of a handover.
>
> Suppose a handover has occurred, and some QoS has been negotiated
> via CT between two access routers to support the mobile node
> at the new
> access routers.  This could involve having the new router making sure
> it has sufficient capacity to support the mobile device, and
> making sure
>
> that the tunnel between the two routers can be managed with small
> enough delay.
>
> Then, after the handover is complete, it might be better to
> renegotiate
> QoS so that the previous access router no longer was required to
> maintain the excess capacity needed to serve the tunnel to the new
> access router.  This could involve signaling so that packets are
> routed directly to the new access router, presumably with some QoS
> negotiation.  This could involve NSIS.
>
> Thus, I don't agree with your statement above.  But I am willing to
> agree
> that CT should not necessarily be intertwined with NSIS.
>
> Regards,
> Charlie P.
>
>
>
> >
>
>

------_=_NextPart_001_01C2268C.E78AED56-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Mon Jul 8 10:42:09 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17212 for ; Mon, 8 Jul 2002 10:42:09 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA21358 for seamoby-archive@odin.ietf.org; Mon, 8 Jul 2002 10:43:00 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA21129; Mon, 8 Jul 2002 10:38:00 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA21068 for ; Mon, 8 Jul 2002 10:37:57 -0400 (EDT) Received: from zcars04f.ca.nortel.com (zcars04f.nortelnetworks.com [47.129.242.57]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17001; Mon, 8 Jul 2002 10:37:04 -0400 (EDT) Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04f.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g68Eb3I09546; Mon, 8 Jul 2002 10:37:03 -0400 (EDT) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 8 Jul 2002 10:37:02 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA4BE9@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'Charlie Perkins'" Cc: nsis@ietf.org, "'seamoby@ietf.org'" Subject: RE: [Seamoby] RE: what is edge signalling? (was: RE: [NSIS] Re: C omments on draft-westphal-nsis-qos-mobileip-00.txt) Date: Mon, 8 Jul 2002 10:36:54 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2268C.E78AED56" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C2268C.E78AED56 Content-Type: text/plain; charset="iso-8859-1" Charlie: I guess the word "negotiate" really trips me up here. CT is a protocol for transferring forwarding service context, not for negotiating services between ARs. If service negotiation is required, then NSIS could be the protocol to be used. In my statement that you quote below, I used the words "should not": in the normal course of a handover, service negotiation must be rare. Negotiation, by definition, takes time, and anything that takes time will generally delay the service from being supported at the new AR. In the normal course of a handover, less signalling is always better. In wireless, of course, the exception is the rule, and so there must be contingencies for service negotiation. This would be NSIS' role. And so, I did not make my point clear. My main intent was to emphasize that if there is a link between CT and NSIS, it is a very simple one: if CT fails to provide a context that is useable by the new AR, then NSIS may be used to negotiate a suitable service with the network (and thus establish suitable context at the new AR). Cheers, Gary > -----Original Message----- > From: Charlie Perkins [mailto:charliep@iprg.nokia.com] > Sent: July 8, 2002 10:16 > To: Kenward, Gary [WDLN2:AN10:EXCH] > Cc: nsis@ietf.org; 'seamoby@ietf.org' > Subject: Re: [Seamoby] RE: what is edge signalling? (was: RE: > [NSIS] Re: > Comments on draft-westphal-nsis-qos-mobileip-00.txt) > > > > Hello Gary, > > I have a comment on another point in your earlier message. > > Gary Kenward wrote: > > > In my view, if CT is in place, then NSIS should not be invoked as a > > result of a handover. > > Suppose a handover has occurred, and some QoS has been negotiated > via CT between two access routers to support the mobile node > at the new > access routers. This could involve having the new router making sure > it has sufficient capacity to support the mobile device, and > making sure > > that the tunnel between the two routers can be managed with small > enough delay. > > Then, after the handover is complete, it might be better to > renegotiate > QoS so that the previous access router no longer was required to > maintain the excess capacity needed to serve the tunnel to the new > access router. This could involve signaling so that packets are > routed directly to the new access router, presumably with some QoS > negotiation. This could involve NSIS. > > Thus, I don't agree with your statement above. But I am willing to > agree > that CT should not necessarily be intertwined with NSIS. > > Regards, > Charlie P. > > > > > > > ------_=_NextPart_001_01C2268C.E78AED56 Content-Type: text/html; charset="iso-8859-1" RE: [Seamoby] RE: what is edge signalling? (was: RE: [NSIS] Re: Comments on draft-westphal-nsis-qos-mobileip-00.txt)

Charlie:

  I guess the word "negotiate" really trips me up here. CT is a
protocol for transferring forwarding service context, not for negotiating
services between ARs. If service negotiation is required, then NSIS could be
the protocol to be used.

  In my statement that you quote below, I used the words "should not": in
the normal course of a handover, service negotiation must be rare. Negotiation,
by definition, takes time, and anything that takes time will generally delay
the service from being supported at the new AR. In the normal course of a handover,
less signalling is always better.

  In wireless, of course, the exception is the rule, and so there must be
contingencies for service negotiation. This would be NSIS' role.

  And so, I did not make my point clear. My main intent was to emphasize that
if there is a link between CT and NSIS, it is a very simple one: if CT fails
to provide a context that is useable by the new AR, then NSIS may be used to
negotiate a suitable service with the network (and thus establish suitable
context at the new AR).

Cheers,
Gary


> -----Original Message-----
> From: Charlie Perkins [mailto:charliep@iprg.nokia.com]
> Sent: July 8, 2002 10:16
> To: Kenward, Gary [WDLN2:AN10:EXCH]
> Cc: nsis@ietf.org; 'seamoby@ietf.org'
> Subject: Re: [Seamoby] RE: what is edge signalling? (was: RE:
> [NSIS] Re:
> Comments on draft-westphal-nsis-qos-mobileip-00.txt)
>
>
>
> Hello Gary,
>
> I have a comment on another point in your earlier message.
>
> Gary Kenward wrote:
>
> > In my view, if CT is in place, then NSIS should not be invoked as a
> > result of a handover.
>
> Suppose a handover has occurred, and some QoS has been negotiated
> via CT between two access routers to support the mobile node
> at the new
> access routers.  This could involve having the new router making sure
> it has sufficient capacity to support the mobile device, and
> making sure
>
> that the tunnel between the two routers can be managed with small
> enough delay.
>
> Then, after the handover is complete, it might be better to
> renegotiate
> QoS so that the previous access router no longer was required to
> maintain the excess capacity needed to serve the tunnel to the new
> access router.  This could involve signaling so that packets are
> routed directly to the new access router, presumably with some QoS
> negotiation.  This could involve NSIS.
>
> Thus, I don't agree with your statement above.  But I am willing to
> agree
> that CT should not necessarily be intertwined with NSIS.
>
> Regards,
> Charlie P.
>
>
>
> >
>
>

------_=_NextPart_001_01C2268C.E78AED56-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Mon Jul 8 11:02:15 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18224 for ; Mon, 8 Jul 2002 11:02:15 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA22269; Mon, 8 Jul 2002 10:58:25 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA22116 for ; Mon, 8 Jul 2002 10:58:19 -0400 (EDT) Received: from zcars04f.ca.nortel.com (zcars04f.nortelnetworks.com [47.129.242.57]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17918; Mon, 8 Jul 2002 10:57:25 -0400 (EDT) Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04f.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g68EtxI11578; Mon, 8 Jul 2002 10:55:59 -0400 (EDT) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 8 Jul 2002 10:55:58 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA4BEA@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'brunner@ccrle.nec.de'" , "'Hancock, Robert'" , john.loughney@nokia.com, cedric@iprg.nokia.com, erafodo@ESEALNT448.al.sw.ericsson.se Cc: nsis@ietf.org, Hemant.Chaskar@nokia.com, "'seamoby@ietf.org'" Date: Mon, 8 Jul 2002 10:55:25 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2268F.7DD7EA5A" Subject: [Seamoby] RE: what is edge signalling? (was: RE: [NSIS] Re: Comments on dra ft-westphal-nsis-qos-mobileip-00.txt) Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C2268F.7DD7EA5A Content-Type: text/plain; charset="iso-8859-1" Marcus: If I understand your comment, I believe there are two responses: first, CT need not be confined to context transfers between ARs, although this is definitely the most straightforward application of CT; second, and probably most important, there are access network solutions that do not require services to be established at the IR on a per flow basis - the per flow management happens only at the edges. It is worth noting that if NSIS *is* required to negotiate services between the MN and any ANR for every handover, then CT is not needed (if an IR must be signalled from the MN, then the AR will receive the signalling first; if ARs are signalling each other using NSIS, then why bother with CT?). I emphasize, again, that building signalling into each and every handover, particularly at the IP layer, is not conducive to seamless handover. It is very difficult to make a case for this assertion without discussing numbers - hopefully it is enough to observe that any exchange of information between the MN and the AN during or after a handover has a great potential for disrupting the service, particularly if resource allocations are delayed. I am not sure of what you mean by the "far end": are you suggesting end-to- end signalling with each handover? Or, by far end do you mean the AN to core network edge? If so for what purpose? Is there an edge based approach that would eliminated the need for access edge to "far edge" signalling with each handover? Regards, Gary > -----Original Message----- > From: Marcus Brunner [mailto:brunner@ccrle.nec.de] > Sent: July 8, 2002 04:28 > To: Kenward, Gary [WDLN2:AN10:EXCH]; 'Hancock, Robert'; > john.loughney@nokia.com; cedric@iprg.nokia.com; > erafodo@ESEALNT448.al.sw.ericsson.se > Cc: nsis@ietf.org; Hemant.Chaskar@nokia.com; 'seamoby@ietf.org' > Subject: RE: what is edge signalling? (was: RE: [NSIS] Re: Comments on > dra ft-westphal-nsis-qos-mobileip-00.txt) > > > > > > In my view, if CT is in place, then NSIS should not be > invoked as a > > result of a handover. A pretty simple relationship. The > only exception > > that I can imagine is if there is some impact on a service > that is not > > provided at an ANR (i.e. an AR or an internal router), then > NSIS may be > > required to maintain that service. However, I could not > name this service > > at this point. > > I don't see how CT can work without NSIS in the general case. > If all your > AR are connected to the swame next hop router, it may work. > Generally, you > might need to signal to the far end after handover. > > Marcus > > > > > > > -----Original Message----- > > From: Hancock, Robert [mailto:robert.hancock@roke.co.uk] > > Sent: July 5, 2002 10:59 > > To: Kenward, Gary [WDLN2:AN10:EXCH]; 'brunner@ccrle.nec.de'; > > john.loughney@nokia.com; cedric@iprg.nokia.com; > > erafodo@ESEALNT448.al.sw.ericsson.se Cc: nsis@ietf.org; > > Hemant.Chaskar@nokia.com; 'seamoby@ietf.org' > > Subject: RE: what is edge signalling? (was: RE: [NSIS] Re: > Comments on > > dra ft-westphal-nsis-qos-mobileip-00.txt) > > > > > > hi gary, > > > > my comments are purely on draft-westphal-nsis-qos-mobileip > and associated > > email discussions (since that's been the only input I have > seen recently > > which explicitly discusses the relationship between CT and NSIS, and > > which I had worries about). in particular, any comments I > make about > > MN-AR signalling are really to emphasise the difference > between the cases > > of a) not having CT signalling that carries QoS > information MN-AR (if > > there is or isn't other CT signalling I don't really care), and b) > > having CT signalling that does carry QoS information MN-AR, > which seems > > to be the assumption of the mentioned draft. > > our recent framework activities assumed (a). if you're > saying that the > > seamoby w.g. requirements also impose (a), that's fine by me. i also > > don't want to re-open old discussions (certainly not on the > nsis list, > > anyway). > > i suspect we're basically in agreement about NSIS/CT > relationships: after > > a handover, if CT happened, it should be possible to have less NSIS > > signalling on the on-path segment which goes over the air. > > cheers, > > > > robert h. > > > > PS referring to a previous email, i think the view that > NSIS is "likely > > to be of limited use in mobility situations" is rather > pessimistic. i > > would rather say that if you want the resources signalled > for by NSIS to > > be available seamlessly over handovers, you'll need > something else as > > well, which could be CT. the basic point seems to be that > NSIS shouldn't > > try to solve the cross-path context/state transfer problem > - any more > > than CT should try to solve the along-path context/state > establishment > > problem. [gwk] I agree. I was not trying to be as much > pessimistic, as I > > was pushing back against this concept that NSIS + LMM => Seamless > > Mobility. To be more precise, if it takes longer then a > few 10s of ms to > > set up the new, conditioned path, then the handover will > likely not be > > seamless in 3G. Signalling, particularly over the air > (again, 3G), takes > > relatively significant amount of time to complete. 10s of > ms is a rough > > approximation, but if you are running voice frames, more > then, say 20ms > > of additional handover delay will start impinging on the service > > requirements for the voice - i.e. either frames have to be > dropped or > > delayed beyond the performance constraint. It is difficult > to pin down > > these numbers, particularly in an IETF email list, but any > delay budget > > analysis that I have seen usually yields numbers in the > stated range > > (keep in mind that delay/drop allowances have to be > budgeted for other > > components of the access network and for the link layer handover). > > > > NSIS + LMM (or some variant of MIP) might be one approach > to mobility. > > Fine, but given what I understand about what NSIS is, and > is not, it can > > never be any where near as seamless as a solution that > incorporates CT. > > Is CT simply an "optimization" - well, that depends on how > much service > > disruption the user can tolerate. Usually, there is a > threshold where > > the service is simply considered unusable. > > Cheers, > > Gary > > > > > > -------------------------------------- > Dr. Marcus Brunner > Network Laboratories > NEC Europe Ltd. > > E-Mail: brunner@ccrle.nec.de > WWW: http://www.ccrle.nec.de/ > personal home page: http://www.brubers.org/marcus > > > ------_=_NextPart_001_01C2268F.7DD7EA5A Content-Type: text/html; charset="iso-8859-1" RE: what is edge signalling? (was: RE: [NSIS] Re: Comments on dra ft-westphal-nsis-qos-mobileip-00.txt)

Marcus:

  If I understand your comment, I believe there are two responses:
first, CT need not be confined to context transfers between ARs,
although this is definitely the most straightforward application of CT;
second, and probably most important, there are access network solutions
that do not require services to be established at the IR on a per flow
basis - the per flow management happens only at the edges.

  It is worth noting that if NSIS *is* required to negotiate services between
the MN and any ANR for every handover, then CT is not needed (if an IR must be
signalled from the MN, then the AR will receive the signalling first; if ARs
are signalling each other using NSIS, then why bother with CT?).

  I emphasize, again, that building signalling into each and every
handover, particularly at the IP layer, is not conducive to seamless
handover. It is very difficult to make a case for this assertion without
discussing numbers - hopefully it is enough to observe that any exchange
of information between the MN and the AN during or after a handover has
a great potential for disrupting the service, particularly if resource
allocations are delayed.

  I am not sure of what you mean by the "far end": are you suggesting end-to-
end signalling with each handover? Or, by far end do you mean the AN to
core network edge? If so for what purpose? Is there an edge based approach
that would eliminated the need for access edge to "far edge" signalling
with each handover?

Regards,
Gary

> -----Original Message-----
> From: Marcus Brunner [mailto:brunner@ccrle.nec.de]
> Sent: July 8, 2002 04:28
> To: Kenward, Gary [WDLN2:AN10:EXCH]; 'Hancock, Robert';
> john.loughney@nokia.com; cedric@iprg.nokia.com;
> erafodo@ESEALNT448.al.sw.ericsson.se
> Cc: nsis@ietf.org; Hemant.Chaskar@nokia.com; 'seamoby@ietf.org'
> Subject: RE: what is edge signalling? (was: RE: [NSIS] Re: Comments on
> dra ft-westphal-nsis-qos-mobileip-00.txt)
>
>
>
>
> >   In my view, if CT is in place, then NSIS should not be
> invoked as a
> > result of a handover. A pretty simple relationship. The
> only exception
> > that I can imagine is if there is some impact on a service
> that is not
> > provided at an ANR (i.e. an AR or an internal router), then
> NSIS may  be
> > required to maintain that service. However, I could not
> name this service
> > at this point.
>
> I don't see how CT can work without NSIS in the general case.
> If all your
> AR are connected to the swame next hop router, it may work.
> Generally, you
> might need to signal to the far end after handover.
>
> Marcus
>
> >
> >
> > -----Original Message-----
> > From: Hancock, Robert [mailto:robert.hancock@roke.co.uk]
> > Sent: July 5, 2002 10:59
> > To: Kenward, Gary [WDLN2:AN10:EXCH]; 'brunner@ccrle.nec.de';
> > john.loughney@nokia.com; cedric@iprg.nokia.com;
> > erafodo@ESEALNT448.al.sw.ericsson.se Cc: nsis@ietf.org;
> > Hemant.Chaskar@nokia.com; 'seamoby@ietf.org'
> > Subject: RE: what is edge signalling? (was: RE: [NSIS] Re:
> Comments on
> > dra ft-westphal-nsis-qos-mobileip-00.txt)
> >
> >
> > hi gary,
> >
> > my comments are purely on draft-westphal-nsis-qos-mobileip
> and associated
> > email discussions (since that's been the only input I have
> seen recently
> > which explicitly discusses the relationship between CT and NSIS, and
> > which I had worries about).  in particular, any comments I
> make about
> > MN-AR signalling are really to emphasise the difference
> between the cases
> > of  a) not having CT signalling that carries QoS
> information MN-AR (if
> > there is or isn't other CT signalling I don't really care), and  b)
> > having CT signalling that does carry QoS information MN-AR,
> which seems
> > to be the assumption of the mentioned draft.
> > our recent framework activities assumed (a). if you're
> saying that the
> > seamoby w.g. requirements also impose (a), that's fine by me. i also
> > don't want to re-open old discussions (certainly not on the
> nsis list,
> > anyway).
> > i suspect we're basically in agreement about NSIS/CT
> relationships: after
> > a handover, if CT happened, it should be possible to have less NSIS
> > signalling on the on-path segment which goes over the air.
> > cheers,
> >
> > robert h.
> >
> > PS referring to a previous email, i think the view that
> NSIS is "likely
> > to be of limited use in mobility situations" is rather
> pessimistic. i
> > would rather say that if you want the resources signalled
> for by NSIS to
> > be available seamlessly over handovers, you'll need
> something else as
> > well, which could be CT. the basic point seems to be that
> NSIS shouldn't
> > try to solve the cross-path context/state transfer problem
> - any more
> > than CT should try to solve the along-path context/state
> establishment
> > problem.  [gwk] I agree. I was not trying to be as much
> pessimistic, as I
> > was pushing back against this concept that NSIS + LMM => Seamless
> > Mobility. To be more precise,  if it takes longer then a
> few 10s of ms to
> > set up the new, conditioned path, then the handover will
> likely not be
> > seamless in 3G. Signalling, particularly over the  air
> (again, 3G), takes
> > relatively significant amount of time to complete. 10s of
> ms is a rough
> > approximation, but if you are running voice frames, more
> then, say  20ms
> > of additional handover delay will start  impinging on the service
> > requirements for the voice - i.e. either frames have to be
> dropped or
> > delayed beyond  the performance constraint. It is difficult
> to pin down
> > these numbers, particularly in an IETF email list, but any
> delay budget
> > analysis that I have seen usually  yields numbers in the
> stated range
> > (keep in mind that delay/drop allowances have to be
> budgeted for other
> > components of the access network and for the  link layer handover).
> >
> > NSIS + LMM (or some variant of MIP) might be one approach
> to mobility.
> > Fine, but given what I understand about what NSIS is, and
> is not, it can
> > never be  any where near as seamless as a solution that
> incorporates CT.
> > Is CT simply an "optimization" - well, that depends on how
> much service
> > disruption the user  can tolerate. Usually, there is a
> threshold where
> > the service is simply considered unusable.
> > Cheers,
> > Gary
> >
>
>
>
> --------------------------------------
> Dr. Marcus Brunner
> Network Laboratories
> NEC Europe Ltd.
>
> E-Mail: brunner@ccrle.nec.de
> WWW:    http://www.ccrle.nec.de/
> personal home page: http://www.brubers.org/marcus
>
>
>

------_=_NextPart_001_01C2268F.7DD7EA5A-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Mon Jul 8 11:02:15 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18233 for ; Mon, 8 Jul 2002 11:02:15 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA23109 for seamoby-archive@odin.ietf.org; Mon, 8 Jul 2002 11:03:07 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA22269; Mon, 8 Jul 2002 10:58:25 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA22116 for ; Mon, 8 Jul 2002 10:58:19 -0400 (EDT) Received: from zcars04f.ca.nortel.com (zcars04f.nortelnetworks.com [47.129.242.57]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17918; Mon, 8 Jul 2002 10:57:25 -0400 (EDT) Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04f.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g68EtxI11578; Mon, 8 Jul 2002 10:55:59 -0400 (EDT) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 8 Jul 2002 10:55:58 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA4BEA@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'brunner@ccrle.nec.de'" , "'Hancock, Robert'" , john.loughney@nokia.com, cedric@iprg.nokia.com, erafodo@ESEALNT448.al.sw.ericsson.se Cc: nsis@ietf.org, Hemant.Chaskar@nokia.com, "'seamoby@ietf.org'" Date: Mon, 8 Jul 2002 10:55:25 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2268F.7DD7EA5A" Subject: [Seamoby] RE: what is edge signalling? (was: RE: [NSIS] Re: Comments on dra ft-westphal-nsis-qos-mobileip-00.txt) Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C2268F.7DD7EA5A Content-Type: text/plain; charset="iso-8859-1" Marcus: If I understand your comment, I believe there are two responses: first, CT need not be confined to context transfers between ARs, although this is definitely the most straightforward application of CT; second, and probably most important, there are access network solutions that do not require services to be established at the IR on a per flow basis - the per flow management happens only at the edges. It is worth noting that if NSIS *is* required to negotiate services between the MN and any ANR for every handover, then CT is not needed (if an IR must be signalled from the MN, then the AR will receive the signalling first; if ARs are signalling each other using NSIS, then why bother with CT?). I emphasize, again, that building signalling into each and every handover, particularly at the IP layer, is not conducive to seamless handover. It is very difficult to make a case for this assertion without discussing numbers - hopefully it is enough to observe that any exchange of information between the MN and the AN during or after a handover has a great potential for disrupting the service, particularly if resource allocations are delayed. I am not sure of what you mean by the "far end": are you suggesting end-to- end signalling with each handover? Or, by far end do you mean the AN to core network edge? If so for what purpose? Is there an edge based approach that would eliminated the need for access edge to "far edge" signalling with each handover? Regards, Gary > -----Original Message----- > From: Marcus Brunner [mailto:brunner@ccrle.nec.de] > Sent: July 8, 2002 04:28 > To: Kenward, Gary [WDLN2:AN10:EXCH]; 'Hancock, Robert'; > john.loughney@nokia.com; cedric@iprg.nokia.com; > erafodo@ESEALNT448.al.sw.ericsson.se > Cc: nsis@ietf.org; Hemant.Chaskar@nokia.com; 'seamoby@ietf.org' > Subject: RE: what is edge signalling? (was: RE: [NSIS] Re: Comments on > dra ft-westphal-nsis-qos-mobileip-00.txt) > > > > > > In my view, if CT is in place, then NSIS should not be > invoked as a > > result of a handover. A pretty simple relationship. The > only exception > > that I can imagine is if there is some impact on a service > that is not > > provided at an ANR (i.e. an AR or an internal router), then > NSIS may be > > required to maintain that service. However, I could not > name this service > > at this point. > > I don't see how CT can work without NSIS in the general case. > If all your > AR are connected to the swame next hop router, it may work. > Generally, you > might need to signal to the far end after handover. > > Marcus > > > > > > > -----Original Message----- > > From: Hancock, Robert [mailto:robert.hancock@roke.co.uk] > > Sent: July 5, 2002 10:59 > > To: Kenward, Gary [WDLN2:AN10:EXCH]; 'brunner@ccrle.nec.de'; > > john.loughney@nokia.com; cedric@iprg.nokia.com; > > erafodo@ESEALNT448.al.sw.ericsson.se Cc: nsis@ietf.org; > > Hemant.Chaskar@nokia.com; 'seamoby@ietf.org' > > Subject: RE: what is edge signalling? (was: RE: [NSIS] Re: > Comments on > > dra ft-westphal-nsis-qos-mobileip-00.txt) > > > > > > hi gary, > > > > my comments are purely on draft-westphal-nsis-qos-mobileip > and associated > > email discussions (since that's been the only input I have > seen recently > > which explicitly discusses the relationship between CT and NSIS, and > > which I had worries about). in particular, any comments I > make about > > MN-AR signalling are really to emphasise the difference > between the cases > > of a) not having CT signalling that carries QoS > information MN-AR (if > > there is or isn't other CT signalling I don't really care), and b) > > having CT signalling that does carry QoS information MN-AR, > which seems > > to be the assumption of the mentioned draft. > > our recent framework activities assumed (a). if you're > saying that the > > seamoby w.g. requirements also impose (a), that's fine by me. i also > > don't want to re-open old discussions (certainly not on the > nsis list, > > anyway). > > i suspect we're basically in agreement about NSIS/CT > relationships: after > > a handover, if CT happened, it should be possible to have less NSIS > > signalling on the on-path segment which goes over the air. > > cheers, > > > > robert h. > > > > PS referring to a previous email, i think the view that > NSIS is "likely > > to be of limited use in mobility situations" is rather > pessimistic. i > > would rather say that if you want the resources signalled > for by NSIS to > > be available seamlessly over handovers, you'll need > something else as > > well, which could be CT. the basic point seems to be that > NSIS shouldn't > > try to solve the cross-path context/state transfer problem > - any more > > than CT should try to solve the along-path context/state > establishment > > problem. [gwk] I agree. I was not trying to be as much > pessimistic, as I > > was pushing back against this concept that NSIS + LMM => Seamless > > Mobility. To be more precise, if it takes longer then a > few 10s of ms to > > set up the new, conditioned path, then the handover will > likely not be > > seamless in 3G. Signalling, particularly over the air > (again, 3G), takes > > relatively significant amount of time to complete. 10s of > ms is a rough > > approximation, but if you are running voice frames, more > then, say 20ms > > of additional handover delay will start impinging on the service > > requirements for the voice - i.e. either frames have to be > dropped or > > delayed beyond the performance constraint. It is difficult > to pin down > > these numbers, particularly in an IETF email list, but any > delay budget > > analysis that I have seen usually yields numbers in the > stated range > > (keep in mind that delay/drop allowances have to be > budgeted for other > > components of the access network and for the link layer handover). > > > > NSIS + LMM (or some variant of MIP) might be one approach > to mobility. > > Fine, but given what I understand about what NSIS is, and > is not, it can > > never be any where near as seamless as a solution that > incorporates CT. > > Is CT simply an "optimization" - well, that depends on how > much service > > disruption the user can tolerate. Usually, there is a > threshold where > > the service is simply considered unusable. > > Cheers, > > Gary > > > > > > -------------------------------------- > Dr. Marcus Brunner > Network Laboratories > NEC Europe Ltd. > > E-Mail: brunner@ccrle.nec.de > WWW: http://www.ccrle.nec.de/ > personal home page: http://www.brubers.org/marcus > > > ------_=_NextPart_001_01C2268F.7DD7EA5A Content-Type: text/html; charset="iso-8859-1" RE: what is edge signalling? (was: RE: [NSIS] Re: Comments on dra ft-westphal-nsis-qos-mobileip-00.txt)

Marcus:

  If I understand your comment, I believe there are two responses:
first, CT need not be confined to context transfers between ARs,
although this is definitely the most straightforward application of CT;
second, and probably most important, there are access network solutions
that do not require services to be established at the IR on a per flow
basis - the per flow management happens only at the edges.

  It is worth noting that if NSIS *is* required to negotiate services between
the MN and any ANR for every handover, then CT is not needed (if an IR must be
signalled from the MN, then the AR will receive the signalling first; if ARs
are signalling each other using NSIS, then why bother with CT?).

  I emphasize, again, that building signalling into each and every
handover, particularly at the IP layer, is not conducive to seamless
handover. It is very difficult to make a case for this assertion without
discussing numbers - hopefully it is enough to observe that any exchange
of information between the MN and the AN during or after a handover has
a great potential for disrupting the service, particularly if resource
allocations are delayed.

  I am not sure of what you mean by the "far end": are you suggesting end-to-
end signalling with each handover? Or, by far end do you mean the AN to
core network edge? If so for what purpose? Is there an edge based approach
that would eliminated the need for access edge to "far edge" signalling
with each handover?

Regards,
Gary

> -----Original Message-----
> From: Marcus Brunner [mailto:brunner@ccrle.nec.de]
> Sent: July 8, 2002 04:28
> To: Kenward, Gary [WDLN2:AN10:EXCH]; 'Hancock, Robert';
> john.loughney@nokia.com; cedric@iprg.nokia.com;
> erafodo@ESEALNT448.al.sw.ericsson.se
> Cc: nsis@ietf.org; Hemant.Chaskar@nokia.com; 'seamoby@ietf.org'
> Subject: RE: what is edge signalling? (was: RE: [NSIS] Re: Comments on
> dra ft-westphal-nsis-qos-mobileip-00.txt)
>
>
>
>
> >   In my view, if CT is in place, then NSIS should not be
> invoked as a
> > result of a handover. A pretty simple relationship. The
> only exception
> > that I can imagine is if there is some impact on a service
> that is not
> > provided at an ANR (i.e. an AR or an internal router), then
> NSIS may  be
> > required to maintain that service. However, I could not
> name this service
> > at this point.
>
> I don't see how CT can work without NSIS in the general case.
> If all your
> AR are connected to the swame next hop router, it may work.
> Generally, you
> might need to signal to the far end after handover.
>
> Marcus
>
> >
> >
> > -----Original Message-----
> > From: Hancock, Robert [mailto:robert.hancock@roke.co.uk]
> > Sent: July 5, 2002 10:59
> > To: Kenward, Gary [WDLN2:AN10:EXCH]; 'brunner@ccrle.nec.de';
> > john.loughney@nokia.com; cedric@iprg.nokia.com;
> > erafodo@ESEALNT448.al.sw.ericsson.se Cc: nsis@ietf.org;
> > Hemant.Chaskar@nokia.com; 'seamoby@ietf.org'
> > Subject: RE: what is edge signalling? (was: RE: [NSIS] Re:
> Comments on
> > dra ft-westphal-nsis-qos-mobileip-00.txt)
> >
> >
> > hi gary,
> >
> > my comments are purely on draft-westphal-nsis-qos-mobileip
> and associated
> > email discussions (since that's been the only input I have
> seen recently
> > which explicitly discusses the relationship between CT and NSIS, and
> > which I had worries about).  in particular, any comments I
> make about
> > MN-AR signalling are really to emphasise the difference
> between the cases
> > of  a) not having CT signalling that carries QoS
> information MN-AR (if
> > there is or isn't other CT signalling I don't really care), and  b)
> > having CT signalling that does carry QoS information MN-AR,
> which seems
> > to be the assumption of the mentioned draft.
> > our recent framework activities assumed (a). if you're
> saying that the
> > seamoby w.g. requirements also impose (a), that's fine by me. i also
> > don't want to re-open old discussions (certainly not on the
> nsis list,
> > anyway).
> > i suspect we're basically in agreement about NSIS/CT
> relationships: after
> > a handover, if CT happened, it should be possible to have less NSIS
> > signalling on the on-path segment which goes over the air.
> > cheers,
> >
> > robert h.
> >
> > PS referring to a previous email, i think the view that
> NSIS is "likely
> > to be of limited use in mobility situations" is rather
> pessimistic. i
> > would rather say that if you want the resources signalled
> for by NSIS to
> > be available seamlessly over handovers, you'll need
> something else as
> > well, which could be CT. the basic point seems to be that
> NSIS shouldn't
> > try to solve the cross-path context/state transfer problem
> - any more
> > than CT should try to solve the along-path context/state
> establishment
> > problem.  [gwk] I agree. I was not trying to be as much
> pessimistic, as I
> > was pushing back against this concept that NSIS + LMM => Seamless
> > Mobility. To be more precise,  if it takes longer then a
> few 10s of ms to
> > set up the new, conditioned path, then the handover will
> likely not be
> > seamless in 3G. Signalling, particularly over the  air
> (again, 3G), takes
> > relatively significant amount of time to complete. 10s of
> ms is a rough
> > approximation, but if you are running voice frames, more
> then, say  20ms
> > of additional handover delay will start  impinging on the service
> > requirements for the voice - i.e. either frames have to be
> dropped or
> > delayed beyond  the performance constraint. It is difficult
> to pin down
> > these numbers, particularly in an IETF email list, but any
> delay budget
> > analysis that I have seen usually  yields numbers in the
> stated range
> > (keep in mind that delay/drop allowances have to be
> budgeted for other
> > components of the access network and for the  link layer handover).
> >
> > NSIS + LMM (or some variant of MIP) might be one approach
> to mobility.
> > Fine, but given what I understand about what NSIS is, and
> is not, it can
> > never be  any where near as seamless as a solution that
> incorporates CT.
> > Is CT simply an "optimization" - well, that depends on how
> much service
> > disruption the user  can tolerate. Usually, there is a
> threshold where
> > the service is simply considered unusable.
> > Cheers,
> > Gary
> >
>
>
>
> --------------------------------------
> Dr. Marcus Brunner
> Network Laboratories
> NEC Europe Ltd.
>
> E-Mail: brunner@ccrle.nec.de
> WWW:    http://www.ccrle.nec.de/
> personal home page: http://www.brubers.org/marcus
>
>
>

------_=_NextPart_001_01C2268F.7DD7EA5A-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Mon Jul 8 12:06:12 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21759 for ; Mon, 8 Jul 2002 12:06:12 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA27798; Mon, 8 Jul 2002 12:00:39 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA27690 for ; Mon, 8 Jul 2002 12:00:33 -0400 (EDT) Received: from zcars04e.ca.nortel.com (zcars04e.nortelnetworks.com [47.129.242.56]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21319 for ; Mon, 8 Jul 2002 11:59:37 -0400 (EDT) Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g68Fxw920523 for ; Mon, 8 Jul 2002 11:59:58 -0400 (EDT) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 8 Jul 2002 11:59:57 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA4BED@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'seamoby@ietf.org'" , "'NSIS'" Date: Mon, 8 Jul 2002 11:59:51 -0400 Sensitivity: Company-Confidential MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C22698.7DF6A1F8" Subject: [Seamoby] Re: draft-westphal-nsis-qos-mobileip-00.txt Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C22698.7DF6A1F8 Content-Type: text/plain; charset="iso-8859-1" I finally managed to find time to read through Cedric's and Hemant's draft. Overally, I think it is a good description of one possible integrated approach. The one general comment I would like to offer up at this time, is that while the draft does a good job of integrating MIP, CT and NSIS concepts, the proposed solutions for QoS negotiation between MN and AN (e.g. the use of the CIN message) is NSIS not CT. CT is concerned with the transfer of forwarding service context between ANRs. NSIS is concerned with the signalling of service requirements. Thus, the issue is not how to interwork the "CT" CIN, for example, with NSIS signalling, but how the CIN, etc., form part of the NSIS solution. This is not simply an issue of adherence to Seamoby/NSIS models or charters. The intention has always been that CT work as a context transfer mechanism with a variety of mobility and service signalling solutions. There is a significant benefit in the real world to be realized in keeping the context transfer solution (CT) independent from the service signalling solution (NSIS) (and the mobility solution - MIP or whatever). I would think that there is also a benefit to keeping the MN to AR service signalling independent of CT. Stated a different way, do we really need two separate solutions for over the air (MN to AN) service signalling? Regards, Gary Kenward ------_=_NextPart_001_01C22698.7DF6A1F8 Content-Type: text/html; charset="iso-8859-1" Re: draft-westphal-nsis-qos-mobileip-00.txt

I finally managed to find time to read through Cedric's and Hemant's draft.
Overally, I think it is a good description of one possible integrated
approach.

The one general comment I would like to offer up at this time, is that while
the draft does a good job of integrating MIP, CT and NSIS concepts, the
proposed solutions for QoS negotiation between MN and AN (e.g. the use of the
CIN message) is NSIS not CT.

CT is concerned with the transfer of forwarding service context between ANRs.
NSIS is concerned with the signalling of service requirements. Thus, the issue
is not how to interwork the "CT" CIN, for example, with NSIS signalling, but how
the CIN, etc., form part of the NSIS solution.

This is not simply an issue of adherence to Seamoby/NSIS models or charters.
The intention has always been that CT work as a context transfer mechanism
with a variety of mobility and service signalling solutions. There is a significant
benefit in the real world to be realized in keeping the context transfer solution
(CT) independent from the service signalling solution (NSIS) (and the mobility
solution - MIP or whatever). I would think that there is also a benefit to keeping
the MN to AR service signalling independent of CT.

Stated a different way, do we really need two separate solutions for over the air
(MN to AN) service signalling?

Regards,
Gary Kenward


------_=_NextPart_001_01C22698.7DF6A1F8-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Mon Jul 8 12:06:13 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21768 for ; Mon, 8 Jul 2002 12:06:13 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA29350 for seamoby-archive@odin.ietf.org; Mon, 8 Jul 2002 12:07:05 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA27798; Mon, 8 Jul 2002 12:00:39 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA27690 for ; Mon, 8 Jul 2002 12:00:33 -0400 (EDT) Received: from zcars04e.ca.nortel.com (zcars04e.nortelnetworks.com [47.129.242.56]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21319 for ; Mon, 8 Jul 2002 11:59:37 -0400 (EDT) Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g68Fxw920523 for ; Mon, 8 Jul 2002 11:59:58 -0400 (EDT) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 8 Jul 2002 11:59:57 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA4BED@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'seamoby@ietf.org'" , "'NSIS'" Date: Mon, 8 Jul 2002 11:59:51 -0400 Sensitivity: Company-Confidential MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C22698.7DF6A1F8" Subject: [Seamoby] Re: draft-westphal-nsis-qos-mobileip-00.txt Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C22698.7DF6A1F8 Content-Type: text/plain; charset="iso-8859-1" I finally managed to find time to read through Cedric's and Hemant's draft. Overally, I think it is a good description of one possible integrated approach. The one general comment I would like to offer up at this time, is that while the draft does a good job of integrating MIP, CT and NSIS concepts, the proposed solutions for QoS negotiation between MN and AN (e.g. the use of the CIN message) is NSIS not CT. CT is concerned with the transfer of forwarding service context between ANRs. NSIS is concerned with the signalling of service requirements. Thus, the issue is not how to interwork the "CT" CIN, for example, with NSIS signalling, but how the CIN, etc., form part of the NSIS solution. This is not simply an issue of adherence to Seamoby/NSIS models or charters. The intention has always been that CT work as a context transfer mechanism with a variety of mobility and service signalling solutions. There is a significant benefit in the real world to be realized in keeping the context transfer solution (CT) independent from the service signalling solution (NSIS) (and the mobility solution - MIP or whatever). I would think that there is also a benefit to keeping the MN to AR service signalling independent of CT. Stated a different way, do we really need two separate solutions for over the air (MN to AN) service signalling? Regards, Gary Kenward ------_=_NextPart_001_01C22698.7DF6A1F8 Content-Type: text/html; charset="iso-8859-1" Re: draft-westphal-nsis-qos-mobileip-00.txt

I finally managed to find time to read through Cedric's and Hemant's draft.
Overally, I think it is a good description of one possible integrated
approach.

The one general comment I would like to offer up at this time, is that while
the draft does a good job of integrating MIP, CT and NSIS concepts, the
proposed solutions for QoS negotiation between MN and AN (e.g. the use of the
CIN message) is NSIS not CT.

CT is concerned with the transfer of forwarding service context between ANRs.
NSIS is concerned with the signalling of service requirements. Thus, the issue
is not how to interwork the "CT" CIN, for example, with NSIS signalling, but how
the CIN, etc., form part of the NSIS solution.

This is not simply an issue of adherence to Seamoby/NSIS models or charters.
The intention has always been that CT work as a context transfer mechanism
with a variety of mobility and service signalling solutions. There is a significant
benefit in the real world to be realized in keeping the context transfer solution
(CT) independent from the service signalling solution (NSIS) (and the mobility
solution - MIP or whatever). I would think that there is also a benefit to keeping
the MN to AR service signalling independent of CT.

Stated a different way, do we really need two separate solutions for over the air
(MN to AN) service signalling?

Regards,
Gary Kenward


------_=_NextPart_001_01C22698.7DF6A1F8-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Mon Jul 8 12:24:25 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22944 for ; Mon, 8 Jul 2002 12:24:25 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA00567; Mon, 8 Jul 2002 12:20:41 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA00502 for ; Mon, 8 Jul 2002 12:20:37 -0400 (EDT) Received: from mgw-dax2.ext.nokia.com (mgw-dax2.ext.nokia.com [63.78.179.217]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22698; Mon, 8 Jul 2002 12:19:38 -0400 (EDT) From: Hemant.Chaskar@nokia.com Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax2.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g68GOCj11255; Mon, 8 Jul 2002 11:24:12 -0500 (CDT) Received: from daebh002.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 8 Jul 2002 11:20:30 -0500 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Mon, 8 Jul 2002 11:20:24 -0500 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Date: Mon, 8 Jul 2002 12:20:23 -0400 Message-ID: Thread-Topic: [NSIS] Re: draft-westphal-nsis-qos-mobileip-00.txt Thread-Index: AcImmMjymZiFaTWITiG8gRYc39SSCQAANpPQ Sensitivity: Company-Confidential To: , , X-OriginalArrivalTime: 08 Jul 2002 16:20:24.0550 (UTC) FILETIME=[5D378060:01C2269B] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id MAA00503 Subject: [Seamoby] RE: [NSIS] Re: draft-westphal-nsis-qos-mobileip-00.txt Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 8bit Hi Gary: Some comments inline: -----Original Message----- From: ext Gary Kenward [mailto:gkenward@nortelnetworks.com] Sent: 08. July 2002 12:00 To: 'seamoby@ietf.org'; 'NSIS' Subject: [NSIS] Re: draft-westphal-nsis-qos-mobileip-00.txt Sensitivity: Confidential I finally managed to find time to read through Cedric's and Hemant's draft. Overally, I think it is a good description of one possible integrated approach. [Hemant] Please note that the Edge Signaling (MN-AR and AR-AR) and Data Path Signaling (e2e if you will) are not "tightly integrated", i.e., they help each other but do not rely on each other (though I admit that the current writeup makes that impression). In other words, Data Path Signaling can work (at handoff time) even if Edge Signaling fails. The one general comment I would like to offer up at this time, is that while the draft does a good job of integrating MIP, CT and NSIS concepts, the proposed solutions for QoS negotiation between MN and AN (e.g. the use of the CIN message) is NSIS not CT. [Hemant] Point well taken. CT is concerned with the transfer of forwarding service context between ANRs. NSIS is concerned with the signalling of service requirements. Thus, the issue is not how to interwork the "CT" CIN, for example, with NSIS signalling, but how the CIN, etc., form part of the NSIS solution. [Hemant] I agree. The basic idea is that if CT can help avoid MN-new AR NSIS signaling at handoff time, it is a good proposition. Note that context can be constructed at old AR using the information supplied to it by NSIS MN-old AR message at session initiation, which can be transported to new AR in CT. If CT fails, one should use MN-new AR NSIS signaling at handoff time, albeit at certain loss of seamlessness. [Hemant] Thanks, Hemant This is not simply an issue of adherence to Seamoby/NSIS models or charters. The intention has always been that CT work as a context transfer mechanism with a variety of mobility and service signalling solutions. There is a significant benefit in the real world to be realized in keeping the context transfer solution (CT) independent from the service signalling solution (NSIS) (and the mobility solution - MIP or whatever). I would think that there is also a benefit to keeping the MN to AR service signalling independent of CT. Stated a different way, do we really need two separate solutions for over the air (MN to AN) service signalling? Regards, Gary Kenward _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Mon Jul 8 12:24:27 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22958 for ; Mon, 8 Jul 2002 12:24:27 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA01055 for seamoby-archive@odin.ietf.org; Mon, 8 Jul 2002 12:25:18 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA00567; Mon, 8 Jul 2002 12:20:41 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA00502 for ; Mon, 8 Jul 2002 12:20:37 -0400 (EDT) Received: from mgw-dax2.ext.nokia.com (mgw-dax2.ext.nokia.com [63.78.179.217]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22698; Mon, 8 Jul 2002 12:19:38 -0400 (EDT) From: Hemant.Chaskar@nokia.com Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax2.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g68GOCj11255; Mon, 8 Jul 2002 11:24:12 -0500 (CDT) Received: from daebh002.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 8 Jul 2002 11:20:30 -0500 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Mon, 8 Jul 2002 11:20:24 -0500 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Date: Mon, 8 Jul 2002 12:20:23 -0400 Message-ID: Thread-Topic: [NSIS] Re: draft-westphal-nsis-qos-mobileip-00.txt Thread-Index: AcImmMjymZiFaTWITiG8gRYc39SSCQAANpPQ Sensitivity: Company-Confidential To: , , X-OriginalArrivalTime: 08 Jul 2002 16:20:24.0550 (UTC) FILETIME=[5D378060:01C2269B] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id MAA00503 Subject: [Seamoby] RE: [NSIS] Re: draft-westphal-nsis-qos-mobileip-00.txt Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 8bit Hi Gary: Some comments inline: -----Original Message----- From: ext Gary Kenward [mailto:gkenward@nortelnetworks.com] Sent: 08. July 2002 12:00 To: 'seamoby@ietf.org'; 'NSIS' Subject: [NSIS] Re: draft-westphal-nsis-qos-mobileip-00.txt Sensitivity: Confidential I finally managed to find time to read through Cedric's and Hemant's draft. Overally, I think it is a good description of one possible integrated approach. [Hemant] Please note that the Edge Signaling (MN-AR and AR-AR) and Data Path Signaling (e2e if you will) are not "tightly integrated", i.e., they help each other but do not rely on each other (though I admit that the current writeup makes that impression). In other words, Data Path Signaling can work (at handoff time) even if Edge Signaling fails. The one general comment I would like to offer up at this time, is that while the draft does a good job of integrating MIP, CT and NSIS concepts, the proposed solutions for QoS negotiation between MN and AN (e.g. the use of the CIN message) is NSIS not CT. [Hemant] Point well taken. CT is concerned with the transfer of forwarding service context between ANRs. NSIS is concerned with the signalling of service requirements. Thus, the issue is not how to interwork the "CT" CIN, for example, with NSIS signalling, but how the CIN, etc., form part of the NSIS solution. [Hemant] I agree. The basic idea is that if CT can help avoid MN-new AR NSIS signaling at handoff time, it is a good proposition. Note that context can be constructed at old AR using the information supplied to it by NSIS MN-old AR message at session initiation, which can be transported to new AR in CT. If CT fails, one should use MN-new AR NSIS signaling at handoff time, albeit at certain loss of seamlessness. [Hemant] Thanks, Hemant This is not simply an issue of adherence to Seamoby/NSIS models or charters. The intention has always been that CT work as a context transfer mechanism with a variety of mobility and service signalling solutions. There is a significant benefit in the real world to be realized in keeping the context transfer solution (CT) independent from the service signalling solution (NSIS) (and the mobility solution - MIP or whatever). I would think that there is also a benefit to keeping the MN to AR service signalling independent of CT. Stated a different way, do we really need two separate solutions for over the air (MN to AN) service signalling? Regards, Gary Kenward _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Mon Jul 8 12:31:28 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23335 for ; Mon, 8 Jul 2002 12:31:28 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA00956; Mon, 8 Jul 2002 12:24:38 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA00895 for ; Mon, 8 Jul 2002 12:24:35 -0400 (EDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22914; Mon, 8 Jul 2002 12:23:41 -0400 (EDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id JAA21543; Mon, 8 Jul 2002 09:24:02 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g68GO2e16659; Mon, 8 Jul 2002 09:24:02 -0700 X-mProtect: <200207081624> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdF3kG5q; Mon, 08 Jul 2002 09:24:00 PDT Message-ID: <3D29BCA0.50D6211E@iprg.nokia.com> Date: Mon, 08 Jul 2002 09:24:00 -0700 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Gary Kenward CC: nsis@ietf.org, "'seamoby@ietf.org'" Subject: Re: [Seamoby] RE: what is edge signalling? (was: RE: [NSIS] Re: Comments on draft-westphal-nsis-qos-mobileip-00.txt) References: <9FBD322B7824D511B36900508BF93C9C01AA4BE9@zcard031.ca.nortel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit Hello Gary, Thanks for your note. It seems to me that, with your further explanation, we are in agreement. And, I agree that during CT there typically shouldn't be any service negotiation, maybe even never. If it occurs, it should be considered to be part of CAR discovery, not CT. Regards, Charlie P. > Gary Kenward wrote: > > Charlie: > > I guess the word "negotiate" really trips me up here. CT is a > protocol for transferring forwarding service context, not for negotiating > services between ARs. If service negotiation is required, then NSIS could be > the protocol to be used. > > In my statement that you quote below, I used the words "should not": in > the normal course of a handover, service negotiation must be rare. > Negotiation, > by definition, takes time, and anything that takes time will generally delay > the service from being supported at the new AR. In the normal course of a > handover, > less signalling is always better. > > In wireless, of course, the exception is the rule, and so there must be > contingencies for service negotiation. This would be NSIS' role. > > And so, I did not make my point clear. My main intent was to emphasize that > if there is a link between CT and NSIS, it is a very simple one: if CT fails > to provide a context that is useable by the new AR, then NSIS may be used to > negotiate a suitable service with the network (and thus establish suitable > context at the new AR). > > Cheers, > Gary _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Mon Jul 8 12:31:28 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23342 for ; Mon, 8 Jul 2002 12:31:28 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA02001 for seamoby-archive@odin.ietf.org; Mon, 8 Jul 2002 12:32:21 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA00956; Mon, 8 Jul 2002 12:24:38 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA00895 for ; Mon, 8 Jul 2002 12:24:35 -0400 (EDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22914; Mon, 8 Jul 2002 12:23:41 -0400 (EDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id JAA21543; Mon, 8 Jul 2002 09:24:02 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g68GO2e16659; Mon, 8 Jul 2002 09:24:02 -0700 X-mProtect: <200207081624> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdF3kG5q; Mon, 08 Jul 2002 09:24:00 PDT Message-ID: <3D29BCA0.50D6211E@iprg.nokia.com> Date: Mon, 08 Jul 2002 09:24:00 -0700 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Gary Kenward CC: nsis@ietf.org, "'seamoby@ietf.org'" Subject: Re: [Seamoby] RE: what is edge signalling? (was: RE: [NSIS] Re: Comments on draft-westphal-nsis-qos-mobileip-00.txt) References: <9FBD322B7824D511B36900508BF93C9C01AA4BE9@zcard031.ca.nortel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit Hello Gary, Thanks for your note. It seems to me that, with your further explanation, we are in agreement. And, I agree that during CT there typically shouldn't be any service negotiation, maybe even never. If it occurs, it should be considered to be part of CAR discovery, not CT. Regards, Charlie P. > Gary Kenward wrote: > > Charlie: > > I guess the word "negotiate" really trips me up here. CT is a > protocol for transferring forwarding service context, not for negotiating > services between ARs. If service negotiation is required, then NSIS could be > the protocol to be used. > > In my statement that you quote below, I used the words "should not": in > the normal course of a handover, service negotiation must be rare. > Negotiation, > by definition, takes time, and anything that takes time will generally delay > the service from being supported at the new AR. In the normal course of a > handover, > less signalling is always better. > > In wireless, of course, the exception is the rule, and so there must be > contingencies for service negotiation. This would be NSIS' role. > > And so, I did not make my point clear. My main intent was to emphasize that > if there is a link between CT and NSIS, it is a very simple one: if CT fails > to provide a context that is useable by the new AR, then NSIS may be used to > negotiate a suitable service with the network (and thus establish suitable > context at the new AR). > > Cheers, > Gary _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Mon Jul 8 12:43:55 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23965 for ; Mon, 8 Jul 2002 12:43:54 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA02804; Mon, 8 Jul 2002 12:41:06 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA02737 for ; Mon, 8 Jul 2002 12:41:03 -0400 (EDT) Received: from fridge.docomolabs-usa.com (fwuser@key1.docomolabs-usa.com [216.98.102.225]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23756; Mon, 8 Jul 2002 12:40:10 -0400 (EDT) Message-ID: <016701c2269d$ffbc32c0$4f6015ac@T23KEMPF> From: "James Kempf" To: , , , References: Subject: Re: [Seamoby] RE: [NSIS] Re: draft-westphal-nsis-qos-mobileip-00.txt Date: Mon, 8 Jul 2002 09:39:16 -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-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit Could CT be viewed as an optimization of NSIS signaling? jak ----- Original Message ----- From: To: ; ; Sent: Monday, July 08, 2002 9:20 AM Subject: [Seamoby] RE: [NSIS] Re: draft-westphal-nsis-qos-mobileip-00.txt > Hi Gary: > > Some comments inline: > > -----Original Message----- > From: ext Gary Kenward [mailto:gkenward@nortelnetworks.com] > Sent: 08. July 2002 12:00 > To: 'seamoby@ietf.org'; 'NSIS' > Subject: [NSIS] Re: draft-westphal-nsis-qos-mobileip-00.txt > Sensitivity: Confidential > > > I finally managed to find time to read through Cedric's and Hemant's draft. > Overally, I think it is a good description of one possible integrated > approach. > > [Hemant] Please note that the Edge Signaling (MN-AR and AR-AR) and Data Path Signaling (e2e if you will) are not "tightly integrated", i.e., they help each other but do not rely on each other (though I admit that the current writeup makes that impression). In other words, Data Path Signaling can work (at handoff time) even if Edge Signaling fails. > > The one general comment I would like to offer up at this time, is that while > > the draft does a good job of integrating MIP, CT and NSIS concepts, the > proposed solutions for QoS negotiation between MN and AN (e.g. the use of > the > CIN message) is NSIS not CT. > > [Hemant] Point well taken. > > CT is concerned with the transfer of forwarding service context between > ANRs. > NSIS is concerned with the signalling of service requirements. Thus, the > issue > is not how to interwork the "CT" CIN, for example, with NSIS signalling, but > how > the CIN, etc., form part of the NSIS solution. > > [Hemant] I agree. The basic idea is that if CT can help avoid MN-new AR NSIS signaling at handoff time, it is a good proposition. Note that context can be constructed at old AR using the information supplied to it by NSIS MN-old AR message at session initiation, which can be transported to new AR in CT. If CT fails, one should use MN-new AR NSIS signaling at handoff time, albeit at certain loss of seamlessness. > > [Hemant] Thanks, Hemant > > This is not simply an issue of adherence to Seamoby/NSIS models or charters. > The intention has always been that CT work as a context transfer mechanism > with a variety of mobility and service signalling solutions. There is a > significant > benefit in the real world to be realized in keeping the context transfer > solution > (CT) independent from the service signalling solution (NSIS) (and the > mobility > solution - MIP or whatever). I would think that there is also a benefit to > keeping > the MN to AR service signalling independent of CT. > > Stated a different way, do we really need two separate solutions for over > the air > (MN to AN) service signalling? > > Regards, > Gary Kenward > > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > > _______________________________________________ > 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 From daemon@optimus.ietf.org Mon Jul 8 12:43:55 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23972 for ; Mon, 8 Jul 2002 12:43:55 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA03252 for seamoby-archive@odin.ietf.org; Mon, 8 Jul 2002 12:44:46 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA02804; Mon, 8 Jul 2002 12:41:06 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA02737 for ; Mon, 8 Jul 2002 12:41:03 -0400 (EDT) Received: from fridge.docomolabs-usa.com (fwuser@key1.docomolabs-usa.com [216.98.102.225]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23756; Mon, 8 Jul 2002 12:40:10 -0400 (EDT) Message-ID: <016701c2269d$ffbc32c0$4f6015ac@T23KEMPF> From: "James Kempf" To: , , , References: Subject: Re: [Seamoby] RE: [NSIS] Re: draft-westphal-nsis-qos-mobileip-00.txt Date: Mon, 8 Jul 2002 09:39:16 -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-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit Could CT be viewed as an optimization of NSIS signaling? jak ----- Original Message ----- From: To: ; ; Sent: Monday, July 08, 2002 9:20 AM Subject: [Seamoby] RE: [NSIS] Re: draft-westphal-nsis-qos-mobileip-00.txt > Hi Gary: > > Some comments inline: > > -----Original Message----- > From: ext Gary Kenward [mailto:gkenward@nortelnetworks.com] > Sent: 08. July 2002 12:00 > To: 'seamoby@ietf.org'; 'NSIS' > Subject: [NSIS] Re: draft-westphal-nsis-qos-mobileip-00.txt > Sensitivity: Confidential > > > I finally managed to find time to read through Cedric's and Hemant's draft. > Overally, I think it is a good description of one possible integrated > approach. > > [Hemant] Please note that the Edge Signaling (MN-AR and AR-AR) and Data Path Signaling (e2e if you will) are not "tightly integrated", i.e., they help each other but do not rely on each other (though I admit that the current writeup makes that impression). In other words, Data Path Signaling can work (at handoff time) even if Edge Signaling fails. > > The one general comment I would like to offer up at this time, is that while > > the draft does a good job of integrating MIP, CT and NSIS concepts, the > proposed solutions for QoS negotiation between MN and AN (e.g. the use of > the > CIN message) is NSIS not CT. > > [Hemant] Point well taken. > > CT is concerned with the transfer of forwarding service context between > ANRs. > NSIS is concerned with the signalling of service requirements. Thus, the > issue > is not how to interwork the "CT" CIN, for example, with NSIS signalling, but > how > the CIN, etc., form part of the NSIS solution. > > [Hemant] I agree. The basic idea is that if CT can help avoid MN-new AR NSIS signaling at handoff time, it is a good proposition. Note that context can be constructed at old AR using the information supplied to it by NSIS MN-old AR message at session initiation, which can be transported to new AR in CT. If CT fails, one should use MN-new AR NSIS signaling at handoff time, albeit at certain loss of seamlessness. > > [Hemant] Thanks, Hemant > > This is not simply an issue of adherence to Seamoby/NSIS models or charters. > The intention has always been that CT work as a context transfer mechanism > with a variety of mobility and service signalling solutions. There is a > significant > benefit in the real world to be realized in keeping the context transfer > solution > (CT) independent from the service signalling solution (NSIS) (and the > mobility > solution - MIP or whatever). I would think that there is also a benefit to > keeping > the MN to AR service signalling independent of CT. > > Stated a different way, do we really need two separate solutions for over > the air > (MN to AN) service signalling? > > Regards, > Gary Kenward > > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > > _______________________________________________ > 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 From seamoby-admin@ietf.org Mon Jul 8 13:10:52 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25639 for ; Mon, 8 Jul 2002 13:10:52 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA05055; Mon, 8 Jul 2002 13:05:39 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA04986 for ; Mon, 8 Jul 2002 13:05:36 -0400 (EDT) Received: from mgw-dax2.ext.nokia.com (mgw-dax2.ext.nokia.com [63.78.179.217]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25330; Mon, 8 Jul 2002 13:04:44 -0400 (EDT) From: Hemant.Chaskar@nokia.com Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax2.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g68H9Gj19579; Mon, 8 Jul 2002 12:09:16 -0500 (CDT) Received: from daebh002.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 8 Jul 2002 12:05:33 -0500 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Mon, 8 Jul 2002 12:04:37 -0500 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Seamoby] RE: [NSIS] Re: draft-westphal-nsis-qos-mobileip-00.txt X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Date: Mon, 8 Jul 2002 13:04:36 -0400 Message-ID: Thread-Topic: [Seamoby] RE: [NSIS] Re: draft-westphal-nsis-qos-mobileip-00.txt Thread-Index: AcImnjwicOWGywY0SGyWtZe2Im4KQQAAIWpg To: , , , X-OriginalArrivalTime: 08 Jul 2002 17:04:37.0145 (UTC) FILETIME=[8A496090:01C226A1] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id NAA04987 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 8bit Hi James: I have the impression that CT is an optimization for NSIS as it can help avoid sending signaling payload bits over MN-new AR link at handoff time. Now, this assumes that there is only one feasible target for handoff. Then, CT is simply transferring QoS description available at old AR to new AR. If the level of service available at new AR is greater or less that what CT has transferred, NSIS can take care of adaptation as the session continues from new AR. If there are more than one feasible targets for handoff (this is where CARD may come in play), then the situation is little involved. If we can limit CARD negotiation to new AR resource check alone (as simple as bandwidth available on new AR-MN link or new AR outgoing interfaces), then the NSIS data path QoS signaling payload will be automatically available at new AR as a result of CARD negotiation procedures. On the other hand, if we have to check resource on new AR - CN data path also before concluding anything about handoff target, some NSIS signaling could occur along data path before CARD. Hemant -----Original Message----- From: ext James Kempf [mailto:kempf@docomolabs-usa.com] Sent: 08. July 2002 12:39 To: Chaskar Hemant (NRC/Boston); gkenward@nortelnetworks.com; seamoby@ietf.org; nsis@ietf.org Subject: Re: [Seamoby] RE: [NSIS] Re: draft-westphal-nsis-qos-mobileip-00.txt Could CT be viewed as an optimization of NSIS signaling? jak ----- Original Message ----- From: To: ; ; Sent: Monday, July 08, 2002 9:20 AM Subject: [Seamoby] RE: [NSIS] Re: draft-westphal-nsis-qos-mobileip-00.txt > Hi Gary: > > Some comments inline: > > -----Original Message----- > From: ext Gary Kenward [mailto:gkenward@nortelnetworks.com] > Sent: 08. July 2002 12:00 > To: 'seamoby@ietf.org'; 'NSIS' > Subject: [NSIS] Re: draft-westphal-nsis-qos-mobileip-00.txt > Sensitivity: Confidential > > > I finally managed to find time to read through Cedric's and Hemant's draft. > Overally, I think it is a good description of one possible integrated > approach. > > [Hemant] Please note that the Edge Signaling (MN-AR and AR-AR) and Data Path Signaling (e2e if you will) are not "tightly integrated", i.e., they help each other but do not rely on each other (though I admit that the current writeup makes that impression). In other words, Data Path Signaling can work (at handoff time) even if Edge Signaling fails. > > The one general comment I would like to offer up at this time, is that while > > the draft does a good job of integrating MIP, CT and NSIS concepts, the > proposed solutions for QoS negotiation between MN and AN (e.g. the use of > the > CIN message) is NSIS not CT. > > [Hemant] Point well taken. > > CT is concerned with the transfer of forwarding service context between > ANRs. > NSIS is concerned with the signalling of service requirements. Thus, the > issue > is not how to interwork the "CT" CIN, for example, with NSIS signalling, but > how > the CIN, etc., form part of the NSIS solution. > > [Hemant] I agree. The basic idea is that if CT can help avoid MN-new AR NSIS signaling at handoff time, it is a good proposition. Note that context can be constructed at old AR using the information supplied to it by NSIS MN-old AR message at session initiation, which can be transported to new AR in CT. If CT fails, one should use MN-new AR NSIS signaling at handoff time, albeit at certain loss of seamlessness. > > [Hemant] Thanks, Hemant > > This is not simply an issue of adherence to Seamoby/NSIS models or charters. > The intention has always been that CT work as a context transfer mechanism > with a variety of mobility and service signalling solutions. There is a > significant > benefit in the real world to be realized in keeping the context transfer > solution > (CT) independent from the service signalling solution (NSIS) (and the > mobility > solution - MIP or whatever). I would think that there is also a benefit to > keeping > the MN to AR service signalling independent of CT. > > Stated a different way, do we really need two separate solutions for over > the air > (MN to AN) service signalling? > > Regards, > Gary Kenward > > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > > _______________________________________________ > 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 From daemon@optimus.ietf.org Mon Jul 8 13:10:52 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25647 for ; Mon, 8 Jul 2002 13:10:52 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA05427 for seamoby-archive@odin.ietf.org; Mon, 8 Jul 2002 13:11:43 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA05055; Mon, 8 Jul 2002 13:05:39 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA04986 for ; Mon, 8 Jul 2002 13:05:36 -0400 (EDT) Received: from mgw-dax2.ext.nokia.com (mgw-dax2.ext.nokia.com [63.78.179.217]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25330; Mon, 8 Jul 2002 13:04:44 -0400 (EDT) From: Hemant.Chaskar@nokia.com Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax2.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g68H9Gj19579; Mon, 8 Jul 2002 12:09:16 -0500 (CDT) Received: from daebh002.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 8 Jul 2002 12:05:33 -0500 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Mon, 8 Jul 2002 12:04:37 -0500 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Seamoby] RE: [NSIS] Re: draft-westphal-nsis-qos-mobileip-00.txt X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Date: Mon, 8 Jul 2002 13:04:36 -0400 Message-ID: Thread-Topic: [Seamoby] RE: [NSIS] Re: draft-westphal-nsis-qos-mobileip-00.txt Thread-Index: AcImnjwicOWGywY0SGyWtZe2Im4KQQAAIWpg To: , , , X-OriginalArrivalTime: 08 Jul 2002 17:04:37.0145 (UTC) FILETIME=[8A496090:01C226A1] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id NAA04987 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 8bit Hi James: I have the impression that CT is an optimization for NSIS as it can help avoid sending signaling payload bits over MN-new AR link at handoff time. Now, this assumes that there is only one feasible target for handoff. Then, CT is simply transferring QoS description available at old AR to new AR. If the level of service available at new AR is greater or less that what CT has transferred, NSIS can take care of adaptation as the session continues from new AR. If there are more than one feasible targets for handoff (this is where CARD may come in play), then the situation is little involved. If we can limit CARD negotiation to new AR resource check alone (as simple as bandwidth available on new AR-MN link or new AR outgoing interfaces), then the NSIS data path QoS signaling payload will be automatically available at new AR as a result of CARD negotiation procedures. On the other hand, if we have to check resource on new AR - CN data path also before concluding anything about handoff target, some NSIS signaling could occur along data path before CARD. Hemant -----Original Message----- From: ext James Kempf [mailto:kempf@docomolabs-usa.com] Sent: 08. July 2002 12:39 To: Chaskar Hemant (NRC/Boston); gkenward@nortelnetworks.com; seamoby@ietf.org; nsis@ietf.org Subject: Re: [Seamoby] RE: [NSIS] Re: draft-westphal-nsis-qos-mobileip-00.txt Could CT be viewed as an optimization of NSIS signaling? jak ----- Original Message ----- From: To: ; ; Sent: Monday, July 08, 2002 9:20 AM Subject: [Seamoby] RE: [NSIS] Re: draft-westphal-nsis-qos-mobileip-00.txt > Hi Gary: > > Some comments inline: > > -----Original Message----- > From: ext Gary Kenward [mailto:gkenward@nortelnetworks.com] > Sent: 08. July 2002 12:00 > To: 'seamoby@ietf.org'; 'NSIS' > Subject: [NSIS] Re: draft-westphal-nsis-qos-mobileip-00.txt > Sensitivity: Confidential > > > I finally managed to find time to read through Cedric's and Hemant's draft. > Overally, I think it is a good description of one possible integrated > approach. > > [Hemant] Please note that the Edge Signaling (MN-AR and AR-AR) and Data Path Signaling (e2e if you will) are not "tightly integrated", i.e., they help each other but do not rely on each other (though I admit that the current writeup makes that impression). In other words, Data Path Signaling can work (at handoff time) even if Edge Signaling fails. > > The one general comment I would like to offer up at this time, is that while > > the draft does a good job of integrating MIP, CT and NSIS concepts, the > proposed solutions for QoS negotiation between MN and AN (e.g. the use of > the > CIN message) is NSIS not CT. > > [Hemant] Point well taken. > > CT is concerned with the transfer of forwarding service context between > ANRs. > NSIS is concerned with the signalling of service requirements. Thus, the > issue > is not how to interwork the "CT" CIN, for example, with NSIS signalling, but > how > the CIN, etc., form part of the NSIS solution. > > [Hemant] I agree. The basic idea is that if CT can help avoid MN-new AR NSIS signaling at handoff time, it is a good proposition. Note that context can be constructed at old AR using the information supplied to it by NSIS MN-old AR message at session initiation, which can be transported to new AR in CT. If CT fails, one should use MN-new AR NSIS signaling at handoff time, albeit at certain loss of seamlessness. > > [Hemant] Thanks, Hemant > > This is not simply an issue of adherence to Seamoby/NSIS models or charters. > The intention has always been that CT work as a context transfer mechanism > with a variety of mobility and service signalling solutions. There is a > significant > benefit in the real world to be realized in keeping the context transfer > solution > (CT) independent from the service signalling solution (NSIS) (and the > mobility > solution - MIP or whatever). I would think that there is also a benefit to > keeping > the MN to AR service signalling independent of CT. > > Stated a different way, do we really need two separate solutions for over > the air > (MN to AN) service signalling? > > Regards, > Gary Kenward > > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > > _______________________________________________ > 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 From seamoby-admin@ietf.org Mon Jul 8 13:22:30 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26316 for ; Mon, 8 Jul 2002 13:22:30 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA05845; Mon, 8 Jul 2002 13:18:16 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA05735 for ; Mon, 8 Jul 2002 13:18:11 -0400 (EDT) Received: from zcars04e.ca.nortel.com (zcars04e.nortelnetworks.com [47.129.242.56]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26034; Mon, 8 Jul 2002 13:17:19 -0400 (EDT) Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g68HHE901854; Mon, 8 Jul 2002 13:17:14 -0400 (EDT) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 8 Jul 2002 13:17:13 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA4BEF@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'James Kempf'" , Hemant.Chaskar@nokia.com, seamoby@ietf.org, nsis@ietf.org Subject: RE: [Seamoby] RE: [NSIS] Re: draft-westphal-nsis-qos-mobileip-00. txt Date: Mon, 8 Jul 2002 13:17:08 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C226A3.49C8C2B6" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C226A3.49C8C2B6 Content-Type: text/plain; charset="iso-8859-1" James: In a way, yes. But if CT is present, and succeeds, then there should be no need for MN-AN signalling, thus CT optimizes NSIS completely away during handover (in this preferred scenario). Note that I specifically identified MN-AN NSIS, as I think what happens within the interior of the AN is a broader discussion. From a seamless perspective, one would hope that no signalling would be required. However, this objective may not be possible with some service topologies (e.g. Int Serv QoS). As I hinted earlier, one could assume the use of CT for internal router context transfer (e.g. Int Serv configuration/state between IRs), unfortunately, there are some serious discover/topological issues that arise. NSIS may be the best possible general approach for per flow IR service configuration with handovers. On the other hand, some may be willing to live with topological constraints (PDP context relocation comes to mind here). Gary > -----Original Message----- > From: James Kempf [mailto:kempf@docomolabs-usa.com] > Sent: July 8, 2002 12:39 > To: Hemant.Chaskar@nokia.com; Kenward, Gary [WDLN2:AN10:EXCH]; > seamoby@ietf.org; nsis@ietf.org > Subject: Re: [Seamoby] RE: [NSIS] Re: > draft-westphal-nsis-qos-mobileip-00.txt > > > Could CT be viewed as an optimization of NSIS signaling? > > jak > > ----- Original Message ----- > From: > To: ; ; > Sent: Monday, July 08, 2002 9:20 AM > Subject: [Seamoby] RE: [NSIS] Re: > draft-westphal-nsis-qos-mobileip-00.txt > > > > Hi Gary: > > > > Some comments inline: > > > > -----Original Message----- > > From: ext Gary Kenward [mailto:gkenward@nortelnetworks.com] > > Sent: 08. July 2002 12:00 > > To: 'seamoby@ietf.org'; 'NSIS' > > Subject: [NSIS] Re: draft-westphal-nsis-qos-mobileip-00.txt > > Sensitivity: Confidential > > > > > > I finally managed to find time to read through Cedric's and > Hemant's draft. > > Overally, I think it is a good description of one possible > integrated > > approach. > > > > [Hemant] Please note that the Edge Signaling (MN-AR and > AR-AR) and Data Path Signaling (e2e if you will) are not "tightly > integrated", i.e., they help each other but do not rely on > each other (though I admit that the current writeup makes that > impression). In other words, Data Path Signaling can work (at > handoff time) even if Edge Signaling fails. > > > > The one general comment I would like to offer up at this > time, is that while > > > > the draft does a good job of integrating MIP, CT and NSIS > concepts, the > > proposed solutions for QoS negotiation between MN and AN > (e.g. the use of > > the > > CIN message) is NSIS not CT. > > > > [Hemant] Point well taken. > > > > CT is concerned with the transfer of forwarding service > context between > > ANRs. > > NSIS is concerned with the signalling of service > requirements. Thus, the > > issue > > is not how to interwork the "CT" CIN, for example, with > NSIS signalling, but > > how > > the CIN, etc., form part of the NSIS solution. > > > > [Hemant] I agree. The basic idea is that if CT can help > avoid MN-new AR NSIS signaling at handoff time, it is a good > proposition. > Note that context can be constructed at old AR using the > information supplied to it by NSIS MN-old AR message at > session initiation, > which can be transported to new AR in CT. If CT fails, one > should use MN-new AR NSIS signaling at handoff time, albeit at certain > loss of seamlessness. > > > > [Hemant] Thanks, Hemant > > > > This is not simply an issue of adherence to Seamoby/NSIS > models or charters. > > The intention has always been that CT work as a context > transfer mechanism > > with a variety of mobility and service signalling > solutions. There is a > > significant > > benefit in the real world to be realized in keeping the > context transfer > > solution > > (CT) independent from the service signalling solution > (NSIS) (and the > > mobility > > solution - MIP or whatever). I would think that there is > also a benefit to > > keeping > > the MN to AR service signalling independent of CT. > > > > Stated a different way, do we really need two separate > solutions for over > > the air > > (MN to AN) service signalling? > > > > Regards, > > Gary Kenward > > > > > > > > _______________________________________________ > > nsis mailing list > > nsis@ietf.org > > https://www1.ietf.org/mailman/listinfo/nsis > > > > _______________________________________________ > > Seamoby mailing list > > Seamoby@ietf.org > > https://www1.ietf.org/mailman/listinfo/seamoby > > > > ------_=_NextPart_001_01C226A3.49C8C2B6 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Seamoby] RE: [NSIS] Re: = draft-westphal-nsis-qos-mobileip-00.txt

James:

  In a way, yes. But if CT is present, and = succeeds, then there
should be no need for MN-AN signalling, thus CT = optimizes NSIS completely
away during handover (in this preferred = scenario).

  Note that I specifically identified MN-AN = NSIS, as I think what happens
within the interior of the AN is a broader = discussion. From a seamless
perspective, one would hope that no signalling would = be required. However,
this objective may not be possible with some service = topologies (e.g. Int
Serv QoS). As I hinted earlier, one could assume the = use of CT for internal
router context transfer (e.g. Int Serv = configuration/state between IRs),
unfortunately, there are some serious = discover/topological issues that arise.
NSIS may be the best possible general approach for = per flow IR service
configuration with handovers. On the other hand, = some may be willing to live
with topological constraints (PDP context relocation = comes to mind here).

Gary

> -----Original Message-----
> From: James Kempf [mailto:kempf@docomolabs-usa.com= ]
> Sent: July 8, 2002 12:39
> To: Hemant.Chaskar@nokia.com; Kenward, Gary = [WDLN2:AN10:EXCH];
> seamoby@ietf.org; nsis@ietf.org
> Subject: Re: [Seamoby] RE: [NSIS] Re:
> draft-westphal-nsis-qos-mobileip-00.txt
>
>
> Could CT be viewed as an optimization of NSIS = signaling?
>
>          = ;   jak
>
> ----- Original Message -----
> From: <Hemant.Chaskar@nokia.com>
> To: <gkenward@nortelnetworks.com>; = <seamoby@ietf.org>; <nsis@ietf.org>
> Sent: Monday, July 08, 2002 9:20 AM
> Subject: [Seamoby] RE: [NSIS] Re:
> draft-westphal-nsis-qos-mobileip-00.txt
>
>
> > Hi Gary:
> >
> > Some comments inline:
> >
> > -----Original Message-----
> > From: ext Gary Kenward [mailto:gkenward@nortelnetwor= ks.com]
> > Sent: 08. July 2002 12:00
> > To: 'seamoby@ietf.org'; 'NSIS'
> > Subject: [NSIS] Re: = draft-westphal-nsis-qos-mobileip-00.txt
> > Sensitivity: Confidential
> >
> >
> > I finally managed to find time to read = through Cedric's and
> Hemant's draft.
> > Overally, I think it is a good description = of one possible
> integrated
> > approach.
> >
> > [Hemant] Please note that the Edge = Signaling (MN-AR and
> AR-AR) and Data Path Signaling (e2e if you = will) are not "tightly
> integrated", i.e., they help each other = but do not rely on
> each other (though I admit that the current = writeup makes that
> impression). In other words, Data Path = Signaling can work (at
> handoff time) even if Edge Signaling = fails.
> >
> > The one general comment I would like to = offer up at this
> time, is that while
> >
> > the draft does a good job of integrating = MIP, CT and NSIS
> concepts, the
> > proposed solutions for QoS negotiation = between MN and AN
> (e.g. the use of
> > the
> > CIN message) is NSIS not CT.
> >
> > [Hemant] Point well taken.
> >
> > CT is concerned with the transfer of = forwarding service
> context between
> > ANRs.
> > NSIS is concerned with the signalling of = service
> requirements. Thus, the
> > issue
> > is not how to interwork the "CT" = CIN, for example, with
> NSIS signalling, but
> > how
> > the CIN, etc., form part of the NSIS = solution.
> >
> > [Hemant] I agree. The basic idea is that = if CT can help
> avoid MN-new AR NSIS signaling at handoff time, = it is a good
> proposition.
> Note that context can be constructed at old AR = using the
> information supplied to it by NSIS MN-old AR = message at
> session initiation,
> which can be transported to new AR in CT. If CT = fails, one
> should use MN-new AR NSIS signaling at handoff = time, albeit at certain
> loss of seamlessness.
> >
> > [Hemant] Thanks, Hemant
> >
> > This is not simply an issue of adherence = to Seamoby/NSIS
> models or charters.
> > The intention has always been that CT work = as a context
> transfer mechanism
> > with a variety of mobility and service = signalling
> solutions. There is a
> > significant
> > benefit in the real world to be realized = in keeping the
> context transfer
> > solution
> > (CT) independent from the service = signalling solution
> (NSIS) (and the
> > mobility
> > solution - MIP or whatever). I would think = that there is
> also a benefit to
> > keeping
> > the MN to AR service signalling = independent of CT.
> >
> > Stated a different way, do we really need = two separate
> solutions for over
> > the air
> > (MN to AN) service signalling?
> >
> > Regards,
> > Gary Kenward
> >
> >
> >
> > = _______________________________________________
> > nsis mailing list
> > nsis@ietf.org
> > https://www1.ietf.org/mailman/listinfo/nsis=
> >
> > = _______________________________________________
> > Seamoby mailing list
> > Seamoby@ietf.org
> > https://www1.ietf.org/mailman/listinfo/seamoby
> >
>
>

------_=_NextPart_001_01C226A3.49C8C2B6-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Mon Jul 8 13:22:31 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26324 for ; Mon, 8 Jul 2002 13:22:31 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA06146 for seamoby-archive@odin.ietf.org; Mon, 8 Jul 2002 13:23:22 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA05845; Mon, 8 Jul 2002 13:18:16 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA05735 for ; Mon, 8 Jul 2002 13:18:11 -0400 (EDT) Received: from zcars04e.ca.nortel.com (zcars04e.nortelnetworks.com [47.129.242.56]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26034; Mon, 8 Jul 2002 13:17:19 -0400 (EDT) Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g68HHE901854; Mon, 8 Jul 2002 13:17:14 -0400 (EDT) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 8 Jul 2002 13:17:13 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA4BEF@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'James Kempf'" , Hemant.Chaskar@nokia.com, seamoby@ietf.org, nsis@ietf.org Subject: RE: [Seamoby] RE: [NSIS] Re: draft-westphal-nsis-qos-mobileip-00. txt Date: Mon, 8 Jul 2002 13:17:08 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C226A3.49C8C2B6" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C226A3.49C8C2B6 Content-Type: text/plain; charset="iso-8859-1" James: In a way, yes. But if CT is present, and succeeds, then there should be no need for MN-AN signalling, thus CT optimizes NSIS completely away during handover (in this preferred scenario). Note that I specifically identified MN-AN NSIS, as I think what happens within the interior of the AN is a broader discussion. From a seamless perspective, one would hope that no signalling would be required. However, this objective may not be possible with some service topologies (e.g. Int Serv QoS). As I hinted earlier, one could assume the use of CT for internal router context transfer (e.g. Int Serv configuration/state between IRs), unfortunately, there are some serious discover/topological issues that arise. NSIS may be the best possible general approach for per flow IR service configuration with handovers. On the other hand, some may be willing to live with topological constraints (PDP context relocation comes to mind here). Gary > -----Original Message----- > From: James Kempf [mailto:kempf@docomolabs-usa.com] > Sent: July 8, 2002 12:39 > To: Hemant.Chaskar@nokia.com; Kenward, Gary [WDLN2:AN10:EXCH]; > seamoby@ietf.org; nsis@ietf.org > Subject: Re: [Seamoby] RE: [NSIS] Re: > draft-westphal-nsis-qos-mobileip-00.txt > > > Could CT be viewed as an optimization of NSIS signaling? > > jak > > ----- Original Message ----- > From: > To: ; ; > Sent: Monday, July 08, 2002 9:20 AM > Subject: [Seamoby] RE: [NSIS] Re: > draft-westphal-nsis-qos-mobileip-00.txt > > > > Hi Gary: > > > > Some comments inline: > > > > -----Original Message----- > > From: ext Gary Kenward [mailto:gkenward@nortelnetworks.com] > > Sent: 08. July 2002 12:00 > > To: 'seamoby@ietf.org'; 'NSIS' > > Subject: [NSIS] Re: draft-westphal-nsis-qos-mobileip-00.txt > > Sensitivity: Confidential > > > > > > I finally managed to find time to read through Cedric's and > Hemant's draft. > > Overally, I think it is a good description of one possible > integrated > > approach. > > > > [Hemant] Please note that the Edge Signaling (MN-AR and > AR-AR) and Data Path Signaling (e2e if you will) are not "tightly > integrated", i.e., they help each other but do not rely on > each other (though I admit that the current writeup makes that > impression). In other words, Data Path Signaling can work (at > handoff time) even if Edge Signaling fails. > > > > The one general comment I would like to offer up at this > time, is that while > > > > the draft does a good job of integrating MIP, CT and NSIS > concepts, the > > proposed solutions for QoS negotiation between MN and AN > (e.g. the use of > > the > > CIN message) is NSIS not CT. > > > > [Hemant] Point well taken. > > > > CT is concerned with the transfer of forwarding service > context between > > ANRs. > > NSIS is concerned with the signalling of service > requirements. Thus, the > > issue > > is not how to interwork the "CT" CIN, for example, with > NSIS signalling, but > > how > > the CIN, etc., form part of the NSIS solution. > > > > [Hemant] I agree. The basic idea is that if CT can help > avoid MN-new AR NSIS signaling at handoff time, it is a good > proposition. > Note that context can be constructed at old AR using the > information supplied to it by NSIS MN-old AR message at > session initiation, > which can be transported to new AR in CT. If CT fails, one > should use MN-new AR NSIS signaling at handoff time, albeit at certain > loss of seamlessness. > > > > [Hemant] Thanks, Hemant > > > > This is not simply an issue of adherence to Seamoby/NSIS > models or charters. > > The intention has always been that CT work as a context > transfer mechanism > > with a variety of mobility and service signalling > solutions. There is a > > significant > > benefit in the real world to be realized in keeping the > context transfer > > solution > > (CT) independent from the service signalling solution > (NSIS) (and the > > mobility > > solution - MIP or whatever). I would think that there is > also a benefit to > > keeping > > the MN to AR service signalling independent of CT. > > > > Stated a different way, do we really need two separate > solutions for over > > the air > > (MN to AN) service signalling? > > > > Regards, > > Gary Kenward > > > > > > > > _______________________________________________ > > nsis mailing list > > nsis@ietf.org > > https://www1.ietf.org/mailman/listinfo/nsis > > > > _______________________________________________ > > Seamoby mailing list > > Seamoby@ietf.org > > https://www1.ietf.org/mailman/listinfo/seamoby > > > > ------_=_NextPart_001_01C226A3.49C8C2B6 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Seamoby] RE: [NSIS] Re: = draft-westphal-nsis-qos-mobileip-00.txt

James:

  In a way, yes. But if CT is present, and = succeeds, then there
should be no need for MN-AN signalling, thus CT = optimizes NSIS completely
away during handover (in this preferred = scenario).

  Note that I specifically identified MN-AN = NSIS, as I think what happens
within the interior of the AN is a broader = discussion. From a seamless
perspective, one would hope that no signalling would = be required. However,
this objective may not be possible with some service = topologies (e.g. Int
Serv QoS). As I hinted earlier, one could assume the = use of CT for internal
router context transfer (e.g. Int Serv = configuration/state between IRs),
unfortunately, there are some serious = discover/topological issues that arise.
NSIS may be the best possible general approach for = per flow IR service
configuration with handovers. On the other hand, = some may be willing to live
with topological constraints (PDP context relocation = comes to mind here).

Gary

> -----Original Message-----
> From: James Kempf [mailto:kempf@docomolabs-usa.com= ]
> Sent: July 8, 2002 12:39
> To: Hemant.Chaskar@nokia.com; Kenward, Gary = [WDLN2:AN10:EXCH];
> seamoby@ietf.org; nsis@ietf.org
> Subject: Re: [Seamoby] RE: [NSIS] Re:
> draft-westphal-nsis-qos-mobileip-00.txt
>
>
> Could CT be viewed as an optimization of NSIS = signaling?
>
>          = ;   jak
>
> ----- Original Message -----
> From: <Hemant.Chaskar@nokia.com>
> To: <gkenward@nortelnetworks.com>; = <seamoby@ietf.org>; <nsis@ietf.org>
> Sent: Monday, July 08, 2002 9:20 AM
> Subject: [Seamoby] RE: [NSIS] Re:
> draft-westphal-nsis-qos-mobileip-00.txt
>
>
> > Hi Gary:
> >
> > Some comments inline:
> >
> > -----Original Message-----
> > From: ext Gary Kenward [mailto:gkenward@nortelnetwor= ks.com]
> > Sent: 08. July 2002 12:00
> > To: 'seamoby@ietf.org'; 'NSIS'
> > Subject: [NSIS] Re: = draft-westphal-nsis-qos-mobileip-00.txt
> > Sensitivity: Confidential
> >
> >
> > I finally managed to find time to read = through Cedric's and
> Hemant's draft.
> > Overally, I think it is a good description = of one possible
> integrated
> > approach.
> >
> > [Hemant] Please note that the Edge = Signaling (MN-AR and
> AR-AR) and Data Path Signaling (e2e if you = will) are not "tightly
> integrated", i.e., they help each other = but do not rely on
> each other (though I admit that the current = writeup makes that
> impression). In other words, Data Path = Signaling can work (at
> handoff time) even if Edge Signaling = fails.
> >
> > The one general comment I would like to = offer up at this
> time, is that while
> >
> > the draft does a good job of integrating = MIP, CT and NSIS
> concepts, the
> > proposed solutions for QoS negotiation = between MN and AN
> (e.g. the use of
> > the
> > CIN message) is NSIS not CT.
> >
> > [Hemant] Point well taken.
> >
> > CT is concerned with the transfer of = forwarding service
> context between
> > ANRs.
> > NSIS is concerned with the signalling of = service
> requirements. Thus, the
> > issue
> > is not how to interwork the "CT" = CIN, for example, with
> NSIS signalling, but
> > how
> > the CIN, etc., form part of the NSIS = solution.
> >
> > [Hemant] I agree. The basic idea is that = if CT can help
> avoid MN-new AR NSIS signaling at handoff time, = it is a good
> proposition.
> Note that context can be constructed at old AR = using the
> information supplied to it by NSIS MN-old AR = message at
> session initiation,
> which can be transported to new AR in CT. If CT = fails, one
> should use MN-new AR NSIS signaling at handoff = time, albeit at certain
> loss of seamlessness.
> >
> > [Hemant] Thanks, Hemant
> >
> > This is not simply an issue of adherence = to Seamoby/NSIS
> models or charters.
> > The intention has always been that CT work = as a context
> transfer mechanism
> > with a variety of mobility and service = signalling
> solutions. There is a
> > significant
> > benefit in the real world to be realized = in keeping the
> context transfer
> > solution
> > (CT) independent from the service = signalling solution
> (NSIS) (and the
> > mobility
> > solution - MIP or whatever). I would think = that there is
> also a benefit to
> > keeping
> > the MN to AR service signalling = independent of CT.
> >
> > Stated a different way, do we really need = two separate
> solutions for over
> > the air
> > (MN to AN) service signalling?
> >
> > Regards,
> > Gary Kenward
> >
> >
> >
> > = _______________________________________________
> > nsis mailing list
> > nsis@ietf.org
> > https://www1.ietf.org/mailman/listinfo/nsis=
> >
> > = _______________________________________________
> > Seamoby mailing list
> > Seamoby@ietf.org
> > https://www1.ietf.org/mailman/listinfo/seamoby
> >
>
>

------_=_NextPart_001_01C226A3.49C8C2B6-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Mon Jul 8 14:34:08 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00524 for ; Mon, 8 Jul 2002 14:34:08 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA10803; Mon, 8 Jul 2002 14:30:25 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA10699 for ; Mon, 8 Jul 2002 14:30:18 -0400 (EDT) Received: from auds952.usa.alcatel.com (auds952.usa.alcatel.com [143.209.238.7]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00167; Mon, 8 Jul 2002 14:29:25 -0400 (EDT) Received: from alcatel.com (localhost [127.0.0.1]) by auds952.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id g68ITjv03128; Mon, 8 Jul 2002 13:29:45 -0500 (CDT) Message-ID: <3D29DA39.1090405@alcatel.com> Date: Mon, 08 Jul 2002 13:30:17 -0500 From: Behcet Sarikaya Organization: Alcatel USA User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4.1) Gecko/20020314 Netscape6/6.2.2 X-Accept-Language: en-us MIME-Version: 1.0 To: Hemant.Chaskar@nokia.com CC: seamoby@ietf.org, nsis@ietf.org Subject: Re: [Seamoby] RE: [NSIS] Re: draft-westphal-nsis-qos-mobileip-00.txt References: Content-Type: multipart/alternative; boundary="------------060308060208010408090808" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org --------------060308060208010408090808 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hello Hemant, The relationship between nsis and CT, as far as I know is that of uncertainty. nsis which started out to develop signaling for QoS now changed to only signaling, CT is going nowhere at Seamoby. The only sure thing is that the links have CT quite well defined, IEEE defined for 802.11 links and 3G links also have well defined context transfer protocols. In order to add to the present confusion, let me note the new BOF called: Topology-Insensitive Service Traversal which is probably going to deal with RSVP based signaling. My 0.03 euros (increased due to recent increase in value of the Euro). Hemant.Chaskar@nokia.com wrote: >Hi James: > >I have the impression that CT is an optimization for NSIS as it can help avoid sending signaling payload bits over MN-new AR link at handoff time. Now, this assumes that there is only one feasible target for handoff. Then, CT is simply transferring QoS description available at old AR to new AR. If the level of service available at new AR is greater or less that what CT has transferred, NSIS can take care of adaptation as the session continues from new AR. > >If there are more than one feasible targets for handoff (this is where CARD may come in play), then the situation is little involved. If we can limit CARD negotiation to new AR resource check alone (as simple as bandwidth available on new AR-MN link or new AR outgoing interfaces), then the NSIS data path QoS signaling payload will be automatically available at new AR as a result of CARD negotiation procedures. On the other hand, if we have to check resource on new AR - CN data path also before concluding anything about handoff target, some NSIS signaling could occur along data path before CARD. > >Hemant > >-----Original Message----- >From: ext James Kempf [mailto:kempf@docomolabs-usa.com] >Sent: 08. July 2002 12:39 >To: Chaskar Hemant (NRC/Boston); gkenward@nortelnetworks.com; >seamoby@ietf.org; nsis@ietf.org >Subject: Re: [Seamoby] RE: [NSIS] Re: >draft-westphal-nsis-qos-mobileip-00.txt > > >Could CT be viewed as an optimization of NSIS signaling? > > jak > >----- Original Message ----- >From: >To: ; ; >Sent: Monday, July 08, 2002 9:20 AM >Subject: [Seamoby] RE: [NSIS] Re: draft-westphal-nsis-qos-mobileip-00.txt > > >>Hi Gary: >> >>Some comments inline: >> >>-----Original Message----- >>From: ext Gary Kenward [mailto:gkenward@nortelnetworks.com] >>Sent: 08. July 2002 12:00 >>To: 'seamoby@ietf.org'; 'NSIS' >>Subject: [NSIS] Re: draft-westphal-nsis-qos-mobileip-00.txt >>Sensitivity: Confidential >> >> >>I finally managed to find time to read through Cedric's and Hemant's draft. >>Overally, I think it is a good description of one possible integrated >>approach. >> >>[Hemant] Please note that the Edge Signaling (MN-AR and AR-AR) and Data Path Signaling (e2e if you will) are not "tightly >> >integrated", i.e., they help each other but do not rely on each other (though I admit that the current writeup makes that >impression). In other words, Data Path Signaling can work (at handoff time) even if Edge Signaling fails. > >>The one general comment I would like to offer up at this time, is that while >> >>the draft does a good job of integrating MIP, CT and NSIS concepts, the >>proposed solutions for QoS negotiation between MN and AN (e.g. the use of >>the >>CIN message) is NSIS not CT. >> >>[Hemant] Point well taken. >> >>CT is concerned with the transfer of forwarding service context between >>ANRs. >>NSIS is concerned with the signalling of service requirements. Thus, the >>issue >>is not how to interwork the "CT" CIN, for example, with NSIS signalling, but >>how >>the CIN, etc., form part of the NSIS solution. >> >>[Hemant] I agree. The basic idea is that if CT can help avoid MN-new AR NSIS signaling at handoff time, it is a good proposition. >> >Note that context can be constructed at old AR using the information supplied to it by NSIS MN-old AR message at session initiation, >which can be transported to new AR in CT. If CT fails, one should use MN-new AR NSIS signaling at handoff time, albeit at certain >loss of seamlessness. > >>[Hemant] Thanks, Hemant >> >>This is not simply an issue of adherence to Seamoby/NSIS models or charters. >>The intention has always been that CT work as a context transfer mechanism >>with a variety of mobility and service signalling solutions. There is a >>significant >>benefit in the real world to be realized in keeping the context transfer >>solution >>(CT) independent from the service signalling solution (NSIS) (and the >>mobility >>solution - MIP or whatever). I would think that there is also a benefit to >>keeping >>the MN to AR service signalling independent of CT. >> >>Stated a different way, do we really need two separate solutions for over >>the air >>(MN to AN) service signalling? >> >>Regards, >>Gary Kenward >> >> >> >>_______________________________________________ >>nsis mailing list >>nsis@ietf.org >>https://www1.ietf.org/mailman/listinfo/nsis >> >>_______________________________________________ >>Seamoby mailing list >>Seamoby@ietf.org >>https://www1.ietf.org/mailman/listinfo/seamoby >> > > >_______________________________________________ >nsis mailing list >nsis@ietf.org >https://www1.ietf.org/mailman/listinfo/nsis > -- Behcet --------------060308060208010408090808 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hello Hemant,
 The relationship between nsis and CT, as far as I know is
that of uncertainty.
nsis which started out to develop signaling for QoS now changed to only signaling,
CT is going nowhere at Seamoby.
  The only sure thing is that the links have CT quite well defined, IEEE defined for 802.11 links and 3G links also have well defined context transfer protocols.
  In order to add to the present confusion, let me note the new BOF called:
Topology-Insensitive Service Traversal
which is probably going to deal with RSVP based signaling.

  My 0.03 euros (increased due to recent increase in value of the Euro).

Hemant.Chaskar@nokia.com wrote:
Hi James: 

I have the impression that CT is an optimization for NSIS as it can help avoid sending signaling payload bits over MN-new AR link at handoff time. Now, this assumes that there is only one feasible target for handoff. Then, CT is simply transferring QoS description available at old AR to new AR. If the level of service available at new AR is greater or less that what CT has transferred, NSIS can take care of adaptation as the session continues from new AR.

If there are more than one feasible targets for handoff (this is where CARD may come in play), then the situation is little involved. If we can limit CARD negotiation to new AR resource check alone (as simple as bandwidth available on new AR-MN link or new AR outgoing interfaces), then the NSIS data path QoS signaling payload will be automatically available at new AR as a result of CARD negotiation procedures. On the other hand, if we have to check resource on new AR - CN data path al
so before concluding anything about handoff target, some NSIS signaling could occur along data path before CARD.

Hemant

-----Original Message-----
From: ext James Kempf [mailto:kempf@docomolabs-usa.com]
Sent: 08. July 2002 12:39
To: Chaskar Hemant (NRC/Boston); gkenward@nortelnetworks.com;
seamoby@ietf.org; nsis@ietf.org
Subject: Re: [Seamoby] RE: [NSIS] Re:
draft-westphal-nsis-qos-mobileip-00.txt


Could CT be viewed as an optimization of NSIS signaling?

            jak

----- Original Message -----
From: <Hemant.Chaskar@nokia.com>
To: <gkenward@nortelnetworks.com>; <seamoby@ietf.org>; <nsis@ietf.org>
Sent: Monday, July 08, 2002 9:20 AM
Subject: [Seamoby] RE: [NSIS] Re: draft-westphal-nsis-qos-mobileip-00.txt


Hi Gary:

Some comments inline:

-----Original Message-----
From: ext Gary Kenward [mailto:gkenward@nortelnetworks.com]
Sent: 08. July 2002 12:00
To: 'seamoby@ietf.org'; 'NSIS'
Subject: [NSIS] Re: draft-westphal-nsis-qos-mobileip-00.txt
Sensitivity: Confidential


I finally managed to find time to read through Cedric's and Hemant's draft.
Overally, I think it is a good description of one possible integrated
approach.

[Hemant] Please note that the Edge Signaling (MN-AR and AR-AR) and Data Path Signaling (e2e if you will) are not "tightly
integrated", i.e., they help each other but do not rely on each other (though I admit that the current writeup makes that
impression). In other words, Data Path Signaling can work (at handoff time) even if Edge Signaling fails.
The one general comment I would like to offer up at this time, is that while

the draft does a good job of integrating MIP, CT and NSIS concepts, the
proposed solutions for QoS negotiation between MN and AN (e.g. the use of
the
CIN message) is NSIS not CT.

[Hemant] Point well taken.

CT is concerned with the transfer of forwarding service context between
ANRs.
NSIS is concerned with the signalling of service requirements. Thus, the
issue
is not how to interwork the "CT" CIN, for example, with NSIS signalling, but
how
the CIN, etc., form part of the NSIS solution.

[Hemant] I agree. The basic idea is that if CT can help avoid MN-new AR NSIS signaling at handoff time, it is a good proposition.
Note that context can be constructed at old AR using the information supplied to it by NSIS MN-old AR message at session initiation,
which can be transported to new AR in CT. If CT fails, one should use MN-new AR NSIS signaling at handoff time, albeit at certain
loss of seamlessness.
[Hemant] Thanks, Hemant

This is not simply an issue of adherence to Seamoby/NSIS models or charters.
The intention has always been that CT work as a context transfer mechanism
with a variety of mobility and service signalling solutions. There is a
significant
benefit in the real world to be realized in keeping the context transfer
solution
(CT) independent from the service signalling solution (NSIS) (and the
mobility
solution - MIP or whatever). I would think that there is also a benefit to
keeping
the MN to AR service signalling independent of CT.

Stated a different way, do we really need two separate solutions for over
the air
(MN to AN) service signalling?

Regards,
Gary Kenward



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

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



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

-- 
Behcet

--------------060308060208010408090808-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Mon Jul 8 14:34:08 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00532 for ; Mon, 8 Jul 2002 14:34:08 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA11412 for seamoby-archive@odin.ietf.org; Mon, 8 Jul 2002 14:35:00 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA10803; Mon, 8 Jul 2002 14:30:25 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA10699 for ; Mon, 8 Jul 2002 14:30:18 -0400 (EDT) Received: from auds952.usa.alcatel.com (auds952.usa.alcatel.com [143.209.238.7]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00167; Mon, 8 Jul 2002 14:29:25 -0400 (EDT) Received: from alcatel.com (localhost [127.0.0.1]) by auds952.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id g68ITjv03128; Mon, 8 Jul 2002 13:29:45 -0500 (CDT) Message-ID: <3D29DA39.1090405@alcatel.com> Date: Mon, 08 Jul 2002 13:30:17 -0500 From: Behcet Sarikaya Organization: Alcatel USA User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4.1) Gecko/20020314 Netscape6/6.2.2 X-Accept-Language: en-us MIME-Version: 1.0 To: Hemant.Chaskar@nokia.com CC: seamoby@ietf.org, nsis@ietf.org Subject: Re: [Seamoby] RE: [NSIS] Re: draft-westphal-nsis-qos-mobileip-00.txt References: Content-Type: multipart/alternative; boundary="------------060308060208010408090808" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org --------------060308060208010408090808 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hello Hemant, The relationship between nsis and CT, as far as I know is that of uncertainty. nsis which started out to develop signaling for QoS now changed to only signaling, CT is going nowhere at Seamoby. The only sure thing is that the links have CT quite well defined, IEEE defined for 802.11 links and 3G links also have well defined context transfer protocols. In order to add to the present confusion, let me note the new BOF called: Topology-Insensitive Service Traversal which is probably going to deal with RSVP based signaling. My 0.03 euros (increased due to recent increase in value of the Euro). Hemant.Chaskar@nokia.com wrote: >Hi James: > >I have the impression that CT is an optimization for NSIS as it can help avoid sending signaling payload bits over MN-new AR link at handoff time. Now, this assumes that there is only one feasible target for handoff. Then, CT is simply transferring QoS description available at old AR to new AR. If the level of service available at new AR is greater or less that what CT has transferred, NSIS can take care of adaptation as the session continues from new AR. > >If there are more than one feasible targets for handoff (this is where CARD may come in play), then the situation is little involved. If we can limit CARD negotiation to new AR resource check alone (as simple as bandwidth available on new AR-MN link or new AR outgoing interfaces), then the NSIS data path QoS signaling payload will be automatically available at new AR as a result of CARD negotiation procedures. On the other hand, if we have to check resource on new AR - CN data path also before concluding anything about handoff target, some NSIS signaling could occur along data path before CARD. > >Hemant > >-----Original Message----- >From: ext James Kempf [mailto:kempf@docomolabs-usa.com] >Sent: 08. July 2002 12:39 >To: Chaskar Hemant (NRC/Boston); gkenward@nortelnetworks.com; >seamoby@ietf.org; nsis@ietf.org >Subject: Re: [Seamoby] RE: [NSIS] Re: >draft-westphal-nsis-qos-mobileip-00.txt > > >Could CT be viewed as an optimization of NSIS signaling? > > jak > >----- Original Message ----- >From: >To: ; ; >Sent: Monday, July 08, 2002 9:20 AM >Subject: [Seamoby] RE: [NSIS] Re: draft-westphal-nsis-qos-mobileip-00.txt > > >>Hi Gary: >> >>Some comments inline: >> >>-----Original Message----- >>From: ext Gary Kenward [mailto:gkenward@nortelnetworks.com] >>Sent: 08. July 2002 12:00 >>To: 'seamoby@ietf.org'; 'NSIS' >>Subject: [NSIS] Re: draft-westphal-nsis-qos-mobileip-00.txt >>Sensitivity: Confidential >> >> >>I finally managed to find time to read through Cedric's and Hemant's draft. >>Overally, I think it is a good description of one possible integrated >>approach. >> >>[Hemant] Please note that the Edge Signaling (MN-AR and AR-AR) and Data Path Signaling (e2e if you will) are not "tightly >> >integrated", i.e., they help each other but do not rely on each other (though I admit that the current writeup makes that >impression). In other words, Data Path Signaling can work (at handoff time) even if Edge Signaling fails. > >>The one general comment I would like to offer up at this time, is that while >> >>the draft does a good job of integrating MIP, CT and NSIS concepts, the >>proposed solutions for QoS negotiation between MN and AN (e.g. the use of >>the >>CIN message) is NSIS not CT. >> >>[Hemant] Point well taken. >> >>CT is concerned with the transfer of forwarding service context between >>ANRs. >>NSIS is concerned with the signalling of service requirements. Thus, the >>issue >>is not how to interwork the "CT" CIN, for example, with NSIS signalling, but >>how >>the CIN, etc., form part of the NSIS solution. >> >>[Hemant] I agree. The basic idea is that if CT can help avoid MN-new AR NSIS signaling at handoff time, it is a good proposition. >> >Note that context can be constructed at old AR using the information supplied to it by NSIS MN-old AR message at session initiation, >which can be transported to new AR in CT. If CT fails, one should use MN-new AR NSIS signaling at handoff time, albeit at certain >loss of seamlessness. > >>[Hemant] Thanks, Hemant >> >>This is not simply an issue of adherence to Seamoby/NSIS models or charters. >>The intention has always been that CT work as a context transfer mechanism >>with a variety of mobility and service signalling solutions. There is a >>significant >>benefit in the real world to be realized in keeping the context transfer >>solution >>(CT) independent from the service signalling solution (NSIS) (and the >>mobility >>solution - MIP or whatever). I would think that there is also a benefit to >>keeping >>the MN to AR service signalling independent of CT. >> >>Stated a different way, do we really need two separate solutions for over >>the air >>(MN to AN) service signalling? >> >>Regards, >>Gary Kenward >> >> >> >>_______________________________________________ >>nsis mailing list >>nsis@ietf.org >>https://www1.ietf.org/mailman/listinfo/nsis >> >>_______________________________________________ >>Seamoby mailing list >>Seamoby@ietf.org >>https://www1.ietf.org/mailman/listinfo/seamoby >> > > >_______________________________________________ >nsis mailing list >nsis@ietf.org >https://www1.ietf.org/mailman/listinfo/nsis > -- Behcet --------------060308060208010408090808 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hello Hemant,
 The relationship between nsis and CT, as far as I know is
that of uncertainty.
nsis which started out to develop signaling for QoS now changed to only signaling,
CT is going nowhere at Seamoby.
  The only sure thing is that the links have CT quite well defined, IEEE defined for 802.11 links and 3G links also have well defined context transfer protocols.
  In order to add to the present confusion, let me note the new BOF called:
Topology-Insensitive Service Traversal
which is probably going to deal with RSVP based signaling.

  My 0.03 euros (increased due to recent increase in value of the Euro).

Hemant.Chaskar@nokia.com wrote:
Hi James: 

I have the impression that CT is an optimization for NSIS as it can help avoid sending signaling payload bits over MN-new AR link at handoff time. Now, this assumes that there is only one feasible target for handoff. Then, CT is simply transferring QoS description available at old AR to new AR. If the level of service available at new AR is greater or less that what CT has transferred, NSIS can take care of adaptation as the session continues from new AR.

If there are more than one feasible targets for handoff (this is where CARD may come in play), then the situation is little involved. If we can limit CARD negotiation to new AR resource check alone (as simple as bandwidth available on new AR-MN link or new AR outgoing interfaces), then the NSIS data path QoS signaling payload will be automatically available at new AR as a result of CARD negotiation procedures. On the other hand, if we have to check resource on new AR - CN data path al
so before concluding anything about handoff target, some NSIS signaling could occur along data path before CARD.

Hemant

-----Original Message-----
From: ext James Kempf [mailto:kempf@docomolabs-usa.com]
Sent: 08. July 2002 12:39
To: Chaskar Hemant (NRC/Boston); gkenward@nortelnetworks.com;
seamoby@ietf.org; nsis@ietf.org
Subject: Re: [Seamoby] RE: [NSIS] Re:
draft-westphal-nsis-qos-mobileip-00.txt


Could CT be viewed as an optimization of NSIS signaling?

            jak

----- Original Message -----
From: <Hemant.Chaskar@nokia.com>
To: <gkenward@nortelnetworks.com>; <seamoby@ietf.org>; <nsis@ietf.org>
Sent: Monday, July 08, 2002 9:20 AM
Subject: [Seamoby] RE: [NSIS] Re: draft-westphal-nsis-qos-mobileip-00.txt


Hi Gary:

Some comments inline:

-----Original Message-----
From: ext Gary Kenward [mailto:gkenward@nortelnetworks.com]
Sent: 08. July 2002 12:00
To: 'seamoby@ietf.org'; 'NSIS'
Subject: [NSIS] Re: draft-westphal-nsis-qos-mobileip-00.txt
Sensitivity: Confidential


I finally managed to find time to read through Cedric's and Hemant's draft.
Overally, I think it is a good description of one possible integrated
approach.

[Hemant] Please note that the Edge Signaling (MN-AR and AR-AR) and Data Path Signaling (e2e if you will) are not "tightly
integrated", i.e., they help each other but do not rely on each other (though I admit that the current writeup makes that
impression). In other words, Data Path Signaling can work (at handoff time) even if Edge Signaling fails.
The one general comment I would like to offer up at this time, is that while

the draft does a good job of integrating MIP, CT and NSIS concepts, the
proposed solutions for QoS negotiation between MN and AN (e.g. the use of
the
CIN message) is NSIS not CT.

[Hemant] Point well taken.

CT is concerned with the transfer of forwarding service context between
ANRs.
NSIS is concerned with the signalling of service requirements. Thus, the
issue
is not how to interwork the "CT" CIN, for example, with NSIS signalling, but
how
the CIN, etc., form part of the NSIS solution.

[Hemant] I agree. The basic idea is that if CT can help avoid MN-new AR NSIS signaling at handoff time, it is a good proposition.
Note that context can be constructed at old AR using the information supplied to it by NSIS MN-old AR message at session initiation,
which can be transported to new AR in CT. If CT fails, one should use MN-new AR NSIS signaling at handoff time, albeit at certain
loss of seamlessness.
[Hemant] Thanks, Hemant

This is not simply an issue of adherence to Seamoby/NSIS models or charters.
The intention has always been that CT work as a context transfer mechanism
with a variety of mobility and service signalling solutions. There is a
significant
benefit in the real world to be realized in keeping the context transfer
solution
(CT) independent from the service signalling solution (NSIS) (and the
mobility
solution - MIP or whatever). I would think that there is also a benefit to
keeping
the MN to AR service signalling independent of CT.

Stated a different way, do we really need two separate solutions for over
the air
(MN to AN) service signalling?

Regards,
Gary Kenward



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

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



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

-- 
Behcet

--------------060308060208010408090808-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Mon Jul 8 15:43:59 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05073 for ; Mon, 8 Jul 2002 15:43:59 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA16811; Mon, 8 Jul 2002 15:32:47 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA16704 for ; Mon, 8 Jul 2002 15:32:41 -0400 (EDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04572; Mon, 8 Jul 2002 15:31:48 -0400 (EDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id MAA02525; Mon, 8 Jul 2002 12:32:08 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g68JW6s31258; Mon, 8 Jul 2002 12:32:06 -0700 X-mProtect: <200207081932> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.90, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd69jaUF; Mon, 08 Jul 2002 12:32:04 PDT Message-ID: <3D29E8B4.71E86F9A@iprg.nokia.com> Date: Mon, 08 Jul 2002 12:32:04 -0700 From: Rajeev Koodli Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Hemant.Chaskar@nokia.com CC: kempf@docomolabs-usa.com, gkenward@nortelnetworks.com, seamoby@ietf.org, nsis@ietf.org Subject: Re: [Seamoby] RE: [NSIS] Re: draft-westphal-nsis-qos-mobileip-00.txt References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit Hemant, Hemant.Chaskar@nokia.com wrote: > Hi James: > > I have the impression that CT is an optimization for NSIS as it can help avoid sending signaling payload bits over MN-new AR link at handoff time. Now, this assumes that there is only one feasible target for handoff. Then, CT is CT is an optimization to avoid signaling and the associated overheads, and maintain desirable transport (RTP/TCP)performance. A historical note: CT was not designed to be an optimization for NSIS. > simply transferring QoS description available at old AR to new AR. If the level of service available at new AR is greater or less that what CT has transferred, NSIS can take care of adaptation as the session continues from new AR. This was discussed earlier. In essence, - with some standard Profile Types, you would expect participating routers to support a majority of the feature contexts. In the absence of additional protocol support (e.g., CARD), transferring what you have is just fine. The receiving router ignores the context(s) it does not understand. London IETF was where we specifically had this discussion in depth. - when a feature context type is not understood, CT should provide a notification. Such a notification is also useful when a feature context is partially understood. This notification could be used as a trigger to engage in NSIS signaling. This was presented at the NSIS interim WG meeting. > > > If there are more than one feasible targets for handoff (this is where CARD may come in play), then the situation is little involved. If we can limit CARD negotiation to new AR resource check alone (as simple as bandwidth available on new AR-MN link or new AR outgoing interfaces), then the NSIS data path QoS signaling payload will be automatically available at new AR as a result of CARD negotiation procedures. On the other hand, if we have to check resource on new AR - CN data path also before concluding anything about handoff target, some NSIS signaling could occur along data path before CARD. > Ok. When CARD is available, it can provide input to CT. -Rajeev > > Hemant > > -----Original Message----- > From: ext James Kempf [mailto:kempf@docomolabs-usa.com] > Sent: 08. July 2002 12:39 > To: Chaskar Hemant (NRC/Boston); gkenward@nortelnetworks.com; > seamoby@ietf.org; nsis@ietf.org > Subject: Re: [Seamoby] RE: [NSIS] Re: > draft-westphal-nsis-qos-mobileip-00.txt > > Could CT be viewed as an optimization of NSIS signaling? > > jak > > ----- Original Message ----- > From: > To: ; ; > Sent: Monday, July 08, 2002 9:20 AM > Subject: [Seamoby] RE: [NSIS] Re: draft-westphal-nsis-qos-mobileip-00.txt > > > Hi Gary: > > > > Some comments inline: > > > > -----Original Message----- > > From: ext Gary Kenward [mailto:gkenward@nortelnetworks.com] > > Sent: 08. July 2002 12:00 > > To: 'seamoby@ietf.org'; 'NSIS' > > Subject: [NSIS] Re: draft-westphal-nsis-qos-mobileip-00.txt > > Sensitivity: Confidential > > > > > > I finally managed to find time to read through Cedric's and Hemant's draft. > > Overally, I think it is a good description of one possible integrated > > approach. > > > > [Hemant] Please note that the Edge Signaling (MN-AR and AR-AR) and Data Path Signaling (e2e if you will) are not "tightly > integrated", i.e., they help each other but do not rely on each other (though I admit that the current writeup makes that > impression). In other words, Data Path Signaling can work (at handoff time) even if Edge Signaling fails. > > > > The one general comment I would like to offer up at this time, is that while > > > > the draft does a good job of integrating MIP, CT and NSIS concepts, the > > proposed solutions for QoS negotiation between MN and AN (e.g. the use of > > the > > CIN message) is NSIS not CT. > > > > [Hemant] Point well taken. > > > > CT is concerned with the transfer of forwarding service context between > > ANRs. > > NSIS is concerned with the signalling of service requirements. Thus, the > > issue > > is not how to interwork the "CT" CIN, for example, with NSIS signalling, but > > how > > the CIN, etc., form part of the NSIS solution. > > > > [Hemant] I agree. The basic idea is that if CT can help avoid MN-new AR NSIS signaling at handoff time, it is a good proposition. > Note that context can be constructed at old AR using the information supplied to it by NSIS MN-old AR message at session initiation, > which can be transported to new AR in CT. If CT fails, one should use MN-new AR NSIS signaling at handoff time, albeit at certain > loss of seamlessness. > > > > [Hemant] Thanks, Hemant > > > > This is not simply an issue of adherence to Seamoby/NSIS models or charters. > > The intention has always been that CT work as a context transfer mechanism > > with a variety of mobility and service signalling solutions. There is a > > significant > > benefit in the real world to be realized in keeping the context transfer > > solution > > (CT) independent from the service signalling solution (NSIS) (and the > > mobility > > solution - MIP or whatever). I would think that there is also a benefit to > > keeping > > the MN to AR service signalling independent of CT. > > > > Stated a different way, do we really need two separate solutions for over > > the air > > (MN to AN) service signalling? > > > > Regards, > > Gary Kenward > > > > > > > > _______________________________________________ > > nsis mailing list > > nsis@ietf.org > > https://www1.ietf.org/mailman/listinfo/nsis > > > > _______________________________________________ > > 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 From daemon@optimus.ietf.org Mon Jul 8 15:43:59 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05078 for ; Mon, 8 Jul 2002 15:43:59 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA17962 for seamoby-archive@odin.ietf.org; Mon, 8 Jul 2002 15:44:52 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA16811; Mon, 8 Jul 2002 15:32:47 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA16704 for ; Mon, 8 Jul 2002 15:32:41 -0400 (EDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04572; Mon, 8 Jul 2002 15:31:48 -0400 (EDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id MAA02525; Mon, 8 Jul 2002 12:32:08 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g68JW6s31258; Mon, 8 Jul 2002 12:32:06 -0700 X-mProtect: <200207081932> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.90, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd69jaUF; Mon, 08 Jul 2002 12:32:04 PDT Message-ID: <3D29E8B4.71E86F9A@iprg.nokia.com> Date: Mon, 08 Jul 2002 12:32:04 -0700 From: Rajeev Koodli Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Hemant.Chaskar@nokia.com CC: kempf@docomolabs-usa.com, gkenward@nortelnetworks.com, seamoby@ietf.org, nsis@ietf.org Subject: Re: [Seamoby] RE: [NSIS] Re: draft-westphal-nsis-qos-mobileip-00.txt References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit Hemant, Hemant.Chaskar@nokia.com wrote: > Hi James: > > I have the impression that CT is an optimization for NSIS as it can help avoid sending signaling payload bits over MN-new AR link at handoff time. Now, this assumes that there is only one feasible target for handoff. Then, CT is CT is an optimization to avoid signaling and the associated overheads, and maintain desirable transport (RTP/TCP)performance. A historical note: CT was not designed to be an optimization for NSIS. > simply transferring QoS description available at old AR to new AR. If the level of service available at new AR is greater or less that what CT has transferred, NSIS can take care of adaptation as the session continues from new AR. This was discussed earlier. In essence, - with some standard Profile Types, you would expect participating routers to support a majority of the feature contexts. In the absence of additional protocol support (e.g., CARD), transferring what you have is just fine. The receiving router ignores the context(s) it does not understand. London IETF was where we specifically had this discussion in depth. - when a feature context type is not understood, CT should provide a notification. Such a notification is also useful when a feature context is partially understood. This notification could be used as a trigger to engage in NSIS signaling. This was presented at the NSIS interim WG meeting. > > > If there are more than one feasible targets for handoff (this is where CARD may come in play), then the situation is little involved. If we can limit CARD negotiation to new AR resource check alone (as simple as bandwidth available on new AR-MN link or new AR outgoing interfaces), then the NSIS data path QoS signaling payload will be automatically available at new AR as a result of CARD negotiation procedures. On the other hand, if we have to check resource on new AR - CN data path also before concluding anything about handoff target, some NSIS signaling could occur along data path before CARD. > Ok. When CARD is available, it can provide input to CT. -Rajeev > > Hemant > > -----Original Message----- > From: ext James Kempf [mailto:kempf@docomolabs-usa.com] > Sent: 08. July 2002 12:39 > To: Chaskar Hemant (NRC/Boston); gkenward@nortelnetworks.com; > seamoby@ietf.org; nsis@ietf.org > Subject: Re: [Seamoby] RE: [NSIS] Re: > draft-westphal-nsis-qos-mobileip-00.txt > > Could CT be viewed as an optimization of NSIS signaling? > > jak > > ----- Original Message ----- > From: > To: ; ; > Sent: Monday, July 08, 2002 9:20 AM > Subject: [Seamoby] RE: [NSIS] Re: draft-westphal-nsis-qos-mobileip-00.txt > > > Hi Gary: > > > > Some comments inline: > > > > -----Original Message----- > > From: ext Gary Kenward [mailto:gkenward@nortelnetworks.com] > > Sent: 08. July 2002 12:00 > > To: 'seamoby@ietf.org'; 'NSIS' > > Subject: [NSIS] Re: draft-westphal-nsis-qos-mobileip-00.txt > > Sensitivity: Confidential > > > > > > I finally managed to find time to read through Cedric's and Hemant's draft. > > Overally, I think it is a good description of one possible integrated > > approach. > > > > [Hemant] Please note that the Edge Signaling (MN-AR and AR-AR) and Data Path Signaling (e2e if you will) are not "tightly > integrated", i.e., they help each other but do not rely on each other (though I admit that the current writeup makes that > impression). In other words, Data Path Signaling can work (at handoff time) even if Edge Signaling fails. > > > > The one general comment I would like to offer up at this time, is that while > > > > the draft does a good job of integrating MIP, CT and NSIS concepts, the > > proposed solutions for QoS negotiation between MN and AN (e.g. the use of > > the > > CIN message) is NSIS not CT. > > > > [Hemant] Point well taken. > > > > CT is concerned with the transfer of forwarding service context between > > ANRs. > > NSIS is concerned with the signalling of service requirements. Thus, the > > issue > > is not how to interwork the "CT" CIN, for example, with NSIS signalling, but > > how > > the CIN, etc., form part of the NSIS solution. > > > > [Hemant] I agree. The basic idea is that if CT can help avoid MN-new AR NSIS signaling at handoff time, it is a good proposition. > Note that context can be constructed at old AR using the information supplied to it by NSIS MN-old AR message at session initiation, > which can be transported to new AR in CT. If CT fails, one should use MN-new AR NSIS signaling at handoff time, albeit at certain > loss of seamlessness. > > > > [Hemant] Thanks, Hemant > > > > This is not simply an issue of adherence to Seamoby/NSIS models or charters. > > The intention has always been that CT work as a context transfer mechanism > > with a variety of mobility and service signalling solutions. There is a > > significant > > benefit in the real world to be realized in keeping the context transfer > > solution > > (CT) independent from the service signalling solution (NSIS) (and the > > mobility > > solution - MIP or whatever). I would think that there is also a benefit to > > keeping > > the MN to AR service signalling independent of CT. > > > > Stated a different way, do we really need two separate solutions for over > > the air > > (MN to AN) service signalling? > > > > Regards, > > Gary Kenward > > > > > > > > _______________________________________________ > > nsis mailing list > > nsis@ietf.org > > https://www1.ietf.org/mailman/listinfo/nsis > > > > _______________________________________________ > > 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 From seamoby-admin@ietf.org Mon Jul 8 17:41:56 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12402 for ; Mon, 8 Jul 2002 17:41:56 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA28769; Mon, 8 Jul 2002 17:38:47 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA28706 for ; Mon, 8 Jul 2002 17:38:43 -0400 (EDT) Received: from fridge.docomolabs-usa.com (fwuser@key1.docomolabs-usa.com [216.98.102.225]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12229; Mon, 8 Jul 2002 17:37:47 -0400 (EDT) Message-ID: <021401c226c7$91cc54f0$4f6015ac@T23KEMPF> From: "James Kempf" To: "Rajeev Koodli" , Cc: , , References: <3D29E8B4.71E86F9A@iprg.nokia.com> Subject: Re: [Seamoby] RE: [NSIS] Re: draft-westphal-nsis-qos-mobileip-00.txt Date: Mon, 8 Jul 2002 14:36:50 -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-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit > CT is an optimization to avoid signaling and the associated overheads, and maintain > desirable transport (RTP/TCP)performance. A historical note: CT was not designed > to be an optimization for NSIS. > Do you mean that the requirements weren't so designed? Because, to my knowledge, the WG has not yet settled on a design. We are currently awaiting IESG feedback on our requirements. The problem statement was just approved by the IESG. jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Mon Jul 8 17:41:56 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12410 for ; Mon, 8 Jul 2002 17:41:56 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA29073 for seamoby-archive@odin.ietf.org; Mon, 8 Jul 2002 17:42:50 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA28769; Mon, 8 Jul 2002 17:38:47 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA28706 for ; Mon, 8 Jul 2002 17:38:43 -0400 (EDT) Received: from fridge.docomolabs-usa.com (fwuser@key1.docomolabs-usa.com [216.98.102.225]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12229; Mon, 8 Jul 2002 17:37:47 -0400 (EDT) Message-ID: <021401c226c7$91cc54f0$4f6015ac@T23KEMPF> From: "James Kempf" To: "Rajeev Koodli" , Cc: , , References: <3D29E8B4.71E86F9A@iprg.nokia.com> Subject: Re: [Seamoby] RE: [NSIS] Re: draft-westphal-nsis-qos-mobileip-00.txt Date: Mon, 8 Jul 2002 14:36:50 -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-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit > CT is an optimization to avoid signaling and the associated overheads, and maintain > desirable transport (RTP/TCP)performance. A historical note: CT was not designed > to be an optimization for NSIS. > Do you mean that the requirements weren't so designed? Because, to my knowledge, the WG has not yet settled on a design. We are currently awaiting IESG feedback on our requirements. The problem statement was just approved by the IESG. jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Mon Jul 8 17:43:14 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12523 for ; Mon, 8 Jul 2002 17:43:13 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA28922; Mon, 8 Jul 2002 17:40:15 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA28891 for ; Mon, 8 Jul 2002 17:40:13 -0400 (EDT) Received: from fridge.docomolabs-usa.com (fwuser@key1.docomolabs-usa.com [216.98.102.225]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12309; Mon, 8 Jul 2002 17:39:13 -0400 (EDT) Message-ID: <022501c226c7$c8f3bf40$4f6015ac@T23KEMPF> From: "James Kempf" To: "Behcet Sarikaya" , Cc: , References: <3D29DA39.1090405@alcatel.com> Subject: Re: [Seamoby] RE: [NSIS] Re: draft-westphal-nsis-qos-mobileip-00.txt Date: Mon, 8 Jul 2002 14:38:23 -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-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit > CT is going nowhere at Seamoby. Depends on your definition of "going nowhere." The problem statement was just approved by the IESG and we are awaiting IESG feedback on the requirements. We can't progress on the protocol design until we have IESG approval of the requirements. jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Mon Jul 8 17:43:14 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12531 for ; Mon, 8 Jul 2002 17:43:14 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA29285 for seamoby-archive@odin.ietf.org; Mon, 8 Jul 2002 17:44:07 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA28922; Mon, 8 Jul 2002 17:40:15 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA28891 for ; Mon, 8 Jul 2002 17:40:13 -0400 (EDT) Received: from fridge.docomolabs-usa.com (fwuser@key1.docomolabs-usa.com [216.98.102.225]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12309; Mon, 8 Jul 2002 17:39:13 -0400 (EDT) Message-ID: <022501c226c7$c8f3bf40$4f6015ac@T23KEMPF> From: "James Kempf" To: "Behcet Sarikaya" , Cc: , References: <3D29DA39.1090405@alcatel.com> Subject: Re: [Seamoby] RE: [NSIS] Re: draft-westphal-nsis-qos-mobileip-00.txt Date: Mon, 8 Jul 2002 14:38:23 -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-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit > CT is going nowhere at Seamoby. Depends on your definition of "going nowhere." The problem statement was just approved by the IESG and we are awaiting IESG feedback on the requirements. We can't progress on the protocol design until we have IESG approval of the requirements. jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Mon Jul 8 17:47:05 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12770 for ; Mon, 8 Jul 2002 17:47:05 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA29271; Mon, 8 Jul 2002 17:44:06 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA29201 for ; Mon, 8 Jul 2002 17:44:02 -0400 (EDT) Received: from mgw-dax2.ext.nokia.com (mgw-dax2.ext.nokia.com [63.78.179.217]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12492; Mon, 8 Jul 2002 17:43:07 -0400 (EDT) From: Hemant.Chaskar@nokia.com Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax2.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g68Llej03128; Mon, 8 Jul 2002 16:47:40 -0500 (CDT) Received: from daebh002.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 8 Jul 2002 16:43:58 -0500 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Mon, 8 Jul 2002 16:43:58 -0500 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Subject: RE: [Seamoby] RE: [NSIS] Re: draft-westphal-nsis-qos-mobileip-00.txt Date: Mon, 8 Jul 2002 17:43:57 -0400 Message-ID: Thread-Topic: [Seamoby] RE: [NSIS] Re: draft-westphal-nsis-qos-mobileip-00.txt Thread-Index: AcImtifUuI8DrDTlR82P34Xy7o1IaAAAQf9QAARgF6A= To: , X-OriginalArrivalTime: 08 Jul 2002 21:43:58.0303 (UTC) FILETIME=[90B71EF0:01C226C8] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id RAA29202 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 8bit Hi Rajeev: Some questions inline: -----Original Message----- From: Rajeev Koodli [mailto:rajeev@iprg.nokia.com] Sent: 08. July 2002 15:32 To: Chaskar Hemant (NRC/Boston) Cc: kempf@docomolabs-usa.com; gkenward@nortelnetworks.com; seamoby@ietf.org; nsis@ietf.org Subject: Re: [Seamoby] RE: [NSIS] Re: draft-westphal-nsis-qos-mobileip-00.txt Hemant, Hemant.Chaskar@nokia.com wrote: > Hi James: > > I have the impression that CT is an optimization for NSIS as it can help avoid sending signaling payload bits over MN-new AR link at handoff time. Now, this assumes that there is only one feasible target for handoff. Then, CT is CT is an optimization to avoid signaling and the associated overheads, and maintain desirable transport (RTP/TCP)performance. A historical note: CT was not designed to be an optimization for NSIS. [Hemant] Does reduction of latency in establishing QoS along the new packet path count as transport performance enhancement? Also, is it not (at all) a goal of CT to save wireless bandwidth for redundant signaling on a new AR - MN link? In other words, is it appropriate to view CT as a tool to enhance seamlessness of handoff, or should be limited to the role of RTP/TCP performance booster (did you mean header compression there?). Also, are you suggesting that NSIS should design its independent AR-AR protocol.? > simply transferring QoS description available at old AR to new AR. If the level of service available at new AR is greater or less that what CT has transferred, NSIS can take care of adaptation as the session continues from new AR. This was discussed earlier. In essence, - with some standard Profile Types, you would expect participating routers to support a majority of the feature contexts. In the absence of additional protocol support (e.g., CARD), transferring what you have is just fine. The receiving router ignores the context(s) it does not understand. London IETF was where we specifically had this discussion in depth. [Hemant] I did not mean readability or otherwise of CT bit layout at new AR when I said this. Level of service can imply for example increased/descreased available throughput. So, even if everybody understands profile types, values of service parameters could change (e.g. when you move from 2.5G to Operator WLAN and vice versa). - when a feature context type is not understood, CT should provide a notification. Such a notification is also useful when a feature context is partially understood. This notification could be used as a trigger to engage in NSIS signaling. This was presented at the NSIS interim WG meeting. > > > If there are more than one feasible targets for handoff (this is where CARD may come in play), then the situation is little involved. If we can limit CARD negotiation to new AR resource check alone (as simple as bandwidth available on new AR-MN link or new AR outgoing interfaces), then the NSIS data path QoS signaling payload will be automatically available at new AR as a result of CARD negotiation procedures. On the other hand, if we have to check resource on new AR - CN data path also before concluding anything about handoff target, some NSIS signaling could occur along data path before CARD. > Ok. When CARD is available, it can provide input to CT. [Hemant] But then new AR would know during CARD negotiation itself what the new context is? Do we need another CT (at least for QoS) after CARD has executed? [Hemant] Hemant -Rajeev > > Hemant > > -----Original Message----- > From: ext James Kempf [mailto:kempf@docomolabs-usa.com] > Sent: 08. July 2002 12:39 > To: Chaskar Hemant (NRC/Boston); gkenward@nortelnetworks.com; > seamoby@ietf.org; nsis@ietf.org > Subject: Re: [Seamoby] RE: [NSIS] Re: > draft-westphal-nsis-qos-mobileip-00.txt > > Could CT be viewed as an optimization of NSIS signaling? > > jak > > ----- Original Message ----- > From: > To: ; ; > Sent: Monday, July 08, 2002 9:20 AM > Subject: [Seamoby] RE: [NSIS] Re: draft-westphal-nsis-qos-mobileip-00.txt > > > Hi Gary: > > > > Some comments inline: > > > > -----Original Message----- > > From: ext Gary Kenward [mailto:gkenward@nortelnetworks.com] > > Sent: 08. July 2002 12:00 > > To: 'seamoby@ietf.org'; 'NSIS' > > Subject: [NSIS] Re: draft-westphal-nsis-qos-mobileip-00.txt > > Sensitivity: Confidential > > > > > > I finally managed to find time to read through Cedric's and Hemant's draft. > > Overally, I think it is a good description of one possible integrated > > approach. > > > > [Hemant] Please note that the Edge Signaling (MN-AR and AR-AR) and Data Path Signaling (e2e if you will) are not "tightly > integrated", i.e., they help each other but do not rely on each other (though I admit that the current writeup makes that > impression). In other words, Data Path Signaling can work (at handoff time) even if Edge Signaling fails. > > > > The one general comment I would like to offer up at this time, is that while > > > > the draft does a good job of integrating MIP, CT and NSIS concepts, the > > proposed solutions for QoS negotiation between MN and AN (e.g. the use of > > the > > CIN message) is NSIS not CT. > > > > [Hemant] Point well taken. > > > > CT is concerned with the transfer of forwarding service context between > > ANRs. > > NSIS is concerned with the signalling of service requirements. Thus, the > > issue > > is not how to interwork the "CT" CIN, for example, with NSIS signalling, but > > how > > the CIN, etc., form part of the NSIS solution. > > > > [Hemant] I agree. The basic idea is that if CT can help avoid MN-new AR NSIS signaling at handoff time, it is a good proposition. > Note that context can be constructed at old AR using the information supplied to it by NSIS MN-old AR message at session initiation, > which can be transported to new AR in CT. If CT fails, one should use MN-new AR NSIS signaling at handoff time, albeit at certain > loss of seamlessness. > > > > [Hemant] Thanks, Hemant > > > > This is not simply an issue of adherence to Seamoby/NSIS models or charters. > > The intention has always been that CT work as a context transfer mechanism > > with a variety of mobility and service signalling solutions. There is a > > significant > > benefit in the real world to be realized in keeping the context transfer > > solution > > (CT) independent from the service signalling solution (NSIS) (and the > > mobility > > solution - MIP or whatever). I would think that there is also a benefit to > > keeping > > the MN to AR service signalling independent of CT. > > > > Stated a different way, do we really need two separate solutions for over > > the air > > (MN to AN) service signalling? > > > > Regards, > > Gary Kenward > > > > > > > > _______________________________________________ > > nsis mailing list > > nsis@ietf.org > > https://www1.ietf.org/mailman/listinfo/nsis > > > > _______________________________________________ > > 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 From daemon@optimus.ietf.org Mon Jul 8 17:47:05 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12778 for ; Mon, 8 Jul 2002 17:47:05 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA29595 for seamoby-archive@odin.ietf.org; Mon, 8 Jul 2002 17:47:59 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA29271; Mon, 8 Jul 2002 17:44:06 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA29201 for ; Mon, 8 Jul 2002 17:44:02 -0400 (EDT) Received: from mgw-dax2.ext.nokia.com (mgw-dax2.ext.nokia.com [63.78.179.217]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12492; Mon, 8 Jul 2002 17:43:07 -0400 (EDT) From: Hemant.Chaskar@nokia.com Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax2.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g68Llej03128; Mon, 8 Jul 2002 16:47:40 -0500 (CDT) Received: from daebh002.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 8 Jul 2002 16:43:58 -0500 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Mon, 8 Jul 2002 16:43:58 -0500 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Subject: RE: [Seamoby] RE: [NSIS] Re: draft-westphal-nsis-qos-mobileip-00.txt Date: Mon, 8 Jul 2002 17:43:57 -0400 Message-ID: Thread-Topic: [Seamoby] RE: [NSIS] Re: draft-westphal-nsis-qos-mobileip-00.txt Thread-Index: AcImtifUuI8DrDTlR82P34Xy7o1IaAAAQf9QAARgF6A= To: , X-OriginalArrivalTime: 08 Jul 2002 21:43:58.0303 (UTC) FILETIME=[90B71EF0:01C226C8] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id RAA29202 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 8bit Hi Rajeev: Some questions inline: -----Original Message----- From: Rajeev Koodli [mailto:rajeev@iprg.nokia.com] Sent: 08. July 2002 15:32 To: Chaskar Hemant (NRC/Boston) Cc: kempf@docomolabs-usa.com; gkenward@nortelnetworks.com; seamoby@ietf.org; nsis@ietf.org Subject: Re: [Seamoby] RE: [NSIS] Re: draft-westphal-nsis-qos-mobileip-00.txt Hemant, Hemant.Chaskar@nokia.com wrote: > Hi James: > > I have the impression that CT is an optimization for NSIS as it can help avoid sending signaling payload bits over MN-new AR link at handoff time. Now, this assumes that there is only one feasible target for handoff. Then, CT is CT is an optimization to avoid signaling and the associated overheads, and maintain desirable transport (RTP/TCP)performance. A historical note: CT was not designed to be an optimization for NSIS. [Hemant] Does reduction of latency in establishing QoS along the new packet path count as transport performance enhancement? Also, is it not (at all) a goal of CT to save wireless bandwidth for redundant signaling on a new AR - MN link? In other words, is it appropriate to view CT as a tool to enhance seamlessness of handoff, or should be limited to the role of RTP/TCP performance booster (did you mean header compression there?). Also, are you suggesting that NSIS should design its independent AR-AR protocol.? > simply transferring QoS description available at old AR to new AR. If the level of service available at new AR is greater or less that what CT has transferred, NSIS can take care of adaptation as the session continues from new AR. This was discussed earlier. In essence, - with some standard Profile Types, you would expect participating routers to support a majority of the feature contexts. In the absence of additional protocol support (e.g., CARD), transferring what you have is just fine. The receiving router ignores the context(s) it does not understand. London IETF was where we specifically had this discussion in depth. [Hemant] I did not mean readability or otherwise of CT bit layout at new AR when I said this. Level of service can imply for example increased/descreased available throughput. So, even if everybody understands profile types, values of service parameters could change (e.g. when you move from 2.5G to Operator WLAN and vice versa). - when a feature context type is not understood, CT should provide a notification. Such a notification is also useful when a feature context is partially understood. This notification could be used as a trigger to engage in NSIS signaling. This was presented at the NSIS interim WG meeting. > > > If there are more than one feasible targets for handoff (this is where CARD may come in play), then the situation is little involved. If we can limit CARD negotiation to new AR resource check alone (as simple as bandwidth available on new AR-MN link or new AR outgoing interfaces), then the NSIS data path QoS signaling payload will be automatically available at new AR as a result of CARD negotiation procedures. On the other hand, if we have to check resource on new AR - CN data path also before concluding anything about handoff target, some NSIS signaling could occur along data path before CARD. > Ok. When CARD is available, it can provide input to CT. [Hemant] But then new AR would know during CARD negotiation itself what the new context is? Do we need another CT (at least for QoS) after CARD has executed? [Hemant] Hemant -Rajeev > > Hemant > > -----Original Message----- > From: ext James Kempf [mailto:kempf@docomolabs-usa.com] > Sent: 08. July 2002 12:39 > To: Chaskar Hemant (NRC/Boston); gkenward@nortelnetworks.com; > seamoby@ietf.org; nsis@ietf.org > Subject: Re: [Seamoby] RE: [NSIS] Re: > draft-westphal-nsis-qos-mobileip-00.txt > > Could CT be viewed as an optimization of NSIS signaling? > > jak > > ----- Original Message ----- > From: > To: ; ; > Sent: Monday, July 08, 2002 9:20 AM > Subject: [Seamoby] RE: [NSIS] Re: draft-westphal-nsis-qos-mobileip-00.txt > > > Hi Gary: > > > > Some comments inline: > > > > -----Original Message----- > > From: ext Gary Kenward [mailto:gkenward@nortelnetworks.com] > > Sent: 08. July 2002 12:00 > > To: 'seamoby@ietf.org'; 'NSIS' > > Subject: [NSIS] Re: draft-westphal-nsis-qos-mobileip-00.txt > > Sensitivity: Confidential > > > > > > I finally managed to find time to read through Cedric's and Hemant's draft. > > Overally, I think it is a good description of one possible integrated > > approach. > > > > [Hemant] Please note that the Edge Signaling (MN-AR and AR-AR) and Data Path Signaling (e2e if you will) are not "tightly > integrated", i.e., they help each other but do not rely on each other (though I admit that the current writeup makes that > impression). In other words, Data Path Signaling can work (at handoff time) even if Edge Signaling fails. > > > > The one general comment I would like to offer up at this time, is that while > > > > the draft does a good job of integrating MIP, CT and NSIS concepts, the > > proposed solutions for QoS negotiation between MN and AN (e.g. the use of > > the > > CIN message) is NSIS not CT. > > > > [Hemant] Point well taken. > > > > CT is concerned with the transfer of forwarding service context between > > ANRs. > > NSIS is concerned with the signalling of service requirements. Thus, the > > issue > > is not how to interwork the "CT" CIN, for example, with NSIS signalling, but > > how > > the CIN, etc., form part of the NSIS solution. > > > > [Hemant] I agree. The basic idea is that if CT can help avoid MN-new AR NSIS signaling at handoff time, it is a good proposition. > Note that context can be constructed at old AR using the information supplied to it by NSIS MN-old AR message at session initiation, > which can be transported to new AR in CT. If CT fails, one should use MN-new AR NSIS signaling at handoff time, albeit at certain > loss of seamlessness. > > > > [Hemant] Thanks, Hemant > > > > This is not simply an issue of adherence to Seamoby/NSIS models or charters. > > The intention has always been that CT work as a context transfer mechanism > > with a variety of mobility and service signalling solutions. There is a > > significant > > benefit in the real world to be realized in keeping the context transfer > > solution > > (CT) independent from the service signalling solution (NSIS) (and the > > mobility > > solution - MIP or whatever). I would think that there is also a benefit to > > keeping > > the MN to AR service signalling independent of CT. > > > > Stated a different way, do we really need two separate solutions for over > > the air > > (MN to AN) service signalling? > > > > Regards, > > Gary Kenward > > > > > > > > _______________________________________________ > > nsis mailing list > > nsis@ietf.org > > https://www1.ietf.org/mailman/listinfo/nsis > > > > _______________________________________________ > > 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 From seamoby-admin@ietf.org Mon Jul 8 18:50:22 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15477 for ; Mon, 8 Jul 2002 18:50:22 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA04160; Mon, 8 Jul 2002 18:46:46 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA04123 for ; Mon, 8 Jul 2002 18:46:44 -0400 (EDT) Received: from auds951.usa.alcatel.com (auds951.usa.alcatel.com [143.209.238.80]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15247 for ; Mon, 8 Jul 2002 18:45:52 -0400 (EDT) Received: from alcatel.com (localhost [127.0.0.1]) by auds951.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id g68MkCr20957; Mon, 8 Jul 2002 17:46:12 -0500 (CDT) Message-ID: <3D2A1653.60505@alcatel.com> Date: Mon, 08 Jul 2002 17:46:43 -0500 From: Behcet Sarikaya Organization: Alcatel USA User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4.1) Gecko/20020314 Netscape6/6.2.2 X-Accept-Language: en-us MIME-Version: 1.0 To: James Kempf CC: seamoby@ietf.org Subject: Re: [Seamoby] RE: [NSIS] Re: draft-westphal-nsis-qos-mobileip-00.txt References: <3D29DA39.1090405@alcatel.com> <022501c226c7$c8f3bf40$4f6015ac@T23KEMPF> Content-Type: multipart/alternative; boundary="------------050906070906090500060600" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org --------------050906070906090500060600 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Thanks for the update. James Kempf wrote: >>CT is going nowhere at Seamoby. >> > >Depends on your definition of "going nowhere." The problem statement was just approved by the IESG and we are awaiting IESG feedback >on the requirements. We can't progress on the protocol design until we have IESG approval of the requirements. > > jak > > >_______________________________________________ >Seamoby mailing list >Seamoby@ietf.org >https://www1.ietf.org/mailman/listinfo/seamoby > -- Behcet --------------050906070906090500060600 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Thanks for the update.

James Kempf wrote:
CT is going nowhere at Seamoby.

Depends on your definition of "going nowhere." The problem statement was just approved by the IESG and we are awaiting IESG feedback
on the requirements. We can't progress on the protocol design until we have IESG approval of the requirements.

            jak


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

-- 
Behcet

--------------050906070906090500060600-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Mon Jul 8 18:50:23 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15484 for ; Mon, 8 Jul 2002 18:50:23 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA04622 for seamoby-archive@odin.ietf.org; Mon, 8 Jul 2002 18:51:13 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA04160; Mon, 8 Jul 2002 18:46:46 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA04123 for ; Mon, 8 Jul 2002 18:46:44 -0400 (EDT) Received: from auds951.usa.alcatel.com (auds951.usa.alcatel.com [143.209.238.80]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15247 for ; Mon, 8 Jul 2002 18:45:52 -0400 (EDT) Received: from alcatel.com (localhost [127.0.0.1]) by auds951.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id g68MkCr20957; Mon, 8 Jul 2002 17:46:12 -0500 (CDT) Message-ID: <3D2A1653.60505@alcatel.com> Date: Mon, 08 Jul 2002 17:46:43 -0500 From: Behcet Sarikaya Organization: Alcatel USA User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4.1) Gecko/20020314 Netscape6/6.2.2 X-Accept-Language: en-us MIME-Version: 1.0 To: James Kempf CC: seamoby@ietf.org Subject: Re: [Seamoby] RE: [NSIS] Re: draft-westphal-nsis-qos-mobileip-00.txt References: <3D29DA39.1090405@alcatel.com> <022501c226c7$c8f3bf40$4f6015ac@T23KEMPF> Content-Type: multipart/alternative; boundary="------------050906070906090500060600" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org --------------050906070906090500060600 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Thanks for the update. James Kempf wrote: >>CT is going nowhere at Seamoby. >> > >Depends on your definition of "going nowhere." The problem statement was just approved by the IESG and we are awaiting IESG feedback >on the requirements. We can't progress on the protocol design until we have IESG approval of the requirements. > > jak > > >_______________________________________________ >Seamoby mailing list >Seamoby@ietf.org >https://www1.ietf.org/mailman/listinfo/seamoby > -- Behcet --------------050906070906090500060600 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Thanks for the update.

James Kempf wrote:
CT is going nowhere at Seamoby.

Depends on your definition of "going nowhere." The problem statement was just approved by the IESG and we are awaiting IESG feedback
on the requirements. We can't progress on the protocol design until we have IESG approval of the requirements.

            jak


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

-- 
Behcet

--------------050906070906090500060600-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Mon Jul 8 19:04:33 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16046 for ; Mon, 8 Jul 2002 19:04:33 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA05697; Mon, 8 Jul 2002 19:02:00 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA05641 for ; Mon, 8 Jul 2002 19:01:55 -0400 (EDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15912; Mon, 8 Jul 2002 19:01:04 -0400 (EDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id QAA14127; Mon, 8 Jul 2002 16:01:24 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g68N1Nk25328; Mon, 8 Jul 2002 16:01:23 -0700 X-mProtect: <200207082301> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.90, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdNMXJ4N; Mon, 08 Jul 2002 16:01:21 PDT Message-ID: <3D2A19C2.CB8889D9@iprg.nokia.com> Date: Mon, 08 Jul 2002 16:01:22 -0700 From: Rajeev Koodli Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: James Kempf CC: Hemant.Chaskar@nokia.com, gkenward@nortelnetworks.com, seamoby@ietf.org, nsis@ietf.org Subject: Re: [Seamoby] RE: [NSIS] Re: draft-westphal-nsis-qos-mobileip-00.txt References: <3D29E8B4.71E86F9A@iprg.nokia.com> <021401c226c7$91cc54f0$4f6015ac@T23KEMPF> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit James Kempf wrote: > > CT is an optimization to avoid signaling and the associated overheads, and maintain > > desirable transport (RTP/TCP)performance. A historical note: CT was not designed > > to be an optimization for NSIS. > > > > Do you mean that the requirements weren't so designed? Because, to my knowledge, the WG has not yet settled on a design. We are > currently awaiting IESG feedback on our requirements. The problem statement was just approved by the IESG. > I meant when CT got started, there was no NSIS. However, our objective has been to avoid signaling overheads (bandwidth, delay, unreliable link effects,..) and (hence) maintain desirable transport performance. -Rajeev > > jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Mon Jul 8 19:04:34 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16054 for ; Mon, 8 Jul 2002 19:04:33 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id TAA06056 for seamoby-archive@odin.ietf.org; Mon, 8 Jul 2002 19:05:24 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA05697; Mon, 8 Jul 2002 19:02:00 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA05641 for ; Mon, 8 Jul 2002 19:01:55 -0400 (EDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15912; Mon, 8 Jul 2002 19:01:04 -0400 (EDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id QAA14127; Mon, 8 Jul 2002 16:01:24 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g68N1Nk25328; Mon, 8 Jul 2002 16:01:23 -0700 X-mProtect: <200207082301> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.90, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdNMXJ4N; Mon, 08 Jul 2002 16:01:21 PDT Message-ID: <3D2A19C2.CB8889D9@iprg.nokia.com> Date: Mon, 08 Jul 2002 16:01:22 -0700 From: Rajeev Koodli Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: James Kempf CC: Hemant.Chaskar@nokia.com, gkenward@nortelnetworks.com, seamoby@ietf.org, nsis@ietf.org Subject: Re: [Seamoby] RE: [NSIS] Re: draft-westphal-nsis-qos-mobileip-00.txt References: <3D29E8B4.71E86F9A@iprg.nokia.com> <021401c226c7$91cc54f0$4f6015ac@T23KEMPF> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit James Kempf wrote: > > CT is an optimization to avoid signaling and the associated overheads, and maintain > > desirable transport (RTP/TCP)performance. A historical note: CT was not designed > > to be an optimization for NSIS. > > > > Do you mean that the requirements weren't so designed? Because, to my knowledge, the WG has not yet settled on a design. We are > currently awaiting IESG feedback on our requirements. The problem statement was just approved by the IESG. > I meant when CT got started, there was no NSIS. However, our objective has been to avoid signaling overheads (bandwidth, delay, unreliable link effects,..) and (hence) maintain desirable transport performance. -Rajeev > > jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Mon Jul 8 19:48:22 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17766 for ; Mon, 8 Jul 2002 19:48:22 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA08810; Mon, 8 Jul 2002 19:45:50 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA08707 for ; Mon, 8 Jul 2002 19:45:45 -0400 (EDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17658; Mon, 8 Jul 2002 19:44:53 -0400 (EDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id QAA16466; Mon, 8 Jul 2002 16:45:13 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g68NjBN08913; Mon, 8 Jul 2002 16:45:11 -0700 X-mProtect: <200207082345> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.90, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdEsWp86; Mon, 08 Jul 2002 16:45:08 PDT Message-ID: <3D2A2405.9E4B33B9@iprg.nokia.com> Date: Mon, 08 Jul 2002 16:45:09 -0700 From: Rajeev Koodli Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Hemant.Chaskar@nokia.com CC: kempf@docomolabs-usa.com, gkenward@nortelnetworks.com, seamoby@ietf.org, nsis@ietf.org Subject: Re: [Seamoby] RE: [NSIS] Re: draft-westphal-nsis-qos-mobileip-00.txt References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit Hemant.Chaskar@nokia.com wrote: > > > Hi James: > > > > I have the impression that CT is an optimization for NSIS as it can help avoid sending signaling payload bits over MN-new AR link at handoff time. Now, this assumes that there is only one feasible target for handoff. Then, CT is > > CT is an optimization to avoid signaling and the associated overheads, and maintain > desirable transport (RTP/TCP)performance. A historical note: CT was not designed > to be an optimization for NSIS. > > [Hemant] Does reduction of latency in establishing QoS along the new packet path count as transport performance enhancement? Also, is it not (at all) a goal of CT to save wireless bandwidth for redundant signaling on a new AR - If there is a need for re-establishing QoS along the new path, then yes. And, CT can trigger such a signaling when needed, and NSIS is probably the right place for this signaling. In the NSIS interim meeting, there seemed to be favorable response to this thinking when I made this point. > MN link? In other words, is it appropriate to view CT as a tool to enhance seamlessness of handoff, or should be limited to the role of RTP/TCP performance booster (did you mean header compression there?). Also, are you Ofcourse CT is meant to enable "seamless handover", which includes transport protocol performance. > suggesting that NSIS should design its independent AR-AR protocol.? No. I am not saying that NSIS should design its own AR-AR protocol. However, it's for NSIS folks to decide why/when/how such a thing is needed :-) BTW, what I meant in my previous e-mail was that CT was conceived when NSIS was not on radar. I see NSIS might be useful in providing a MN - AR signaling mechanism that would establish feature contexts. However, feature contexts could be established by other means as well. > > > simply transferring QoS description available at old AR to new AR. If the level of service available at new AR is greater or less that what CT has transferred, NSIS can take care of adaptation as the session continues from new AR. > > This was discussed earlier. In essence, > > - with some standard Profile Types, you would expect participating routers to > support a majority of the feature contexts. In the absence of additional > protocol support (e.g., CARD), transferring what you have is just fine. The > receiving router ignores the context(s) it does not understand. > London IETF was where we specifically had this discussion in depth. > > [Hemant] I did not mean readability or otherwise of CT bit layout at new AR when I said this. Level of service can imply for example increased/descreased available throughput. So, even if everybody understands profile types, values of service parameters could change (e.g. when you move from 2.5G to Operator WLAN and vice versa). > A Profile Type could encode the parameter values. > > - when a feature context type is not understood, CT should provide a notification. > Such a notification is also useful when a feature context is partially understood. > This notification could be used as a trigger to engage in NSIS signaling. > This was presented at the NSIS interim WG meeting. > > > > > > > If there are more than one feasible targets for handoff (this is where CARD may come in play), then the situation is little involved. If we can limit CARD negotiation to new AR resource check alone (as simple as bandwidth available on new AR-MN link or new AR outgoing interfaces), then the NSIS data path QoS signaling payload will be automatically available at new AR as a result of CARD negotiation procedures. On the other hand, if we have to check resource on new AR - CN data path also before concluding anything about handoff target, some NSIS signaling could occur along data path before CARD. > > > > Ok. When CARD is available, it can provide input to CT. > > [Hemant] But then new AR would know during CARD negotiation itself what the new context is? Do we need another CT (at least for QoS) after CARD has executed? > What is CARD doing here ? Figuring out capability or actually transferring contexts ? I am not sure.. I think the two should be treated separately. -Rajeev > > [Hemant] Hemant > > -Rajeev > > > > > Hemant > > > > -----Original Message----- > > From: ext James Kempf [mailto:kempf@docomolabs-usa.com] > > Sent: 08. July 2002 12:39 > > To: Chaskar Hemant (NRC/Boston); gkenward@nortelnetworks.com; > > seamoby@ietf.org; nsis@ietf.org > > Subject: Re: [Seamoby] RE: [NSIS] Re: > > draft-westphal-nsis-qos-mobileip-00.txt > > > > Could CT be viewed as an optimization of NSIS signaling? > > > > jak > > > > ----- Original Message ----- > > From: > > To: ; ; > > Sent: Monday, July 08, 2002 9:20 AM > > Subject: [Seamoby] RE: [NSIS] Re: draft-westphal-nsis-qos-mobileip-00.txt > > > > > Hi Gary: > > > > > > Some comments inline: > > > > > > -----Original Message----- > > > From: ext Gary Kenward [mailto:gkenward@nortelnetworks.com] > > > Sent: 08. July 2002 12:00 > > > To: 'seamoby@ietf.org'; 'NSIS' > > > Subject: [NSIS] Re: draft-westphal-nsis-qos-mobileip-00.txt > > > Sensitivity: Confidential > > > > > > > > > I finally managed to find time to read through Cedric's and Hemant's draft. > > > Overally, I think it is a good description of one possible integrated > > > approach. > > > > > > [Hemant] Please note that the Edge Signaling (MN-AR and AR-AR) and Data Path Signaling (e2e if you will) are not "tightly > > integrated", i.e., they help each other but do not rely on each other (though I admit that the current writeup makes that > > impression). In other words, Data Path Signaling can work (at handoff time) even if Edge Signaling fails. > > > > > > The one general comment I would like to offer up at this time, is that while > > > > > > the draft does a good job of integrating MIP, CT and NSIS concepts, the > > > proposed solutions for QoS negotiation between MN and AN (e.g. the use of > > > the > > > CIN message) is NSIS not CT. > > > > > > [Hemant] Point well taken. > > > > > > CT is concerned with the transfer of forwarding service context between > > > ANRs. > > > NSIS is concerned with the signalling of service requirements. Thus, the > > > issue > > > is not how to interwork the "CT" CIN, for example, with NSIS signalling, but > > > how > > > the CIN, etc., form part of the NSIS solution. > > > > > > [Hemant] I agree. The basic idea is that if CT can help avoid MN-new AR NSIS signaling at handoff time, it is a good proposition. > > Note that context can be constructed at old AR using the information supplied to it by NSIS MN-old AR message at session initiation, > > which can be transported to new AR in CT. If CT fails, one should use MN-new AR NSIS signaling at handoff time, albeit at certain > > loss of seamlessness. > > > > > > [Hemant] Thanks, Hemant > > > > > > This is not simply an issue of adherence to Seamoby/NSIS models or charters. > > > The intention has always been that CT work as a context transfer mechanism > > > with a variety of mobility and service signalling solutions. There is a > > > significant > > > benefit in the real world to be realized in keeping the context transfer > > > solution > > > (CT) independent from the service signalling solution (NSIS) (and the > > > mobility > > > solution - MIP or whatever). I would think that there is also a benefit to > > > keeping > > > the MN to AR service signalling independent of CT. > > > > > > Stated a different way, do we really need two separate solutions for over > > > the air > > > (MN to AN) service signalling? > > > > > > Regards, > > > Gary Kenward > > > > > > > > > > > > _______________________________________________ > > > nsis mailing list > > > nsis@ietf.org > > > https://www1.ietf.org/mailman/listinfo/nsis > > > > > > _______________________________________________ > > > 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 From daemon@optimus.ietf.org Mon Jul 8 19:48:22 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17774 for ; Mon, 8 Jul 2002 19:48:22 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id TAA08983 for seamoby-archive@odin.ietf.org; Mon, 8 Jul 2002 19:49:13 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA08810; Mon, 8 Jul 2002 19:45:50 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA08707 for ; Mon, 8 Jul 2002 19:45:45 -0400 (EDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17658; Mon, 8 Jul 2002 19:44:53 -0400 (EDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id QAA16466; Mon, 8 Jul 2002 16:45:13 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g68NjBN08913; Mon, 8 Jul 2002 16:45:11 -0700 X-mProtect: <200207082345> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.90, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdEsWp86; Mon, 08 Jul 2002 16:45:08 PDT Message-ID: <3D2A2405.9E4B33B9@iprg.nokia.com> Date: Mon, 08 Jul 2002 16:45:09 -0700 From: Rajeev Koodli Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Hemant.Chaskar@nokia.com CC: kempf@docomolabs-usa.com, gkenward@nortelnetworks.com, seamoby@ietf.org, nsis@ietf.org Subject: Re: [Seamoby] RE: [NSIS] Re: draft-westphal-nsis-qos-mobileip-00.txt References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit Hemant.Chaskar@nokia.com wrote: > > > Hi James: > > > > I have the impression that CT is an optimization for NSIS as it can help avoid sending signaling payload bits over MN-new AR link at handoff time. Now, this assumes that there is only one feasible target for handoff. Then, CT is > > CT is an optimization to avoid signaling and the associated overheads, and maintain > desirable transport (RTP/TCP)performance. A historical note: CT was not designed > to be an optimization for NSIS. > > [Hemant] Does reduction of latency in establishing QoS along the new packet path count as transport performance enhancement? Also, is it not (at all) a goal of CT to save wireless bandwidth for redundant signaling on a new AR - If there is a need for re-establishing QoS along the new path, then yes. And, CT can trigger such a signaling when needed, and NSIS is probably the right place for this signaling. In the NSIS interim meeting, there seemed to be favorable response to this thinking when I made this point. > MN link? In other words, is it appropriate to view CT as a tool to enhance seamlessness of handoff, or should be limited to the role of RTP/TCP performance booster (did you mean header compression there?). Also, are you Ofcourse CT is meant to enable "seamless handover", which includes transport protocol performance. > suggesting that NSIS should design its independent AR-AR protocol.? No. I am not saying that NSIS should design its own AR-AR protocol. However, it's for NSIS folks to decide why/when/how such a thing is needed :-) BTW, what I meant in my previous e-mail was that CT was conceived when NSIS was not on radar. I see NSIS might be useful in providing a MN - AR signaling mechanism that would establish feature contexts. However, feature contexts could be established by other means as well. > > > simply transferring QoS description available at old AR to new AR. If the level of service available at new AR is greater or less that what CT has transferred, NSIS can take care of adaptation as the session continues from new AR. > > This was discussed earlier. In essence, > > - with some standard Profile Types, you would expect participating routers to > support a majority of the feature contexts. In the absence of additional > protocol support (e.g., CARD), transferring what you have is just fine. The > receiving router ignores the context(s) it does not understand. > London IETF was where we specifically had this discussion in depth. > > [Hemant] I did not mean readability or otherwise of CT bit layout at new AR when I said this. Level of service can imply for example increased/descreased available throughput. So, even if everybody understands profile types, values of service parameters could change (e.g. when you move from 2.5G to Operator WLAN and vice versa). > A Profile Type could encode the parameter values. > > - when a feature context type is not understood, CT should provide a notification. > Such a notification is also useful when a feature context is partially understood. > This notification could be used as a trigger to engage in NSIS signaling. > This was presented at the NSIS interim WG meeting. > > > > > > > If there are more than one feasible targets for handoff (this is where CARD may come in play), then the situation is little involved. If we can limit CARD negotiation to new AR resource check alone (as simple as bandwidth available on new AR-MN link or new AR outgoing interfaces), then the NSIS data path QoS signaling payload will be automatically available at new AR as a result of CARD negotiation procedures. On the other hand, if we have to check resource on new AR - CN data path also before concluding anything about handoff target, some NSIS signaling could occur along data path before CARD. > > > > Ok. When CARD is available, it can provide input to CT. > > [Hemant] But then new AR would know during CARD negotiation itself what the new context is? Do we need another CT (at least for QoS) after CARD has executed? > What is CARD doing here ? Figuring out capability or actually transferring contexts ? I am not sure.. I think the two should be treated separately. -Rajeev > > [Hemant] Hemant > > -Rajeev > > > > > Hemant > > > > -----Original Message----- > > From: ext James Kempf [mailto:kempf@docomolabs-usa.com] > > Sent: 08. July 2002 12:39 > > To: Chaskar Hemant (NRC/Boston); gkenward@nortelnetworks.com; > > seamoby@ietf.org; nsis@ietf.org > > Subject: Re: [Seamoby] RE: [NSIS] Re: > > draft-westphal-nsis-qos-mobileip-00.txt > > > > Could CT be viewed as an optimization of NSIS signaling? > > > > jak > > > > ----- Original Message ----- > > From: > > To: ; ; > > Sent: Monday, July 08, 2002 9:20 AM > > Subject: [Seamoby] RE: [NSIS] Re: draft-westphal-nsis-qos-mobileip-00.txt > > > > > Hi Gary: > > > > > > Some comments inline: > > > > > > -----Original Message----- > > > From: ext Gary Kenward [mailto:gkenward@nortelnetworks.com] > > > Sent: 08. July 2002 12:00 > > > To: 'seamoby@ietf.org'; 'NSIS' > > > Subject: [NSIS] Re: draft-westphal-nsis-qos-mobileip-00.txt > > > Sensitivity: Confidential > > > > > > > > > I finally managed to find time to read through Cedric's and Hemant's draft. > > > Overally, I think it is a good description of one possible integrated > > > approach. > > > > > > [Hemant] Please note that the Edge Signaling (MN-AR and AR-AR) and Data Path Signaling (e2e if you will) are not "tightly > > integrated", i.e., they help each other but do not rely on each other (though I admit that the current writeup makes that > > impression). In other words, Data Path Signaling can work (at handoff time) even if Edge Signaling fails. > > > > > > The one general comment I would like to offer up at this time, is that while > > > > > > the draft does a good job of integrating MIP, CT and NSIS concepts, the > > > proposed solutions for QoS negotiation between MN and AN (e.g. the use of > > > the > > > CIN message) is NSIS not CT. > > > > > > [Hemant] Point well taken. > > > > > > CT is concerned with the transfer of forwarding service context between > > > ANRs. > > > NSIS is concerned with the signalling of service requirements. Thus, the > > > issue > > > is not how to interwork the "CT" CIN, for example, with NSIS signalling, but > > > how > > > the CIN, etc., form part of the NSIS solution. > > > > > > [Hemant] I agree. The basic idea is that if CT can help avoid MN-new AR NSIS signaling at handoff time, it is a good proposition. > > Note that context can be constructed at old AR using the information supplied to it by NSIS MN-old AR message at session initiation, > > which can be transported to new AR in CT. If CT fails, one should use MN-new AR NSIS signaling at handoff time, albeit at certain > > loss of seamlessness. > > > > > > [Hemant] Thanks, Hemant > > > > > > This is not simply an issue of adherence to Seamoby/NSIS models or charters. > > > The intention has always been that CT work as a context transfer mechanism > > > with a variety of mobility and service signalling solutions. There is a > > > significant > > > benefit in the real world to be realized in keeping the context transfer > > > solution > > > (CT) independent from the service signalling solution (NSIS) (and the > > > mobility > > > solution - MIP or whatever). I would think that there is also a benefit to > > > keeping > > > the MN to AR service signalling independent of CT. > > > > > > Stated a different way, do we really need two separate solutions for over > > > the air > > > (MN to AN) service signalling? > > > > > > Regards, > > > Gary Kenward > > > > > > > > > > > > _______________________________________________ > > > nsis mailing list > > > nsis@ietf.org > > > https://www1.ietf.org/mailman/listinfo/nsis > > > > > > _______________________________________________ > > > 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 From seamoby-admin@ietf.org Mon Jul 8 20:05:00 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18392 for ; Mon, 8 Jul 2002 20:04:59 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA09877; Mon, 8 Jul 2002 20:01:55 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA09827 for ; Mon, 8 Jul 2002 20:01:52 -0400 (EDT) Received: from 132.151.1.176 (sdn-ap-008neomahP0471.dialsprint.net [63.189.9.217]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA18287 for ; Mon, 8 Jul 2002 20:01:00 -0400 (EDT) Message-Id: <200207090001.UAA18287@ietf.org> From: "BeeSold" To: seamoby@ietf.org Date: Mon, 08 Jul 2002 17:02:20 -8:0 MIME-Version: 1.0 X-Priority: 3 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id UAA09828 Subject: [Seamoby] BeeSold.com - Your Online Auction House Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 8bit BeeSold.com - Your Online Auction House Tired of high prices on ebay.com ? Try the free auction listings at http://www.beesold.com FREE $20 Sign up Credit! 10,000 Page Views a week! Dont wait! Register today! http://www.beesold.com #This is not a mailing list - You will not be mailed again# _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Mon Jul 8 20:05:00 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18399 for ; Mon, 8 Jul 2002 20:05:00 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id UAA09994 for seamoby-archive@odin.ietf.org; Mon, 8 Jul 2002 20:05:51 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA09877; Mon, 8 Jul 2002 20:01:55 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA09827 for ; Mon, 8 Jul 2002 20:01:52 -0400 (EDT) Received: from 132.151.1.176 (sdn-ap-008neomahP0471.dialsprint.net [63.189.9.217]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA18287 for ; Mon, 8 Jul 2002 20:01:00 -0400 (EDT) Message-Id: <200207090001.UAA18287@ietf.org> From: "BeeSold" To: seamoby@ietf.org Date: Mon, 08 Jul 2002 17:02:20 -8:0 MIME-Version: 1.0 X-Priority: 3 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id UAA09828 Subject: [Seamoby] BeeSold.com - Your Online Auction House Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 8bit BeeSold.com - Your Online Auction House Tired of high prices on ebay.com ? Try the free auction listings at http://www.beesold.com FREE $20 Sign up Credit! 10,000 Page Views a week! Dont wait! Register today! http://www.beesold.com #This is not a mailing list - You will not be mailed again# _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Mon Jul 8 23:48:53 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA01276 for ; Mon, 8 Jul 2002 23:48:53 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA20363; Mon, 8 Jul 2002 23:45:06 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA20303 for ; Mon, 8 Jul 2002 23:45:03 -0400 (EDT) Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA01081; Mon, 8 Jul 2002 23:44:08 -0400 (EDT) From: john.loughney@nokia.com Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x3.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g693kxW27986; Tue, 9 Jul 2002 06:46:59 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 9 Jul 2002 06:45:00 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Tue, 9 Jul 2002 06:45:00 +0300 content-class: urn:content-classes:message Subject: RE: [Seamoby] RE: [NSIS] Re: draft-westphal-nsis-qos-mobileip-00.txt MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Tue, 9 Jul 2002 06:44:59 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC6568E@esebe004.NOE.Nokia.com> Thread-Topic: [Seamoby] RE: [NSIS] Re: draft-westphal-nsis-qos-mobileip-00.txt Thread-Index: AcImnk1mQ3tCY3p6QGmketUOdjRSZgAXGCeg To: , , , , X-OriginalArrivalTime: 09 Jul 2002 03:45:00.0496 (UTC) FILETIME=[00637500:01C226FB] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id XAA20304 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 8bit Hi James, > Could CT be viewed as an optimization of NSIS signaling? I would not state it that way. NSIS is working on on-path signaling; CT is decidedly off-path. CT is a tool that NSIS could co-operate with to ensure QoS, etc. for mobility. John _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Mon Jul 8 23:48:54 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA01283 for ; Mon, 8 Jul 2002 23:48:54 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id XAA20465 for seamoby-archive@odin.ietf.org; Mon, 8 Jul 2002 23:49:47 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA20363; Mon, 8 Jul 2002 23:45:06 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA20303 for ; Mon, 8 Jul 2002 23:45:03 -0400 (EDT) Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA01081; Mon, 8 Jul 2002 23:44:08 -0400 (EDT) From: john.loughney@nokia.com Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x3.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g693kxW27986; Tue, 9 Jul 2002 06:46:59 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 9 Jul 2002 06:45:00 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Tue, 9 Jul 2002 06:45:00 +0300 content-class: urn:content-classes:message Subject: RE: [Seamoby] RE: [NSIS] Re: draft-westphal-nsis-qos-mobileip-00.txt MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Tue, 9 Jul 2002 06:44:59 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC6568E@esebe004.NOE.Nokia.com> Thread-Topic: [Seamoby] RE: [NSIS] Re: draft-westphal-nsis-qos-mobileip-00.txt Thread-Index: AcImnk1mQ3tCY3p6QGmketUOdjRSZgAXGCeg To: , , , , X-OriginalArrivalTime: 09 Jul 2002 03:45:00.0496 (UTC) FILETIME=[00637500:01C226FB] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id XAA20304 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 8bit Hi James, > Could CT be viewed as an optimization of NSIS signaling? I would not state it that way. NSIS is working on on-path signaling; CT is decidedly off-path. CT is a tool that NSIS could co-operate with to ensure QoS, etc. for mobility. John _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Tue Jul 9 13:31:09 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04526 for ; Tue, 9 Jul 2002 13:31:09 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA23375; Tue, 9 Jul 2002 13:23:49 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA23350 for ; Tue, 9 Jul 2002 13:23:47 -0400 (EDT) Received: from fridge.docomolabs-usa.com (fwuser@key1.docomolabs-usa.com [216.98.102.225]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04369 for ; Tue, 9 Jul 2002 13:22:55 -0400 (EDT) Message-ID: <011501c2276d$28cd0ac0$4f6015ac@T23KEMPF> From: "James Kempf" To: Date: Tue, 9 Jul 2002 10:22:10 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Seamoby] CT Requirements Comments from IESG Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit I have finally managed to get a couple of technical comments out of the IESG on the CT requirements. More are coming but I think it might be worthwhile to start discussing these. 1) The requirements say nothing about the maintenance of dynamic context. Something must be said, is this out of scope or what? Gary tells me that supporting dynamic context was rejected by the working group, but it seems like we cannot punt on at least saying something about this issue. 2) The requirements say nothing about context which must be modified on the new router in order to be useful. An example is ROHC context when the mobile obtains a new care of address. How would the CT protocol handle this? I've asked Gary to lead a discussion on these two issues, please send comments to the list. jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Tue Jul 9 13:31:10 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04532 for ; Tue, 9 Jul 2002 13:31:10 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA24126 for seamoby-archive@odin.ietf.org; Tue, 9 Jul 2002 13:32:01 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA23375; Tue, 9 Jul 2002 13:23:49 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA23350 for ; Tue, 9 Jul 2002 13:23:47 -0400 (EDT) Received: from fridge.docomolabs-usa.com (fwuser@key1.docomolabs-usa.com [216.98.102.225]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04369 for ; Tue, 9 Jul 2002 13:22:55 -0400 (EDT) Message-ID: <011501c2276d$28cd0ac0$4f6015ac@T23KEMPF> From: "James Kempf" To: Date: Tue, 9 Jul 2002 10:22:10 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Seamoby] CT Requirements Comments from IESG Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit I have finally managed to get a couple of technical comments out of the IESG on the CT requirements. More are coming but I think it might be worthwhile to start discussing these. 1) The requirements say nothing about the maintenance of dynamic context. Something must be said, is this out of scope or what? Gary tells me that supporting dynamic context was rejected by the working group, but it seems like we cannot punt on at least saying something about this issue. 2) The requirements say nothing about context which must be modified on the new router in order to be useful. An example is ROHC context when the mobile obtains a new care of address. How would the CT protocol handle this? I've asked Gary to lead a discussion on these two issues, please send comments to the list. jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Tue Jul 9 13:52:01 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05048 for ; Tue, 9 Jul 2002 13:52:01 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA24799; Tue, 9 Jul 2002 13:47:06 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA24770 for ; Tue, 9 Jul 2002 13:47:04 -0400 (EDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04910 for ; Tue, 9 Jul 2002 13:46:11 -0400 (EDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id KAA27432 for ; Tue, 9 Jul 2002 10:46:32 -0700 (PDT) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g69HkWC25238 for ; Tue, 9 Jul 2002 10:46:32 -0700 X-mProtect: <200207091746> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdqBM72e; Tue, 09 Jul 2002 10:46:30 PDT Message-ID: <3D2B2177.82344C97@iprg.nokia.com> Date: Tue, 09 Jul 2002 10:46:31 -0700 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: seamoby@ietf.org Subject: Re: [Seamoby] CT Requirements Comments from IESG References: <011501c2276d$28cd0ac0$4f6015ac@T23KEMPF> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit Hello, James Kempf wrote: > 1) The requirements say nothing about the maintenance of dynamic context. > Something must be said, is this out of scope or what? Gary tells me that > supporting dynamic context was rejected by the working group, but it > seems like we cannot punt on at least saying something about this issue. What does "static" context mean? Is it something that doesn't change? I would expect that the kinds of context that are worth transferring would very often contain dynamic information. Even QoS, which may be set up with static parameters per flow (or per mobile, even), would likely have dynamic measurements that needed to be transferred (for traffic shaping or metering). Security associations (which could be transferred (and should be)) also have dynamic ancillary data (like lifetime or current volume of data). > 2) The requirements say nothing about context which must be modified on > the new router in order to be useful. An example is ROHC context when > the mobile obtains a new care of address. How would the CT protocol > handle this? This is a property of the context, not a property of the context transfer protocol. In fact, whether or not the context is dynamic is also not a property of the context transfer protocol. It's up to the new access router to figure out how to "install" the context, whether or not it's dynamic, or dependent upon link parameters at the new access router. For instance, transferring QoS between dissimilar access routers would require different procedures to manage the QoS transfer effectively. The security associations should be modified in some predictable way in order to be installed at the new access router. Regards, Charlie P. _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Tue Jul 9 13:52:01 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05058 for ; Tue, 9 Jul 2002 13:52:01 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA24974 for seamoby-archive@odin.ietf.org; Tue, 9 Jul 2002 13:52:53 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA24799; Tue, 9 Jul 2002 13:47:06 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA24770 for ; Tue, 9 Jul 2002 13:47:04 -0400 (EDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04910 for ; Tue, 9 Jul 2002 13:46:11 -0400 (EDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id KAA27432 for ; Tue, 9 Jul 2002 10:46:32 -0700 (PDT) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g69HkWC25238 for ; Tue, 9 Jul 2002 10:46:32 -0700 X-mProtect: <200207091746> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdqBM72e; Tue, 09 Jul 2002 10:46:30 PDT Message-ID: <3D2B2177.82344C97@iprg.nokia.com> Date: Tue, 09 Jul 2002 10:46:31 -0700 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: seamoby@ietf.org Subject: Re: [Seamoby] CT Requirements Comments from IESG References: <011501c2276d$28cd0ac0$4f6015ac@T23KEMPF> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit Hello, James Kempf wrote: > 1) The requirements say nothing about the maintenance of dynamic context. > Something must be said, is this out of scope or what? Gary tells me that > supporting dynamic context was rejected by the working group, but it > seems like we cannot punt on at least saying something about this issue. What does "static" context mean? Is it something that doesn't change? I would expect that the kinds of context that are worth transferring would very often contain dynamic information. Even QoS, which may be set up with static parameters per flow (or per mobile, even), would likely have dynamic measurements that needed to be transferred (for traffic shaping or metering). Security associations (which could be transferred (and should be)) also have dynamic ancillary data (like lifetime or current volume of data). > 2) The requirements say nothing about context which must be modified on > the new router in order to be useful. An example is ROHC context when > the mobile obtains a new care of address. How would the CT protocol > handle this? This is a property of the context, not a property of the context transfer protocol. In fact, whether or not the context is dynamic is also not a property of the context transfer protocol. It's up to the new access router to figure out how to "install" the context, whether or not it's dynamic, or dependent upon link parameters at the new access router. For instance, transferring QoS between dissimilar access routers would require different procedures to manage the QoS transfer effectively. The security associations should be modified in some predictable way in order to be installed at the new access router. Regards, Charlie P. _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Tue Jul 9 16:00:33 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15311 for ; Tue, 9 Jul 2002 16:00:33 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA03398; Tue, 9 Jul 2002 15:51:24 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA03367 for ; Tue, 9 Jul 2002 15:51:22 -0400 (EDT) Received: from zcars04e.ca.nortel.com (zcars04e.nortelnetworks.com [47.129.242.56]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15012 for ; Tue, 9 Jul 2002 15:50:28 -0400 (EDT) Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g69JogP24302; Tue, 9 Jul 2002 15:50:42 -0400 (EDT) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 9 Jul 2002 15:50:41 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA4BF9@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'James Kempf'" , seamoby@ietf.org Subject: RE: [Seamoby] CT Requirements Comments from IESG Date: Tue, 9 Jul 2002 15:50:33 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C22781.E2F3BBA6" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C22781.E2F3BBA6 Content-Type: text/plain; charset="iso-8859-1" James: Sorry, but a small clarification: I did not say that dynamic context was rejected, I said that I recalled that there was, at one time, a requirement that attempted to directly address dynamic context and the need to update it and that requirement was eventually removed. I think the reason was the difficulty in defining "dynamic" versus "static" context, as Charlie outlines in his response. There is, however, a requirement, 5.5, that speaks to context updates in general: 5.5 Context Update and Synchronization 5.5.1 The context transfer protocol MUST be capable of updating context information when it changes. 5.5.2 A context update MUST preserve the integrity, and thus the meaning, of the context at each receiving AR. The context at the AR actually supporting an MN's traffic will change with time. For example, the MN may initiate new microflow(s), or discontinue existing microflows. Any change of context at the supporting AR must be replicated at those ARs that have already received context for that MN. I am now wondering why this requirement did not answer the IESGs concerns? Possibly because it does not explicitly mention "dynamic context" or "dynamic updates"? Gary > -----Original Message----- > From: James Kempf [mailto:kempf@docomolabs-usa.com] > Sent: July 9, 2002 13:22 > To: seamoby@ietf.org > Subject: [Seamoby] CT Requirements Comments from IESG > > > I have finally managed to get a couple of technical comments > out of the IESG on the CT requirements. More are coming but I think it > might be worthwhile to start discussing these. > > 1) The requirements say nothing about the maintenance of > dynamic context. Something must be said, is this out of scope > or what? Gary > tells me that supporting dynamic context was rejected by the > working group, but it seems like we cannot punt on at least saying > something about this issue. > > 2) The requirements say nothing about context which must be > modified on the new router in order to be useful. An example is ROHC > context when the mobile obtains a new care of address. How > would the CT protocol handle this? > > I've asked Gary to lead a discussion on these two issues, > please send comments to the list. > > jak > > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > ------_=_NextPart_001_01C22781.E2F3BBA6 Content-Type: text/html; charset="iso-8859-1" RE: [Seamoby] CT Requirements Comments from IESG

James:

  Sorry, but a small clarification: I did not say that dynamic context
was rejected, I said that I recalled that there was, at one time, a requirement
that attempted to directly address dynamic context and the need to update it
and that requirement was eventually removed. I think the reason was the difficulty
in defining "dynamic" versus "static" context, as Charlie outlines in his response.

  There is, however, a requirement, 5.5, that speaks to context updates in general:

5.5 Context Update and Synchronization

5.5.1 The context transfer protocol MUST be capable of updating
      context information when it changes.

5.5.2 A context update MUST preserve the integrity, and thus the
      meaning, of the context at each receiving AR.

   The context at the AR actually supporting an MN's traffic will
   change with time. For example, the MN may initiate new microflow(s),
   or discontinue existing microflows. Any change of context at the
   supporting AR must be replicated at those ARs that have already
   received context for that MN.

I am now wondering why this requirement did not answer the IESGs concerns?
Possibly because it does not explicitly mention "dynamic context" or "dynamic
updates"?

Gary

> -----Original Message-----
> From: James Kempf [mailto:kempf@docomolabs-usa.com]
> Sent: July 9, 2002 13:22
> To: seamoby@ietf.org
> Subject: [Seamoby] CT Requirements Comments from IESG
>
>
> I have finally managed to get a couple of technical comments
> out of the IESG on the CT requirements. More are coming but I think it
> might be worthwhile to start discussing these.
>
> 1) The requirements say nothing about the maintenance of
> dynamic context. Something must be said, is this out of scope
> or what? Gary
> tells me that supporting dynamic context was rejected by the
> working group, but it seems like we cannot punt on at least saying
> something about this issue.
>
> 2) The requirements say nothing about context which must be
> modified on the new router in order to be useful. An example is ROHC
> context when the mobile obtains a new care of address. How
> would the CT protocol handle this?
>
> I've asked Gary to lead a discussion on these two issues,
> please send comments to the list.
>
>             jak
>
>
> _______________________________________________
> Seamoby mailing list
> Seamoby@ietf.org
> https://www1.ietf.org/mailman/listinfo/seamoby
>

------_=_NextPart_001_01C22781.E2F3BBA6-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Tue Jul 9 16:00:34 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15324 for ; Tue, 9 Jul 2002 16:00:34 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA04372 for seamoby-archive@odin.ietf.org; Tue, 9 Jul 2002 16:01:26 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA03398; Tue, 9 Jul 2002 15:51:24 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA03367 for ; Tue, 9 Jul 2002 15:51:22 -0400 (EDT) Received: from zcars04e.ca.nortel.com (zcars04e.nortelnetworks.com [47.129.242.56]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15012 for ; Tue, 9 Jul 2002 15:50:28 -0400 (EDT) Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g69JogP24302; Tue, 9 Jul 2002 15:50:42 -0400 (EDT) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 9 Jul 2002 15:50:41 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA4BF9@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'James Kempf'" , seamoby@ietf.org Subject: RE: [Seamoby] CT Requirements Comments from IESG Date: Tue, 9 Jul 2002 15:50:33 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C22781.E2F3BBA6" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C22781.E2F3BBA6 Content-Type: text/plain; charset="iso-8859-1" James: Sorry, but a small clarification: I did not say that dynamic context was rejected, I said that I recalled that there was, at one time, a requirement that attempted to directly address dynamic context and the need to update it and that requirement was eventually removed. I think the reason was the difficulty in defining "dynamic" versus "static" context, as Charlie outlines in his response. There is, however, a requirement, 5.5, that speaks to context updates in general: 5.5 Context Update and Synchronization 5.5.1 The context transfer protocol MUST be capable of updating context information when it changes. 5.5.2 A context update MUST preserve the integrity, and thus the meaning, of the context at each receiving AR. The context at the AR actually supporting an MN's traffic will change with time. For example, the MN may initiate new microflow(s), or discontinue existing microflows. Any change of context at the supporting AR must be replicated at those ARs that have already received context for that MN. I am now wondering why this requirement did not answer the IESGs concerns? Possibly because it does not explicitly mention "dynamic context" or "dynamic updates"? Gary > -----Original Message----- > From: James Kempf [mailto:kempf@docomolabs-usa.com] > Sent: July 9, 2002 13:22 > To: seamoby@ietf.org > Subject: [Seamoby] CT Requirements Comments from IESG > > > I have finally managed to get a couple of technical comments > out of the IESG on the CT requirements. More are coming but I think it > might be worthwhile to start discussing these. > > 1) The requirements say nothing about the maintenance of > dynamic context. Something must be said, is this out of scope > or what? Gary > tells me that supporting dynamic context was rejected by the > working group, but it seems like we cannot punt on at least saying > something about this issue. > > 2) The requirements say nothing about context which must be > modified on the new router in order to be useful. An example is ROHC > context when the mobile obtains a new care of address. How > would the CT protocol handle this? > > I've asked Gary to lead a discussion on these two issues, > please send comments to the list. > > jak > > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > ------_=_NextPart_001_01C22781.E2F3BBA6 Content-Type: text/html; charset="iso-8859-1" RE: [Seamoby] CT Requirements Comments from IESG

James:

  Sorry, but a small clarification: I did not say that dynamic context
was rejected, I said that I recalled that there was, at one time, a requirement
that attempted to directly address dynamic context and the need to update it
and that requirement was eventually removed. I think the reason was the difficulty
in defining "dynamic" versus "static" context, as Charlie outlines in his response.

  There is, however, a requirement, 5.5, that speaks to context updates in general:

5.5 Context Update and Synchronization

5.5.1 The context transfer protocol MUST be capable of updating
      context information when it changes.

5.5.2 A context update MUST preserve the integrity, and thus the
      meaning, of the context at each receiving AR.

   The context at the AR actually supporting an MN's traffic will
   change with time. For example, the MN may initiate new microflow(s),
   or discontinue existing microflows. Any change of context at the
   supporting AR must be replicated at those ARs that have already
   received context for that MN.

I am now wondering why this requirement did not answer the IESGs concerns?
Possibly because it does not explicitly mention "dynamic context" or "dynamic
updates"?

Gary

> -----Original Message-----
> From: James Kempf [mailto:kempf@docomolabs-usa.com]
> Sent: July 9, 2002 13:22
> To: seamoby@ietf.org
> Subject: [Seamoby] CT Requirements Comments from IESG
>
>
> I have finally managed to get a couple of technical comments
> out of the IESG on the CT requirements. More are coming but I think it
> might be worthwhile to start discussing these.
>
> 1) The requirements say nothing about the maintenance of
> dynamic context. Something must be said, is this out of scope
> or what? Gary
> tells me that supporting dynamic context was rejected by the
> working group, but it seems like we cannot punt on at least saying
> something about this issue.
>
> 2) The requirements say nothing about context which must be
> modified on the new router in order to be useful. An example is ROHC
> context when the mobile obtains a new care of address. How
> would the CT protocol handle this?
>
> I've asked Gary to lead a discussion on these two issues,
> please send comments to the list.
>
>             jak
>
>
> _______________________________________________
> Seamoby mailing list
> Seamoby@ietf.org
> https://www1.ietf.org/mailman/listinfo/seamoby
>

------_=_NextPart_001_01C22781.E2F3BBA6-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Tue Jul 9 16:08:02 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15517 for ; Tue, 9 Jul 2002 16:08:02 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA04428; Tue, 9 Jul 2002 16:01:42 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA04399 for ; Tue, 9 Jul 2002 16:01:40 -0400 (EDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15337 for ; Tue, 9 Jul 2002 16:00:44 -0400 (EDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id NAA04136; Tue, 9 Jul 2002 13:00:59 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g69K0x414931; Tue, 9 Jul 2002 13:00:59 -0700 X-mProtect: <200207092000> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdGItpus; Tue, 09 Jul 2002 13:00:57 PDT Message-ID: <3D2B40F9.4F9699CF@iprg.nokia.com> Date: Tue, 09 Jul 2002 13:00:57 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: James Kempf CC: seamoby@ietf.org Subject: Re: [Seamoby] CT Requirements Comments from IESG References: <011501c2276d$28cd0ac0$4f6015ac@T23KEMPF> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit hi Jim, James Kempf wrote: > 2) The requirements say nothing about context which must be modified on the new router in order to be useful. An example is ROHC > context when the mobile obtains a new care of address. How would the CT protocol handle this? the context transfer protocol should not worry about this at all. it is specific to each feature. for ROHC, the IP addresses have to be changed. for IPsec Security Associations, the SPIs maybe need to be changed in addition to the IP addresses. regards Vijay _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Tue Jul 9 16:08:02 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15522 for ; Tue, 9 Jul 2002 16:08:02 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA04769 for seamoby-archive@odin.ietf.org; Tue, 9 Jul 2002 16:08:55 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA04428; Tue, 9 Jul 2002 16:01:42 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA04399 for ; Tue, 9 Jul 2002 16:01:40 -0400 (EDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15337 for ; Tue, 9 Jul 2002 16:00:44 -0400 (EDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id NAA04136; Tue, 9 Jul 2002 13:00:59 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g69K0x414931; Tue, 9 Jul 2002 13:00:59 -0700 X-mProtect: <200207092000> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdGItpus; Tue, 09 Jul 2002 13:00:57 PDT Message-ID: <3D2B40F9.4F9699CF@iprg.nokia.com> Date: Tue, 09 Jul 2002 13:00:57 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: James Kempf CC: seamoby@ietf.org Subject: Re: [Seamoby] CT Requirements Comments from IESG References: <011501c2276d$28cd0ac0$4f6015ac@T23KEMPF> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit hi Jim, James Kempf wrote: > 2) The requirements say nothing about context which must be modified on the new router in order to be useful. An example is ROHC > context when the mobile obtains a new care of address. How would the CT protocol handle this? the context transfer protocol should not worry about this at all. it is specific to each feature. for ROHC, the IP addresses have to be changed. for IPsec Security Associations, the SPIs maybe need to be changed in addition to the IP addresses. regards Vijay _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Tue Jul 9 17:02:24 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17377 for ; Tue, 9 Jul 2002 17:02:24 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA07468; Tue, 9 Jul 2002 16:57:47 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA07441 for ; Tue, 9 Jul 2002 16:57:45 -0400 (EDT) Received: from fridge.docomolabs-usa.com (fwuser@key1.docomolabs-usa.com [216.98.102.225]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17214 for ; Tue, 9 Jul 2002 16:56:50 -0400 (EDT) Message-ID: <020401c2278b$085b3e10$4f6015ac@T23KEMPF> From: "James Kempf" To: "Gary Kenward" , References: <9FBD322B7824D511B36900508BF93C9C01AA4BF9@zcard031.ca.nortel.com> Subject: Re: [Seamoby] CT Requirements Comments from IESG Date: Tue, 9 Jul 2002 13:56:01 -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-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Gary Kenward" To: "'James Kempf'" ; Sent: Tuesday, July 09, 2002 12:50 PM Subject: RE: [Seamoby] CT Requirements Comments from IESG > James: > > Sorry, but a small clarification: I did not say that dynamic context > was rejected, I said that I recalled that there was, at one time, a > requirement > that attempted to directly address dynamic context and the need to update it > > and that requirement was eventually removed. I think the reason was the > difficulty > in defining "dynamic" versus "static" context, as Charlie outlines in his > response. > > There is, however, a requirement, 5.5, that speaks to context updates in > general: > > 5.5 Context Update and Synchronization > > 5.5.1 The context transfer protocol MUST be capable of updating > context information when it changes. > > 5.5.2 A context update MUST preserve the integrity, and thus the > meaning, of the context at each receiving AR. > > The context at the AR actually supporting an MN's traffic will > change with time. For example, the MN may initiate new microflow(s), > or discontinue existing microflows. Any change of context at the > supporting AR must be replicated at those ARs that have already > received context for that MN. > > I am now wondering why this requirement did not answer the IESGs concerns? > Possibly because it does not explicitly mention "dynamic context" or > "dynamic > updates"? > I suspect that is it. What is "meaning"? jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Tue Jul 9 17:02:25 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17394 for ; Tue, 9 Jul 2002 17:02:25 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA09015 for seamoby-archive@odin.ietf.org; Tue, 9 Jul 2002 17:03:18 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA07413; Tue, 9 Jul 2002 16:57:24 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA07385 for ; Tue, 9 Jul 2002 16:57:22 -0400 (EDT) Received: from zcars04e.ca.nortel.com (zcars04e.nortelnetworks.com [47.129.242.56]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17206 for ; Tue, 9 Jul 2002 16:56:28 -0400 (EDT) Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g69KuVP29425; Tue, 9 Jul 2002 16:56:32 -0400 (EDT) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 9 Jul 2002 16:56:24 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA4BFC@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'Vijay Devarapalli'" , James Kempf Cc: seamoby@ietf.org Subject: RE: [Seamoby] CT Requirements Comments from IESG Date: Tue, 9 Jul 2002 16:56:23 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2278B.1536E814" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C2278B.1536E814 Content-Type: text/plain; charset="iso-8859-1" I agree with Vijay and Charlie on the response to this question. It may still be useful to add this response to the requirements, explicitly stating that the receiving AR *may* change the received context for its own use, but the nature of these changes, and how they are effected are not part of the context transfer solution. Gary > -----Original Message----- > From: Vijay Devarapalli [mailto:vijayd@iprg.nokia.com] > Sent: July 9, 2002 16:01 > To: James Kempf > Cc: seamoby@ietf.org > Subject: Re: [Seamoby] CT Requirements Comments from IESG > > > hi Jim, > > James Kempf wrote: > > > 2) The requirements say nothing about context which must be > modified on the new router in order to be useful. An example is ROHC > > context when the mobile obtains a new care of address. How > would the CT protocol handle this? > > the context transfer protocol should not worry about this at all. > it is specific to each feature. for ROHC, the IP addresses have > to be changed. for IPsec Security Associations, the SPIs maybe > need to be changed in addition to the IP addresses. > > regards > Vijay > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > ------_=_NextPart_001_01C2278B.1536E814 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Seamoby] CT Requirements Comments from IESG

I agree with Vijay and Charlie on the response to = this question.
It may still be useful to add this response to the = requirements,
explicitly stating that the receiving AR *may* = change the received
context for its own use, but the nature of these = changes, and how
they are effected are not part of the context = transfer solution.

Gary

> -----Original Message-----
> From: Vijay Devarapalli [mailto:vijayd@iprg.nokia.com]<= /FONT>
> Sent: July 9, 2002 16:01
> To: James Kempf
> Cc: seamoby@ietf.org
> Subject: Re: [Seamoby] CT Requirements Comments = from IESG
>
>
> hi Jim,
>
> James Kempf wrote:
>
> > 2) The requirements say nothing about = context which must be
> modified on the new router in order to be = useful. An example is ROHC
> > context when the mobile obtains a new care = of address. How
> would the CT protocol handle this?
>
> the context transfer protocol should not worry = about this at all.
> it is specific to each feature. for ROHC, the = IP addresses have
> to be changed. for IPsec Security Associations, = the SPIs maybe
> need to be changed in addition to the IP = addresses.
>
> regards
> Vijay
>
> = _______________________________________________
> Seamoby mailing list
> Seamoby@ietf.org
> https://www1.ietf.org/mailman/listinfo/seamoby
>

------_=_NextPart_001_01C2278B.1536E814-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Tue Jul 9 17:55:33 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17386 for ; Tue, 9 Jul 2002 17:02:25 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA09004 for seamoby-archive@odin.ietf.org; Tue, 9 Jul 2002 17:03:18 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA07468; Tue, 9 Jul 2002 16:57:47 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA07441 for ; Tue, 9 Jul 2002 16:57:45 -0400 (EDT) Received: from fridge.docomolabs-usa.com (fwuser@key1.docomolabs-usa.com [216.98.102.225]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17214 for ; Tue, 9 Jul 2002 16:56:50 -0400 (EDT) Message-ID: <020401c2278b$085b3e10$4f6015ac@T23KEMPF> From: "James Kempf" To: "Gary Kenward" , References: <9FBD322B7824D511B36900508BF93C9C01AA4BF9@zcard031.ca.nortel.com> Subject: Re: [Seamoby] CT Requirements Comments from IESG Date: Tue, 9 Jul 2002 13:56:01 -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-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Gary Kenward" To: "'James Kempf'" ; Sent: Tuesday, July 09, 2002 12:50 PM Subject: RE: [Seamoby] CT Requirements Comments from IESG > James: > > Sorry, but a small clarification: I did not say that dynamic context > was rejected, I said that I recalled that there was, at one time, a > requirement > that attempted to directly address dynamic context and the need to update it > > and that requirement was eventually removed. I think the reason was the > difficulty > in defining "dynamic" versus "static" context, as Charlie outlines in his > response. > > There is, however, a requirement, 5.5, that speaks to context updates in > general: > > 5.5 Context Update and Synchronization > > 5.5.1 The context transfer protocol MUST be capable of updating > context information when it changes. > > 5.5.2 A context update MUST preserve the integrity, and thus the > meaning, of the context at each receiving AR. > > The context at the AR actually supporting an MN's traffic will > change with time. For example, the MN may initiate new microflow(s), > or discontinue existing microflows. Any change of context at the > supporting AR must be replicated at those ARs that have already > received context for that MN. > > I am now wondering why this requirement did not answer the IESGs concerns? > Possibly because it does not explicitly mention "dynamic context" or > "dynamic > updates"? > I suspect that is it. What is "meaning"? jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Tue Jul 9 17:55:33 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17381 for ; Tue, 9 Jul 2002 17:02:24 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA07413; Tue, 9 Jul 2002 16:57:24 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA07385 for ; Tue, 9 Jul 2002 16:57:22 -0400 (EDT) Received: from zcars04e.ca.nortel.com (zcars04e.nortelnetworks.com [47.129.242.56]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17206 for ; Tue, 9 Jul 2002 16:56:28 -0400 (EDT) Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g69KuVP29425; Tue, 9 Jul 2002 16:56:32 -0400 (EDT) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 9 Jul 2002 16:56:24 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA4BFC@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'Vijay Devarapalli'" , James Kempf Cc: seamoby@ietf.org Subject: RE: [Seamoby] CT Requirements Comments from IESG Date: Tue, 9 Jul 2002 16:56:23 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2278B.1536E814" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C2278B.1536E814 Content-Type: text/plain; charset="iso-8859-1" I agree with Vijay and Charlie on the response to this question. It may still be useful to add this response to the requirements, explicitly stating that the receiving AR *may* change the received context for its own use, but the nature of these changes, and how they are effected are not part of the context transfer solution. Gary > -----Original Message----- > From: Vijay Devarapalli [mailto:vijayd@iprg.nokia.com] > Sent: July 9, 2002 16:01 > To: James Kempf > Cc: seamoby@ietf.org > Subject: Re: [Seamoby] CT Requirements Comments from IESG > > > hi Jim, > > James Kempf wrote: > > > 2) The requirements say nothing about context which must be > modified on the new router in order to be useful. An example is ROHC > > context when the mobile obtains a new care of address. How > would the CT protocol handle this? > > the context transfer protocol should not worry about this at all. > it is specific to each feature. for ROHC, the IP addresses have > to be changed. for IPsec Security Associations, the SPIs maybe > need to be changed in addition to the IP addresses. > > regards > Vijay > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > ------_=_NextPart_001_01C2278B.1536E814 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Seamoby] CT Requirements Comments from IESG

I agree with Vijay and Charlie on the response to = this question.
It may still be useful to add this response to the = requirements,
explicitly stating that the receiving AR *may* = change the received
context for its own use, but the nature of these = changes, and how
they are effected are not part of the context = transfer solution.

Gary

> -----Original Message-----
> From: Vijay Devarapalli [mailto:vijayd@iprg.nokia.com]<= /FONT>
> Sent: July 9, 2002 16:01
> To: James Kempf
> Cc: seamoby@ietf.org
> Subject: Re: [Seamoby] CT Requirements Comments = from IESG
>
>
> hi Jim,
>
> James Kempf wrote:
>
> > 2) The requirements say nothing about = context which must be
> modified on the new router in order to be = useful. An example is ROHC
> > context when the mobile obtains a new care = of address. How
> would the CT protocol handle this?
>
> the context transfer protocol should not worry = about this at all.
> it is specific to each feature. for ROHC, the = IP addresses have
> to be changed. for IPsec Security Associations, = the SPIs maybe
> need to be changed in addition to the IP = addresses.
>
> regards
> Vijay
>
> = _______________________________________________
> Seamoby mailing list
> Seamoby@ietf.org
> https://www1.ietf.org/mailman/listinfo/seamoby
>

------_=_NextPart_001_01C2278B.1536E814-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Tue Jul 9 17:59:27 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19488 for ; Tue, 9 Jul 2002 17:59:27 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA13702; Tue, 9 Jul 2002 17:56:11 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA13673 for ; Tue, 9 Jul 2002 17:56:09 -0400 (EDT) Received: from fridge.docomolabs-usa.com (fwuser@key1.docomolabs-usa.com [216.98.102.225]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19414 for ; Tue, 9 Jul 2002 17:55:14 -0400 (EDT) Message-ID: <027401c22793$2ebdc660$4f6015ac@T23KEMPF> From: "James Kempf" To: "Gary Kenward" , "'Vijay Devarapalli'" Cc: References: <9FBD322B7824D511B36900508BF93C9C01AA4BFC@zcard031.ca.nortel.com> Subject: Re: [Seamoby] CT Requirements Comments from IESG Date: Tue, 9 Jul 2002 14:54:21 -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-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit I think what the IESG wants to see is a statement like this. jak ----- Original Message ----- From: "Gary Kenward" To: "'Vijay Devarapalli'" ; "James Kempf" Cc: Sent: Tuesday, July 09, 2002 1:56 PM Subject: RE: [Seamoby] CT Requirements Comments from IESG > I agree with Vijay and Charlie on the response to this question. > It may still be useful to add this response to the requirements, > explicitly stating that the receiving AR *may* change the received > context for its own use, but the nature of these changes, and how > they are effected are not part of the context transfer solution. > > Gary > > > -----Original Message----- > > From: Vijay Devarapalli [mailto:vijayd@iprg.nokia.com] > > Sent: July 9, 2002 16:01 > > To: James Kempf > > Cc: seamoby@ietf.org > > Subject: Re: [Seamoby] CT Requirements Comments from IESG > > > > > > hi Jim, > > > > James Kempf wrote: > > > > > 2) The requirements say nothing about context which must be > > modified on the new router in order to be useful. An example is ROHC > > > context when the mobile obtains a new care of address. How > > would the CT protocol handle this? > > > > the context transfer protocol should not worry about this at all. > > it is specific to each feature. for ROHC, the IP addresses have > > to be changed. for IPsec Security Associations, the SPIs maybe > > need to be changed in addition to the IP addresses. > > > > regards > > Vijay > > > > _______________________________________________ > > 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 From daemon@optimus.ietf.org Tue Jul 9 17:59:28 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19495 for ; Tue, 9 Jul 2002 17:59:28 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA14004 for seamoby-archive@odin.ietf.org; Tue, 9 Jul 2002 18:00:22 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA13702; Tue, 9 Jul 2002 17:56:11 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA13673 for ; Tue, 9 Jul 2002 17:56:09 -0400 (EDT) Received: from fridge.docomolabs-usa.com (fwuser@key1.docomolabs-usa.com [216.98.102.225]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19414 for ; Tue, 9 Jul 2002 17:55:14 -0400 (EDT) Message-ID: <027401c22793$2ebdc660$4f6015ac@T23KEMPF> From: "James Kempf" To: "Gary Kenward" , "'Vijay Devarapalli'" Cc: References: <9FBD322B7824D511B36900508BF93C9C01AA4BFC@zcard031.ca.nortel.com> Subject: Re: [Seamoby] CT Requirements Comments from IESG Date: Tue, 9 Jul 2002 14:54:21 -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-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit I think what the IESG wants to see is a statement like this. jak ----- Original Message ----- From: "Gary Kenward" To: "'Vijay Devarapalli'" ; "James Kempf" Cc: Sent: Tuesday, July 09, 2002 1:56 PM Subject: RE: [Seamoby] CT Requirements Comments from IESG > I agree with Vijay and Charlie on the response to this question. > It may still be useful to add this response to the requirements, > explicitly stating that the receiving AR *may* change the received > context for its own use, but the nature of these changes, and how > they are effected are not part of the context transfer solution. > > Gary > > > -----Original Message----- > > From: Vijay Devarapalli [mailto:vijayd@iprg.nokia.com] > > Sent: July 9, 2002 16:01 > > To: James Kempf > > Cc: seamoby@ietf.org > > Subject: Re: [Seamoby] CT Requirements Comments from IESG > > > > > > hi Jim, > > > > James Kempf wrote: > > > > > 2) The requirements say nothing about context which must be > > modified on the new router in order to be useful. An example is ROHC > > > context when the mobile obtains a new care of address. How > > would the CT protocol handle this? > > > > the context transfer protocol should not worry about this at all. > > it is specific to each feature. for ROHC, the IP addresses have > > to be changed. for IPsec Security Associations, the SPIs maybe > > need to be changed in addition to the IP addresses. > > > > regards > > Vijay > > > > _______________________________________________ > > 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 From seamoby-admin@ietf.org Wed Jul 10 10:14:43 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03625 for ; Wed, 10 Jul 2002 10:14:43 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA27672; Wed, 10 Jul 2002 10:09:35 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA27631 for ; Wed, 10 Jul 2002 10:09:33 -0400 (EDT) Received: from zcars04f.ca.nortel.com (zcars04f.nortelnetworks.com [47.129.242.57]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03152 for ; Wed, 10 Jul 2002 10:08:38 -0400 (EDT) Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04f.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g6AE8UB20511; Wed, 10 Jul 2002 10:08:30 -0400 (EDT) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 10 Jul 2002 10:08:29 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA4BFD@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'James Kempf'" , seamoby@ietf.org Subject: RE: [Seamoby] CT Requirements Comments from IESG Date: Wed, 10 Jul 2002 10:08:28 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2281B.4344D92E" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C2281B.4344D92E Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Main Entry: mean=B7ing=20 Pronunciation: 'mE-ni[ng] Function: noun 4 a : the logical connotation of a word or phrase=20 ------------ I propose, for section 5.5.2, to replace "meaning" with=20 "original syntax and semantics", unless someone has a better idea. Gary > -----Original Message----- > From: James Kempf [mailto:kempf@docomolabs-usa.com] > Sent: July 9, 2002 16:56 > To: Kenward, Gary [WDLN2:AN10:EXCH]; seamoby@ietf.org > Subject: Re: [Seamoby] CT Requirements Comments from IESG >=20 >=20 >=20 > ----- Original Message -----=20 > From: "Gary Kenward" > To: "'James Kempf'" ; > Sent: Tuesday, July 09, 2002 12:50 PM > Subject: RE: [Seamoby] CT Requirements Comments from IESG >=20 >=20 > > James: > >=20 > > Sorry, but a small clarification: I did not say that=20 > dynamic context=20 > > was rejected, I said that I recalled that there was, at one time, a > > requirement > > that attempted to directly address dynamic context and the=20 > need to update it > >=20 > > and that requirement was eventually removed. I think the=20 > reason was the > > difficulty > > in defining "dynamic" versus "static" context, as Charlie=20 > outlines in his > > response. > >=20 > > There is, however, a requirement, 5.5, that speaks to=20 > context updates in > > general: > >=20 > > 5.5 Context Update and Synchronization > >=20 > > 5.5.1 The context transfer protocol MUST be capable of updating=20 > > context information when it changes. > >=20 > > 5.5.2 A context update MUST preserve the integrity, and thus the > > meaning, of the context at each receiving AR. > >=20 > > The context at the AR actually supporting an MN's traffic will > > change with time. For example, the MN may initiate new=20 > microflow(s), > > or discontinue existing microflows. Any change of context at the > > supporting AR must be replicated at those ARs that have already > > received context for that MN. > >=20 > > I am now wondering why this requirement did not answer the=20 > IESGs concerns? > > Possibly because it does not explicitly mention "dynamic context" = or > > "dynamic > > updates"?=20 > >=20 >=20 > I suspect that is it. What is "meaning"?=20 >=20 > jak=20 >=20 >=20 ------_=_NextPart_001_01C2281B.4344D92E Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Seamoby] CT Requirements Comments from IESG

Main Entry: mean=B7ing
Pronunciation: 'mE-ni[ng]
Function: noun

4 a : the logical connotation of a word or phrase =

------------

I propose, for section 5.5.2, to replace = "meaning" with
"original syntax and semantics", unless = someone has a better
idea.

Gary

> -----Original Message-----
> From: James Kempf [mailto:kempf@docomolabs-usa.com= ]
> Sent: July 9, 2002 16:56
> To: Kenward, Gary [WDLN2:AN10:EXCH]; = seamoby@ietf.org
> Subject: Re: [Seamoby] CT Requirements Comments = from IESG
>
>
>
> ----- Original Message -----
> From: "Gary Kenward" = <gkenward@nortelnetworks.com>
> To: "'James Kempf'" = <kempf@docomolabs-usa.com>; <seamoby@ietf.org>
> Sent: Tuesday, July 09, 2002 12:50 PM
> Subject: RE: [Seamoby] CT Requirements Comments = from IESG
>
>
> > James:
> >
> >   Sorry, but a small = clarification: I did not say that
> dynamic context
> > was rejected, I said that I recalled that = there was, at one time, a
> > requirement
> > that attempted to directly address dynamic = context and the
> need to update it
> >
> > and that requirement was eventually = removed. I think the
> reason was the
> > difficulty
> > in defining "dynamic" versus = "static" context, as Charlie
> outlines in his
> > response.
> >
> >   There is, however, a = requirement, 5.5, that speaks to
> context updates in
> > general:
> >
> > 5.5 Context Update and = Synchronization
> >
> > 5.5.1 The context transfer protocol MUST = be capable of updating
> >       = context information when it changes.
> >
> > 5.5.2 A context update MUST preserve the = integrity, and thus the
> >       = meaning, of the context at each receiving AR.
> >
> >    The context at the AR = actually supporting an MN's traffic will
> >    change with time. For = example, the MN may initiate new
> microflow(s),
> >    or discontinue existing = microflows. Any change of context at the
> >    supporting AR must be = replicated at those ARs that have already
> >    received context for = that MN.
> >
> > I am now wondering why this requirement = did not answer the
> IESGs concerns?
> > Possibly because it does not explicitly = mention "dynamic context" or
> > "dynamic
> > updates"?
> >
>
> I suspect that is it. What is = "meaning"?
>
>          = ;   jak
>
>

------_=_NextPart_001_01C2281B.4344D92E-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Wed Jul 10 10:14:43 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03634 for ; Wed, 10 Jul 2002 10:14:43 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA28859 for seamoby-archive@odin.ietf.org; Wed, 10 Jul 2002 10:15:38 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA27672; Wed, 10 Jul 2002 10:09:35 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA27631 for ; Wed, 10 Jul 2002 10:09:33 -0400 (EDT) Received: from zcars04f.ca.nortel.com (zcars04f.nortelnetworks.com [47.129.242.57]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03152 for ; Wed, 10 Jul 2002 10:08:38 -0400 (EDT) Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04f.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g6AE8UB20511; Wed, 10 Jul 2002 10:08:30 -0400 (EDT) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 10 Jul 2002 10:08:29 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA4BFD@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'James Kempf'" , seamoby@ietf.org Subject: RE: [Seamoby] CT Requirements Comments from IESG Date: Wed, 10 Jul 2002 10:08:28 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2281B.4344D92E" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C2281B.4344D92E Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Main Entry: mean=B7ing=20 Pronunciation: 'mE-ni[ng] Function: noun 4 a : the logical connotation of a word or phrase=20 ------------ I propose, for section 5.5.2, to replace "meaning" with=20 "original syntax and semantics", unless someone has a better idea. Gary > -----Original Message----- > From: James Kempf [mailto:kempf@docomolabs-usa.com] > Sent: July 9, 2002 16:56 > To: Kenward, Gary [WDLN2:AN10:EXCH]; seamoby@ietf.org > Subject: Re: [Seamoby] CT Requirements Comments from IESG >=20 >=20 >=20 > ----- Original Message -----=20 > From: "Gary Kenward" > To: "'James Kempf'" ; > Sent: Tuesday, July 09, 2002 12:50 PM > Subject: RE: [Seamoby] CT Requirements Comments from IESG >=20 >=20 > > James: > >=20 > > Sorry, but a small clarification: I did not say that=20 > dynamic context=20 > > was rejected, I said that I recalled that there was, at one time, a > > requirement > > that attempted to directly address dynamic context and the=20 > need to update it > >=20 > > and that requirement was eventually removed. I think the=20 > reason was the > > difficulty > > in defining "dynamic" versus "static" context, as Charlie=20 > outlines in his > > response. > >=20 > > There is, however, a requirement, 5.5, that speaks to=20 > context updates in > > general: > >=20 > > 5.5 Context Update and Synchronization > >=20 > > 5.5.1 The context transfer protocol MUST be capable of updating=20 > > context information when it changes. > >=20 > > 5.5.2 A context update MUST preserve the integrity, and thus the > > meaning, of the context at each receiving AR. > >=20 > > The context at the AR actually supporting an MN's traffic will > > change with time. For example, the MN may initiate new=20 > microflow(s), > > or discontinue existing microflows. Any change of context at the > > supporting AR must be replicated at those ARs that have already > > received context for that MN. > >=20 > > I am now wondering why this requirement did not answer the=20 > IESGs concerns? > > Possibly because it does not explicitly mention "dynamic context" = or > > "dynamic > > updates"?=20 > >=20 >=20 > I suspect that is it. What is "meaning"?=20 >=20 > jak=20 >=20 >=20 ------_=_NextPart_001_01C2281B.4344D92E Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Seamoby] CT Requirements Comments from IESG

Main Entry: mean=B7ing
Pronunciation: 'mE-ni[ng]
Function: noun

4 a : the logical connotation of a word or phrase =

------------

I propose, for section 5.5.2, to replace = "meaning" with
"original syntax and semantics", unless = someone has a better
idea.

Gary

> -----Original Message-----
> From: James Kempf [mailto:kempf@docomolabs-usa.com= ]
> Sent: July 9, 2002 16:56
> To: Kenward, Gary [WDLN2:AN10:EXCH]; = seamoby@ietf.org
> Subject: Re: [Seamoby] CT Requirements Comments = from IESG
>
>
>
> ----- Original Message -----
> From: "Gary Kenward" = <gkenward@nortelnetworks.com>
> To: "'James Kempf'" = <kempf@docomolabs-usa.com>; <seamoby@ietf.org>
> Sent: Tuesday, July 09, 2002 12:50 PM
> Subject: RE: [Seamoby] CT Requirements Comments = from IESG
>
>
> > James:
> >
> >   Sorry, but a small = clarification: I did not say that
> dynamic context
> > was rejected, I said that I recalled that = there was, at one time, a
> > requirement
> > that attempted to directly address dynamic = context and the
> need to update it
> >
> > and that requirement was eventually = removed. I think the
> reason was the
> > difficulty
> > in defining "dynamic" versus = "static" context, as Charlie
> outlines in his
> > response.
> >
> >   There is, however, a = requirement, 5.5, that speaks to
> context updates in
> > general:
> >
> > 5.5 Context Update and = Synchronization
> >
> > 5.5.1 The context transfer protocol MUST = be capable of updating
> >       = context information when it changes.
> >
> > 5.5.2 A context update MUST preserve the = integrity, and thus the
> >       = meaning, of the context at each receiving AR.
> >
> >    The context at the AR = actually supporting an MN's traffic will
> >    change with time. For = example, the MN may initiate new
> microflow(s),
> >    or discontinue existing = microflows. Any change of context at the
> >    supporting AR must be = replicated at those ARs that have already
> >    received context for = that MN.
> >
> > I am now wondering why this requirement = did not answer the
> IESGs concerns?
> > Possibly because it does not explicitly = mention "dynamic context" or
> > "dynamic
> > updates"?
> >
>
> I suspect that is it. What is = "meaning"?
>
>          = ;   jak
>
>

------_=_NextPart_001_01C2281B.4344D92E-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Jul 10 11:41:43 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07666 for ; Wed, 10 Jul 2002 11:41:43 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA09341; Wed, 10 Jul 2002 11:39:09 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA09302 for ; Wed, 10 Jul 2002 11:39:07 -0400 (EDT) Received: from excite.com (sdn-ap-008neomahP0389.dialsprint.net [63.189.9.135]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA07413 for ; Wed, 10 Jul 2002 11:38:10 -0400 (EDT) Message-Id: <200207101538.LAA07413@ietf.org> From: "BeeSold" To: Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Date: Wed, 10 Jul 2002 08:39:39 -0700 Content-Transfer-Encoding: 8bit Subject: [Seamoby] BeeSold.com -Your Online Auction House Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 8bit BeeSold.com - Your Online Auction House Tired of high prices on ebay.com ? Try the free auction listings at http://www.beesold.com FREE $20 Sign up Credit! 10,000 Page Views a week! Dont wait! Register today! http://www.beesold.com #This is not a mailing list - You will not be mailed again# _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Wed Jul 10 11:41:43 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07672 for ; Wed, 10 Jul 2002 11:41:43 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA09722 for seamoby-archive@odin.ietf.org; Wed, 10 Jul 2002 11:42:38 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA09341; Wed, 10 Jul 2002 11:39:09 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA09302 for ; Wed, 10 Jul 2002 11:39:07 -0400 (EDT) Received: from excite.com (sdn-ap-008neomahP0389.dialsprint.net [63.189.9.135]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA07413 for ; Wed, 10 Jul 2002 11:38:10 -0400 (EDT) Message-Id: <200207101538.LAA07413@ietf.org> From: "BeeSold" To: Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Date: Wed, 10 Jul 2002 08:39:39 -0700 Content-Transfer-Encoding: 8bit Subject: [Seamoby] BeeSold.com -Your Online Auction House Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 8bit BeeSold.com - Your Online Auction House Tired of high prices on ebay.com ? Try the free auction listings at http://www.beesold.com FREE $20 Sign up Credit! 10,000 Page Views a week! Dont wait! Register today! http://www.beesold.com #This is not a mailing list - You will not be mailed again# _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Jul 10 12:17:44 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09549 for ; Wed, 10 Jul 2002 12:17:44 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA15379; Wed, 10 Jul 2002 12:10:58 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA15344 for ; Wed, 10 Jul 2002 12:10:56 -0400 (EDT) Received: from fridge.docomolabs-usa.com (fwuser@key1.docomolabs-usa.com [216.98.102.225]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09057 for ; Wed, 10 Jul 2002 12:10:02 -0400 (EDT) Message-ID: <008d01c2282c$23061b30$4f6015ac@T23KEMPF> From: "James Kempf" To: "Gary Kenward" , References: <9FBD322B7824D511B36900508BF93C9C01AA4BFD@zcard031.ca.nortel.com> Subject: Re: [Seamoby] CT Requirements Comments from IESG Date: Wed, 10 Jul 2002 09:09:14 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 8bit Hmm. So since there is no natural language conversation going on between these two routers, may I suggest that "meaning" is not a sufficiently precise word to use in this context? How about something along the lines of "usable to establish services on the new router" or something like that. jak ----- Original Message ----- From: "Gary Kenward" To: "'James Kempf'" ; Sent: Wednesday, July 10, 2002 7:08 AM Subject: RE: [Seamoby] CT Requirements Comments from IESG Main Entry: mean·ing Pronunciation: 'mE-ni[ng] Function: noun 4 a : the logical connotation of a word or phrase ------------ I propose, for section 5.5.2, to replace "meaning" with "original syntax and semantics", unless someone has a better idea. Gary > -----Original Message----- > From: James Kempf [mailto:kempf@docomolabs-usa.com] > Sent: July 9, 2002 16:56 > To: Kenward, Gary [WDLN2:AN10:EXCH]; seamoby@ietf.org > Subject: Re: [Seamoby] CT Requirements Comments from IESG > > > > ----- Original Message ----- > From: "Gary Kenward" > To: "'James Kempf'" ; > Sent: Tuesday, July 09, 2002 12:50 PM > Subject: RE: [Seamoby] CT Requirements Comments from IESG > > > > James: > > > > Sorry, but a small clarification: I did not say that > dynamic context > > was rejected, I said that I recalled that there was, at one time, a > > requirement > > that attempted to directly address dynamic context and the > need to update it > > > > and that requirement was eventually removed. I think the > reason was the > > difficulty > > in defining "dynamic" versus "static" context, as Charlie > outlines in his > > response. > > > > There is, however, a requirement, 5.5, that speaks to > context updates in > > general: > > > > 5.5 Context Update and Synchronization > > > > 5.5.1 The context transfer protocol MUST be capable of updating > > context information when it changes. > > > > 5.5.2 A context update MUST preserve the integrity, and thus the > > meaning, of the context at each receiving AR. > > > > The context at the AR actually supporting an MN's traffic will > > change with time. For example, the MN may initiate new > microflow(s), > > or discontinue existing microflows. Any change of context at the > > supporting AR must be replicated at those ARs that have already > > received context for that MN. > > > > I am now wondering why this requirement did not answer the > IESGs concerns? > > Possibly because it does not explicitly mention "dynamic context" or > > "dynamic > > updates"? > > > > I suspect that is it. What is "meaning"? > > jak > > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Jul 10 13:05:09 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11350 for ; Wed, 10 Jul 2002 13:05:08 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA20239; Wed, 10 Jul 2002 12:59:21 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA20206 for ; Wed, 10 Jul 2002 12:59:19 -0400 (EDT) Received: from zcars04e.ca.nortel.com (zcars04e.nortelnetworks.com [47.129.242.56]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11118 for ; Wed, 10 Jul 2002 12:58:24 -0400 (EDT) Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g6AGwci15419; Wed, 10 Jul 2002 12:58:39 -0400 (EDT) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 10 Jul 2002 12:58:38 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA4BFF@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'James Kempf'" , seamoby@ietf.org Subject: RE: [Seamoby] CT Requirements Comments from IESG Date: Wed, 10 Jul 2002 12:58:34 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C22833.067B52C6" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C22833.067B52C6 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable What does natural language have to do with it? I am not a linguist, but information representations have=20 syntax and semantics (and as a result, they have meaning, at the very least one would assume, to the originator of=20 the information). 'useable' on the other hand, is a wide open term, that could be interpreted strictly (i.e. the information has to exactly conformant to the requirements for configuration of the destination router), or very loosely (i.e. "null" information could be interpreted as "useable", in the trivial sense). In other words, there would be no requirement. The intent of this requirement, which went through much debate over the meaning of "integrity", is that the CT protocol must=20 preserve what was sent by the source. For me, stating that the = integrity=20 of the information was preserved was enough. The wg decided that "meaning" had to be preserved. I cannot think of an example where, if one preserves the syntax and=20 the symbol values (i.e. the "bits") of a given piece of information, the semantics would be lost. But then, I'm not a linguist. Said another way, the bits of the payload of the CT protocol must=20 arrive in the order they were sent, and without any errors. Whether the receiving AR can understand what the sender sent is not a CT issue. CT just transfers the context, it does not define it. Thus, it is not required that the CT protocol ensure "useability" at the = destination. That is a problem for the source. The analogy would be a requirement = that TCP ensure that the application could interpret the payload delivered = to it. It's always perplexed me why this simple, and somewhat obvious = requirement, has been subject to so much controversy. Gary > -----Original Message----- > From: James Kempf [mailto:kempf@docomolabs-usa.com] > Sent: July 10, 2002 12:09 > To: Kenward, Gary [WDLN2:AN10:EXCH]; seamoby@ietf.org > Subject: Re: [Seamoby] CT Requirements Comments from IESG >=20 >=20 > Hmm. >=20 > So since there is no natural language conversation going on=20 > between these two routers, may I suggest that "meaning" is not a > sufficiently precise word to use in this context? >=20 > How about something along the lines of "usable to establish=20 > services on the new router" or something like that. >=20 > jak >=20 > ----- Original Message ----- > From: "Gary Kenward" > To: "'James Kempf'" ; > Sent: Wednesday, July 10, 2002 7:08 AM > Subject: RE: [Seamoby] CT Requirements Comments from IESG >=20 >=20 > Main Entry: mean=B7ing > Pronunciation: 'mE-ni[ng] > Function: noun >=20 > 4 a : the logical connotation of a word or phrase >=20 > ------------ >=20 > I propose, for section 5.5.2, to replace "meaning" with > "original syntax and semantics", unless someone has a better > idea. >=20 > Gary >=20 *snip* > > > > > > > I suspect that is it. What is "meaning"? > > > > jak > > > > >=20 >=20 >=20 ------_=_NextPart_001_01C22833.067B52C6 Content-Type: text/html; charset="iso-8859-1" RE: [Seamoby] CT Requirements Comments from IESG

What does natural language have to do with it?
I am not a linguist, but information representations have
syntax and semantics (and as a result, they have meaning,
at the very least one would assume, to the originator of
the information).

'useable' on the other hand, is a wide open term, that could
be interpreted strictly (i.e. the information has to exactly
conformant to the requirements for configuration of the destination
router), or very loosely (i.e. "null" information could be
interpreted as "useable", in the trivial sense). In other words,
there would be no requirement.

The intent of this requirement, which went through much debate
over the meaning of "integrity", is that the CT protocol must
preserve what was sent by the source. For me, stating that the integrity
of the information was preserved was enough. The wg decided that
"meaning" had to be preserved.

I cannot think of an example where, if one preserves the syntax and
the symbol values (i.e. the "bits") of a given piece of information,
the semantics would be lost. But then, I'm not a linguist.

Said another way, the bits of the payload of the CT protocol must
arrive in the order they were sent, and without any errors. Whether
the receiving AR can understand what the sender sent is not a CT
issue. CT just transfers the context, it does not define it. Thus, it
is not required that the CT protocol ensure "useability" at the destination.
That is a problem for the source. The analogy would be a requirement that
TCP ensure that the application could interpret the payload delivered to it.

It's always perplexed me why this simple, and somewhat obvious requirement,
has been subject to so much controversy.

Gary

> -----Original Message-----
> From: James Kempf [mailto:kempf@docomolabs-usa.com]
> Sent: July 10, 2002 12:09
> To: Kenward, Gary [WDLN2:AN10:EXCH]; seamoby@ietf.org
> Subject: Re: [Seamoby] CT Requirements Comments from IESG
>
>
> Hmm.
>
> So since there is no natural language conversation going on
> between these two routers, may I suggest that "meaning" is not a
> sufficiently precise word to use in this context?
>
> How about something along the lines of "usable to establish
> services on the new router" or something like that.
>
>             jak
>
> ----- Original Message -----
> From: "Gary Kenward" <gkenward@nortelnetworks.com>
> To: "'James Kempf'" <kempf@docomolabs-usa.com>; <seamoby@ietf.org>
> Sent: Wednesday, July 10, 2002 7:08 AM
> Subject: RE: [Seamoby] CT Requirements Comments from IESG
>
>
> Main Entry: mean·ing
> Pronunciation: 'mE-ni[ng]
> Function: noun
>
> 4 a : the logical connotation of a word or phrase
>
> ------------
>
> I propose, for section 5.5.2, to replace "meaning" with
> "original syntax and semantics", unless someone has a better
> idea.
>
> Gary
>
*snip*
> > >
> >
> > I suspect that is it. What is "meaning"?
> >
> >             jak
> >
> >
>
>
>

------_=_NextPart_001_01C22833.067B52C6-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Wed Jul 10 13:05:09 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11358 for ; Wed, 10 Jul 2002 13:05:09 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA21218 for seamoby-archive@odin.ietf.org; Wed, 10 Jul 2002 13:06:03 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA20239; Wed, 10 Jul 2002 12:59:21 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA20206 for ; Wed, 10 Jul 2002 12:59:19 -0400 (EDT) Received: from zcars04e.ca.nortel.com (zcars04e.nortelnetworks.com [47.129.242.56]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11118 for ; Wed, 10 Jul 2002 12:58:24 -0400 (EDT) Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g6AGwci15419; Wed, 10 Jul 2002 12:58:39 -0400 (EDT) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 10 Jul 2002 12:58:38 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA4BFF@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'James Kempf'" , seamoby@ietf.org Subject: RE: [Seamoby] CT Requirements Comments from IESG Date: Wed, 10 Jul 2002 12:58:34 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C22833.067B52C6" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C22833.067B52C6 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable What does natural language have to do with it? I am not a linguist, but information representations have=20 syntax and semantics (and as a result, they have meaning, at the very least one would assume, to the originator of=20 the information). 'useable' on the other hand, is a wide open term, that could be interpreted strictly (i.e. the information has to exactly conformant to the requirements for configuration of the destination router), or very loosely (i.e. "null" information could be interpreted as "useable", in the trivial sense). In other words, there would be no requirement. The intent of this requirement, which went through much debate over the meaning of "integrity", is that the CT protocol must=20 preserve what was sent by the source. For me, stating that the = integrity=20 of the information was preserved was enough. The wg decided that "meaning" had to be preserved. I cannot think of an example where, if one preserves the syntax and=20 the symbol values (i.e. the "bits") of a given piece of information, the semantics would be lost. But then, I'm not a linguist. Said another way, the bits of the payload of the CT protocol must=20 arrive in the order they were sent, and without any errors. Whether the receiving AR can understand what the sender sent is not a CT issue. CT just transfers the context, it does not define it. Thus, it is not required that the CT protocol ensure "useability" at the = destination. That is a problem for the source. The analogy would be a requirement = that TCP ensure that the application could interpret the payload delivered = to it. It's always perplexed me why this simple, and somewhat obvious = requirement, has been subject to so much controversy. Gary > -----Original Message----- > From: James Kempf [mailto:kempf@docomolabs-usa.com] > Sent: July 10, 2002 12:09 > To: Kenward, Gary [WDLN2:AN10:EXCH]; seamoby@ietf.org > Subject: Re: [Seamoby] CT Requirements Comments from IESG >=20 >=20 > Hmm. >=20 > So since there is no natural language conversation going on=20 > between these two routers, may I suggest that "meaning" is not a > sufficiently precise word to use in this context? >=20 > How about something along the lines of "usable to establish=20 > services on the new router" or something like that. >=20 > jak >=20 > ----- Original Message ----- > From: "Gary Kenward" > To: "'James Kempf'" ; > Sent: Wednesday, July 10, 2002 7:08 AM > Subject: RE: [Seamoby] CT Requirements Comments from IESG >=20 >=20 > Main Entry: mean=B7ing > Pronunciation: 'mE-ni[ng] > Function: noun >=20 > 4 a : the logical connotation of a word or phrase >=20 > ------------ >=20 > I propose, for section 5.5.2, to replace "meaning" with > "original syntax and semantics", unless someone has a better > idea. >=20 > Gary >=20 *snip* > > > > > > > I suspect that is it. What is "meaning"? > > > > jak > > > > >=20 >=20 >=20 ------_=_NextPart_001_01C22833.067B52C6 Content-Type: text/html; charset="iso-8859-1" RE: [Seamoby] CT Requirements Comments from IESG

What does natural language have to do with it?
I am not a linguist, but information representations have
syntax and semantics (and as a result, they have meaning,
at the very least one would assume, to the originator of
the information).

'useable' on the other hand, is a wide open term, that could
be interpreted strictly (i.e. the information has to exactly
conformant to the requirements for configuration of the destination
router), or very loosely (i.e. "null" information could be
interpreted as "useable", in the trivial sense). In other words,
there would be no requirement.

The intent of this requirement, which went through much debate
over the meaning of "integrity", is that the CT protocol must
preserve what was sent by the source. For me, stating that the integrity
of the information was preserved was enough. The wg decided that
"meaning" had to be preserved.

I cannot think of an example where, if one preserves the syntax and
the symbol values (i.e. the "bits") of a given piece of information,
the semantics would be lost. But then, I'm not a linguist.

Said another way, the bits of the payload of the CT protocol must
arrive in the order they were sent, and without any errors. Whether
the receiving AR can understand what the sender sent is not a CT
issue. CT just transfers the context, it does not define it. Thus, it
is not required that the CT protocol ensure "useability" at the destination.
That is a problem for the source. The analogy would be a requirement that
TCP ensure that the application could interpret the payload delivered to it.

It's always perplexed me why this simple, and somewhat obvious requirement,
has been subject to so much controversy.

Gary

> -----Original Message-----
> From: James Kempf [mailto:kempf@docomolabs-usa.com]
> Sent: July 10, 2002 12:09
> To: Kenward, Gary [WDLN2:AN10:EXCH]; seamoby@ietf.org
> Subject: Re: [Seamoby] CT Requirements Comments from IESG
>
>
> Hmm.
>
> So since there is no natural language conversation going on
> between these two routers, may I suggest that "meaning" is not a
> sufficiently precise word to use in this context?
>
> How about something along the lines of "usable to establish
> services on the new router" or something like that.
>
>             jak
>
> ----- Original Message -----
> From: "Gary Kenward" <gkenward@nortelnetworks.com>
> To: "'James Kempf'" <kempf@docomolabs-usa.com>; <seamoby@ietf.org>
> Sent: Wednesday, July 10, 2002 7:08 AM
> Subject: RE: [Seamoby] CT Requirements Comments from IESG
>
>
> Main Entry: mean·ing
> Pronunciation: 'mE-ni[ng]
> Function: noun
>
> 4 a : the logical connotation of a word or phrase
>
> ------------
>
> I propose, for section 5.5.2, to replace "meaning" with
> "original syntax and semantics", unless someone has a better
> idea.
>
> Gary
>
*snip*
> > >
> >
> > I suspect that is it. What is "meaning"?
> >
> >             jak
> >
> >
>
>
>

------_=_NextPart_001_01C22833.067B52C6-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Wed Jul 10 13:10:39 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09557 for ; Wed, 10 Jul 2002 12:17:44 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA16376 for seamoby-archive@odin.ietf.org; Wed, 10 Jul 2002 12:18:38 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA15379; Wed, 10 Jul 2002 12:10:58 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA15344 for ; Wed, 10 Jul 2002 12:10:56 -0400 (EDT) Received: from fridge.docomolabs-usa.com (fwuser@key1.docomolabs-usa.com [216.98.102.225]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09057 for ; Wed, 10 Jul 2002 12:10:02 -0400 (EDT) Message-ID: <008d01c2282c$23061b30$4f6015ac@T23KEMPF> From: "James Kempf" To: "Gary Kenward" , References: <9FBD322B7824D511B36900508BF93C9C01AA4BFD@zcard031.ca.nortel.com> Subject: Re: [Seamoby] CT Requirements Comments from IESG Date: Wed, 10 Jul 2002 09:09:14 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 8bit Hmm. So since there is no natural language conversation going on between these two routers, may I suggest that "meaning" is not a sufficiently precise word to use in this context? How about something along the lines of "usable to establish services on the new router" or something like that. jak ----- Original Message ----- From: "Gary Kenward" To: "'James Kempf'" ; Sent: Wednesday, July 10, 2002 7:08 AM Subject: RE: [Seamoby] CT Requirements Comments from IESG Main Entry: mean·ing Pronunciation: 'mE-ni[ng] Function: noun 4 a : the logical connotation of a word or phrase ------------ I propose, for section 5.5.2, to replace "meaning" with "original syntax and semantics", unless someone has a better idea. Gary > -----Original Message----- > From: James Kempf [mailto:kempf@docomolabs-usa.com] > Sent: July 9, 2002 16:56 > To: Kenward, Gary [WDLN2:AN10:EXCH]; seamoby@ietf.org > Subject: Re: [Seamoby] CT Requirements Comments from IESG > > > > ----- Original Message ----- > From: "Gary Kenward" > To: "'James Kempf'" ; > Sent: Tuesday, July 09, 2002 12:50 PM > Subject: RE: [Seamoby] CT Requirements Comments from IESG > > > > James: > > > > Sorry, but a small clarification: I did not say that > dynamic context > > was rejected, I said that I recalled that there was, at one time, a > > requirement > > that attempted to directly address dynamic context and the > need to update it > > > > and that requirement was eventually removed. I think the > reason was the > > difficulty > > in defining "dynamic" versus "static" context, as Charlie > outlines in his > > response. > > > > There is, however, a requirement, 5.5, that speaks to > context updates in > > general: > > > > 5.5 Context Update and Synchronization > > > > 5.5.1 The context transfer protocol MUST be capable of updating > > context information when it changes. > > > > 5.5.2 A context update MUST preserve the integrity, and thus the > > meaning, of the context at each receiving AR. > > > > The context at the AR actually supporting an MN's traffic will > > change with time. For example, the MN may initiate new > microflow(s), > > or discontinue existing microflows. Any change of context at the > > supporting AR must be replicated at those ARs that have already > > received context for that MN. > > > > I am now wondering why this requirement did not answer the > IESGs concerns? > > Possibly because it does not explicitly mention "dynamic context" or > > "dynamic > > updates"? > > > > I suspect that is it. What is "meaning"? > > jak > > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Jul 10 14:16:59 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14091 for ; Wed, 10 Jul 2002 14:16:59 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA26770; Wed, 10 Jul 2002 14:14:59 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA26739 for ; Wed, 10 Jul 2002 14:14:57 -0400 (EDT) Received: from fridge.docomolabs-usa.com (fwuser@key1.docomolabs-usa.com [216.98.102.225]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13924 for ; Wed, 10 Jul 2002 14:14:03 -0400 (EDT) Message-ID: <012401c2283d$4d237280$4f6015ac@T23KEMPF> From: "James Kempf" To: "Gary Kenward" , References: <9FBD322B7824D511B36900508BF93C9C01AA4BFF@zcard031.ca.nortel.com> Subject: Re: [Seamoby] CT Requirements Comments from IESG Date: Wed, 10 Jul 2002 11:12:07 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 8bit "Word" or "phrase", from the definition you cite, typically applies to natural language. I have not heard anyone use that terminology for machine readable information, even in programming languages. jak ----- Original Message ----- From: "Gary Kenward" To: "'James Kempf'" ; Sent: Wednesday, July 10, 2002 9:58 AM Subject: RE: [Seamoby] CT Requirements Comments from IESG What does natural language have to do with it? I am not a linguist, but information representations have syntax and semantics (and as a result, they have meaning, at the very least one would assume, to the originator of the information). 'useable' on the other hand, is a wide open term, that could be interpreted strictly (i.e. the information has to exactly conformant to the requirements for configuration of the destination router), or very loosely (i.e. "null" information could be interpreted as "useable", in the trivial sense). In other words, there would be no requirement. The intent of this requirement, which went through much debate over the meaning of "integrity", is that the CT protocol must preserve what was sent by the source. For me, stating that the integrity of the information was preserved was enough. The wg decided that "meaning" had to be preserved. I cannot think of an example where, if one preserves the syntax and the symbol values (i.e. the "bits") of a given piece of information, the semantics would be lost. But then, I'm not a linguist. Said another way, the bits of the payload of the CT protocol must arrive in the order they were sent, and without any errors. Whether the receiving AR can understand what the sender sent is not a CT issue. CT just transfers the context, it does not define it. Thus, it is not required that the CT protocol ensure "useability" at the destination. That is a problem for the source. The analogy would be a requirement that TCP ensure that the application could interpret the payload delivered to it. It's always perplexed me why this simple, and somewhat obvious requirement, has been subject to so much controversy. Gary > -----Original Message----- > From: James Kempf [mailto:kempf@docomolabs-usa.com] > Sent: July 10, 2002 12:09 > To: Kenward, Gary [WDLN2:AN10:EXCH]; seamoby@ietf.org > Subject: Re: [Seamoby] CT Requirements Comments from IESG > > > Hmm. > > So since there is no natural language conversation going on > between these two routers, may I suggest that "meaning" is not a > sufficiently precise word to use in this context? > > How about something along the lines of "usable to establish > services on the new router" or something like that. > > jak > > ----- Original Message ----- > From: "Gary Kenward" > To: "'James Kempf'" ; > Sent: Wednesday, July 10, 2002 7:08 AM > Subject: RE: [Seamoby] CT Requirements Comments from IESG > > > Main Entry: mean·ing > Pronunciation: 'mE-ni[ng] > Function: noun > > 4 a : the logical connotation of a word or phrase > > ------------ > > I propose, for section 5.5.2, to replace "meaning" with > "original syntax and semantics", unless someone has a better > idea. > > Gary > *snip* > > > > > > > I suspect that is it. What is "meaning"? > > > > jak > > > > > > > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Wed Jul 10 14:17:00 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14098 for ; Wed, 10 Jul 2002 14:16:59 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA27191 for seamoby-archive@odin.ietf.org; Wed, 10 Jul 2002 14:17:52 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA26770; Wed, 10 Jul 2002 14:14:59 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA26739 for ; Wed, 10 Jul 2002 14:14:57 -0400 (EDT) Received: from fridge.docomolabs-usa.com (fwuser@key1.docomolabs-usa.com [216.98.102.225]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13924 for ; Wed, 10 Jul 2002 14:14:03 -0400 (EDT) Message-ID: <012401c2283d$4d237280$4f6015ac@T23KEMPF> From: "James Kempf" To: "Gary Kenward" , References: <9FBD322B7824D511B36900508BF93C9C01AA4BFF@zcard031.ca.nortel.com> Subject: Re: [Seamoby] CT Requirements Comments from IESG Date: Wed, 10 Jul 2002 11:12:07 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 8bit "Word" or "phrase", from the definition you cite, typically applies to natural language. I have not heard anyone use that terminology for machine readable information, even in programming languages. jak ----- Original Message ----- From: "Gary Kenward" To: "'James Kempf'" ; Sent: Wednesday, July 10, 2002 9:58 AM Subject: RE: [Seamoby] CT Requirements Comments from IESG What does natural language have to do with it? I am not a linguist, but information representations have syntax and semantics (and as a result, they have meaning, at the very least one would assume, to the originator of the information). 'useable' on the other hand, is a wide open term, that could be interpreted strictly (i.e. the information has to exactly conformant to the requirements for configuration of the destination router), or very loosely (i.e. "null" information could be interpreted as "useable", in the trivial sense). In other words, there would be no requirement. The intent of this requirement, which went through much debate over the meaning of "integrity", is that the CT protocol must preserve what was sent by the source. For me, stating that the integrity of the information was preserved was enough. The wg decided that "meaning" had to be preserved. I cannot think of an example where, if one preserves the syntax and the symbol values (i.e. the "bits") of a given piece of information, the semantics would be lost. But then, I'm not a linguist. Said another way, the bits of the payload of the CT protocol must arrive in the order they were sent, and without any errors. Whether the receiving AR can understand what the sender sent is not a CT issue. CT just transfers the context, it does not define it. Thus, it is not required that the CT protocol ensure "useability" at the destination. That is a problem for the source. The analogy would be a requirement that TCP ensure that the application could interpret the payload delivered to it. It's always perplexed me why this simple, and somewhat obvious requirement, has been subject to so much controversy. Gary > -----Original Message----- > From: James Kempf [mailto:kempf@docomolabs-usa.com] > Sent: July 10, 2002 12:09 > To: Kenward, Gary [WDLN2:AN10:EXCH]; seamoby@ietf.org > Subject: Re: [Seamoby] CT Requirements Comments from IESG > > > Hmm. > > So since there is no natural language conversation going on > between these two routers, may I suggest that "meaning" is not a > sufficiently precise word to use in this context? > > How about something along the lines of "usable to establish > services on the new router" or something like that. > > jak > > ----- Original Message ----- > From: "Gary Kenward" > To: "'James Kempf'" ; > Sent: Wednesday, July 10, 2002 7:08 AM > Subject: RE: [Seamoby] CT Requirements Comments from IESG > > > Main Entry: mean·ing > Pronunciation: 'mE-ni[ng] > Function: noun > > 4 a : the logical connotation of a word or phrase > > ------------ > > I propose, for section 5.5.2, to replace "meaning" with > "original syntax and semantics", unless someone has a better > idea. > > Gary > *snip* > > > > > > > I suspect that is it. What is "meaning"? > > > > jak > > > > > > > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Jul 10 14:33:21 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14693 for ; Wed, 10 Jul 2002 14:33:21 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA28471; Wed, 10 Jul 2002 14:32:01 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA28436 for ; Wed, 10 Jul 2002 14:31:58 -0400 (EDT) Received: from zcars04e.ca.nortel.com (zcars04e.nortelnetworks.com [47.129.242.56]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14661 for ; Wed, 10 Jul 2002 14:31:05 -0400 (EDT) Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g6AIVNi02390; Wed, 10 Jul 2002 14:31:23 -0400 (EDT) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 10 Jul 2002 14:31:23 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA4C01@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'James Kempf'" , seamoby@ietf.org Subject: RE: [Seamoby] CT Requirements Comments from IESG Date: Wed, 10 Jul 2002 14:31:18 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2283F.A10DD848" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C2283F.A10DD848 Content-Type: text/plain; charset="iso-8859-1" A word is often defined as 4 bytes, or 32 bits :-) in many computational architectures and programming languages. Neither here nor there, really. I'll wait for further suggestions/comments on the working of 5.5.2 from the wg. Gary > -----Original Message----- > From: James Kempf [mailto:kempf@docomolabs-usa.com] > Sent: July 10, 2002 14:12 > To: Kenward, Gary [WDLN2:AN10:EXCH]; seamoby@ietf.org > Subject: Re: [Seamoby] CT Requirements Comments from IESG > > > "Word" or "phrase", from the definition you cite, typically > applies to natural language. I have not heard anyone use that > terminology for machine readable information, even in > programming languages. > > jak > > ----- Original Message ----- > From: "Gary Kenward" > To: "'James Kempf'" ; > Sent: Wednesday, July 10, 2002 9:58 AM > Subject: RE: [Seamoby] CT Requirements Comments from IESG > > *snip* > ------_=_NextPart_001_01C2283F.A10DD848 Content-Type: text/html; charset="iso-8859-1" RE: [Seamoby] CT Requirements Comments from IESG

A word is often defined as 4 bytes, or 32 bits :-) in many
computational architectures and programming languages.

Neither here nor there, really. I'll wait for further
suggestions/comments on the working of 5.5.2 from the wg.

Gary

> -----Original Message-----
> From: James Kempf [mailto:kempf@docomolabs-usa.com]
> Sent: July 10, 2002 14:12
> To: Kenward, Gary [WDLN2:AN10:EXCH]; seamoby@ietf.org
> Subject: Re: [Seamoby] CT Requirements Comments from IESG
>
>
> "Word" or "phrase", from the definition you cite, typically
> applies to natural language. I have not heard anyone use that
> terminology for machine readable information, even in
> programming languages.
>
>             jak
>
> ----- Original Message -----
> From: "Gary Kenward" <gkenward@nortelnetworks.com>
> To: "'James Kempf'" <kempf@docomolabs-usa.com>; <seamoby@ietf.org>
> Sent: Wednesday, July 10, 2002 9:58 AM
> Subject: RE: [Seamoby] CT Requirements Comments from IESG
>
>

*snip*

>

------_=_NextPart_001_01C2283F.A10DD848-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Wed Jul 10 14:33:22 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14702 for ; Wed, 10 Jul 2002 14:33:21 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA28551 for seamoby-archive@odin.ietf.org; Wed, 10 Jul 2002 14:34:14 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA28471; Wed, 10 Jul 2002 14:32:01 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA28436 for ; Wed, 10 Jul 2002 14:31:58 -0400 (EDT) Received: from zcars04e.ca.nortel.com (zcars04e.nortelnetworks.com [47.129.242.56]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14661 for ; Wed, 10 Jul 2002 14:31:05 -0400 (EDT) Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g6AIVNi02390; Wed, 10 Jul 2002 14:31:23 -0400 (EDT) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 10 Jul 2002 14:31:23 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA4C01@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'James Kempf'" , seamoby@ietf.org Subject: RE: [Seamoby] CT Requirements Comments from IESG Date: Wed, 10 Jul 2002 14:31:18 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2283F.A10DD848" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C2283F.A10DD848 Content-Type: text/plain; charset="iso-8859-1" A word is often defined as 4 bytes, or 32 bits :-) in many computational architectures and programming languages. Neither here nor there, really. I'll wait for further suggestions/comments on the working of 5.5.2 from the wg. Gary > -----Original Message----- > From: James Kempf [mailto:kempf@docomolabs-usa.com] > Sent: July 10, 2002 14:12 > To: Kenward, Gary [WDLN2:AN10:EXCH]; seamoby@ietf.org > Subject: Re: [Seamoby] CT Requirements Comments from IESG > > > "Word" or "phrase", from the definition you cite, typically > applies to natural language. I have not heard anyone use that > terminology for machine readable information, even in > programming languages. > > jak > > ----- Original Message ----- > From: "Gary Kenward" > To: "'James Kempf'" ; > Sent: Wednesday, July 10, 2002 9:58 AM > Subject: RE: [Seamoby] CT Requirements Comments from IESG > > *snip* > ------_=_NextPart_001_01C2283F.A10DD848 Content-Type: text/html; charset="iso-8859-1" RE: [Seamoby] CT Requirements Comments from IESG

A word is often defined as 4 bytes, or 32 bits :-) in many
computational architectures and programming languages.

Neither here nor there, really. I'll wait for further
suggestions/comments on the working of 5.5.2 from the wg.

Gary

> -----Original Message-----
> From: James Kempf [mailto:kempf@docomolabs-usa.com]
> Sent: July 10, 2002 14:12
> To: Kenward, Gary [WDLN2:AN10:EXCH]; seamoby@ietf.org
> Subject: Re: [Seamoby] CT Requirements Comments from IESG
>
>
> "Word" or "phrase", from the definition you cite, typically
> applies to natural language. I have not heard anyone use that
> terminology for machine readable information, even in
> programming languages.
>
>             jak
>
> ----- Original Message -----
> From: "Gary Kenward" <gkenward@nortelnetworks.com>
> To: "'James Kempf'" <kempf@docomolabs-usa.com>; <seamoby@ietf.org>
> Sent: Wednesday, July 10, 2002 9:58 AM
> Subject: RE: [Seamoby] CT Requirements Comments from IESG
>
>

*snip*

>

------_=_NextPart_001_01C2283F.A10DD848-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Jul 10 15:05:01 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15734 for ; Wed, 10 Jul 2002 15:05:01 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA29710; Wed, 10 Jul 2002 14:59:57 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA29648 for ; Wed, 10 Jul 2002 14:59:54 -0400 (EDT) Received: from motgate3.mot.com (motgate3.mot.com [144.189.100.103]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15489; Wed, 10 Jul 2002 14:59:00 -0400 (EDT) Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate3.mot.com (motgate3 2.1) with ESMTP id LAA20680; Wed, 10 Jul 2002 11:58:20 -0700 (MST)] Received: [from il75exm04.cig.mot.com ([136.182.110.113]) by mothost.mot.com (MOT-pobox 2.0) with ESMTP id LAA22816; Wed, 10 Jul 2002 11:59:25 -0700 (MST)] Received: by IL75EXM04 with Internet Mail Service (5.5.2654.52) id ; Wed, 10 Jul 2002 13:59:14 -0500 Message-ID: <35DBB8B7AC89D4118E98009027B1009B08AD5554@IL27EXM10.cig.mot.com> From: Nakhjiri Madjid-MNAKHJI1 To: "'James Kempf'" , Rajeev Koodli , Hemant.Chaskar@nokia.com Cc: gkenward@nortelnetworks.com, seamoby@ietf.org, nsis@ietf.org Subject: RE: [Seamoby] RE: [NSIS] Re: draft-westphal-nsis-qos-mobileip-00. txt Date: Wed, 10 Jul 2002 13:58:59 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.52) Content-Type: text/plain; charset="iso-8859-1" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org James, As much as I like to see a clean interaction between CT and NSIS, I don't see any reason why CT needs to play the role of NSIS optimization, not to forget the NSIS didn't even exist back then. CT is simply a tool you need in your seamless mobility toolbox, it eventually involved into a container carrying any context you like (even non-IP context, as long as it is feasible). The profile types, that Rajeev mentioned is aligned with this line of thinking. I seriously advise against going back and change CT requirements for the sake of optimizing NSIS, which at this point we don't know what it is. A couple of months from now, we have to revise CT because of a security related protocol, later for something else..... The later we wait for CT standardization, the more home brewed versions are going to pop up, just like Behcet mentioned. My 1.5 cents (lower dollars) Madjid -----Original Message----- From: James Kempf [mailto:kempf@docomolabs-usa.com] Sent: Monday, July 08, 2002 4:37 PM To: Rajeev Koodli; Hemant.Chaskar@nokia.com Cc: gkenward@nortelnetworks.com; seamoby@ietf.org; nsis@ietf.org Subject: Re: [Seamoby] RE: [NSIS] Re: draft-westphal-nsis-qos-mobileip-00.txt > CT is an optimization to avoid signaling and the associated overheads, and maintain > desirable transport (RTP/TCP)performance. A historical note: CT was not designed > to be an optimization for NSIS. > Do you mean that the requirements weren't so designed? Because, to my knowledge, the WG has not yet settled on a design. We are currently awaiting IESG feedback on our requirements. The problem statement was just approved by the IESG. jak _______________________________________________ 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 From daemon@optimus.ietf.org Wed Jul 10 15:05:02 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15739 for ; Wed, 10 Jul 2002 15:05:02 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA00506 for seamoby-archive@odin.ietf.org; Wed, 10 Jul 2002 15:05:55 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA29710; Wed, 10 Jul 2002 14:59:57 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA29648 for ; Wed, 10 Jul 2002 14:59:54 -0400 (EDT) Received: from motgate3.mot.com (motgate3.mot.com [144.189.100.103]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15489; Wed, 10 Jul 2002 14:59:00 -0400 (EDT) Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate3.mot.com (motgate3 2.1) with ESMTP id LAA20680; Wed, 10 Jul 2002 11:58:20 -0700 (MST)] Received: [from il75exm04.cig.mot.com ([136.182.110.113]) by mothost.mot.com (MOT-pobox 2.0) with ESMTP id LAA22816; Wed, 10 Jul 2002 11:59:25 -0700 (MST)] Received: by IL75EXM04 with Internet Mail Service (5.5.2654.52) id ; Wed, 10 Jul 2002 13:59:14 -0500 Message-ID: <35DBB8B7AC89D4118E98009027B1009B08AD5554@IL27EXM10.cig.mot.com> From: Nakhjiri Madjid-MNAKHJI1 To: "'James Kempf'" , Rajeev Koodli , Hemant.Chaskar@nokia.com Cc: gkenward@nortelnetworks.com, seamoby@ietf.org, nsis@ietf.org Subject: RE: [Seamoby] RE: [NSIS] Re: draft-westphal-nsis-qos-mobileip-00. txt Date: Wed, 10 Jul 2002 13:58:59 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.52) Content-Type: text/plain; charset="iso-8859-1" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org James, As much as I like to see a clean interaction between CT and NSIS, I don't see any reason why CT needs to play the role of NSIS optimization, not to forget the NSIS didn't even exist back then. CT is simply a tool you need in your seamless mobility toolbox, it eventually involved into a container carrying any context you like (even non-IP context, as long as it is feasible). The profile types, that Rajeev mentioned is aligned with this line of thinking. I seriously advise against going back and change CT requirements for the sake of optimizing NSIS, which at this point we don't know what it is. A couple of months from now, we have to revise CT because of a security related protocol, later for something else..... The later we wait for CT standardization, the more home brewed versions are going to pop up, just like Behcet mentioned. My 1.5 cents (lower dollars) Madjid -----Original Message----- From: James Kempf [mailto:kempf@docomolabs-usa.com] Sent: Monday, July 08, 2002 4:37 PM To: Rajeev Koodli; Hemant.Chaskar@nokia.com Cc: gkenward@nortelnetworks.com; seamoby@ietf.org; nsis@ietf.org Subject: Re: [Seamoby] RE: [NSIS] Re: draft-westphal-nsis-qos-mobileip-00.txt > CT is an optimization to avoid signaling and the associated overheads, and maintain > desirable transport (RTP/TCP)performance. A historical note: CT was not designed > to be an optimization for NSIS. > Do you mean that the requirements weren't so designed? Because, to my knowledge, the WG has not yet settled on a design. We are currently awaiting IESG feedback on our requirements. The problem statement was just approved by the IESG. jak _______________________________________________ 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 From seamoby-admin@ietf.org Wed Jul 10 15:10:39 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16013 for ; Wed, 10 Jul 2002 15:10:39 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA00595; Wed, 10 Jul 2002 15:07:25 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA00564 for ; Wed, 10 Jul 2002 15:07:23 -0400 (EDT) Received: from motgate3.mot.com (motgate3.mot.com [144.189.100.103]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15796 for ; Wed, 10 Jul 2002 15:06:29 -0400 (EDT) Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate3.mot.com (motgate3 2.1) with ESMTP id MAA25234 for ; Wed, 10 Jul 2002 12:06:26 -0700 (MST)] Received: [from il27exm07.cig.mot.com (IL27EXM07.cig.mot.com [136.182.15.116]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id MAA02686 for ; Wed, 10 Jul 2002 12:07:21 -0700 (MST)] Received: by IL27EXM07.cig.mot.com with Internet Mail Service (5.5.2654.52) id <3FLZTMWZ>; Wed, 10 Jul 2002 14:07:21 -0500 Message-ID: <35DBB8B7AC89D4118E98009027B1009B08AD5555@IL27EXM10.cig.mot.com> From: Nakhjiri Madjid-MNAKHJI1 To: "'Vijay Devarapalli'" , James Kempf Cc: seamoby@ietf.org Subject: RE: [Seamoby] CT Requirements Comments from IESG Date: Wed, 10 Jul 2002 14:07:19 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.52) Content-Type: text/plain Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org hi Jim, James Kempf wrote: > 2) The requirements say nothing about context which must be modified on the new router in order to be useful. An example is ROHC > context when the mobile obtains a new care of address. How would the CT protocol handle this? the context transfer protocol should not worry about this at all. it is specific to each feature. for ROHC, the IP addresses have to be changed. for IPsec Security Associations, the SPIs maybe need to be changed in addition to the IP addresses. Madjid>> I agree with both Charlie and Vijay. Also we are getting into solution space when asking this sort of questions. Our proposal (TEXT) which is based on BETH idea, deals with Rohc context very nicely. Madjid _______________________________________________ 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 From daemon@optimus.ietf.org Wed Jul 10 15:10:39 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16021 for ; Wed, 10 Jul 2002 15:10:39 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA00902 for seamoby-archive@odin.ietf.org; Wed, 10 Jul 2002 15:11:32 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA00595; Wed, 10 Jul 2002 15:07:25 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA00564 for ; Wed, 10 Jul 2002 15:07:23 -0400 (EDT) Received: from motgate3.mot.com (motgate3.mot.com [144.189.100.103]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15796 for ; Wed, 10 Jul 2002 15:06:29 -0400 (EDT) Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate3.mot.com (motgate3 2.1) with ESMTP id MAA25234 for ; Wed, 10 Jul 2002 12:06:26 -0700 (MST)] Received: [from il27exm07.cig.mot.com (IL27EXM07.cig.mot.com [136.182.15.116]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id MAA02686 for ; Wed, 10 Jul 2002 12:07:21 -0700 (MST)] Received: by IL27EXM07.cig.mot.com with Internet Mail Service (5.5.2654.52) id <3FLZTMWZ>; Wed, 10 Jul 2002 14:07:21 -0500 Message-ID: <35DBB8B7AC89D4118E98009027B1009B08AD5555@IL27EXM10.cig.mot.com> From: Nakhjiri Madjid-MNAKHJI1 To: "'Vijay Devarapalli'" , James Kempf Cc: seamoby@ietf.org Subject: RE: [Seamoby] CT Requirements Comments from IESG Date: Wed, 10 Jul 2002 14:07:19 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.52) Content-Type: text/plain Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org hi Jim, James Kempf wrote: > 2) The requirements say nothing about context which must be modified on the new router in order to be useful. An example is ROHC > context when the mobile obtains a new care of address. How would the CT protocol handle this? the context transfer protocol should not worry about this at all. it is specific to each feature. for ROHC, the IP addresses have to be changed. for IPsec Security Associations, the SPIs maybe need to be changed in addition to the IP addresses. Madjid>> I agree with both Charlie and Vijay. Also we are getting into solution space when asking this sort of questions. Our proposal (TEXT) which is based on BETH idea, deals with Rohc context very nicely. Madjid _______________________________________________ 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 From seamoby-admin@ietf.org Wed Jul 10 15:20:33 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16422 for ; Wed, 10 Jul 2002 15:20:33 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA01130; Wed, 10 Jul 2002 15:18:57 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA01101 for ; Wed, 10 Jul 2002 15:18:55 -0400 (EDT) Received: from motgate4.mot.com (motgate4.mot.com [144.189.100.102]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16368 for ; Wed, 10 Jul 2002 15:18:00 -0400 (EDT) Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate4.mot.com (motgate4 2.1) with ESMTP id MAA27110 for ; Wed, 10 Jul 2002 12:18:48 -0700 (MST)] Received: [from il75exm04.cig.mot.com ([136.182.110.113]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id MAA07075 for ; Wed, 10 Jul 2002 12:18:47 -0700 (MST)] Received: by IL75EXM04 with Internet Mail Service (5.5.2654.52) id ; Wed, 10 Jul 2002 14:18:47 -0500 Message-ID: <35DBB8B7AC89D4118E98009027B1009B08AD5556@IL27EXM10.cig.mot.com> From: Nakhjiri Madjid-MNAKHJI1 To: "'James Kempf'" , seamoby@ietf.org Subject: RE: [Seamoby] CT Requirements Comments from IESG Date: Wed, 10 Jul 2002 14:18:47 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.52) Content-Type: text/plain; charset="iso-8859-1" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org James, all, I think we are walking on a fine line between requirements and solutions. 1- It was decided long time ago that collection and drainage of context is not the job of context transfer protocol. whichever protocol entity injecting its states into the CT protocol is responsible for the freshness of context. We debated a lifetime field for each context, in case the context is dynamic, how you handle these sort of issues is completely in solution space. For requirement phase, again I say the freshness of context is the job of the protocol unit. Now you can argue that we don't have any reliability mechanisms (such as error protection and retransmissions) so after a couple of retries the context gets old, but again in the absence of reliability mechanisms only a life time mechanisms is the most the CT protocol can do. 2- Usefulness at the new AR is not CT's headache. Rohc is just one thing, different QoS policies, DSCP<->PHB/ service mapping are another, different security mechanisms are another. Negotiation is another. CT is not supposed to deal with adaptation, negotiation, remapping.... CT only transfers what it thinks is the same at both side. As far as Rohc goes, well change of IP address might change a lot of things, not just headers (QoS profile is one example, SPI is another, as Vijay mentioned). I don't think this is CT's problem. This is the problem of the protocol that uses CT for things that are not the same at both sides of handover. Regards, Madjid -----Original Message----- From: James Kempf [mailto:kempf@docomolabs-usa.com] Sent: Tuesday, July 09, 2002 12:22 PM To: seamoby@ietf.org Subject: [Seamoby] CT Requirements Comments from IESG I have finally managed to get a couple of technical comments out of the IESG on the CT requirements. More are coming but I think it might be worthwhile to start discussing these. 1) The requirements say nothing about the maintenance of dynamic context. Something must be said, is this out of scope or what? Gary tells me that supporting dynamic context was rejected by the working group, but it seems like we cannot punt on at least saying something about this issue. 2) The requirements say nothing about context which must be modified on the new router in order to be useful. An example is ROHC context when the mobile obtains a new care of address. How would the CT protocol handle this? I've asked Gary to lead a discussion on these two issues, please send comments to the list. jak _______________________________________________ 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 From daemon@optimus.ietf.org Wed Jul 10 15:20:34 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16430 for ; Wed, 10 Jul 2002 15:20:33 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA01183 for seamoby-archive@odin.ietf.org; Wed, 10 Jul 2002 15:21:27 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA01130; Wed, 10 Jul 2002 15:18:57 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA01101 for ; Wed, 10 Jul 2002 15:18:55 -0400 (EDT) Received: from motgate4.mot.com (motgate4.mot.com [144.189.100.102]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16368 for ; Wed, 10 Jul 2002 15:18:00 -0400 (EDT) Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate4.mot.com (motgate4 2.1) with ESMTP id MAA27110 for ; Wed, 10 Jul 2002 12:18:48 -0700 (MST)] Received: [from il75exm04.cig.mot.com ([136.182.110.113]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id MAA07075 for ; Wed, 10 Jul 2002 12:18:47 -0700 (MST)] Received: by IL75EXM04 with Internet Mail Service (5.5.2654.52) id ; Wed, 10 Jul 2002 14:18:47 -0500 Message-ID: <35DBB8B7AC89D4118E98009027B1009B08AD5556@IL27EXM10.cig.mot.com> From: Nakhjiri Madjid-MNAKHJI1 To: "'James Kempf'" , seamoby@ietf.org Subject: RE: [Seamoby] CT Requirements Comments from IESG Date: Wed, 10 Jul 2002 14:18:47 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.52) Content-Type: text/plain; charset="iso-8859-1" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org James, all, I think we are walking on a fine line between requirements and solutions. 1- It was decided long time ago that collection and drainage of context is not the job of context transfer protocol. whichever protocol entity injecting its states into the CT protocol is responsible for the freshness of context. We debated a lifetime field for each context, in case the context is dynamic, how you handle these sort of issues is completely in solution space. For requirement phase, again I say the freshness of context is the job of the protocol unit. Now you can argue that we don't have any reliability mechanisms (such as error protection and retransmissions) so after a couple of retries the context gets old, but again in the absence of reliability mechanisms only a life time mechanisms is the most the CT protocol can do. 2- Usefulness at the new AR is not CT's headache. Rohc is just one thing, different QoS policies, DSCP<->PHB/ service mapping are another, different security mechanisms are another. Negotiation is another. CT is not supposed to deal with adaptation, negotiation, remapping.... CT only transfers what it thinks is the same at both side. As far as Rohc goes, well change of IP address might change a lot of things, not just headers (QoS profile is one example, SPI is another, as Vijay mentioned). I don't think this is CT's problem. This is the problem of the protocol that uses CT for things that are not the same at both sides of handover. Regards, Madjid -----Original Message----- From: James Kempf [mailto:kempf@docomolabs-usa.com] Sent: Tuesday, July 09, 2002 12:22 PM To: seamoby@ietf.org Subject: [Seamoby] CT Requirements Comments from IESG I have finally managed to get a couple of technical comments out of the IESG on the CT requirements. More are coming but I think it might be worthwhile to start discussing these. 1) The requirements say nothing about the maintenance of dynamic context. Something must be said, is this out of scope or what? Gary tells me that supporting dynamic context was rejected by the working group, but it seems like we cannot punt on at least saying something about this issue. 2) The requirements say nothing about context which must be modified on the new router in order to be useful. An example is ROHC context when the mobile obtains a new care of address. How would the CT protocol handle this? I've asked Gary to lead a discussion on these two issues, please send comments to the list. jak _______________________________________________ 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 From seamoby-admin@ietf.org Wed Jul 10 18:16:01 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21929 for ; Wed, 10 Jul 2002 18:16:01 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA13274; Wed, 10 Jul 2002 18:13:36 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA13245 for ; Wed, 10 Jul 2002 18:13:34 -0400 (EDT) Received: from fridge.docomolabs-usa.com (fwuser@key1.docomolabs-usa.com [216.98.102.225]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21848 for ; Wed, 10 Jul 2002 18:12:39 -0400 (EDT) Message-ID: <017e01c2285e$c8c5d380$4f6015ac@T23KEMPF> From: "James Kempf" To: "Gary Kenward" , References: <9FBD322B7824D511B36900508BF93C9C01AA4C01@zcard031.ca.nortel.com> Subject: Re: [Seamoby] CT Requirements Comments from IESG Date: Wed, 10 Jul 2002 15:11:47 -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-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit It's not the same definition I suggest: 5.5.2 A context update MUST preserve the integrity, and thus the intended useability, of the context at each receiving AR. jak ----- Original Message ----- From: "Gary Kenward" To: "'James Kempf'" ; Sent: Wednesday, July 10, 2002 11:31 AM Subject: RE: [Seamoby] CT Requirements Comments from IESG > A word is often defined as 4 bytes, or 32 bits :-) in many > computational architectures and programming languages. > > Neither here nor there, really. I'll wait for further > suggestions/comments on the working of 5.5.2 from the wg. > > Gary > > > -----Original Message----- > > From: James Kempf [mailto:kempf@docomolabs-usa.com] > > Sent: July 10, 2002 14:12 > > To: Kenward, Gary [WDLN2:AN10:EXCH]; seamoby@ietf.org > > Subject: Re: [Seamoby] CT Requirements Comments from IESG > > > > > > "Word" or "phrase", from the definition you cite, typically > > applies to natural language. I have not heard anyone use that > > terminology for machine readable information, even in > > programming languages. > > > > jak > > > > ----- Original Message ----- > > From: "Gary Kenward" > > To: "'James Kempf'" ; > > Sent: Wednesday, July 10, 2002 9:58 AM > > Subject: RE: [Seamoby] CT Requirements Comments from IESG > > > > > > *snip* > > > > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Wed Jul 10 18:16:01 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21937 for ; Wed, 10 Jul 2002 18:16:01 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA13500 for seamoby-archive@odin.ietf.org; Wed, 10 Jul 2002 18:16:56 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA13274; Wed, 10 Jul 2002 18:13:36 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA13245 for ; Wed, 10 Jul 2002 18:13:34 -0400 (EDT) Received: from fridge.docomolabs-usa.com (fwuser@key1.docomolabs-usa.com [216.98.102.225]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21848 for ; Wed, 10 Jul 2002 18:12:39 -0400 (EDT) Message-ID: <017e01c2285e$c8c5d380$4f6015ac@T23KEMPF> From: "James Kempf" To: "Gary Kenward" , References: <9FBD322B7824D511B36900508BF93C9C01AA4C01@zcard031.ca.nortel.com> Subject: Re: [Seamoby] CT Requirements Comments from IESG Date: Wed, 10 Jul 2002 15:11:47 -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-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit It's not the same definition I suggest: 5.5.2 A context update MUST preserve the integrity, and thus the intended useability, of the context at each receiving AR. jak ----- Original Message ----- From: "Gary Kenward" To: "'James Kempf'" ; Sent: Wednesday, July 10, 2002 11:31 AM Subject: RE: [Seamoby] CT Requirements Comments from IESG > A word is often defined as 4 bytes, or 32 bits :-) in many > computational architectures and programming languages. > > Neither here nor there, really. I'll wait for further > suggestions/comments on the working of 5.5.2 from the wg. > > Gary > > > -----Original Message----- > > From: James Kempf [mailto:kempf@docomolabs-usa.com] > > Sent: July 10, 2002 14:12 > > To: Kenward, Gary [WDLN2:AN10:EXCH]; seamoby@ietf.org > > Subject: Re: [Seamoby] CT Requirements Comments from IESG > > > > > > "Word" or "phrase", from the definition you cite, typically > > applies to natural language. I have not heard anyone use that > > terminology for machine readable information, even in > > programming languages. > > > > jak > > > > ----- Original Message ----- > > From: "Gary Kenward" > > To: "'James Kempf'" ; > > Sent: Wednesday, July 10, 2002 9:58 AM > > Subject: RE: [Seamoby] CT Requirements Comments from IESG > > > > > > *snip* > > > > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Jul 10 18:19:41 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21994 for ; Wed, 10 Jul 2002 18:19:41 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA13483; Wed, 10 Jul 2002 18:16:53 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA13382 for ; Wed, 10 Jul 2002 18:16:47 -0400 (EDT) Received: from fridge.docomolabs-usa.com (fwuser@key1.docomolabs-usa.com [216.98.102.225]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21926; Wed, 10 Jul 2002 18:15:51 -0400 (EDT) Message-ID: <018a01c2285f$392d00d0$4f6015ac@T23KEMPF> From: "James Kempf" To: "Nakhjiri Madjid-MNAKHJI1" , "Rajeev Koodli" , Cc: , , References: <35DBB8B7AC89D4118E98009027B1009B08AD5554@IL27EXM10.cig.mot.com> Subject: Re: [Seamoby] RE: [NSIS] Re: draft-westphal-nsis-qos-mobileip-00.txt Date: Wed, 10 Jul 2002 15:14:55 -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-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit I guess I didn't make my point clear. The point I was trying to make is that given CT of QoS context succeeds, NSIS signaling at the new access subnet is unnecessary. Thus, it could be viewed as a kind of optimization. If CT fails, then signaling would be needed. I did not mean to imply that any changes were required in the generic CT requirements (though perhaps there would need to be some changes in the QoS specific context definition). Is this accurate, from the NSIS viewpoint? One case where I could see it not being accurate is if there were some changes required behind the access router in order to obtain QoS for the mobile on the new router, but perhaps there are others. jak ----- Original Message ----- From: "Nakhjiri Madjid-MNAKHJI1" To: "'James Kempf'" ; "Rajeev Koodli" ; Cc: ; ; Sent: Wednesday, July 10, 2002 11:58 AM Subject: RE: [Seamoby] RE: [NSIS] Re: draft-westphal-nsis-qos-mobileip-00.txt > James, > > As much as I like to see a clean interaction between CT and NSIS, > I don't see any reason why CT needs to play the role of NSIS optimization, > not to forget the NSIS didn't even exist back then. > > CT is simply a tool you need in your seamless mobility toolbox, it > eventually > involved into a container carrying any context you like (even non-IP > context, as > long as it is feasible). The profile types, that Rajeev mentioned is aligned > with > this line of thinking. > > I seriously advise against going back and change CT > requirements for the sake of optimizing NSIS, which at this point we don't > know > what it is. A couple of months from now, we have to revise CT because of a > security > related protocol, later for something else..... > > > The later we wait for CT standardization, the more home brewed versions are > going to pop up, just like Behcet mentioned. > > My 1.5 cents (lower dollars) > > Madjid > > -----Original Message----- > From: James Kempf [mailto:kempf@docomolabs-usa.com] > Sent: Monday, July 08, 2002 4:37 PM > To: Rajeev Koodli; Hemant.Chaskar@nokia.com > Cc: gkenward@nortelnetworks.com; seamoby@ietf.org; nsis@ietf.org > Subject: Re: [Seamoby] RE: [NSIS] Re: > draft-westphal-nsis-qos-mobileip-00.txt > > > > CT is an optimization to avoid signaling and the associated overheads, and > maintain > > desirable transport (RTP/TCP)performance. A historical note: CT was not > designed > > to be an optimization for NSIS. > > > > Do you mean that the requirements weren't so designed? Because, to my > knowledge, the WG has not yet settled on a design. We are > currently awaiting IESG feedback on our requirements. The problem statement > was just approved by the IESG. > > jak > > > _______________________________________________ > 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 From daemon@optimus.ietf.org Wed Jul 10 18:19:41 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22002 for ; Wed, 10 Jul 2002 18:19:41 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA13621 for seamoby-archive@odin.ietf.org; Wed, 10 Jul 2002 18:20:36 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA13483; Wed, 10 Jul 2002 18:16:53 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA13382 for ; Wed, 10 Jul 2002 18:16:47 -0400 (EDT) Received: from fridge.docomolabs-usa.com (fwuser@key1.docomolabs-usa.com [216.98.102.225]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21926; Wed, 10 Jul 2002 18:15:51 -0400 (EDT) Message-ID: <018a01c2285f$392d00d0$4f6015ac@T23KEMPF> From: "James Kempf" To: "Nakhjiri Madjid-MNAKHJI1" , "Rajeev Koodli" , Cc: , , References: <35DBB8B7AC89D4118E98009027B1009B08AD5554@IL27EXM10.cig.mot.com> Subject: Re: [Seamoby] RE: [NSIS] Re: draft-westphal-nsis-qos-mobileip-00.txt Date: Wed, 10 Jul 2002 15:14:55 -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-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit I guess I didn't make my point clear. The point I was trying to make is that given CT of QoS context succeeds, NSIS signaling at the new access subnet is unnecessary. Thus, it could be viewed as a kind of optimization. If CT fails, then signaling would be needed. I did not mean to imply that any changes were required in the generic CT requirements (though perhaps there would need to be some changes in the QoS specific context definition). Is this accurate, from the NSIS viewpoint? One case where I could see it not being accurate is if there were some changes required behind the access router in order to obtain QoS for the mobile on the new router, but perhaps there are others. jak ----- Original Message ----- From: "Nakhjiri Madjid-MNAKHJI1" To: "'James Kempf'" ; "Rajeev Koodli" ; Cc: ; ; Sent: Wednesday, July 10, 2002 11:58 AM Subject: RE: [Seamoby] RE: [NSIS] Re: draft-westphal-nsis-qos-mobileip-00.txt > James, > > As much as I like to see a clean interaction between CT and NSIS, > I don't see any reason why CT needs to play the role of NSIS optimization, > not to forget the NSIS didn't even exist back then. > > CT is simply a tool you need in your seamless mobility toolbox, it > eventually > involved into a container carrying any context you like (even non-IP > context, as > long as it is feasible). The profile types, that Rajeev mentioned is aligned > with > this line of thinking. > > I seriously advise against going back and change CT > requirements for the sake of optimizing NSIS, which at this point we don't > know > what it is. A couple of months from now, we have to revise CT because of a > security > related protocol, later for something else..... > > > The later we wait for CT standardization, the more home brewed versions are > going to pop up, just like Behcet mentioned. > > My 1.5 cents (lower dollars) > > Madjid > > -----Original Message----- > From: James Kempf [mailto:kempf@docomolabs-usa.com] > Sent: Monday, July 08, 2002 4:37 PM > To: Rajeev Koodli; Hemant.Chaskar@nokia.com > Cc: gkenward@nortelnetworks.com; seamoby@ietf.org; nsis@ietf.org > Subject: Re: [Seamoby] RE: [NSIS] Re: > draft-westphal-nsis-qos-mobileip-00.txt > > > > CT is an optimization to avoid signaling and the associated overheads, and > maintain > > desirable transport (RTP/TCP)performance. A historical note: CT was not > designed > > to be an optimization for NSIS. > > > > Do you mean that the requirements weren't so designed? Because, to my > knowledge, the WG has not yet settled on a design. We are > currently awaiting IESG feedback on our requirements. The problem statement > was just approved by the IESG. > > jak > > > _______________________________________________ > 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 From seamoby-admin@ietf.org Wed Jul 10 18:39:54 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22345 for ; Wed, 10 Jul 2002 18:39:54 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA14706; Wed, 10 Jul 2002 18:38:57 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA14645 for ; Wed, 10 Jul 2002 18:38:53 -0400 (EDT) Received: from motgate3.mot.com (motgate3.mot.com [144.189.100.103]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22304; Wed, 10 Jul 2002 18:37:57 -0400 (EDT) Received: [from pobox4.mot.com (pobox4.mot.com [10.64.251.243]) by motgate3.mot.com (motgate3 2.1) with ESMTP id PAA26907; Wed, 10 Jul 2002 15:37:55 -0700 (MST)] Received: [from il27exb01.cig.mot.com (il27exb01.cig.mot.com [136.182.15.100]) by pobox4.mot.com (MOT-pobox4 2.0) with ESMTP id PAA04289; Wed, 10 Jul 2002 15:38:49 -0700 (MST)] Received: by il27exb01.cig.mot.com with Internet Mail Service (5.5.2654.52) id ; Wed, 10 Jul 2002 17:38:49 -0500 Message-ID: <35DBB8B7AC89D4118E98009027B1009B08AD5569@IL27EXM10.cig.mot.com> From: Nakhjiri Madjid-MNAKHJI1 To: "'James Kempf'" , Nakhjiri Madjid-MNAKHJI1 , Rajeev Koodli , Hemant.Chaskar@nokia.com Cc: gkenward@nortelnetworks.com, seamoby@ietf.org, nsis@ietf.org Subject: RE: [Seamoby] RE: [NSIS] Re: draft-westphal-nsis-qos-mobileip-00. txt Date: Wed, 10 Jul 2002 17:38:49 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.52) Content-Type: text/plain; charset="iso-8859-1" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org -----Original Message----- From: James Kempf [mailto:kempf@docomolabs-usa.com] Sent: Wednesday, July 10, 2002 5:15 PM To: Nakhjiri Madjid-MNAKHJI1; Rajeev Koodli; Hemant.Chaskar@nokia.com Cc: gkenward@nortelnetworks.com; seamoby@ietf.org; nsis@ietf.org Subject: Re: [Seamoby] RE: [NSIS] Re: draft-westphal-nsis-qos-mobileip-00.txt I guess I didn't make my point clear. The point I was trying to make is that given CT of QoS context succeeds, NSIS signaling at the new access subnet is unnecessary. Thus, it could be viewed as a kind of optimization. If CT fails, then signaling would be needed. Madjid>> don't quite agree. A QoS framework that tightly controls resources, might need to release resources at old AR and obtain resources at new AR, so CT by itself is not always enough. I did not mean to imply that any changes were required in the generic CT requirements (though perhaps there would need to be some changes in the QoS specific context definition). Madjid>> Ok. Is this accurate, from the NSIS viewpoint? One case where I could see it not being accurate is if there were some changes required behind the access router in order to obtain QoS for the mobile on the new router, but perhaps there are others. jak ----- Original Message ----- From: "Nakhjiri Madjid-MNAKHJI1" To: "'James Kempf'" ; "Rajeev Koodli" ; Cc: ; ; Sent: Wednesday, July 10, 2002 11:58 AM Subject: RE: [Seamoby] RE: [NSIS] Re: draft-westphal-nsis-qos-mobileip-00.txt > James, > > As much as I like to see a clean interaction between CT and NSIS, > I don't see any reason why CT needs to play the role of NSIS optimization, > not to forget the NSIS didn't even exist back then. > > CT is simply a tool you need in your seamless mobility toolbox, it > eventually > involved into a container carrying any context you like (even non-IP > context, as > long as it is feasible). The profile types, that Rajeev mentioned is aligned > with > this line of thinking. > > I seriously advise against going back and change CT > requirements for the sake of optimizing NSIS, which at this point we don't > know > what it is. A couple of months from now, we have to revise CT because of a > security > related protocol, later for something else..... > > > The later we wait for CT standardization, the more home brewed versions are > going to pop up, just like Behcet mentioned. > > My 1.5 cents (lower dollars) > > Madjid > > -----Original Message----- > From: James Kempf [mailto:kempf@docomolabs-usa.com] > Sent: Monday, July 08, 2002 4:37 PM > To: Rajeev Koodli; Hemant.Chaskar@nokia.com > Cc: gkenward@nortelnetworks.com; seamoby@ietf.org; nsis@ietf.org > Subject: Re: [Seamoby] RE: [NSIS] Re: > draft-westphal-nsis-qos-mobileip-00.txt > > > > CT is an optimization to avoid signaling and the associated overheads, and > maintain > > desirable transport (RTP/TCP)performance. A historical note: CT was not > designed > > to be an optimization for NSIS. > > > > Do you mean that the requirements weren't so designed? Because, to my > knowledge, the WG has not yet settled on a design. We are > currently awaiting IESG feedback on our requirements. The problem statement > was just approved by the IESG. > > jak > > > _______________________________________________ > 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 From daemon@optimus.ietf.org Wed Jul 10 18:39:55 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22359 for ; Wed, 10 Jul 2002 18:39:55 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA14870 for seamoby-archive@odin.ietf.org; Wed, 10 Jul 2002 18:40:50 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA14706; Wed, 10 Jul 2002 18:38:57 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA14645 for ; Wed, 10 Jul 2002 18:38:53 -0400 (EDT) Received: from motgate3.mot.com (motgate3.mot.com [144.189.100.103]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22304; Wed, 10 Jul 2002 18:37:57 -0400 (EDT) Received: [from pobox4.mot.com (pobox4.mot.com [10.64.251.243]) by motgate3.mot.com (motgate3 2.1) with ESMTP id PAA26907; Wed, 10 Jul 2002 15:37:55 -0700 (MST)] Received: [from il27exb01.cig.mot.com (il27exb01.cig.mot.com [136.182.15.100]) by pobox4.mot.com (MOT-pobox4 2.0) with ESMTP id PAA04289; Wed, 10 Jul 2002 15:38:49 -0700 (MST)] Received: by il27exb01.cig.mot.com with Internet Mail Service (5.5.2654.52) id ; Wed, 10 Jul 2002 17:38:49 -0500 Message-ID: <35DBB8B7AC89D4118E98009027B1009B08AD5569@IL27EXM10.cig.mot.com> From: Nakhjiri Madjid-MNAKHJI1 To: "'James Kempf'" , Nakhjiri Madjid-MNAKHJI1 , Rajeev Koodli , Hemant.Chaskar@nokia.com Cc: gkenward@nortelnetworks.com, seamoby@ietf.org, nsis@ietf.org Subject: RE: [Seamoby] RE: [NSIS] Re: draft-westphal-nsis-qos-mobileip-00. txt Date: Wed, 10 Jul 2002 17:38:49 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.52) Content-Type: text/plain; charset="iso-8859-1" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org -----Original Message----- From: James Kempf [mailto:kempf@docomolabs-usa.com] Sent: Wednesday, July 10, 2002 5:15 PM To: Nakhjiri Madjid-MNAKHJI1; Rajeev Koodli; Hemant.Chaskar@nokia.com Cc: gkenward@nortelnetworks.com; seamoby@ietf.org; nsis@ietf.org Subject: Re: [Seamoby] RE: [NSIS] Re: draft-westphal-nsis-qos-mobileip-00.txt I guess I didn't make my point clear. The point I was trying to make is that given CT of QoS context succeeds, NSIS signaling at the new access subnet is unnecessary. Thus, it could be viewed as a kind of optimization. If CT fails, then signaling would be needed. Madjid>> don't quite agree. A QoS framework that tightly controls resources, might need to release resources at old AR and obtain resources at new AR, so CT by itself is not always enough. I did not mean to imply that any changes were required in the generic CT requirements (though perhaps there would need to be some changes in the QoS specific context definition). Madjid>> Ok. Is this accurate, from the NSIS viewpoint? One case where I could see it not being accurate is if there were some changes required behind the access router in order to obtain QoS for the mobile on the new router, but perhaps there are others. jak ----- Original Message ----- From: "Nakhjiri Madjid-MNAKHJI1" To: "'James Kempf'" ; "Rajeev Koodli" ; Cc: ; ; Sent: Wednesday, July 10, 2002 11:58 AM Subject: RE: [Seamoby] RE: [NSIS] Re: draft-westphal-nsis-qos-mobileip-00.txt > James, > > As much as I like to see a clean interaction between CT and NSIS, > I don't see any reason why CT needs to play the role of NSIS optimization, > not to forget the NSIS didn't even exist back then. > > CT is simply a tool you need in your seamless mobility toolbox, it > eventually > involved into a container carrying any context you like (even non-IP > context, as > long as it is feasible). The profile types, that Rajeev mentioned is aligned > with > this line of thinking. > > I seriously advise against going back and change CT > requirements for the sake of optimizing NSIS, which at this point we don't > know > what it is. A couple of months from now, we have to revise CT because of a > security > related protocol, later for something else..... > > > The later we wait for CT standardization, the more home brewed versions are > going to pop up, just like Behcet mentioned. > > My 1.5 cents (lower dollars) > > Madjid > > -----Original Message----- > From: James Kempf [mailto:kempf@docomolabs-usa.com] > Sent: Monday, July 08, 2002 4:37 PM > To: Rajeev Koodli; Hemant.Chaskar@nokia.com > Cc: gkenward@nortelnetworks.com; seamoby@ietf.org; nsis@ietf.org > Subject: Re: [Seamoby] RE: [NSIS] Re: > draft-westphal-nsis-qos-mobileip-00.txt > > > > CT is an optimization to avoid signaling and the associated overheads, and > maintain > > desirable transport (RTP/TCP)performance. A historical note: CT was not > designed > > to be an optimization for NSIS. > > > > Do you mean that the requirements weren't so designed? Because, to my > knowledge, the WG has not yet settled on a design. We are > currently awaiting IESG feedback on our requirements. The problem statement > was just approved by the IESG. > > jak > > > _______________________________________________ > 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 From seamoby-admin@ietf.org Thu Jul 11 04:32:36 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA13179 for ; Thu, 11 Jul 2002 04:32:36 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA21332; Thu, 11 Jul 2002 04:25:02 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA21249 for ; Thu, 11 Jul 2002 04:24:58 -0400 (EDT) Received: from mail1.telekom.de (mail1.telekom.de [62.225.183.235]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12786; Thu, 11 Jul 2002 04:24:03 -0400 (EDT) Received: from g8pbr.blf01.telekom.de by G8SBV.dmz.telekom.de with ESMTP; Thu, 11 Jul 2002 10:23:39 +0200 Received: by G8PBR.blf01.telekom.de with Internet Mail Service (5.5.2653.19) id <3VR7PRVX>; Thu, 11 Jul 2002 10:24:16 +0200 Message-Id: From: "Geib, Ruediger" To: kempf@docomolabs-usa.com, Madjid.Nakhjiri@motorola.com, rajeev@iprg.nokia.com, Hemant.Chaskar@nokia.com Cc: gkenward@nortelnetworks.com, seamoby@ietf.org, nsis@ietf.org Subject: RE: [Seamoby] RE: [NSIS] Re: draft-westphal-nsis-qos-mobileip-00. txt Date: Thu, 11 Jul 2002 10:24:13 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id EAA21252 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 8bit Hi James > The point I was trying to make is that given CT of QoS > context succeeds, NSIS signaling at the new access subnet is > unnecessary. Thus, it could be viewed as a kind of > optimization. If CT fails, then signaling would be needed. [RG] If this means "QoS related CT replaces MN signaling during [RG] handoff", given that the related resource reservation [RG] doesn't change. > I did not mean to imply that any changes were required in the > generic CT requirements (though perhaps there would need to be > some changes in the QoS specific context definition). [RG] QoS CT should use the NSIS resource reservation parameters [RG] as basic input for its own QoS parameters. Whether the [RG] original NSIS parameters are copied or derived [RG] technology or domain specific parameters are used for CT [RG] doesn't matter if the result is as if the original NSIS [RG] parameters were used to establish resources at the new AR. > Is this accurate, from the NSIS viewpoint? One case where I > could see it not being accurate is if there were some changes > required behind the access router in order to obtain QoS for > the mobile on the new router, but perhaps there are others. [RG] This may have to be clarified. I wouldn't expect an MN [RG] to get involved into tunnel set up and release, should [RG] this be the way an access network supports QoS and [RG] mobility. A local NSIS solution may be used within [RG] the access network to provide the required signaling. [RG] But I'd expect this to be invisible to the MN. [RG] I think NSIS and SEAMOBY must agree how both interwork. [RG] Besides the QoS parameter issue, an MN should be aware [RG] of the fact whether CT is supported and whether it is [RG] succesful (or whether it wasn't). [RG] To me this seems to be a loose cooperation. If NSIS and [RG] SEAMOBY conclude to ignore each other, I'd regard both [RG] as a waste of time with regard to wireless mobility [RG] combined with QoS. Regards, Rüdiger _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Thu Jul 11 04:32:37 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA13185 for ; Thu, 11 Jul 2002 04:32:37 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA22514 for seamoby-archive@odin.ietf.org; Thu, 11 Jul 2002 04:33:29 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA21332; Thu, 11 Jul 2002 04:25:02 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA21249 for ; Thu, 11 Jul 2002 04:24:58 -0400 (EDT) Received: from mail1.telekom.de (mail1.telekom.de [62.225.183.235]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12786; Thu, 11 Jul 2002 04:24:03 -0400 (EDT) Received: from g8pbr.blf01.telekom.de by G8SBV.dmz.telekom.de with ESMTP; Thu, 11 Jul 2002 10:23:39 +0200 Received: by G8PBR.blf01.telekom.de with Internet Mail Service (5.5.2653.19) id <3VR7PRVX>; Thu, 11 Jul 2002 10:24:16 +0200 Message-Id: From: "Geib, Ruediger" To: kempf@docomolabs-usa.com, Madjid.Nakhjiri@motorola.com, rajeev@iprg.nokia.com, Hemant.Chaskar@nokia.com Cc: gkenward@nortelnetworks.com, seamoby@ietf.org, nsis@ietf.org Subject: RE: [Seamoby] RE: [NSIS] Re: draft-westphal-nsis-qos-mobileip-00. txt Date: Thu, 11 Jul 2002 10:24:13 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id EAA21252 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 8bit Hi James > The point I was trying to make is that given CT of QoS > context succeeds, NSIS signaling at the new access subnet is > unnecessary. Thus, it could be viewed as a kind of > optimization. If CT fails, then signaling would be needed. [RG] If this means "QoS related CT replaces MN signaling during [RG] handoff", given that the related resource reservation [RG] doesn't change. > I did not mean to imply that any changes were required in the > generic CT requirements (though perhaps there would need to be > some changes in the QoS specific context definition). [RG] QoS CT should use the NSIS resource reservation parameters [RG] as basic input for its own QoS parameters. Whether the [RG] original NSIS parameters are copied or derived [RG] technology or domain specific parameters are used for CT [RG] doesn't matter if the result is as if the original NSIS [RG] parameters were used to establish resources at the new AR. > Is this accurate, from the NSIS viewpoint? One case where I > could see it not being accurate is if there were some changes > required behind the access router in order to obtain QoS for > the mobile on the new router, but perhaps there are others. [RG] This may have to be clarified. I wouldn't expect an MN [RG] to get involved into tunnel set up and release, should [RG] this be the way an access network supports QoS and [RG] mobility. A local NSIS solution may be used within [RG] the access network to provide the required signaling. [RG] But I'd expect this to be invisible to the MN. [RG] I think NSIS and SEAMOBY must agree how both interwork. [RG] Besides the QoS parameter issue, an MN should be aware [RG] of the fact whether CT is supported and whether it is [RG] succesful (or whether it wasn't). [RG] To me this seems to be a loose cooperation. If NSIS and [RG] SEAMOBY conclude to ignore each other, I'd regard both [RG] as a waste of time with regard to wireless mobility [RG] combined with QoS. Regards, Rüdiger _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Thu Jul 11 10:39:39 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19323 for ; Thu, 11 Jul 2002 10:39:39 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA11624; Thu, 11 Jul 2002 10:35:02 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA11600 for ; Thu, 11 Jul 2002 10:35:01 -0400 (EDT) Received: from zcars04e.ca.nortel.com (zcars04e.nortelnetworks.com [47.129.242.56]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19205 for ; Thu, 11 Jul 2002 10:34:07 -0400 (EDT) Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g6BEY7H14264; Thu, 11 Jul 2002 10:34:07 -0400 (EDT) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 11 Jul 2002 10:34:07 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA4C03@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'James Kempf'" , seamoby@ietf.org Subject: RE: [Seamoby] CT Requirements Comments from IESG Date: Thu, 11 Jul 2002 10:34:04 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C228E7.799DF86C" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C228E7.799DF86C Content-Type: text/plain; charset="iso-8859-1" I understand your intentions James, but as a requirement, preserving "intended usability" does not make any sense to me. How does on test that a solution is in conformance to this requirement? Just to be clear, I don't believe that "preserving meaning" is a real requirement either. It is also not testable. I am not just arguing semantics here, if we are going to revise these requirements, let's make sure that they are real requirements. Perhaps the actual answer is to state exactly what was intended originally: that the bit order and bit values have to arrive exactly as they were transmitted. gary > -----Original Message----- > From: James Kempf [mailto:kempf@docomolabs-usa.com] > Sent: July 10, 2002 18:12 > To: Kenward, Gary [WDLN2:AN10:EXCH]; seamoby@ietf.org > Subject: Re: [Seamoby] CT Requirements Comments from IESG > > > It's not the same definition > > I suggest: > > 5.5.2 A context update MUST preserve the integrity, and thus the > intended useability, of the context at each receiving AR. > > jak > > > > ----- Original Message ----- > From: "Gary Kenward" > To: "'James Kempf'" ; > Sent: Wednesday, July 10, 2002 11:31 AM > Subject: RE: [Seamoby] CT Requirements Comments from IESG > > > > A word is often defined as 4 bytes, or 32 bits :-) in many > > computational architectures and programming languages. > > > > Neither here nor there, really. I'll wait for further > > suggestions/comments on the working of 5.5.2 from the wg. > > > > Gary > > > > > -----Original Message----- > > > From: James Kempf [mailto:kempf@docomolabs-usa.com] > > > Sent: July 10, 2002 14:12 > > > To: Kenward, Gary [WDLN2:AN10:EXCH]; seamoby@ietf.org > > > Subject: Re: [Seamoby] CT Requirements Comments from IESG > > > > > > > > > "Word" or "phrase", from the definition you cite, typically > > > applies to natural language. I have not heard anyone use that > > > terminology for machine readable information, even in > > > programming languages. > > > > > > jak > > > > > > ----- Original Message ----- > > > From: "Gary Kenward" > > > To: "'James Kempf'" ; > > > Sent: Wednesday, July 10, 2002 9:58 AM > > > Subject: RE: [Seamoby] CT Requirements Comments from IESG > > > > > > > > > > *snip* > > > > > > > > > ------_=_NextPart_001_01C228E7.799DF86C Content-Type: text/html; charset="iso-8859-1" RE: [Seamoby] CT Requirements Comments from IESG

I understand your intentions James, but as a requirement,
preserving "intended usability" does not make any sense to
me. How does on test that a solution is in conformance to
this requirement?

Just to be clear, I don't believe that "preserving meaning"
is a real requirement either. It is also not testable.

I am not just arguing semantics here, if we are going to
revise these requirements, let's make sure that they are
real requirements.

Perhaps the actual answer is to state exactly what was intended
originally: that the bit order and bit values have to arrive exactly
as they were transmitted.

gary

> -----Original Message-----
> From: James Kempf [mailto:kempf@docomolabs-usa.com]
> Sent: July 10, 2002 18:12
> To: Kenward, Gary [WDLN2:AN10:EXCH]; seamoby@ietf.org
> Subject: Re: [Seamoby] CT Requirements Comments from IESG
>
>
> It's not the same definition
>
> I suggest:
>
> 5.5.2 A context update MUST preserve the integrity, and thus the
>       intended useability, of the context at each receiving AR.
>
>             jak
>
>
>
> ----- Original Message -----
> From: "Gary Kenward" <gkenward@nortelnetworks.com>
> To: "'James Kempf'" <kempf@docomolabs-usa.com>; <seamoby@ietf.org>
> Sent: Wednesday, July 10, 2002 11:31 AM
> Subject: RE: [Seamoby] CT Requirements Comments from IESG
>
>
> > A word is often defined as 4 bytes, or 32 bits :-) in many
> > computational architectures and programming languages.
> >
> > Neither here nor there, really. I'll wait for further
> > suggestions/comments on the working of 5.5.2 from the wg.
> >
> > Gary
> >
> > > -----Original Message-----
> > > From: James Kempf [mailto:kempf@docomolabs-usa.com]
> > > Sent: July 10, 2002 14:12
> > > To: Kenward, Gary [WDLN2:AN10:EXCH]; seamoby@ietf.org
> > > Subject: Re: [Seamoby] CT Requirements Comments from IESG
> > >
> > >
> > > "Word" or "phrase", from the definition you cite, typically
> > > applies to natural language. I have not heard anyone use that
> > > terminology for machine readable information, even in
> > > programming languages.
> > >
> > >             jak
> > >
> > > ----- Original Message -----
> > > From: "Gary Kenward" <gkenward@nortelnetworks.com>
> > > To: "'James Kempf'" <kempf@docomolabs-usa.com>; <seamoby@ietf.org>
> > > Sent: Wednesday, July 10, 2002 9:58 AM
> > > Subject: RE: [Seamoby] CT Requirements Comments from IESG
> > >
> > >
> >
> > *snip*
> >
> > >
> >
>
>

------_=_NextPart_001_01C228E7.799DF86C-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Thu Jul 11 10:39:39 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19330 for ; Thu, 11 Jul 2002 10:39:39 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA11933 for seamoby-archive@odin.ietf.org; Thu, 11 Jul 2002 10:40:31 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA11624; Thu, 11 Jul 2002 10:35:02 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA11600 for ; Thu, 11 Jul 2002 10:35:01 -0400 (EDT) Received: from zcars04e.ca.nortel.com (zcars04e.nortelnetworks.com [47.129.242.56]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19205 for ; Thu, 11 Jul 2002 10:34:07 -0400 (EDT) Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g6BEY7H14264; Thu, 11 Jul 2002 10:34:07 -0400 (EDT) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 11 Jul 2002 10:34:07 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA4C03@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'James Kempf'" , seamoby@ietf.org Subject: RE: [Seamoby] CT Requirements Comments from IESG Date: Thu, 11 Jul 2002 10:34:04 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C228E7.799DF86C" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C228E7.799DF86C Content-Type: text/plain; charset="iso-8859-1" I understand your intentions James, but as a requirement, preserving "intended usability" does not make any sense to me. How does on test that a solution is in conformance to this requirement? Just to be clear, I don't believe that "preserving meaning" is a real requirement either. It is also not testable. I am not just arguing semantics here, if we are going to revise these requirements, let's make sure that they are real requirements. Perhaps the actual answer is to state exactly what was intended originally: that the bit order and bit values have to arrive exactly as they were transmitted. gary > -----Original Message----- > From: James Kempf [mailto:kempf@docomolabs-usa.com] > Sent: July 10, 2002 18:12 > To: Kenward, Gary [WDLN2:AN10:EXCH]; seamoby@ietf.org > Subject: Re: [Seamoby] CT Requirements Comments from IESG > > > It's not the same definition > > I suggest: > > 5.5.2 A context update MUST preserve the integrity, and thus the > intended useability, of the context at each receiving AR. > > jak > > > > ----- Original Message ----- > From: "Gary Kenward" > To: "'James Kempf'" ; > Sent: Wednesday, July 10, 2002 11:31 AM > Subject: RE: [Seamoby] CT Requirements Comments from IESG > > > > A word is often defined as 4 bytes, or 32 bits :-) in many > > computational architectures and programming languages. > > > > Neither here nor there, really. I'll wait for further > > suggestions/comments on the working of 5.5.2 from the wg. > > > > Gary > > > > > -----Original Message----- > > > From: James Kempf [mailto:kempf@docomolabs-usa.com] > > > Sent: July 10, 2002 14:12 > > > To: Kenward, Gary [WDLN2:AN10:EXCH]; seamoby@ietf.org > > > Subject: Re: [Seamoby] CT Requirements Comments from IESG > > > > > > > > > "Word" or "phrase", from the definition you cite, typically > > > applies to natural language. I have not heard anyone use that > > > terminology for machine readable information, even in > > > programming languages. > > > > > > jak > > > > > > ----- Original Message ----- > > > From: "Gary Kenward" > > > To: "'James Kempf'" ; > > > Sent: Wednesday, July 10, 2002 9:58 AM > > > Subject: RE: [Seamoby] CT Requirements Comments from IESG > > > > > > > > > > *snip* > > > > > > > > > ------_=_NextPart_001_01C228E7.799DF86C Content-Type: text/html; charset="iso-8859-1" RE: [Seamoby] CT Requirements Comments from IESG

I understand your intentions James, but as a requirement,
preserving "intended usability" does not make any sense to
me. How does on test that a solution is in conformance to
this requirement?

Just to be clear, I don't believe that "preserving meaning"
is a real requirement either. It is also not testable.

I am not just arguing semantics here, if we are going to
revise these requirements, let's make sure that they are
real requirements.

Perhaps the actual answer is to state exactly what was intended
originally: that the bit order and bit values have to arrive exactly
as they were transmitted.

gary

> -----Original Message-----
> From: James Kempf [mailto:kempf@docomolabs-usa.com]
> Sent: July 10, 2002 18:12
> To: Kenward, Gary [WDLN2:AN10:EXCH]; seamoby@ietf.org
> Subject: Re: [Seamoby] CT Requirements Comments from IESG
>
>
> It's not the same definition
>
> I suggest:
>
> 5.5.2 A context update MUST preserve the integrity, and thus the
>       intended useability, of the context at each receiving AR.
>
>             jak
>
>
>
> ----- Original Message -----
> From: "Gary Kenward" <gkenward@nortelnetworks.com>
> To: "'James Kempf'" <kempf@docomolabs-usa.com>; <seamoby@ietf.org>
> Sent: Wednesday, July 10, 2002 11:31 AM
> Subject: RE: [Seamoby] CT Requirements Comments from IESG
>
>
> > A word is often defined as 4 bytes, or 32 bits :-) in many
> > computational architectures and programming languages.
> >
> > Neither here nor there, really. I'll wait for further
> > suggestions/comments on the working of 5.5.2 from the wg.
> >
> > Gary
> >
> > > -----Original Message-----
> > > From: James Kempf [mailto:kempf@docomolabs-usa.com]
> > > Sent: July 10, 2002 14:12
> > > To: Kenward, Gary [WDLN2:AN10:EXCH]; seamoby@ietf.org
> > > Subject: Re: [Seamoby] CT Requirements Comments from IESG
> > >
> > >
> > > "Word" or "phrase", from the definition you cite, typically
> > > applies to natural language. I have not heard anyone use that
> > > terminology for machine readable information, even in
> > > programming languages.
> > >
> > >             jak
> > >
> > > ----- Original Message -----
> > > From: "Gary Kenward" <gkenward@nortelnetworks.com>
> > > To: "'James Kempf'" <kempf@docomolabs-usa.com>; <seamoby@ietf.org>
> > > Sent: Wednesday, July 10, 2002 9:58 AM
> > > Subject: RE: [Seamoby] CT Requirements Comments from IESG
> > >
> > >
> >
> > *snip*
> >
> > >
> >
>
>

------_=_NextPart_001_01C228E7.799DF86C-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Thu Jul 11 10:51:47 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19758 for ; Thu, 11 Jul 2002 10:51:43 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA12668; Thu, 11 Jul 2002 10:49:43 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA12577 for ; Thu, 11 Jul 2002 10:49:39 -0400 (EDT) Received: from zcars04f.ca.nortel.com (zcars04f.nortelnetworks.com [47.129.242.57]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19662; Thu, 11 Jul 2002 10:48:45 -0400 (EDT) Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04f.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g6BEl7M29024; Thu, 11 Jul 2002 10:47:07 -0400 (EDT) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 11 Jul 2002 10:47:06 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA4C05@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'Geib, Ruediger'" , kempf@docomolabs-usa.com, Madjid.Nakhjiri@motorola.com, rajeev@iprg.nokia.com, Hemant.Chaskar@nokia.com Cc: seamoby@ietf.org, nsis@ietf.org Subject: RE: [Seamoby] RE: [NSIS] Re: draft-westphal-nsis-qos-mobileip-00. txt Date: Thu, 11 Jul 2002 10:47:03 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C228E9.D1A64AE4" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C228E9.D1A64AE4 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Ruediger: Concerning the comment that CT use the "original NSIS parameters": - CT is not a service establishment protocol; it tranports forwarding context, not service description parameters. Some of the forwarding context *may* be the original service = description parameters, but many *may* be derived values that allow a more representative description of the AR forwarding context. - The issue is rather moot, because neither Seamoby nor NSIS are chartered to define what the signalling parameters or forwarding context are. To say that there should be some commonality is=20 of little import, as neither group can analyze the feasibility = and impact of such a statement. - For the two groups should discuss the common parameters would be = a violation of the respective charters. I think that this is an excellent idea, but I believe it will have to take place outside of the NSIS/Seamoby wgs, and I suggest that it would be best if we knew what the = CT/NSIS=20 protocols were - at the very least, we can proceed with the definition=20 of the protocols. Regards, Gary > -----Original Message----- > From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com] > Sent: July 11, 2002 04:24 > To: kempf@docomolabs-usa.com; Madjid.Nakhjiri@motorola.com; > rajeev@iprg.nokia.com; Hemant.Chaskar@nokia.com > Cc: Kenward, Gary [WDLN2:AN10:EXCH]; seamoby@ietf.org; nsis@ietf.org > Subject: RE: [Seamoby] RE: [NSIS] Re: > draft-westphal-nsis-qos-mobileip-00. txt >=20 >=20 > Hi James >=20 > > The point I was trying to make is that given CT of QoS=20 > > context succeeds, NSIS signaling at the new access subnet is > > unnecessary. Thus, it could be viewed as a kind of=20 > > optimization. If CT fails, then signaling would be needed. >=20 > [RG] If this means "QoS related CT replaces MN signaling during=20 > [RG] handoff", given that the related resource reservation > [RG] doesn't change. >=20 > > I did not mean to imply that any changes were required in the=20 > > generic CT requirements (though perhaps there would need to be > > some changes in the QoS specific context definition). >=20 > [RG] QoS CT should use the NSIS resource reservation parameters > [RG] as basic input for its own QoS parameters. Whether the=20 > [RG] original NSIS parameters are copied or derived=20 > [RG] technology or domain specific parameters are used for CT=20 > [RG] doesn't matter if the result is as if the original NSIS=20 > [RG] parameters were used to establish resources at the new AR. >=20 > > Is this accurate, from the NSIS viewpoint? One case where I=20 > > could see it not being accurate is if there were some changes > > required behind the access router in order to obtain QoS for=20 > > the mobile on the new router, but perhaps there are others. >=20 > [RG] This may have to be clarified. I wouldn't expect an MN > [RG] to get involved into tunnel set up and release, should > [RG] this be the way an access network supports QoS and=20 > [RG] mobility. A local NSIS solution may be used within=20 > [RG] the access network to provide the required signaling. > [RG] But I'd expect this to be invisible to the MN.=20 >=20 > [RG] I think NSIS and SEAMOBY must agree how both interwork. > [RG] Besides the QoS parameter issue, an MN should be aware > [RG] of the fact whether CT is supported and whether it is=20 > [RG] succesful (or whether it wasn't). > [RG] To me this seems to be a loose cooperation. If NSIS and > [RG] SEAMOBY conclude to ignore each other, I'd regard both > [RG] as a waste of time with regard to wireless mobility=20 > [RG] combined with QoS.=20 >=20 > Regards, R=FCdiger >=20 ------_=_NextPart_001_01C228E9.D1A64AE4 Content-Type: text/html; charset="iso-8859-1" RE: [Seamoby] RE: [NSIS] Re: draft-westphal-nsis-qos-mobileip-00. txt

Ruediger:

  Concerning the comment that CT use the "original NSIS parameters":

        - CT is not a service establishment protocol; it tranports
       forwarding context, not service description parameters. Some
       of the forwarding context *may* be the original service description
       parameters, but many *may* be derived values that allow a more
       representative description of the AR forwarding context.

     - The issue is rather moot, because neither Seamoby nor NSIS are
       chartered to define what the signalling parameters or forwarding
       context are. To say that there should be some commonality is
       of little import, as neither group can analyze the feasibility and
       impact of such a statement.

     - For the two groups should discuss the common parameters would be a
       violation of the respective charters. I think that this is an excellent
       idea, but I believe it will have to take place outside of the NSIS/Seamoby
       wgs, and I suggest that it would be best if we knew what the CT/NSIS
       protocols were - at the very least, we can proceed with the definition
       of the protocols.

Regards,
Gary

> -----Original Message-----
> From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com]
> Sent: July 11, 2002 04:24
> To: kempf@docomolabs-usa.com; Madjid.Nakhjiri@motorola.com;
> rajeev@iprg.nokia.com; Hemant.Chaskar@nokia.com
> Cc: Kenward, Gary [WDLN2:AN10:EXCH]; seamoby@ietf.org; nsis@ietf.org
> Subject: RE: [Seamoby] RE: [NSIS] Re:
> draft-westphal-nsis-qos-mobileip-00. txt
>
>
> Hi James
>
> > The point I was trying to make is that given CT of QoS
> > context succeeds, NSIS signaling at the new access subnet is
> > unnecessary. Thus, it could be viewed as a kind of
> > optimization. If CT fails, then signaling would be needed.
>
> [RG] If this means "QoS related CT replaces MN signaling during
> [RG] handoff", given that the related resource reservation
> [RG] doesn't change.
>
> > I did not mean to imply that any changes were required in the
> > generic CT requirements (though perhaps there would need to be
> > some changes in the QoS specific context definition).
>
> [RG] QoS CT should use the NSIS resource reservation parameters
> [RG] as basic input for its own QoS parameters. Whether the
> [RG] original NSIS parameters are copied or derived
> [RG] technology or domain specific parameters are used for CT
> [RG] doesn't matter if the result is as if the original NSIS
> [RG] parameters were used to establish resources at the new AR.
>
> > Is this accurate, from the NSIS viewpoint? One case where I
> > could see it not being accurate is if there were some changes
> > required behind the access router in order to obtain QoS for
> > the mobile on the new router, but perhaps there are others.
>
> [RG] This may have to be clarified. I wouldn't expect an MN
> [RG] to get involved into tunnel set up and release, should
> [RG] this be the way an access network supports QoS and
> [RG] mobility. A local NSIS solution may be used within
> [RG] the access network to provide the required signaling.
> [RG] But I'd expect this to be invisible to the MN.
>
> [RG] I think NSIS and SEAMOBY must agree how both interwork.
> [RG] Besides the QoS parameter issue, an MN should be aware
> [RG] of the fact whether CT is supported and whether it is
> [RG] succesful (or whether it wasn't).
> [RG] To me this seems to be a loose cooperation. If NSIS and
> [RG] SEAMOBY conclude to ignore each other, I'd regard both
> [RG] as a waste of time with regard to wireless mobility
> [RG] combined with QoS.
>
> Regards, Rüdiger
>

------_=_NextPart_001_01C228E9.D1A64AE4-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Thu Jul 11 10:51:48 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19766 for ; Thu, 11 Jul 2002 10:51:48 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA13037 for seamoby-archive@odin.ietf.org; Thu, 11 Jul 2002 10:52:40 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA12668; Thu, 11 Jul 2002 10:49:43 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA12577 for ; Thu, 11 Jul 2002 10:49:39 -0400 (EDT) Received: from zcars04f.ca.nortel.com (zcars04f.nortelnetworks.com [47.129.242.57]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19662; Thu, 11 Jul 2002 10:48:45 -0400 (EDT) Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04f.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g6BEl7M29024; Thu, 11 Jul 2002 10:47:07 -0400 (EDT) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 11 Jul 2002 10:47:06 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA4C05@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'Geib, Ruediger'" , kempf@docomolabs-usa.com, Madjid.Nakhjiri@motorola.com, rajeev@iprg.nokia.com, Hemant.Chaskar@nokia.com Cc: seamoby@ietf.org, nsis@ietf.org Subject: RE: [Seamoby] RE: [NSIS] Re: draft-westphal-nsis-qos-mobileip-00. txt Date: Thu, 11 Jul 2002 10:47:03 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C228E9.D1A64AE4" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C228E9.D1A64AE4 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Ruediger: Concerning the comment that CT use the "original NSIS parameters": - CT is not a service establishment protocol; it tranports forwarding context, not service description parameters. Some of the forwarding context *may* be the original service = description parameters, but many *may* be derived values that allow a more representative description of the AR forwarding context. - The issue is rather moot, because neither Seamoby nor NSIS are chartered to define what the signalling parameters or forwarding context are. To say that there should be some commonality is=20 of little import, as neither group can analyze the feasibility = and impact of such a statement. - For the two groups should discuss the common parameters would be = a violation of the respective charters. I think that this is an excellent idea, but I believe it will have to take place outside of the NSIS/Seamoby wgs, and I suggest that it would be best if we knew what the = CT/NSIS=20 protocols were - at the very least, we can proceed with the definition=20 of the protocols. Regards, Gary > -----Original Message----- > From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com] > Sent: July 11, 2002 04:24 > To: kempf@docomolabs-usa.com; Madjid.Nakhjiri@motorola.com; > rajeev@iprg.nokia.com; Hemant.Chaskar@nokia.com > Cc: Kenward, Gary [WDLN2:AN10:EXCH]; seamoby@ietf.org; nsis@ietf.org > Subject: RE: [Seamoby] RE: [NSIS] Re: > draft-westphal-nsis-qos-mobileip-00. txt >=20 >=20 > Hi James >=20 > > The point I was trying to make is that given CT of QoS=20 > > context succeeds, NSIS signaling at the new access subnet is > > unnecessary. Thus, it could be viewed as a kind of=20 > > optimization. If CT fails, then signaling would be needed. >=20 > [RG] If this means "QoS related CT replaces MN signaling during=20 > [RG] handoff", given that the related resource reservation > [RG] doesn't change. >=20 > > I did not mean to imply that any changes were required in the=20 > > generic CT requirements (though perhaps there would need to be > > some changes in the QoS specific context definition). >=20 > [RG] QoS CT should use the NSIS resource reservation parameters > [RG] as basic input for its own QoS parameters. Whether the=20 > [RG] original NSIS parameters are copied or derived=20 > [RG] technology or domain specific parameters are used for CT=20 > [RG] doesn't matter if the result is as if the original NSIS=20 > [RG] parameters were used to establish resources at the new AR. >=20 > > Is this accurate, from the NSIS viewpoint? One case where I=20 > > could see it not being accurate is if there were some changes > > required behind the access router in order to obtain QoS for=20 > > the mobile on the new router, but perhaps there are others. >=20 > [RG] This may have to be clarified. I wouldn't expect an MN > [RG] to get involved into tunnel set up and release, should > [RG] this be the way an access network supports QoS and=20 > [RG] mobility. A local NSIS solution may be used within=20 > [RG] the access network to provide the required signaling. > [RG] But I'd expect this to be invisible to the MN.=20 >=20 > [RG] I think NSIS and SEAMOBY must agree how both interwork. > [RG] Besides the QoS parameter issue, an MN should be aware > [RG] of the fact whether CT is supported and whether it is=20 > [RG] succesful (or whether it wasn't). > [RG] To me this seems to be a loose cooperation. If NSIS and > [RG] SEAMOBY conclude to ignore each other, I'd regard both > [RG] as a waste of time with regard to wireless mobility=20 > [RG] combined with QoS.=20 >=20 > Regards, R=FCdiger >=20 ------_=_NextPart_001_01C228E9.D1A64AE4 Content-Type: text/html; charset="iso-8859-1" RE: [Seamoby] RE: [NSIS] Re: draft-westphal-nsis-qos-mobileip-00. txt

Ruediger:

  Concerning the comment that CT use the "original NSIS parameters":

        - CT is not a service establishment protocol; it tranports
       forwarding context, not service description parameters. Some
       of the forwarding context *may* be the original service description
       parameters, but many *may* be derived values that allow a more
       representative description of the AR forwarding context.

     - The issue is rather moot, because neither Seamoby nor NSIS are
       chartered to define what the signalling parameters or forwarding
       context are. To say that there should be some commonality is
       of little import, as neither group can analyze the feasibility and
       impact of such a statement.

     - For the two groups should discuss the common parameters would be a
       violation of the respective charters. I think that this is an excellent
       idea, but I believe it will have to take place outside of the NSIS/Seamoby
       wgs, and I suggest that it would be best if we knew what the CT/NSIS
       protocols were - at the very least, we can proceed with the definition
       of the protocols.

Regards,
Gary

> -----Original Message-----
> From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com]
> Sent: July 11, 2002 04:24
> To: kempf@docomolabs-usa.com; Madjid.Nakhjiri@motorola.com;
> rajeev@iprg.nokia.com; Hemant.Chaskar@nokia.com
> Cc: Kenward, Gary [WDLN2:AN10:EXCH]; seamoby@ietf.org; nsis@ietf.org
> Subject: RE: [Seamoby] RE: [NSIS] Re:
> draft-westphal-nsis-qos-mobileip-00. txt
>
>
> Hi James
>
> > The point I was trying to make is that given CT of QoS
> > context succeeds, NSIS signaling at the new access subnet is
> > unnecessary. Thus, it could be viewed as a kind of
> > optimization. If CT fails, then signaling would be needed.
>
> [RG] If this means "QoS related CT replaces MN signaling during
> [RG] handoff", given that the related resource reservation
> [RG] doesn't change.
>
> > I did not mean to imply that any changes were required in the
> > generic CT requirements (though perhaps there would need to be
> > some changes in the QoS specific context definition).
>
> [RG] QoS CT should use the NSIS resource reservation parameters
> [RG] as basic input for its own QoS parameters. Whether the
> [RG] original NSIS parameters are copied or derived
> [RG] technology or domain specific parameters are used for CT
> [RG] doesn't matter if the result is as if the original NSIS
> [RG] parameters were used to establish resources at the new AR.
>
> > Is this accurate, from the NSIS viewpoint? One case where I
> > could see it not being accurate is if there were some changes
> > required behind the access router in order to obtain QoS for
> > the mobile on the new router, but perhaps there are others.
>
> [RG] This may have to be clarified. I wouldn't expect an MN
> [RG] to get involved into tunnel set up and release, should
> [RG] this be the way an access network supports QoS and
> [RG] mobility. A local NSIS solution may be used within
> [RG] the access network to provide the required signaling.
> [RG] But I'd expect this to be invisible to the MN.
>
> [RG] I think NSIS and SEAMOBY must agree how both interwork.
> [RG] Besides the QoS parameter issue, an MN should be aware
> [RG] of the fact whether CT is supported and whether it is
> [RG] succesful (or whether it wasn't).
> [RG] To me this seems to be a loose cooperation. If NSIS and
> [RG] SEAMOBY conclude to ignore each other, I'd regard both
> [RG] as a waste of time with regard to wireless mobility
> [RG] combined with QoS.
>
> Regards, Rüdiger
>

------_=_NextPart_001_01C228E9.D1A64AE4-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Thu Jul 11 10:54:50 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19852 for ; Thu, 11 Jul 2002 10:54:50 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA12923; Thu, 11 Jul 2002 10:51:33 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA12819 for ; Thu, 11 Jul 2002 10:51:27 -0400 (EDT) Received: from mgw-dax2.ext.nokia.com (mgw-dax2.ext.nokia.com [63.78.179.217]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19713; Thu, 11 Jul 2002 10:50:33 -0400 (EDT) From: Hemant.Chaskar@nokia.com Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85]) by mgw-dax2.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g6BEtAj11908; Thu, 11 Jul 2002 09:55:10 -0500 (CDT) Received: from daebh001.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 11 Jul 2002 09:51:25 -0500 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Thu, 11 Jul 2002 09:51:25 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Seamoby] RE: [NSIS] Re: draft-westphal-nsis-qos-mobileip-00.txt Date: Thu, 11 Jul 2002 10:51:24 -0400 Message-ID: Thread-Topic: [Seamoby] RE: [NSIS] Re: draft-westphal-nsis-qos-mobileip-00.txt Thread-Index: AcIoX3b7S89XNHCNQA+R55RD7Gv5YwAid8OQ To: , , Cc: , , X-OriginalArrivalTime: 11 Jul 2002 14:51:25.0817 (UTC) FILETIME=[6E52BE90:01C228EA] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id KAA12820 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 8bit Hi James: Please see inline: -----Original Message----- From: ext James Kempf [mailto:kempf@docomolabs-usa.com] Sent: 10. July 2002 18:15 To: Nakhjiri Madjid-MNAKHJI1; Rajeev Koodli; Chaskar Hemant (NRC/Boston) Cc: gkenward@nortelnetworks.com; seamoby@ietf.org; nsis@ietf.org Subject: Re: [Seamoby] RE: [NSIS] Re: draft-westphal-nsis-qos-mobileip-00.txt I guess I didn't make my point clear. The point I was trying to make is that given CT of QoS context succeeds, NSIS signaling at the new access subnet is unnecessary. Thus, it could be viewed as a kind of optimization. If CT fails, then signaling would be needed. [Hemant] If you mean here that NSIS signaling *between MN and new AR* at the new access subnet is unnecessary, then I agree with you. I did not mean to imply that any changes were required in the generic CT requirements (though perhaps there would need to be some changes in the QoS specific context definition). [Hemant] If CT is merely a carrier protocol, it should be easy to define NSIS payload types to be carried within it. So, I agree that changes may not be required to requirements. Is this accurate, from the NSIS viewpoint? One case where I could see it not being accurate is if there were some changes required behind the access router in order to obtain QoS for the mobile on the new router, but perhaps there are others. [Hemant] Yes, that is one case where NSIS will need to do signaling even after CT. There is also another case, which is when service at new AR is different than that at old AR (2.5G to WLAN handoff). Since, negotiation is out of scope of CT, CT would merely transfer old service description (say thrpt. = 100 kpbs) to new AR. But new AR can actually offer 1000 kbps to flow. NSIS has to later adapt to such changes. Of course, this function could be delegated to CARD, then transferred QoS context will say 1000 kbps in the first place. -Hemant jak ----- Original Message ----- From: "Nakhjiri Madjid-MNAKHJI1" To: "'James Kempf'" ; "Rajeev Koodli" ; Cc: ; ; Sent: Wednesday, July 10, 2002 11:58 AM Subject: RE: [Seamoby] RE: [NSIS] Re: draft-westphal-nsis-qos-mobileip-00.txt > James, > > As much as I like to see a clean interaction between CT and NSIS, > I don't see any reason why CT needs to play the role of NSIS optimization, > not to forget the NSIS didn't even exist back then. > > CT is simply a tool you need in your seamless mobility toolbox, it > eventually > involved into a container carrying any context you like (even non-IP > context, as > long as it is feasible). The profile types, that Rajeev mentioned is aligned > with > this line of thinking. > > I seriously advise against going back and change CT > requirements for the sake of optimizing NSIS, which at this point we don't > know > what it is. A couple of months from now, we have to revise CT because of a > security > related protocol, later for something else..... > > > The later we wait for CT standardization, the more home brewed versions are > going to pop up, just like Behcet mentioned. > > My 1.5 cents (lower dollars) > > Madjid > > -----Original Message----- > From: James Kempf [mailto:kempf@docomolabs-usa.com] > Sent: Monday, July 08, 2002 4:37 PM > To: Rajeev Koodli; Hemant.Chaskar@nokia.com > Cc: gkenward@nortelnetworks.com; seamoby@ietf.org; nsis@ietf.org > Subject: Re: [Seamoby] RE: [NSIS] Re: > draft-westphal-nsis-qos-mobileip-00.txt > > > > CT is an optimization to avoid signaling and the associated overheads, and > maintain > > desirable transport (RTP/TCP)performance. A historical note: CT was not > designed > > to be an optimization for NSIS. > > > > Do you mean that the requirements weren't so designed? Because, to my > knowledge, the WG has not yet settled on a design. We are > currently awaiting IESG feedback on our requirements. The problem statement > was just approved by the IESG. > > jak > > > _______________________________________________ > 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 From daemon@optimus.ietf.org Thu Jul 11 10:54:50 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19860 for ; Thu, 11 Jul 2002 10:54:50 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA13167 for seamoby-archive@odin.ietf.org; Thu, 11 Jul 2002 10:55:42 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA12923; Thu, 11 Jul 2002 10:51:33 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA12819 for ; Thu, 11 Jul 2002 10:51:27 -0400 (EDT) Received: from mgw-dax2.ext.nokia.com (mgw-dax2.ext.nokia.com [63.78.179.217]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19713; Thu, 11 Jul 2002 10:50:33 -0400 (EDT) From: Hemant.Chaskar@nokia.com Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85]) by mgw-dax2.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g6BEtAj11908; Thu, 11 Jul 2002 09:55:10 -0500 (CDT) Received: from daebh001.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 11 Jul 2002 09:51:25 -0500 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Thu, 11 Jul 2002 09:51:25 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Seamoby] RE: [NSIS] Re: draft-westphal-nsis-qos-mobileip-00.txt Date: Thu, 11 Jul 2002 10:51:24 -0400 Message-ID: Thread-Topic: [Seamoby] RE: [NSIS] Re: draft-westphal-nsis-qos-mobileip-00.txt Thread-Index: AcIoX3b7S89XNHCNQA+R55RD7Gv5YwAid8OQ To: , , Cc: , , X-OriginalArrivalTime: 11 Jul 2002 14:51:25.0817 (UTC) FILETIME=[6E52BE90:01C228EA] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id KAA12820 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 8bit Hi James: Please see inline: -----Original Message----- From: ext James Kempf [mailto:kempf@docomolabs-usa.com] Sent: 10. July 2002 18:15 To: Nakhjiri Madjid-MNAKHJI1; Rajeev Koodli; Chaskar Hemant (NRC/Boston) Cc: gkenward@nortelnetworks.com; seamoby@ietf.org; nsis@ietf.org Subject: Re: [Seamoby] RE: [NSIS] Re: draft-westphal-nsis-qos-mobileip-00.txt I guess I didn't make my point clear. The point I was trying to make is that given CT of QoS context succeeds, NSIS signaling at the new access subnet is unnecessary. Thus, it could be viewed as a kind of optimization. If CT fails, then signaling would be needed. [Hemant] If you mean here that NSIS signaling *between MN and new AR* at the new access subnet is unnecessary, then I agree with you. I did not mean to imply that any changes were required in the generic CT requirements (though perhaps there would need to be some changes in the QoS specific context definition). [Hemant] If CT is merely a carrier protocol, it should be easy to define NSIS payload types to be carried within it. So, I agree that changes may not be required to requirements. Is this accurate, from the NSIS viewpoint? One case where I could see it not being accurate is if there were some changes required behind the access router in order to obtain QoS for the mobile on the new router, but perhaps there are others. [Hemant] Yes, that is one case where NSIS will need to do signaling even after CT. There is also another case, which is when service at new AR is different than that at old AR (2.5G to WLAN handoff). Since, negotiation is out of scope of CT, CT would merely transfer old service description (say thrpt. = 100 kpbs) to new AR. But new AR can actually offer 1000 kbps to flow. NSIS has to later adapt to such changes. Of course, this function could be delegated to CARD, then transferred QoS context will say 1000 kbps in the first place. -Hemant jak ----- Original Message ----- From: "Nakhjiri Madjid-MNAKHJI1" To: "'James Kempf'" ; "Rajeev Koodli" ; Cc: ; ; Sent: Wednesday, July 10, 2002 11:58 AM Subject: RE: [Seamoby] RE: [NSIS] Re: draft-westphal-nsis-qos-mobileip-00.txt > James, > > As much as I like to see a clean interaction between CT and NSIS, > I don't see any reason why CT needs to play the role of NSIS optimization, > not to forget the NSIS didn't even exist back then. > > CT is simply a tool you need in your seamless mobility toolbox, it > eventually > involved into a container carrying any context you like (even non-IP > context, as > long as it is feasible). The profile types, that Rajeev mentioned is aligned > with > this line of thinking. > > I seriously advise against going back and change CT > requirements for the sake of optimizing NSIS, which at this point we don't > know > what it is. A couple of months from now, we have to revise CT because of a > security > related protocol, later for something else..... > > > The later we wait for CT standardization, the more home brewed versions are > going to pop up, just like Behcet mentioned. > > My 1.5 cents (lower dollars) > > Madjid > > -----Original Message----- > From: James Kempf [mailto:kempf@docomolabs-usa.com] > Sent: Monday, July 08, 2002 4:37 PM > To: Rajeev Koodli; Hemant.Chaskar@nokia.com > Cc: gkenward@nortelnetworks.com; seamoby@ietf.org; nsis@ietf.org > Subject: Re: [Seamoby] RE: [NSIS] Re: > draft-westphal-nsis-qos-mobileip-00.txt > > > > CT is an optimization to avoid signaling and the associated overheads, and > maintain > > desirable transport (RTP/TCP)performance. A historical note: CT was not > designed > > to be an optimization for NSIS. > > > > Do you mean that the requirements weren't so designed? Because, to my > knowledge, the WG has not yet settled on a design. We are > currently awaiting IESG feedback on our requirements. The problem statement > was just approved by the IESG. > > jak > > > _______________________________________________ > 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 From seamoby-admin@ietf.org Thu Jul 11 12:27:05 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23931 for ; Thu, 11 Jul 2002 12:27:04 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA23287; Thu, 11 Jul 2002 12:24:06 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA23260 for ; Thu, 11 Jul 2002 12:24:03 -0400 (EDT) Received: from fridge.docomolabs-usa.com (fwuser@key1.docomolabs-usa.com [216.98.102.225]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23749 for ; Thu, 11 Jul 2002 12:23:09 -0400 (EDT) Message-ID: <00ba01c228f7$22b3b130$4f6015ac@T23KEMPF> From: "James Kempf" To: "Gary Kenward" , References: <9FBD322B7824D511B36900508BF93C9C01AA4C03@zcard031.ca.nortel.com> Subject: Re: [Seamoby] CT Requirements Comments from IESG Date: Thu, 11 Jul 2002 09:22:22 -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-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit > Perhaps the actual answer is to state exactly what was intended > originally: that the bit order and bit values have to arrive exactly > as they were transmitted. > So this requirement is talking about transmission fidelity? I sure would not have guessed that from reading it. I thought it intended to talk about usability. I would suggest that the wording you have above is really a lot more precise that what is currently in the spec. Any other comments? Could we substitute Gary's wording above for "meaning" in the current requirement. jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Thu Jul 11 12:27:05 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23943 for ; Thu, 11 Jul 2002 12:27:05 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA23695 for seamoby-archive@odin.ietf.org; Thu, 11 Jul 2002 12:27:58 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA23287; Thu, 11 Jul 2002 12:24:06 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA23260 for ; Thu, 11 Jul 2002 12:24:03 -0400 (EDT) Received: from fridge.docomolabs-usa.com (fwuser@key1.docomolabs-usa.com [216.98.102.225]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23749 for ; Thu, 11 Jul 2002 12:23:09 -0400 (EDT) Message-ID: <00ba01c228f7$22b3b130$4f6015ac@T23KEMPF> From: "James Kempf" To: "Gary Kenward" , References: <9FBD322B7824D511B36900508BF93C9C01AA4C03@zcard031.ca.nortel.com> Subject: Re: [Seamoby] CT Requirements Comments from IESG Date: Thu, 11 Jul 2002 09:22:22 -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-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit > Perhaps the actual answer is to state exactly what was intended > originally: that the bit order and bit values have to arrive exactly > as they were transmitted. > So this requirement is talking about transmission fidelity? I sure would not have guessed that from reading it. I thought it intended to talk about usability. I would suggest that the wording you have above is really a lot more precise that what is currently in the spec. Any other comments? Could we substitute Gary's wording above for "meaning" in the current requirement. jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Thu Jul 11 12:30:56 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24195 for ; Thu, 11 Jul 2002 12:30:56 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA23948; Thu, 11 Jul 2002 12:29:34 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA23884 for ; Thu, 11 Jul 2002 12:29:28 -0400 (EDT) Received: from fridge.docomolabs-usa.com (fwuser@key1.docomolabs-usa.com [216.98.102.225]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24060; Thu, 11 Jul 2002 12:28:33 -0400 (EDT) Message-ID: <00c901c228f7$dd8b9220$4f6015ac@T23KEMPF> From: "James Kempf" To: "Gary Kenward" , "'Geib, Ruediger'" , , , Cc: , References: <9FBD322B7824D511B36900508BF93C9C01AA4C05@zcard031.ca.nortel.com> Subject: Re: [Seamoby] RE: [NSIS] Re: draft-westphal-nsis-qos-mobileip-00. txt Date: Thu, 11 Jul 2002 09:27:35 -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-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit > CT is not a service establishment protocol; it tranports forwarding context, not service description parameters. Some of the forwarding context *may* be the original service description parameters, but many *may* be derived values that allow a more representative description of the AR forwarding context. If the service description parameters are involved in fowarding, then the two are the same, right? Will there be any difference for QoS? > For the two groups should discuss the common parameters would be a violation of the respective charters. I think that this is an excellent idea, but I believe it will have to take place outside of the NSIS/Seamoby wgs, and I suggest that it would be best if we knew what the CT/NSIS protocols were - at the very least, we can proceed with the definition of the protocols. We have to make sure the two protocols work well together. CT is not specific to QoS, so I don't see any overlap, but when it comes time to define the QoS feature context type, perhaps that definition can be done by the NSIS group, or in conjunction with it in some way. Requirements, for example. jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Thu Jul 11 12:30:57 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24204 for ; Thu, 11 Jul 2002 12:30:56 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA24724 for seamoby-archive@odin.ietf.org; Thu, 11 Jul 2002 12:31:50 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA23948; Thu, 11 Jul 2002 12:29:34 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA23884 for ; Thu, 11 Jul 2002 12:29:28 -0400 (EDT) Received: from fridge.docomolabs-usa.com (fwuser@key1.docomolabs-usa.com [216.98.102.225]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24060; Thu, 11 Jul 2002 12:28:33 -0400 (EDT) Message-ID: <00c901c228f7$dd8b9220$4f6015ac@T23KEMPF> From: "James Kempf" To: "Gary Kenward" , "'Geib, Ruediger'" , , , Cc: , References: <9FBD322B7824D511B36900508BF93C9C01AA4C05@zcard031.ca.nortel.com> Subject: Re: [Seamoby] RE: [NSIS] Re: draft-westphal-nsis-qos-mobileip-00. txt Date: Thu, 11 Jul 2002 09:27:35 -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-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit > CT is not a service establishment protocol; it tranports forwarding context, not service description parameters. Some of the forwarding context *may* be the original service description parameters, but many *may* be derived values that allow a more representative description of the AR forwarding context. If the service description parameters are involved in fowarding, then the two are the same, right? Will there be any difference for QoS? > For the two groups should discuss the common parameters would be a violation of the respective charters. I think that this is an excellent idea, but I believe it will have to take place outside of the NSIS/Seamoby wgs, and I suggest that it would be best if we knew what the CT/NSIS protocols were - at the very least, we can proceed with the definition of the protocols. We have to make sure the two protocols work well together. CT is not specific to QoS, so I don't see any overlap, but when it comes time to define the QoS feature context type, perhaps that definition can be done by the NSIS group, or in conjunction with it in some way. Requirements, for example. jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Thu Jul 11 15:50:25 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02986 for ; Thu, 11 Jul 2002 15:50:25 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA12373; Thu, 11 Jul 2002 15:48:24 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA12343 for ; Thu, 11 Jul 2002 15:48:22 -0400 (EDT) Received: from zcars04f.ca.nortel.com (zcars04f.nortelnetworks.com [47.129.242.57]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02844 for ; Thu, 11 Jul 2002 15:47:24 -0400 (EDT) Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04f.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g6BJlil25627; Thu, 11 Jul 2002 15:47:44 -0400 (EDT) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 11 Jul 2002 15:47:43 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA4C0C@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'James Kempf'" , seamoby@ietf.org Subject: RE: [Seamoby] CT Requirements Comments from IESG Date: Thu, 11 Jul 2002 15:47:42 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C22913.752BD700" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C22913.752BD700 Content-Type: text/plain; charset="iso-8859-1" You call it fidelity, I call it data integrity. I've seen "data integrity" used in publications (no, I cannot quote references). What we need is a term that everyone, including the IESG, can agree upon. > -----Original Message----- > From: James Kempf [mailto:kempf@docomolabs-usa.com] > Sent: July 11, 2002 12:22 > To: Kenward, Gary [WDLN2:AN10:EXCH]; seamoby@ietf.org > Subject: Re: [Seamoby] CT Requirements Comments from IESG > > > > Perhaps the actual answer is to state exactly what was intended > > originally: that the bit order and bit values have to arrive exactly > > as they were transmitted. > > > > So this requirement is talking about transmission fidelity? I > sure would not have guessed that from reading it. I thought it > intended to talk about usability. > > I would suggest that the wording you have above is really a > lot more precise that what is currently in the spec. > > Any other comments? Could we substitute Gary's wording above > for "meaning" in the current requirement. > > jak > > ------_=_NextPart_001_01C22913.752BD700 Content-Type: text/html; charset="iso-8859-1" RE: [Seamoby] CT Requirements Comments from IESG

You call it fidelity, I call it data integrity.
I've seen "data integrity" used in publications
(no, I cannot quote references).

What we need is a term that everyone, including the
IESG, can agree upon.

> -----Original Message-----
> From: James Kempf [mailto:kempf@docomolabs-usa.com]
> Sent: July 11, 2002 12:22
> To: Kenward, Gary [WDLN2:AN10:EXCH]; seamoby@ietf.org
> Subject: Re: [Seamoby] CT Requirements Comments from IESG
>
>
> > Perhaps the actual answer is to state exactly what was intended
> > originally: that the bit order and bit values have to arrive exactly
> > as they were transmitted.
> >
>
> So this requirement is talking about transmission fidelity? I
> sure would not have guessed that from reading it. I thought it
> intended to talk about usability.
>
> I would suggest that the wording you have above is really a
> lot more precise that what is currently in the spec.
>
> Any other comments? Could we substitute Gary's wording above
> for "meaning" in the current requirement.
>
>             jak
>
>

------_=_NextPart_001_01C22913.752BD700-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Thu Jul 11 15:50:26 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02994 for ; Thu, 11 Jul 2002 15:50:26 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA12450 for seamoby-archive@odin.ietf.org; Thu, 11 Jul 2002 15:51:19 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA12373; Thu, 11 Jul 2002 15:48:24 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA12343 for ; Thu, 11 Jul 2002 15:48:22 -0400 (EDT) Received: from zcars04f.ca.nortel.com (zcars04f.nortelnetworks.com [47.129.242.57]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02844 for ; Thu, 11 Jul 2002 15:47:24 -0400 (EDT) Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04f.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g6BJlil25627; Thu, 11 Jul 2002 15:47:44 -0400 (EDT) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 11 Jul 2002 15:47:43 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA4C0C@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'James Kempf'" , seamoby@ietf.org Subject: RE: [Seamoby] CT Requirements Comments from IESG Date: Thu, 11 Jul 2002 15:47:42 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C22913.752BD700" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C22913.752BD700 Content-Type: text/plain; charset="iso-8859-1" You call it fidelity, I call it data integrity. I've seen "data integrity" used in publications (no, I cannot quote references). What we need is a term that everyone, including the IESG, can agree upon. > -----Original Message----- > From: James Kempf [mailto:kempf@docomolabs-usa.com] > Sent: July 11, 2002 12:22 > To: Kenward, Gary [WDLN2:AN10:EXCH]; seamoby@ietf.org > Subject: Re: [Seamoby] CT Requirements Comments from IESG > > > > Perhaps the actual answer is to state exactly what was intended > > originally: that the bit order and bit values have to arrive exactly > > as they were transmitted. > > > > So this requirement is talking about transmission fidelity? I > sure would not have guessed that from reading it. I thought it > intended to talk about usability. > > I would suggest that the wording you have above is really a > lot more precise that what is currently in the spec. > > Any other comments? Could we substitute Gary's wording above > for "meaning" in the current requirement. > > jak > > ------_=_NextPart_001_01C22913.752BD700 Content-Type: text/html; charset="iso-8859-1" RE: [Seamoby] CT Requirements Comments from IESG

You call it fidelity, I call it data integrity.
I've seen "data integrity" used in publications
(no, I cannot quote references).

What we need is a term that everyone, including the
IESG, can agree upon.

> -----Original Message-----
> From: James Kempf [mailto:kempf@docomolabs-usa.com]
> Sent: July 11, 2002 12:22
> To: Kenward, Gary [WDLN2:AN10:EXCH]; seamoby@ietf.org
> Subject: Re: [Seamoby] CT Requirements Comments from IESG
>
>
> > Perhaps the actual answer is to state exactly what was intended
> > originally: that the bit order and bit values have to arrive exactly
> > as they were transmitted.
> >
>
> So this requirement is talking about transmission fidelity? I
> sure would not have guessed that from reading it. I thought it
> intended to talk about usability.
>
> I would suggest that the wording you have above is really a
> lot more precise that what is currently in the spec.
>
> Any other comments? Could we substitute Gary's wording above
> for "meaning" in the current requirement.
>
>             jak
>
>

------_=_NextPart_001_01C22913.752BD700-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Thu Jul 11 15:57:57 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03348 for ; Thu, 11 Jul 2002 15:57:57 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA12751; Thu, 11 Jul 2002 15:56:58 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA12688 for ; Thu, 11 Jul 2002 15:56:54 -0400 (EDT) Received: from zcars04f.ca.nortel.com (zcars04f.nortelnetworks.com [47.129.242.57]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03232; Thu, 11 Jul 2002 15:56:00 -0400 (EDT) Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04f.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g6BJrXl26163; Thu, 11 Jul 2002 15:53:33 -0400 (EDT) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 11 Jul 2002 15:53:33 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA4C0D@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'James Kempf'" , "'Geib, Ruediger'" , Madjid.Nakhjiri@motorola.com, rajeev@iprg.nokia.com, Hemant.Chaskar@nokia.com Cc: seamoby@ietf.org, nsis@ietf.org Subject: RE: [Seamoby] RE: [NSIS] Re: draft-westphal-nsis-qos-mobileip-00. txt Date: Thu, 11 Jul 2002 15:53:22 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C22913.D99AE640" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C22913.D99AE640 Content-Type: text/plain; charset="iso-8859-1" The point was not that the parameters will be the same or different. The point was that discussion of the context make up is out of scope for Seamoby, and discussion of QoS parameters is out of scope for NSIS. It is too great a leap of faith to say that the NSIS parameters will be the configuration context. Thus, while I agree that the two protocols must interwork, there is nothing we can do about matching the NSIS parameters with the Context, without a change in charter. The one step we could take (but not the one that was suggested) would be to investigate into ensuring some commonality between the formats for encapsulating the respective data chunks (i.e. context/NSIS parameters). Or at least, provide for NSIS to carry CT data chunks and visa versa. gary > -----Original Message----- > From: James Kempf [mailto:kempf@docomolabs-usa.com] > Sent: July 11, 2002 12:28 > To: Kenward, Gary [WDLN2:AN10:EXCH]; 'Geib, Ruediger'; > Madjid.Nakhjiri@motorola.com; rajeev@iprg.nokia.com; > Hemant.Chaskar@nokia.com > Cc: seamoby@ietf.org; nsis@ietf.org > Subject: Re: [Seamoby] RE: [NSIS] Re: > draft-westphal-nsis-qos-mobileip-00. txt > > > > CT is not a service establishment protocol; it tranports > forwarding context, not service description parameters. Some > of the forwarding context *may* be the original > service description > parameters, but many *may* be derived values that allow a more > representative description of the AR forwarding context. > > If the service description parameters are involved in > fowarding, then the two are the same, right? Will there be any > difference for QoS? > > > > For the two groups should discuss the common parameters would be a > violation of the respective charters. I think that this is an > excellent > idea, but I believe it will have to take place outside of the > NSIS/Seamoby > wgs, and I suggest that it would be best if we knew > what the CT/NSIS > protocols were - at the very least, we can proceed with the > definition > of the protocols. > > We have to make sure the two protocols work well together. > > CT is not specific to QoS, so I don't see any overlap, but > when it comes time to define the QoS feature context type, perhaps > that definition can be done by the NSIS group, or in > conjunction with it in some way. Requirements, for example. > > jak > > ------_=_NextPart_001_01C22913.D99AE640 Content-Type: text/html; charset="iso-8859-1" RE: [Seamoby] RE: [NSIS] Re: draft-westphal-nsis-qos-mobileip-00. txt

The point was not that the parameters will be the same or different.
The point was that discussion of the context make up is out of scope
for Seamoby, and discussion of QoS parameters is out of scope for
NSIS. It is too great a leap of faith to say that the NSIS parameters
will be the configuration context. Thus, while I agree that the two
protocols must interwork, there is nothing we can do about matching
the NSIS parameters with the Context, without a change in charter.

The one step we could take (but not the one that was suggested) would
be to investigate into ensuring some commonality between the formats for
encapsulating the respective data chunks (i.e. context/NSIS parameters).
Or at least, provide for NSIS to carry CT data chunks and visa versa.

gary

> -----Original Message-----
> From: James Kempf [mailto:kempf@docomolabs-usa.com]
> Sent: July 11, 2002 12:28
> To: Kenward, Gary [WDLN2:AN10:EXCH]; 'Geib, Ruediger';
> Madjid.Nakhjiri@motorola.com; rajeev@iprg.nokia.com;
> Hemant.Chaskar@nokia.com
> Cc: seamoby@ietf.org; nsis@ietf.org
> Subject: Re: [Seamoby] RE: [NSIS] Re:
> draft-westphal-nsis-qos-mobileip-00. txt
>
>
> > CT is not a service establishment protocol; it tranports
>        forwarding context, not service description parameters. Some
>        of the forwarding context *may* be the original
> service description
>        parameters, but many *may* be derived values that allow a more
>        representative description of the AR forwarding context.
>
> If the service description parameters are involved in
> fowarding, then the two are the same, right? Will there be any
> difference for QoS?
>
>
> > For the two groups should discuss the common parameters would be a
>        violation of the respective charters. I think that this is an
> excellent
>        idea, but I believe it will have to take place outside of the
> NSIS/Seamoby
>        wgs, and I suggest that it would be best if we knew
> what the CT/NSIS
>        protocols were - at the very least, we can proceed with the
> definition
>        of the protocols.
>
> We have to make sure the two protocols work well together.
>
> CT is not specific to QoS, so I don't see any overlap, but
> when it comes time to define the QoS feature context type, perhaps
> that definition can be done by the NSIS group, or in
> conjunction with it in some way. Requirements, for example.
>
>             jak
>
>

------_=_NextPart_001_01C22913.D99AE640-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Thu Jul 11 15:57:58 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03354 for ; Thu, 11 Jul 2002 15:57:58 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA12856 for seamoby-archive@odin.ietf.org; Thu, 11 Jul 2002 15:58:51 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA12751; Thu, 11 Jul 2002 15:56:58 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA12688 for ; Thu, 11 Jul 2002 15:56:54 -0400 (EDT) Received: from zcars04f.ca.nortel.com (zcars04f.nortelnetworks.com [47.129.242.57]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03232; Thu, 11 Jul 2002 15:56:00 -0400 (EDT) Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04f.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g6BJrXl26163; Thu, 11 Jul 2002 15:53:33 -0400 (EDT) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 11 Jul 2002 15:53:33 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA4C0D@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'James Kempf'" , "'Geib, Ruediger'" , Madjid.Nakhjiri@motorola.com, rajeev@iprg.nokia.com, Hemant.Chaskar@nokia.com Cc: seamoby@ietf.org, nsis@ietf.org Subject: RE: [Seamoby] RE: [NSIS] Re: draft-westphal-nsis-qos-mobileip-00. txt Date: Thu, 11 Jul 2002 15:53:22 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C22913.D99AE640" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C22913.D99AE640 Content-Type: text/plain; charset="iso-8859-1" The point was not that the parameters will be the same or different. The point was that discussion of the context make up is out of scope for Seamoby, and discussion of QoS parameters is out of scope for NSIS. It is too great a leap of faith to say that the NSIS parameters will be the configuration context. Thus, while I agree that the two protocols must interwork, there is nothing we can do about matching the NSIS parameters with the Context, without a change in charter. The one step we could take (but not the one that was suggested) would be to investigate into ensuring some commonality between the formats for encapsulating the respective data chunks (i.e. context/NSIS parameters). Or at least, provide for NSIS to carry CT data chunks and visa versa. gary > -----Original Message----- > From: James Kempf [mailto:kempf@docomolabs-usa.com] > Sent: July 11, 2002 12:28 > To: Kenward, Gary [WDLN2:AN10:EXCH]; 'Geib, Ruediger'; > Madjid.Nakhjiri@motorola.com; rajeev@iprg.nokia.com; > Hemant.Chaskar@nokia.com > Cc: seamoby@ietf.org; nsis@ietf.org > Subject: Re: [Seamoby] RE: [NSIS] Re: > draft-westphal-nsis-qos-mobileip-00. txt > > > > CT is not a service establishment protocol; it tranports > forwarding context, not service description parameters. Some > of the forwarding context *may* be the original > service description > parameters, but many *may* be derived values that allow a more > representative description of the AR forwarding context. > > If the service description parameters are involved in > fowarding, then the two are the same, right? Will there be any > difference for QoS? > > > > For the two groups should discuss the common parameters would be a > violation of the respective charters. I think that this is an > excellent > idea, but I believe it will have to take place outside of the > NSIS/Seamoby > wgs, and I suggest that it would be best if we knew > what the CT/NSIS > protocols were - at the very least, we can proceed with the > definition > of the protocols. > > We have to make sure the two protocols work well together. > > CT is not specific to QoS, so I don't see any overlap, but > when it comes time to define the QoS feature context type, perhaps > that definition can be done by the NSIS group, or in > conjunction with it in some way. Requirements, for example. > > jak > > ------_=_NextPart_001_01C22913.D99AE640 Content-Type: text/html; charset="iso-8859-1" RE: [Seamoby] RE: [NSIS] Re: draft-westphal-nsis-qos-mobileip-00. txt

The point was not that the parameters will be the same or different.
The point was that discussion of the context make up is out of scope
for Seamoby, and discussion of QoS parameters is out of scope for
NSIS. It is too great a leap of faith to say that the NSIS parameters
will be the configuration context. Thus, while I agree that the two
protocols must interwork, there is nothing we can do about matching
the NSIS parameters with the Context, without a change in charter.

The one step we could take (but not the one that was suggested) would
be to investigate into ensuring some commonality between the formats for
encapsulating the respective data chunks (i.e. context/NSIS parameters).
Or at least, provide for NSIS to carry CT data chunks and visa versa.

gary

> -----Original Message-----
> From: James Kempf [mailto:kempf@docomolabs-usa.com]
> Sent: July 11, 2002 12:28
> To: Kenward, Gary [WDLN2:AN10:EXCH]; 'Geib, Ruediger';
> Madjid.Nakhjiri@motorola.com; rajeev@iprg.nokia.com;
> Hemant.Chaskar@nokia.com
> Cc: seamoby@ietf.org; nsis@ietf.org
> Subject: Re: [Seamoby] RE: [NSIS] Re:
> draft-westphal-nsis-qos-mobileip-00. txt
>
>
> > CT is not a service establishment protocol; it tranports
>        forwarding context, not service description parameters. Some
>        of the forwarding context *may* be the original
> service description
>        parameters, but many *may* be derived values that allow a more
>        representative description of the AR forwarding context.
>
> If the service description parameters are involved in
> fowarding, then the two are the same, right? Will there be any
> difference for QoS?
>
>
> > For the two groups should discuss the common parameters would be a
>        violation of the respective charters. I think that this is an
> excellent
>        idea, but I believe it will have to take place outside of the
> NSIS/Seamoby
>        wgs, and I suggest that it would be best if we knew
> what the CT/NSIS
>        protocols were - at the very least, we can proceed with the
> definition
>        of the protocols.
>
> We have to make sure the two protocols work well together.
>
> CT is not specific to QoS, so I don't see any overlap, but
> when it comes time to define the QoS feature context type, perhaps
> that definition can be done by the NSIS group, or in
> conjunction with it in some way. Requirements, for example.
>
>             jak
>
>

------_=_NextPart_001_01C22913.D99AE640-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Thu Jul 11 16:06:53 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03805 for ; Thu, 11 Jul 2002 16:06:53 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA13649; Thu, 11 Jul 2002 16:06:08 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA13620 for ; Thu, 11 Jul 2002 16:06:06 -0400 (EDT) Received: from fridge.docomolabs-usa.com (fwuser@key1.docomolabs-usa.com [216.98.102.225]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03709 for ; Thu, 11 Jul 2002 16:05:12 -0400 (EDT) Message-ID: <02ff01c22916$26e0c800$4f6015ac@T23KEMPF> From: "James Kempf" To: "Gary Kenward" , References: <9FBD322B7824D511B36900508BF93C9C01AA4C0C@zcard031.ca.nortel.com> Subject: Re: [Seamoby] CT Requirements Comments from IESG Date: Thu, 11 Jul 2002 13:04:23 -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-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit Gary, All we need to do is agree on some wording that is precise enough for the IESG. I like your wording. Can you please substitute "bit order and bit values" for "meaning" in the requirement? Unless there is any objection from the WG. jak ----- Original Message ----- From: "Gary Kenward" To: "'James Kempf'" ; Sent: Thursday, July 11, 2002 12:47 PM Subject: RE: [Seamoby] CT Requirements Comments from IESG > You call it fidelity, I call it data integrity. > I've seen "data integrity" used in publications > (no, I cannot quote references). > > What we need is a term that everyone, including the > IESG, can agree upon. > > > -----Original Message----- > > From: James Kempf [mailto:kempf@docomolabs-usa.com] > > Sent: July 11, 2002 12:22 > > To: Kenward, Gary [WDLN2:AN10:EXCH]; seamoby@ietf.org > > Subject: Re: [Seamoby] CT Requirements Comments from IESG > > > > > > > Perhaps the actual answer is to state exactly what was intended > > > originally: that the bit order and bit values have to arrive exactly > > > as they were transmitted. > > > > > > > So this requirement is talking about transmission fidelity? I > > sure would not have guessed that from reading it. I thought it > > intended to talk about usability. > > > > I would suggest that the wording you have above is really a > > lot more precise that what is currently in the spec. > > > > Any other comments? Could we substitute Gary's wording above > > for "meaning" in the current requirement. > > > > jak > > > > > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Thu Jul 11 16:06:53 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03811 for ; Thu, 11 Jul 2002 16:06:53 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA13712 for seamoby-archive@odin.ietf.org; Thu, 11 Jul 2002 16:07:47 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA13649; Thu, 11 Jul 2002 16:06:08 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA13620 for ; Thu, 11 Jul 2002 16:06:06 -0400 (EDT) Received: from fridge.docomolabs-usa.com (fwuser@key1.docomolabs-usa.com [216.98.102.225]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03709 for ; Thu, 11 Jul 2002 16:05:12 -0400 (EDT) Message-ID: <02ff01c22916$26e0c800$4f6015ac@T23KEMPF> From: "James Kempf" To: "Gary Kenward" , References: <9FBD322B7824D511B36900508BF93C9C01AA4C0C@zcard031.ca.nortel.com> Subject: Re: [Seamoby] CT Requirements Comments from IESG Date: Thu, 11 Jul 2002 13:04:23 -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-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit Gary, All we need to do is agree on some wording that is precise enough for the IESG. I like your wording. Can you please substitute "bit order and bit values" for "meaning" in the requirement? Unless there is any objection from the WG. jak ----- Original Message ----- From: "Gary Kenward" To: "'James Kempf'" ; Sent: Thursday, July 11, 2002 12:47 PM Subject: RE: [Seamoby] CT Requirements Comments from IESG > You call it fidelity, I call it data integrity. > I've seen "data integrity" used in publications > (no, I cannot quote references). > > What we need is a term that everyone, including the > IESG, can agree upon. > > > -----Original Message----- > > From: James Kempf [mailto:kempf@docomolabs-usa.com] > > Sent: July 11, 2002 12:22 > > To: Kenward, Gary [WDLN2:AN10:EXCH]; seamoby@ietf.org > > Subject: Re: [Seamoby] CT Requirements Comments from IESG > > > > > > > Perhaps the actual answer is to state exactly what was intended > > > originally: that the bit order and bit values have to arrive exactly > > > as they were transmitted. > > > > > > > So this requirement is talking about transmission fidelity? I > > sure would not have guessed that from reading it. I thought it > > intended to talk about usability. > > > > I would suggest that the wording you have above is really a > > lot more precise that what is currently in the spec. > > > > Any other comments? Could we substitute Gary's wording above > > for "meaning" in the current requirement. > > > > jak > > > > > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Thu Jul 11 16:20:22 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04373 for ; Thu, 11 Jul 2002 16:20:22 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA14212; Thu, 11 Jul 2002 16:19:16 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA14049 for ; Thu, 11 Jul 2002 16:18:43 -0400 (EDT) Received: from fridge.docomolabs-usa.com (fwuser@key1.docomolabs-usa.com [216.98.102.225]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04285; Thu, 11 Jul 2002 16:17:48 -0400 (EDT) Message-ID: <030c01c22916$5f16bc20$4f6015ac@T23KEMPF> From: "James Kempf" To: "Gary Kenward" , "'Geib, Ruediger'" , , , Cc: , References: <9FBD322B7824D511B36900508BF93C9C01AA4C0D@zcard031.ca.nortel.com> Subject: Re: [Seamoby] RE: [NSIS] Re: draft-westphal-nsis-qos-mobileip-00. txt Date: Thu, 11 Jul 2002 13:05:58 -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-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit > The one step we could take (but not the one that was suggested) would > be to investigate into ensuring some commonality between the formats for > encapsulating the respective data chunks (i.e. context/NSIS parameters). > Or at least, provide for NSIS to carry CT data chunks and visa versa. > Right, that is in fact the kind of thing I had in mind. If you don't want to call it QoS context, call it "NSIS context". jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Thu Jul 11 16:20:22 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04383 for ; Thu, 11 Jul 2002 16:20:22 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA14303 for seamoby-archive@odin.ietf.org; Thu, 11 Jul 2002 16:21:16 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA14212; Thu, 11 Jul 2002 16:19:16 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA14049 for ; Thu, 11 Jul 2002 16:18:43 -0400 (EDT) Received: from fridge.docomolabs-usa.com (fwuser@key1.docomolabs-usa.com [216.98.102.225]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04285; Thu, 11 Jul 2002 16:17:48 -0400 (EDT) Message-ID: <030c01c22916$5f16bc20$4f6015ac@T23KEMPF> From: "James Kempf" To: "Gary Kenward" , "'Geib, Ruediger'" , , , Cc: , References: <9FBD322B7824D511B36900508BF93C9C01AA4C0D@zcard031.ca.nortel.com> Subject: Re: [Seamoby] RE: [NSIS] Re: draft-westphal-nsis-qos-mobileip-00. txt Date: Thu, 11 Jul 2002 13:05:58 -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-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit > The one step we could take (but not the one that was suggested) would > be to investigate into ensuring some commonality between the formats for > encapsulating the respective data chunks (i.e. context/NSIS parameters). > Or at least, provide for NSIS to carry CT data chunks and visa versa. > Right, that is in fact the kind of thing I had in mind. If you don't want to call it QoS context, call it "NSIS context". jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Thu Jul 11 16:33:07 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04918 for ; Thu, 11 Jul 2002 16:33:07 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA15016; Thu, 11 Jul 2002 16:31:18 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA14939 for ; Thu, 11 Jul 2002 16:31:13 -0400 (EDT) Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04757 for ; Thu, 11 Jul 2002 16:30:19 -0400 (EDT) From: Dirk.Trossen@nokia.com Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84]) by mgw-dax1.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g6BKVhx03951 for ; Thu, 11 Jul 2002 15:31:43 -0500 (CDT) Received: from daebh001.NOE.Nokia.com (unverified) by davir01nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 11 Jul 2002 15:31:12 -0500 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Thu, 11 Jul 2002 15:30:01 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C22919.BAFB5061" Subject: RE: [Seamoby] CT Requirements Comments from IESG Date: Thu, 11 Jul 2002 16:30:00 -0400 Message-ID: Thread-Topic: [Seamoby] CT Requirements Comments from IESG Thread-Index: AcIpFQd8bNm2odPFQe+LMlh1eRvN5AAAQ0TQ To: , , X-OriginalArrivalTime: 11 Jul 2002 20:30:01.0994 (UTC) FILETIME=[BBB556A0:01C22919] Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C22919.BAFB5061 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi all, =20 jumping in as somebody who has been an observer so far, struggling with = the current discussion on 'integrity'. =20 When I look at the current wording, i.e.,=20 "5.5.2 A context update MUST preserve the integrity, and thus the = meaning, of the context=20 at each receiving AR. The context at the AR actually supporting an MN's = traffic will change with time.=20 For example, the MN may initiate new microflow(s), or discontinue = existing microflows. Any change of context=20 at the supporting AR must be replicated at those ARs that have already = received context for that MN.",=20 =20 and compare this to the plain integrity of the actually transmitted data = (i.e., its bits and therefore its semantics) that has been brought to the table as a replacement now, I'm quite = confident that this is not what the requirement=20 is talking about.=20 =20 If we remove the word 'meaning' (which is very vague and free for = interpretation for me as well), it is still the word 'integrity' left, which is more than plain integrity of the transmitted = data, in particular if we look at the following sentences in the requirement, which state what kind of integrity is meant (which = probably also builds the bridge to the vague=20 term 'meaning'), namely that the integrity of a context must be = preserved in the sense that a received context at new=20 AR at some point t must be the same as the context at old AR at the same = time t. This is by far more than plain data=20 integrity of the transmitted data. Even if your data has been = transmitted correctly, the context might be stale (and therefore=20 its integrity is lost) because it had changed at old AR in the = meanwhile. The action to be taken is also given in the text,=20 namely the change of context has to be replicated to the new AR. As you = can (hopefully) see this is by far more than preserving the 'meaning' of each bit. It mandates that changes in the = bit values at one end are reflected at the other end, i.e., it talks about distributed data integrity in my = interpretation of the requirement text. =20 Hence, the actual concern might have been (just guessing) whether or not = it is the task of the CT protocol to=20 preserve the abovementioned integrity. Maybe, the IESG wants to see this = functionality left to the replication logic that resides within each AR. Or on the contrary, they do not see this important topic = covered appropriately.=20 =20 Regards, =20 =20 Dirk=20 -----Original Message----- From: ext Gary Kenward [mailto:gkenward@nortelnetworks.com] Sent: Thursday, July 11, 2002 3:48 PM To: 'James Kempf'; seamoby@ietf.org Subject: RE: [Seamoby] CT Requirements Comments from IESG You call it fidelity, I call it data integrity.=20 I've seen "data integrity" used in publications=20 (no, I cannot quote references).=20 What we need is a term that everyone, including the=20 IESG, can agree upon.=20 > -----Original Message-----=20 > From: James Kempf [ mailto:kempf@docomolabs-usa.com]=20 > Sent: July 11, 2002 12:22=20 > To: Kenward, Gary [WDLN2:AN10:EXCH]; seamoby@ietf.org=20 > Subject: Re: [Seamoby] CT Requirements Comments from IESG=20 >=20 >=20 > > Perhaps the actual answer is to state exactly what was intended=20 > > originally: that the bit order and bit values have to arrive exactly = > > as they were transmitted.=20 > >=20 >=20 > So this requirement is talking about transmission fidelity? I=20 > sure would not have guessed that from reading it. I thought it=20 > intended to talk about usability.=20 >=20 > I would suggest that the wording you have above is really a=20 > lot more precise that what is currently in the spec.=20 >=20 > Any other comments? Could we substitute Gary's wording above=20 > for "meaning" in the current requirement.=20 >=20 > jak=20 >=20 >=20 ------_=_NextPart_001_01C22919.BAFB5061 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Seamoby] CT Requirements Comments from IESG
Hi=20 all,
 
jumping in as somebody who has been an observer so far, = struggling with=20 the current discussion on
'integrity'.
 
When I=20 look at the current wording, i.e.,
"5.5.2 A context update MUST preserve the integrity, and thus = the meaning,=20 of the context
at each receiving AR. The context at the AR actually = supporting an=20 MN's traffic will change with time.
For example, the MN may initiate new microflow(s), or = discontinue=20 existing microflows. Any change of context
at the supporting AR must be replicated at those ARs that have = already=20 received context for that MN.",
 
and = compare this to the plain integrity of the actually transmitted = data=20 (i.e., its bits and therefore its semantics)
that has been brought to the table as a replacement=20 now, I'm quite confident that this is not what = the=20 requirement
is=20 talking about.
 
If we=20 remove the word 'meaning' (which is very vague and free for = interpretation for=20 me as well), it is still the word
'integrity' left, which is more than plain integrity of the = transmitted=20 data, in particular if we look at the following = sentences
in the=20 requirement, which state what kind of integrity is=20 meant (which probably also builds the bridge to the vague =
term=20 'meaning'), namely that the integrity of = a = context must be=20 preserved in the sense that a received context at new =
AR at=20 some point t must be the same as the context at old AR at the = same time t.=20 This is by far more than plain data
integrity of the transmitted data. Even if your data=20 has been transmitted correctly, the context might be stale (and = therefore=20
its=20 integrity is lost) because it had changed at old AR in the = meanwhile. The=20 action to be taken is also given in the text,
namely=20 the change of context has to be replicated to the new AR. = As you can=20 (hopefully) see this is by far more than
preserving the 'meaning' of each bit. It mandates that changes = in the bit=20 values at one end are reflected at the other
end,=20 i.e., it talks about distributed data integrity in my interpretation of = the=20 requirement text.
 
Hence,=20 the actual concern might have been (just guessing) whether or not it is = the task=20 of the CT protocol to
preserve the abovementioned integrity. Maybe, the IESG wants to = see this=20 functionality left to the replication logic that = resides
within=20 each AR. Or on the contrary, they do not see this important topic = covered=20 appropriately.
 
Regards,
 
 
Dirk 
-----Original Message-----
From: ext Gary Kenward=20 [mailto:gkenward@nortelnetworks.com]
Sent: Thursday, July = 11, 2002=20 3:48 PM
To: 'James Kempf'; = seamoby@ietf.org
Subject: RE:=20 [Seamoby] CT Requirements Comments from IESG

You call it fidelity, I call it data = integrity.=20
I've seen "data integrity" used in = publications=20
(no, I cannot quote references).

What we need is a term that everyone, including = the=20
IESG, can agree upon.

> -----Original Message-----
>=20 From: James Kempf [mailto:kempf@docomolabs-usa.com<= /A>]=20
> Sent: July 11, 2002 12:22
>=20 To: Kenward, Gary [WDLN2:AN10:EXCH]; seamoby@ietf.org
> Subject: Re: [Seamoby] CT Requirements Comments from = IESG=20
>
> =
> > Perhaps the actual answer is to state exactly what = was=20 intended
> > originally: that the bit = order and=20 bit values have to arrive exactly
> > = as they=20 were transmitted.
> >
>
> So this requirement is = talking about=20 transmission fidelity? I
> sure would not = have=20 guessed that from reading it. I thought it
>=20 intended to talk about usability.
>=20
> I would suggest that the wording you = have above=20 is really a
> lot more precise that what = is=20 currently in the spec.
>
> Any other comments? Could we substitute Gary's wording = above=20
> for "meaning" in the current = requirement.=20
>
>          =   =20 jak
>
>=20

------_=_NextPart_001_01C22919.BAFB5061-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Thu Jul 11 16:33:08 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04927 for ; Thu, 11 Jul 2002 16:33:08 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA15281 for seamoby-archive@odin.ietf.org; Thu, 11 Jul 2002 16:34:01 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA15016; Thu, 11 Jul 2002 16:31:18 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA14939 for ; Thu, 11 Jul 2002 16:31:13 -0400 (EDT) Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04757 for ; Thu, 11 Jul 2002 16:30:19 -0400 (EDT) From: Dirk.Trossen@nokia.com Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84]) by mgw-dax1.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g6BKVhx03951 for ; Thu, 11 Jul 2002 15:31:43 -0500 (CDT) Received: from daebh001.NOE.Nokia.com (unverified) by davir01nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 11 Jul 2002 15:31:12 -0500 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Thu, 11 Jul 2002 15:30:01 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C22919.BAFB5061" Subject: RE: [Seamoby] CT Requirements Comments from IESG Date: Thu, 11 Jul 2002 16:30:00 -0400 Message-ID: Thread-Topic: [Seamoby] CT Requirements Comments from IESG Thread-Index: AcIpFQd8bNm2odPFQe+LMlh1eRvN5AAAQ0TQ To: , , X-OriginalArrivalTime: 11 Jul 2002 20:30:01.0994 (UTC) FILETIME=[BBB556A0:01C22919] Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C22919.BAFB5061 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi all, =20 jumping in as somebody who has been an observer so far, struggling with = the current discussion on 'integrity'. =20 When I look at the current wording, i.e.,=20 "5.5.2 A context update MUST preserve the integrity, and thus the = meaning, of the context=20 at each receiving AR. The context at the AR actually supporting an MN's = traffic will change with time.=20 For example, the MN may initiate new microflow(s), or discontinue = existing microflows. Any change of context=20 at the supporting AR must be replicated at those ARs that have already = received context for that MN.",=20 =20 and compare this to the plain integrity of the actually transmitted data = (i.e., its bits and therefore its semantics) that has been brought to the table as a replacement now, I'm quite = confident that this is not what the requirement=20 is talking about.=20 =20 If we remove the word 'meaning' (which is very vague and free for = interpretation for me as well), it is still the word 'integrity' left, which is more than plain integrity of the transmitted = data, in particular if we look at the following sentences in the requirement, which state what kind of integrity is meant (which = probably also builds the bridge to the vague=20 term 'meaning'), namely that the integrity of a context must be = preserved in the sense that a received context at new=20 AR at some point t must be the same as the context at old AR at the same = time t. This is by far more than plain data=20 integrity of the transmitted data. Even if your data has been = transmitted correctly, the context might be stale (and therefore=20 its integrity is lost) because it had changed at old AR in the = meanwhile. The action to be taken is also given in the text,=20 namely the change of context has to be replicated to the new AR. As you = can (hopefully) see this is by far more than preserving the 'meaning' of each bit. It mandates that changes in the = bit values at one end are reflected at the other end, i.e., it talks about distributed data integrity in my = interpretation of the requirement text. =20 Hence, the actual concern might have been (just guessing) whether or not = it is the task of the CT protocol to=20 preserve the abovementioned integrity. Maybe, the IESG wants to see this = functionality left to the replication logic that resides within each AR. Or on the contrary, they do not see this important topic = covered appropriately.=20 =20 Regards, =20 =20 Dirk=20 -----Original Message----- From: ext Gary Kenward [mailto:gkenward@nortelnetworks.com] Sent: Thursday, July 11, 2002 3:48 PM To: 'James Kempf'; seamoby@ietf.org Subject: RE: [Seamoby] CT Requirements Comments from IESG You call it fidelity, I call it data integrity.=20 I've seen "data integrity" used in publications=20 (no, I cannot quote references).=20 What we need is a term that everyone, including the=20 IESG, can agree upon.=20 > -----Original Message-----=20 > From: James Kempf [ mailto:kempf@docomolabs-usa.com]=20 > Sent: July 11, 2002 12:22=20 > To: Kenward, Gary [WDLN2:AN10:EXCH]; seamoby@ietf.org=20 > Subject: Re: [Seamoby] CT Requirements Comments from IESG=20 >=20 >=20 > > Perhaps the actual answer is to state exactly what was intended=20 > > originally: that the bit order and bit values have to arrive exactly = > > as they were transmitted.=20 > >=20 >=20 > So this requirement is talking about transmission fidelity? I=20 > sure would not have guessed that from reading it. I thought it=20 > intended to talk about usability.=20 >=20 > I would suggest that the wording you have above is really a=20 > lot more precise that what is currently in the spec.=20 >=20 > Any other comments? Could we substitute Gary's wording above=20 > for "meaning" in the current requirement.=20 >=20 > jak=20 >=20 >=20 ------_=_NextPart_001_01C22919.BAFB5061 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Seamoby] CT Requirements Comments from IESG
Hi=20 all,
 
jumping in as somebody who has been an observer so far, = struggling with=20 the current discussion on
'integrity'.
 
When I=20 look at the current wording, i.e.,
"5.5.2 A context update MUST preserve the integrity, and thus = the meaning,=20 of the context
at each receiving AR. The context at the AR actually = supporting an=20 MN's traffic will change with time.
For example, the MN may initiate new microflow(s), or = discontinue=20 existing microflows. Any change of context
at the supporting AR must be replicated at those ARs that have = already=20 received context for that MN.",
 
and = compare this to the plain integrity of the actually transmitted = data=20 (i.e., its bits and therefore its semantics)
that has been brought to the table as a replacement=20 now, I'm quite confident that this is not what = the=20 requirement
is=20 talking about.
 
If we=20 remove the word 'meaning' (which is very vague and free for = interpretation for=20 me as well), it is still the word
'integrity' left, which is more than plain integrity of the = transmitted=20 data, in particular if we look at the following = sentences
in the=20 requirement, which state what kind of integrity is=20 meant (which probably also builds the bridge to the vague =
term=20 'meaning'), namely that the integrity of = a = context must be=20 preserved in the sense that a received context at new =
AR at=20 some point t must be the same as the context at old AR at the = same time t.=20 This is by far more than plain data
integrity of the transmitted data. Even if your data=20 has been transmitted correctly, the context might be stale (and = therefore=20
its=20 integrity is lost) because it had changed at old AR in the = meanwhile. The=20 action to be taken is also given in the text,
namely=20 the change of context has to be replicated to the new AR. = As you can=20 (hopefully) see this is by far more than
preserving the 'meaning' of each bit. It mandates that changes = in the bit=20 values at one end are reflected at the other
end,=20 i.e., it talks about distributed data integrity in my interpretation of = the=20 requirement text.
 
Hence,=20 the actual concern might have been (just guessing) whether or not it is = the task=20 of the CT protocol to
preserve the abovementioned integrity. Maybe, the IESG wants to = see this=20 functionality left to the replication logic that = resides
within=20 each AR. Or on the contrary, they do not see this important topic = covered=20 appropriately.
 
Regards,
 
 
Dirk 
-----Original Message-----
From: ext Gary Kenward=20 [mailto:gkenward@nortelnetworks.com]
Sent: Thursday, July = 11, 2002=20 3:48 PM
To: 'James Kempf'; = seamoby@ietf.org
Subject: RE:=20 [Seamoby] CT Requirements Comments from IESG

You call it fidelity, I call it data = integrity.=20
I've seen "data integrity" used in = publications=20
(no, I cannot quote references).

What we need is a term that everyone, including = the=20
IESG, can agree upon.

> -----Original Message-----
>=20 From: James Kempf [mailto:kempf@docomolabs-usa.com<= /A>]=20
> Sent: July 11, 2002 12:22
>=20 To: Kenward, Gary [WDLN2:AN10:EXCH]; seamoby@ietf.org
> Subject: Re: [Seamoby] CT Requirements Comments from = IESG=20
>
> =
> > Perhaps the actual answer is to state exactly what = was=20 intended
> > originally: that the bit = order and=20 bit values have to arrive exactly
> > = as they=20 were transmitted.
> >
>
> So this requirement is = talking about=20 transmission fidelity? I
> sure would not = have=20 guessed that from reading it. I thought it
>=20 intended to talk about usability.
>=20
> I would suggest that the wording you = have above=20 is really a
> lot more precise that what = is=20 currently in the spec.
>
> Any other comments? Could we substitute Gary's wording = above=20
> for "meaning" in the current = requirement.=20
>
>          =   =20 jak
>
>=20

------_=_NextPart_001_01C22919.BAFB5061-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Thu Jul 11 17:00:40 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06056 for ; Thu, 11 Jul 2002 17:00:40 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA16069; Thu, 11 Jul 2002 16:57:13 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA16040 for ; Thu, 11 Jul 2002 16:57:12 -0400 (EDT) Received: from zcars04f.ca.nortel.com (zcars04f.nortelnetworks.com [47.129.242.57]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05868 for ; Thu, 11 Jul 2002 16:56:17 -0400 (EDT) Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04f.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g6BKuWl00955; Thu, 11 Jul 2002 16:56:32 -0400 (EDT) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 11 Jul 2002 16:56:32 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA4C14@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'Dirk.Trossen@nokia.com'" , kempf@docomolabs-usa.com, seamoby@ietf.org Subject: RE: [Seamoby] CT Requirements Comments from IESG Date: Thu, 11 Jul 2002 16:56:29 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2291D.6DEF8CA2" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C2291D.6DEF8CA2 Content-Type: text/plain; charset="iso-8859-1" Dirk: A valid point. There is a certain atomic level of granularity which has to be dealt with - that is, there's no protocol in the world that can synchronize changes in information that occur at the source while the information is "in-flight" or being received at the destination. If changes in context while the context is being transferred make a different to the successful performance of CT, then there is no hope. The problem is most significant for state context transfer. E.g. counters will continue to count while CT is moving the context to the destination. Either these changes have no significant impact upon the forwarding service provided at the new AR (e.g. it may not matter that a policing meter misses a few packet counts), or a different mechanism has to be defined for re-establishing the state context. The handover is real and unavoidable. Mitigating the disruption to the service at the new AR is the challenge. It would be nice if the disruption was nil, but unlikely. Gary -----Original Message----- From: Dirk.Trossen@nokia.com [mailto:Dirk.Trossen@nokia.com] Sent: July 11, 2002 16:30 To: Kenward, Gary [WDLN2:AN10:EXCH]; kempf@docomolabs-usa.com; seamoby@ietf.org Subject: RE: [Seamoby] CT Requirements Comments from IESG Hi all, jumping in as somebody who has been an observer so far, struggling with the current discussion on 'integrity'. When I look at the current wording, i.e., "5.5.2 A context update MUST preserve the integrity, and thus the meaning, of the context at each receiving AR. The context at the AR actually supporting an MN's traffic will change with time. For example, the MN may initiate new microflow(s), or discontinue existing microflows. Any change of context at the supporting AR must be replicated at those ARs that have already received context for that MN.", and compare this to the plain integrity of the actually transmitted data (i.e., its bits and therefore its semantics) that has been brought to the table as a replacement now, I'm quite confident that this is not what the requirement is talking about. If we remove the word 'meaning' (which is very vague and free for interpretation for me as well), it is still the word 'integrity' left, which is more than plain integrity of the transmitted data, in particular if we look at the following sentences in the requirement, which state what kind of integrity is meant (which probably also builds the bridge to the vague term 'meaning'), namely that the integrity of a context must be preserved in the sense that a received context at new AR at some point t must be the same as the context at old AR at the same time t. This is by far more than plain data integrity of the transmitted data. Even if your data has been transmitted correctly, the context might be stale (and therefore its integrity is lost) because it had changed at old AR in the meanwhile. The action to be taken is also given in the text, namely the change of context has to be replicated to the new AR. As you can (hopefully) see this is by far more than preserving the 'meaning' of each bit. It mandates that changes in the bit values at one end are reflected at the other end, i.e., it talks about distributed data integrity in my interpretation of the requirement text. Hence, the actual concern might have been (just guessing) whether or not it is the task of the CT protocol to preserve the abovementioned integrity. Maybe, the IESG wants to see this functionality left to the replication logic that resides within each AR. Or on the contrary, they do not see this important topic covered appropriately. Regards, Dirk -----Original Message----- From: ext Gary Kenward [mailto:gkenward@nortelnetworks.com] Sent: Thursday, July 11, 2002 3:48 PM To: 'James Kempf'; seamoby@ietf.org Subject: RE: [Seamoby] CT Requirements Comments from IESG You call it fidelity, I call it data integrity. I've seen "data integrity" used in publications (no, I cannot quote references). What we need is a term that everyone, including the IESG, can agree upon. > -----Original Message----- > From: James Kempf [ mailto:kempf@docomolabs-usa.com ] > Sent: July 11, 2002 12:22 > To: Kenward, Gary [WDLN2:AN10:EXCH]; seamoby@ietf.org > Subject: Re: [Seamoby] CT Requirements Comments from IESG > > > > Perhaps the actual answer is to state exactly what was intended > > originally: that the bit order and bit values have to arrive exactly > > as they were transmitted. > > > > So this requirement is talking about transmission fidelity? I > sure would not have guessed that from reading it. I thought it > intended to talk about usability. > > I would suggest that the wording you have above is really a > lot more precise that what is currently in the spec. > > Any other comments? Could we substitute Gary's wording above > for "meaning" in the current requirement. > > jak > > ------_=_NextPart_001_01C2291D.6DEF8CA2 Content-Type: text/html; charset="iso-8859-1" RE: [Seamoby] CT Requirements Comments from IESG
Dirk:
 
  A valid point. There is a certain atomic level of granularity which has to be
dealt with - that is, there's no protocol in the world that can synchronize changes in
information that occur at the source while the information is "in-flight" or being
received at the destination. If changes in context while the context is being transferred
make a different to the successful performance of CT, then there is no hope.
 
  The problem is most significant for state context transfer. E.g. counters will continue
to count while CT is moving the context to the destination. Either these changes have no
significant impact upon the forwarding service provided at the new AR (e.g. it may not
matter that a policing meter misses a few packet counts), or a different mechanism
has to be defined for re-establishing the state context.
 
  The handover is real and unavoidable. Mitigating the disruption to the service at the new
AR is the challenge. It would be nice if the disruption was nil, but unlikely.
 
Gary
-----Original Message-----
From: Dirk.Trossen@nokia.com [mailto:Dirk.Trossen@nokia.com]
Sent: July 11, 2002 16:30
To: Kenward, Gary [WDLN2:AN10:EXCH]; kempf@docomolabs-usa.com; seamoby@ietf.org
Subject: RE: [Seamoby] CT Requirements Comments from IESG

Hi all,
 
jumping in as somebody who has been an observer so far, struggling with the current discussion on
'integrity'.
 
When I look at the current wording, i.e.,
"5.5.2 A context update MUST preserve the integrity, and thus the meaning, of the context
at each receiving AR. The context at the AR actually supporting an MN's traffic will change with time.
For example, the MN may initiate new microflow(s), or discontinue existing microflows. Any change of context
at the supporting AR must be replicated at those ARs that have already received context for that MN.",
 
and compare this to the plain integrity of the actually transmitted data (i.e., its bits and therefore its semantics)
that has been brought to the table as a replacement now, I'm quite confident that this is not what the requirement
is talking about.
 
If we remove the word 'meaning' (which is very vague and free for interpretation for me as well), it is still the word
'integrity' left, which is more than plain integrity of the transmitted data, in particular if we look at the following sentences
in the requirement, which state what kind of integrity is meant (which probably also builds the bridge to the vague
term 'meaning'), namely that the integrity of a context must be preserved in the sense that a received context at new
AR at some point t must be the same as the context at old AR at the same time t. This is by far more than plain data
integrity of the transmitted data. Even if your data has been transmitted correctly, the context might be stale (and therefore
its integrity is lost) because it had changed at old AR in the meanwhile. The action to be taken is also given in the text,
namely the change of context has to be replicated to the new AR. As you can (hopefully) see this is by far more than
preserving the 'meaning' of each bit. It mandates that changes in the bit values at one end are reflected at the other
end, i.e., it talks about distributed data integrity in my interpretation of the requirement text.
 
Hence, the actual concern might have been (just guessing) whether or not it is the task of the CT protocol to
preserve the abovementioned integrity. Maybe, the IESG wants to see this functionality left to the replication logic that resides
within each AR. Or on the contrary, they do not see this important topic covered appropriately.
 
Regards,
 
 
Dirk 
-----Original Message-----
From: ext Gary Kenward [mailto:gkenward@nortelnetworks.com]
Sent: Thursday, July 11, 2002 3:48 PM
To: 'James Kempf'; seamoby@ietf.org
Subject: RE: [Seamoby] CT Requirements Comments from IESG

You call it fidelity, I call it data integrity.
I've seen "data integrity" used in publications
(no, I cannot quote references).

What we need is a term that everyone, including the
IESG, can agree upon.

> -----Original Message-----
> From: James Kempf [mailto:kempf@docomolabs-usa.com]
> Sent: July 11, 2002 12:22
> To: Kenward, Gary [WDLN2:AN10:EXCH]; seamoby@ietf.org
> Subject: Re: [Seamoby] CT Requirements Comments from IESG
>
>
> > Perhaps the actual answer is to state exactly what was intended
> > originally: that the bit order and bit values have to arrive exactly
> > as they were transmitted.
> >
>
> So this requirement is talking about transmission fidelity? I
> sure would not have guessed that from reading it. I thought it
> intended to talk about usability.
>
> I would suggest that the wording you have above is really a
> lot more precise that what is currently in the spec.
>
> Any other comments? Could we substitute Gary's wording above
> for "meaning" in the current requirement.
>
>             jak
>
>

------_=_NextPart_001_01C2291D.6DEF8CA2-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Thu Jul 11 17:00:41 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06066 for ; Thu, 11 Jul 2002 17:00:40 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA17127 for seamoby-archive@odin.ietf.org; Thu, 11 Jul 2002 17:01:34 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA16069; Thu, 11 Jul 2002 16:57:13 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA16040 for ; Thu, 11 Jul 2002 16:57:12 -0400 (EDT) Received: from zcars04f.ca.nortel.com (zcars04f.nortelnetworks.com [47.129.242.57]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05868 for ; Thu, 11 Jul 2002 16:56:17 -0400 (EDT) Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04f.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g6BKuWl00955; Thu, 11 Jul 2002 16:56:32 -0400 (EDT) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 11 Jul 2002 16:56:32 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA4C14@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'Dirk.Trossen@nokia.com'" , kempf@docomolabs-usa.com, seamoby@ietf.org Subject: RE: [Seamoby] CT Requirements Comments from IESG Date: Thu, 11 Jul 2002 16:56:29 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2291D.6DEF8CA2" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C2291D.6DEF8CA2 Content-Type: text/plain; charset="iso-8859-1" Dirk: A valid point. There is a certain atomic level of granularity which has to be dealt with - that is, there's no protocol in the world that can synchronize changes in information that occur at the source while the information is "in-flight" or being received at the destination. If changes in context while the context is being transferred make a different to the successful performance of CT, then there is no hope. The problem is most significant for state context transfer. E.g. counters will continue to count while CT is moving the context to the destination. Either these changes have no significant impact upon the forwarding service provided at the new AR (e.g. it may not matter that a policing meter misses a few packet counts), or a different mechanism has to be defined for re-establishing the state context. The handover is real and unavoidable. Mitigating the disruption to the service at the new AR is the challenge. It would be nice if the disruption was nil, but unlikely. Gary -----Original Message----- From: Dirk.Trossen@nokia.com [mailto:Dirk.Trossen@nokia.com] Sent: July 11, 2002 16:30 To: Kenward, Gary [WDLN2:AN10:EXCH]; kempf@docomolabs-usa.com; seamoby@ietf.org Subject: RE: [Seamoby] CT Requirements Comments from IESG Hi all, jumping in as somebody who has been an observer so far, struggling with the current discussion on 'integrity'. When I look at the current wording, i.e., "5.5.2 A context update MUST preserve the integrity, and thus the meaning, of the context at each receiving AR. The context at the AR actually supporting an MN's traffic will change with time. For example, the MN may initiate new microflow(s), or discontinue existing microflows. Any change of context at the supporting AR must be replicated at those ARs that have already received context for that MN.", and compare this to the plain integrity of the actually transmitted data (i.e., its bits and therefore its semantics) that has been brought to the table as a replacement now, I'm quite confident that this is not what the requirement is talking about. If we remove the word 'meaning' (which is very vague and free for interpretation for me as well), it is still the word 'integrity' left, which is more than plain integrity of the transmitted data, in particular if we look at the following sentences in the requirement, which state what kind of integrity is meant (which probably also builds the bridge to the vague term 'meaning'), namely that the integrity of a context must be preserved in the sense that a received context at new AR at some point t must be the same as the context at old AR at the same time t. This is by far more than plain data integrity of the transmitted data. Even if your data has been transmitted correctly, the context might be stale (and therefore its integrity is lost) because it had changed at old AR in the meanwhile. The action to be taken is also given in the text, namely the change of context has to be replicated to the new AR. As you can (hopefully) see this is by far more than preserving the 'meaning' of each bit. It mandates that changes in the bit values at one end are reflected at the other end, i.e., it talks about distributed data integrity in my interpretation of the requirement text. Hence, the actual concern might have been (just guessing) whether or not it is the task of the CT protocol to preserve the abovementioned integrity. Maybe, the IESG wants to see this functionality left to the replication logic that resides within each AR. Or on the contrary, they do not see this important topic covered appropriately. Regards, Dirk -----Original Message----- From: ext Gary Kenward [mailto:gkenward@nortelnetworks.com] Sent: Thursday, July 11, 2002 3:48 PM To: 'James Kempf'; seamoby@ietf.org Subject: RE: [Seamoby] CT Requirements Comments from IESG You call it fidelity, I call it data integrity. I've seen "data integrity" used in publications (no, I cannot quote references). What we need is a term that everyone, including the IESG, can agree upon. > -----Original Message----- > From: James Kempf [ mailto:kempf@docomolabs-usa.com ] > Sent: July 11, 2002 12:22 > To: Kenward, Gary [WDLN2:AN10:EXCH]; seamoby@ietf.org > Subject: Re: [Seamoby] CT Requirements Comments from IESG > > > > Perhaps the actual answer is to state exactly what was intended > > originally: that the bit order and bit values have to arrive exactly > > as they were transmitted. > > > > So this requirement is talking about transmission fidelity? I > sure would not have guessed that from reading it. I thought it > intended to talk about usability. > > I would suggest that the wording you have above is really a > lot more precise that what is currently in the spec. > > Any other comments? Could we substitute Gary's wording above > for "meaning" in the current requirement. > > jak > > ------_=_NextPart_001_01C2291D.6DEF8CA2 Content-Type: text/html; charset="iso-8859-1" RE: [Seamoby] CT Requirements Comments from IESG
Dirk:
 
  A valid point. There is a certain atomic level of granularity which has to be
dealt with - that is, there's no protocol in the world that can synchronize changes in
information that occur at the source while the information is "in-flight" or being
received at the destination. If changes in context while the context is being transferred
make a different to the successful performance of CT, then there is no hope.
 
  The problem is most significant for state context transfer. E.g. counters will continue
to count while CT is moving the context to the destination. Either these changes have no
significant impact upon the forwarding service provided at the new AR (e.g. it may not
matter that a policing meter misses a few packet counts), or a different mechanism
has to be defined for re-establishing the state context.
 
  The handover is real and unavoidable. Mitigating the disruption to the service at the new
AR is the challenge. It would be nice if the disruption was nil, but unlikely.
 
Gary
-----Original Message-----
From: Dirk.Trossen@nokia.com [mailto:Dirk.Trossen@nokia.com]
Sent: July 11, 2002 16:30
To: Kenward, Gary [WDLN2:AN10:EXCH]; kempf@docomolabs-usa.com; seamoby@ietf.org
Subject: RE: [Seamoby] CT Requirements Comments from IESG

Hi all,
 
jumping in as somebody who has been an observer so far, struggling with the current discussion on
'integrity'.
 
When I look at the current wording, i.e.,
"5.5.2 A context update MUST preserve the integrity, and thus the meaning, of the context
at each receiving AR. The context at the AR actually supporting an MN's traffic will change with time.
For example, the MN may initiate new microflow(s), or discontinue existing microflows. Any change of context
at the supporting AR must be replicated at those ARs that have already received context for that MN.",
 
and compare this to the plain integrity of the actually transmitted data (i.e., its bits and therefore its semantics)
that has been brought to the table as a replacement now, I'm quite confident that this is not what the requirement
is talking about.
 
If we remove the word 'meaning' (which is very vague and free for interpretation for me as well), it is still the word
'integrity' left, which is more than plain integrity of the transmitted data, in particular if we look at the following sentences
in the requirement, which state what kind of integrity is meant (which probably also builds the bridge to the vague
term 'meaning'), namely that the integrity of a context must be preserved in the sense that a received context at new
AR at some point t must be the same as the context at old AR at the same time t. This is by far more than plain data
integrity of the transmitted data. Even if your data has been transmitted correctly, the context might be stale (and therefore
its integrity is lost) because it had changed at old AR in the meanwhile. The action to be taken is also given in the text,
namely the change of context has to be replicated to the new AR. As you can (hopefully) see this is by far more than
preserving the 'meaning' of each bit. It mandates that changes in the bit values at one end are reflected at the other
end, i.e., it talks about distributed data integrity in my interpretation of the requirement text.
 
Hence, the actual concern might have been (just guessing) whether or not it is the task of the CT protocol to
preserve the abovementioned integrity. Maybe, the IESG wants to see this functionality left to the replication logic that resides
within each AR. Or on the contrary, they do not see this important topic covered appropriately.
 
Regards,
 
 
Dirk 
-----Original Message-----
From: ext Gary Kenward [mailto:gkenward@nortelnetworks.com]
Sent: Thursday, July 11, 2002 3:48 PM
To: 'James Kempf'; seamoby@ietf.org
Subject: RE: [Seamoby] CT Requirements Comments from IESG

You call it fidelity, I call it data integrity.
I've seen "data integrity" used in publications
(no, I cannot quote references).

What we need is a term that everyone, including the
IESG, can agree upon.

> -----Original Message-----
> From: James Kempf [mailto:kempf@docomolabs-usa.com]
> Sent: July 11, 2002 12:22
> To: Kenward, Gary [WDLN2:AN10:EXCH]; seamoby@ietf.org
> Subject: Re: [Seamoby] CT Requirements Comments from IESG
>
>
> > Perhaps the actual answer is to state exactly what was intended
> > originally: that the bit order and bit values have to arrive exactly
> > as they were transmitted.
> >
>
> So this requirement is talking about transmission fidelity? I
> sure would not have guessed that from reading it. I thought it
> intended to talk about usability.
>
> I would suggest that the wording you have above is really a
> lot more precise that what is currently in the spec.
>
> Any other comments? Could we substitute Gary's wording above
> for "meaning" in the current requirement.
>
>             jak
>
>

------_=_NextPart_001_01C2291D.6DEF8CA2-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Thu Jul 11 18:36:44 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10389 for ; Thu, 11 Jul 2002 18:36:44 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA23637; Thu, 11 Jul 2002 18:34:22 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA23610 for ; Thu, 11 Jul 2002 18:34:21 -0400 (EDT) Received: from fridge.docomolabs-usa.com (fwuser@key1.docomolabs-usa.com [216.98.102.225]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10240 for ; Thu, 11 Jul 2002 18:33:25 -0400 (EDT) Message-ID: <034901c2292a$d8530580$4f6015ac@T23KEMPF> From: "James Kempf" To: "Gary Kenward" , , References: <9FBD322B7824D511B36900508BF93C9C01AA4C14@zcard031.ca.nortel.com> Subject: Re: [Seamoby] CT Requirements Comments from IESG Date: Thu, 11 Jul 2002 15:32:28 -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-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit Gary/Dirk, I think you may be on to something here. I think this might be what the IESG was talking about it the first point, namely the lack of discussion of dynamic changes in the context. Is there some way we could cook this idea down into a paragraph that we could insert for this requirement? jak ----- Original Message ----- From: "Gary Kenward" To: ; ; Sent: Thursday, July 11, 2002 1:56 PM Subject: RE: [Seamoby] CT Requirements Comments from IESG > Dirk: > > A valid point. There is a certain atomic level of granularity which has to > be > dealt with - that is, there's no protocol in the world that can synchronize > changes in > information that occur at the source while the information is "in-flight" or > being > received at the destination. If changes in context while the context is > being transferred > make a different to the successful performance of CT, then there is no hope. > > The problem is most significant for state context transfer. E.g. counters > will continue > to count while CT is moving the context to the destination. Either these > changes have no > significant impact upon the forwarding service provided at the new AR (e.g. > it may not > matter that a policing meter misses a few packet counts), or a different > mechanism > has to be defined for re-establishing the state context. > > The handover is real and unavoidable. Mitigating the disruption to the > service at the new > AR is the challenge. It would be nice if the disruption was nil, but > unlikely. > > Gary > > -----Original Message----- > From: Dirk.Trossen@nokia.com [mailto:Dirk.Trossen@nokia.com] > Sent: July 11, 2002 16:30 > To: Kenward, Gary [WDLN2:AN10:EXCH]; kempf@docomolabs-usa.com; > seamoby@ietf.org > Subject: RE: [Seamoby] CT Requirements Comments from IESG > > > Hi all, > > jumping in as somebody who has been an observer so far, struggling with the > current discussion on > 'integrity'. > > When I look at the current wording, i.e., > "5.5.2 A context update MUST preserve the integrity, and thus the meaning, > of the context > at each receiving AR. The context at the AR actually supporting an MN's > traffic will change with time. > For example, the MN may initiate new microflow(s), or discontinue existing > microflows. Any change of context > at the supporting AR must be replicated at those ARs that have already > received context for that MN.", > > and compare this to the plain integrity of the actually transmitted data > (i.e., its bits and therefore its semantics) > that has been brought to the table as a replacement now, I'm quite confident > that this is not what the requirement > is talking about. > > If we remove the word 'meaning' (which is very vague and free for > interpretation for me as well), it is still the word > 'integrity' left, which is more than plain integrity of the transmitted > data, in particular if we look at the following sentences > in the requirement, which state what kind of integrity is meant (which > probably also builds the bridge to the vague > term 'meaning'), namely that the integrity of a context must be preserved in > the sense that a received context at new > AR at some point t must be the same as the context at old AR at the same > time t. This is by far more than plain data > integrity of the transmitted data. Even if your data has been transmitted > correctly, the context might be stale (and therefore > its integrity is lost) because it had changed at old AR in the meanwhile. > The action to be taken is also given in the text, > namely the change of context has to be replicated to the new AR. As you can > (hopefully) see this is by far more than > preserving the 'meaning' of each bit. It mandates that changes in the bit > values at one end are reflected at the other > end, i.e., it talks about distributed data integrity in my interpretation of > the requirement text. > > Hence, the actual concern might have been (just guessing) whether or not it > is the task of the CT protocol to > preserve the abovementioned integrity. Maybe, the IESG wants to see this > functionality left to the replication logic that resides > within each AR. Or on the contrary, they do not see this important topic > covered appropriately. > > Regards, > > > Dirk > > -----Original Message----- > From: ext Gary Kenward [mailto:gkenward@nortelnetworks.com] > Sent: Thursday, July 11, 2002 3:48 PM > To: 'James Kempf'; seamoby@ietf.org > Subject: RE: [Seamoby] CT Requirements Comments from IESG > > > > You call it fidelity, I call it data integrity. > I've seen "data integrity" used in publications > (no, I cannot quote references). > > What we need is a term that everyone, including the > IESG, can agree upon. > > > -----Original Message----- > > From: James Kempf [ mailto:kempf@docomolabs-usa.com > ] > > Sent: July 11, 2002 12:22 > > To: Kenward, Gary [WDLN2:AN10:EXCH]; seamoby@ietf.org > > Subject: Re: [Seamoby] CT Requirements Comments from IESG > > > > > > > Perhaps the actual answer is to state exactly what was intended > > > originally: that the bit order and bit values have to arrive exactly > > > as they were transmitted. > > > > > > > So this requirement is talking about transmission fidelity? I > > sure would not have guessed that from reading it. I thought it > > intended to talk about usability. > > > > I would suggest that the wording you have above is really a > > lot more precise that what is currently in the spec. > > > > Any other comments? Could we substitute Gary's wording above > > for "meaning" in the current requirement. > > > > jak > > > > > > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Thu Jul 11 18:36:49 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10394 for ; Thu, 11 Jul 2002 18:36:44 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA23831 for seamoby-archive@odin.ietf.org; Thu, 11 Jul 2002 18:37:39 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA23637; Thu, 11 Jul 2002 18:34:22 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA23610 for ; Thu, 11 Jul 2002 18:34:21 -0400 (EDT) Received: from fridge.docomolabs-usa.com (fwuser@key1.docomolabs-usa.com [216.98.102.225]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10240 for ; Thu, 11 Jul 2002 18:33:25 -0400 (EDT) Message-ID: <034901c2292a$d8530580$4f6015ac@T23KEMPF> From: "James Kempf" To: "Gary Kenward" , , References: <9FBD322B7824D511B36900508BF93C9C01AA4C14@zcard031.ca.nortel.com> Subject: Re: [Seamoby] CT Requirements Comments from IESG Date: Thu, 11 Jul 2002 15:32:28 -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-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit Gary/Dirk, I think you may be on to something here. I think this might be what the IESG was talking about it the first point, namely the lack of discussion of dynamic changes in the context. Is there some way we could cook this idea down into a paragraph that we could insert for this requirement? jak ----- Original Message ----- From: "Gary Kenward" To: ; ; Sent: Thursday, July 11, 2002 1:56 PM Subject: RE: [Seamoby] CT Requirements Comments from IESG > Dirk: > > A valid point. There is a certain atomic level of granularity which has to > be > dealt with - that is, there's no protocol in the world that can synchronize > changes in > information that occur at the source while the information is "in-flight" or > being > received at the destination. If changes in context while the context is > being transferred > make a different to the successful performance of CT, then there is no hope. > > The problem is most significant for state context transfer. E.g. counters > will continue > to count while CT is moving the context to the destination. Either these > changes have no > significant impact upon the forwarding service provided at the new AR (e.g. > it may not > matter that a policing meter misses a few packet counts), or a different > mechanism > has to be defined for re-establishing the state context. > > The handover is real and unavoidable. Mitigating the disruption to the > service at the new > AR is the challenge. It would be nice if the disruption was nil, but > unlikely. > > Gary > > -----Original Message----- > From: Dirk.Trossen@nokia.com [mailto:Dirk.Trossen@nokia.com] > Sent: July 11, 2002 16:30 > To: Kenward, Gary [WDLN2:AN10:EXCH]; kempf@docomolabs-usa.com; > seamoby@ietf.org > Subject: RE: [Seamoby] CT Requirements Comments from IESG > > > Hi all, > > jumping in as somebody who has been an observer so far, struggling with the > current discussion on > 'integrity'. > > When I look at the current wording, i.e., > "5.5.2 A context update MUST preserve the integrity, and thus the meaning, > of the context > at each receiving AR. The context at the AR actually supporting an MN's > traffic will change with time. > For example, the MN may initiate new microflow(s), or discontinue existing > microflows. Any change of context > at the supporting AR must be replicated at those ARs that have already > received context for that MN.", > > and compare this to the plain integrity of the actually transmitted data > (i.e., its bits and therefore its semantics) > that has been brought to the table as a replacement now, I'm quite confident > that this is not what the requirement > is talking about. > > If we remove the word 'meaning' (which is very vague and free for > interpretation for me as well), it is still the word > 'integrity' left, which is more than plain integrity of the transmitted > data, in particular if we look at the following sentences > in the requirement, which state what kind of integrity is meant (which > probably also builds the bridge to the vague > term 'meaning'), namely that the integrity of a context must be preserved in > the sense that a received context at new > AR at some point t must be the same as the context at old AR at the same > time t. This is by far more than plain data > integrity of the transmitted data. Even if your data has been transmitted > correctly, the context might be stale (and therefore > its integrity is lost) because it had changed at old AR in the meanwhile. > The action to be taken is also given in the text, > namely the change of context has to be replicated to the new AR. As you can > (hopefully) see this is by far more than > preserving the 'meaning' of each bit. It mandates that changes in the bit > values at one end are reflected at the other > end, i.e., it talks about distributed data integrity in my interpretation of > the requirement text. > > Hence, the actual concern might have been (just guessing) whether or not it > is the task of the CT protocol to > preserve the abovementioned integrity. Maybe, the IESG wants to see this > functionality left to the replication logic that resides > within each AR. Or on the contrary, they do not see this important topic > covered appropriately. > > Regards, > > > Dirk > > -----Original Message----- > From: ext Gary Kenward [mailto:gkenward@nortelnetworks.com] > Sent: Thursday, July 11, 2002 3:48 PM > To: 'James Kempf'; seamoby@ietf.org > Subject: RE: [Seamoby] CT Requirements Comments from IESG > > > > You call it fidelity, I call it data integrity. > I've seen "data integrity" used in publications > (no, I cannot quote references). > > What we need is a term that everyone, including the > IESG, can agree upon. > > > -----Original Message----- > > From: James Kempf [ mailto:kempf@docomolabs-usa.com > ] > > Sent: July 11, 2002 12:22 > > To: Kenward, Gary [WDLN2:AN10:EXCH]; seamoby@ietf.org > > Subject: Re: [Seamoby] CT Requirements Comments from IESG > > > > > > > Perhaps the actual answer is to state exactly what was intended > > > originally: that the bit order and bit values have to arrive exactly > > > as they were transmitted. > > > > > > > So this requirement is talking about transmission fidelity? I > > sure would not have guessed that from reading it. I thought it > > intended to talk about usability. > > > > I would suggest that the wording you have above is really a > > lot more precise that what is currently in the spec. > > > > Any other comments? Could we substitute Gary's wording above > > for "meaning" in the current requirement. > > > > jak > > > > > > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Thu Jul 11 19:09:30 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12235 for ; Thu, 11 Jul 2002 19:09:30 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA25992; Thu, 11 Jul 2002 19:08:22 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA25923 for ; Thu, 11 Jul 2002 19:08:19 -0400 (EDT) Received: from mgw-dax2.ext.nokia.com (mgw-dax2.ext.nokia.com [63.78.179.217]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12106 for ; Thu, 11 Jul 2002 19:07:25 -0400 (EDT) From: Dirk.Trossen@nokia.com Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85]) by mgw-dax2.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g6BNC1j28665 for ; Thu, 11 Jul 2002 18:12:01 -0500 (CDT) Received: from daebh001.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 11 Jul 2002 18:08:16 -0500 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Thu, 11 Jul 2002 18:08:16 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Seamoby] CT Requirements Comments from IESG Date: Thu, 11 Jul 2002 19:08:15 -0400 Message-ID: Thread-Topic: [Seamoby] CT Requirements Comments from IESG Thread-Index: AcIpKxmvLd64i0RMQ3K76iH7L7mAUAAAfUtA To: , , X-OriginalArrivalTime: 11 Jul 2002 23:08:16.0773 (UTC) FILETIME=[D709A350:01C2292F] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id TAA25924 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 8bit Hi James, I do think that this is the issue the IESG was after in the first point. The reason might simply be a wording of the requirement that is kind of confusing. Words like 'meaning' certainly don't help. Further, the statement that 'a context update MUST preserve the integrity' didn't tell me in the first place what it is about. Let's assume (and we have to agree on this first) that the requirement is about the following: If a context has been transferred from old AR to new AR, and the context changes after this operation, the CT protocol MUST preserve the integrity through updating the context with its current value, i.e., sending the context again. Why this proposal? Assume a context for a state counter (Gary mentioned a policing meter). In case, that the counter at old AR changes after the context has been transferred, it MUST re-send the context in the first place, according to the wording above. Personally, I think this is enough, although it does not cover cases (how BTW?) in which those updates would come too late, and the old (stale) value is used at the new AR. So here's my proposal for the wording: 5.5.2 A CT solution MUST minimize inconsistencies in the context's integrity at each receiving AR. For that, any changes of context at the supporting AR MUST be reflected at those ARs that have already received the context for that MN, i.e., a context update MUST be performed through re-sending the context to those ARs. Regards, Dirk >-----Original Message----- >From: ext James Kempf [mailto:kempf@docomolabs-usa.com] >Sent: Thursday, July 11, 2002 6:32 PM >To: Gary Kenward; Trossen Dirk (NRC/Boston); seamoby@ietf.org >Subject: Re: [Seamoby] CT Requirements Comments from IESG > > >Gary/Dirk, > >I think you may be on to something here. I think this might be >what the IESG was talking about it the first point, namely the >lack of discussion of dynamic changes in the context. > >Is there some way we could cook this idea down into a >paragraph that we could insert for this requirement? > > jak > >----- Original Message ----- >From: "Gary Kenward" >To: ; ; > >Sent: Thursday, July 11, 2002 1:56 PM >Subject: RE: [Seamoby] CT Requirements Comments from IESG > > >> Dirk: >> >> A valid point. There is a certain atomic level of >granularity which has to >> be >> dealt with - that is, there's no protocol in the world that >can synchronize >> changes in >> information that occur at the source while the information >is "in-flight" or >> being >> received at the destination. If changes in context while the >context is >> being transferred >> make a different to the successful performance of CT, then >there is no hope. >> >> The problem is most significant for state context >transfer. E.g. counters >> will continue >> to count while CT is moving the context to the destination. >Either these >> changes have no >> significant impact upon the forwarding service provided at >the new AR (e.g. >> it may not >> matter that a policing meter misses a few packet counts), or >a different >> mechanism >> has to be defined for re-establishing the state context. >> >> The handover is real and unavoidable. Mitigating the >disruption to the >> service at the new >> AR is the challenge. It would be nice if the disruption was nil, but >> unlikely. >> >> Gary >> >> -----Original Message----- >> From: Dirk.Trossen@nokia.com [mailto:Dirk.Trossen@nokia.com] >> Sent: July 11, 2002 16:30 >> To: Kenward, Gary [WDLN2:AN10:EXCH]; kempf@docomolabs-usa.com; >> seamoby@ietf.org >> Subject: RE: [Seamoby] CT Requirements Comments from IESG >> >> >> Hi all, >> >> jumping in as somebody who has been an observer so far, >struggling with the >> current discussion on >> 'integrity'. >> >> When I look at the current wording, i.e., >> "5.5.2 A context update MUST preserve the integrity, and >thus the meaning, >> of the context >> at each receiving AR. The context at the AR actually >supporting an MN's >> traffic will change with time. >> For example, the MN may initiate new microflow(s), or >discontinue existing >> microflows. Any change of context >> at the supporting AR must be replicated at those ARs that >have already >> received context for that MN.", >> >> and compare this to the plain integrity of the actually >transmitted data >> (i.e., its bits and therefore its semantics) >> that has been brought to the table as a replacement now, I'm >quite confident >> that this is not what the requirement >> is talking about. >> >> If we remove the word 'meaning' (which is very vague and free for >> interpretation for me as well), it is still the word >> 'integrity' left, which is more than plain integrity of the >transmitted >> data, in particular if we look at the following sentences >> in the requirement, which state what kind of integrity is >meant (which >> probably also builds the bridge to the vague >> term 'meaning'), namely that the integrity of a context must >be preserved in >> the sense that a received context at new >> AR at some point t must be the same as the context at old AR >at the same >> time t. This is by far more than plain data >> integrity of the transmitted data. Even if your data has >been transmitted >> correctly, the context might be stale (and therefore >> its integrity is lost) because it had changed at old AR in >the meanwhile. >> The action to be taken is also given in the text, >> namely the change of context has to be replicated to the new >AR. As you can >> (hopefully) see this is by far more than >> preserving the 'meaning' of each bit. It mandates that >changes in the bit >> values at one end are reflected at the other >> end, i.e., it talks about distributed data integrity in my >interpretation of >> the requirement text. >> >> Hence, the actual concern might have been (just guessing) >whether or not it >> is the task of the CT protocol to >> preserve the abovementioned integrity. Maybe, the IESG wants >to see this >> functionality left to the replication logic that resides >> within each AR. Or on the contrary, they do not see this >important topic >> covered appropriately. >> >> Regards, >> >> >> Dirk >> >> -----Original Message----- >> From: ext Gary Kenward [mailto:gkenward@nortelnetworks.com] >> Sent: Thursday, July 11, 2002 3:48 PM >> To: 'James Kempf'; seamoby@ietf.org >> Subject: RE: [Seamoby] CT Requirements Comments from IESG >> >> >> >> You call it fidelity, I call it data integrity. >> I've seen "data integrity" used in publications >> (no, I cannot quote references). >> >> What we need is a term that everyone, including the >> IESG, can agree upon. >> >> > -----Original Message----- >> > From: James Kempf [ mailto:kempf@docomolabs-usa.com >> ] >> > Sent: July 11, 2002 12:22 >> > To: Kenward, Gary [WDLN2:AN10:EXCH]; seamoby@ietf.org >> > Subject: Re: [Seamoby] CT Requirements Comments from IESG >> > >> > >> > > Perhaps the actual answer is to state exactly what was intended >> > > originally: that the bit order and bit values have to >arrive exactly >> > > as they were transmitted. >> > > >> > >> > So this requirement is talking about transmission fidelity? I >> > sure would not have guessed that from reading it. I thought it >> > intended to talk about usability. >> > >> > I would suggest that the wording you have above is really a >> > lot more precise that what is currently in the spec. >> > >> > Any other comments? Could we substitute Gary's wording above >> > for "meaning" in the current requirement. >> > >> > jak >> > >> > >> >> > > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Thu Jul 11 19:09:31 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12243 for ; Thu, 11 Jul 2002 19:09:31 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id TAA26121 for seamoby-archive@odin.ietf.org; Thu, 11 Jul 2002 19:10:24 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA25992; Thu, 11 Jul 2002 19:08:22 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA25923 for ; Thu, 11 Jul 2002 19:08:19 -0400 (EDT) Received: from mgw-dax2.ext.nokia.com (mgw-dax2.ext.nokia.com [63.78.179.217]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12106 for ; Thu, 11 Jul 2002 19:07:25 -0400 (EDT) From: Dirk.Trossen@nokia.com Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85]) by mgw-dax2.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g6BNC1j28665 for ; Thu, 11 Jul 2002 18:12:01 -0500 (CDT) Received: from daebh001.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 11 Jul 2002 18:08:16 -0500 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Thu, 11 Jul 2002 18:08:16 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Seamoby] CT Requirements Comments from IESG Date: Thu, 11 Jul 2002 19:08:15 -0400 Message-ID: Thread-Topic: [Seamoby] CT Requirements Comments from IESG Thread-Index: AcIpKxmvLd64i0RMQ3K76iH7L7mAUAAAfUtA To: , , X-OriginalArrivalTime: 11 Jul 2002 23:08:16.0773 (UTC) FILETIME=[D709A350:01C2292F] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id TAA25924 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 8bit Hi James, I do think that this is the issue the IESG was after in the first point. The reason might simply be a wording of the requirement that is kind of confusing. Words like 'meaning' certainly don't help. Further, the statement that 'a context update MUST preserve the integrity' didn't tell me in the first place what it is about. Let's assume (and we have to agree on this first) that the requirement is about the following: If a context has been transferred from old AR to new AR, and the context changes after this operation, the CT protocol MUST preserve the integrity through updating the context with its current value, i.e., sending the context again. Why this proposal? Assume a context for a state counter (Gary mentioned a policing meter). In case, that the counter at old AR changes after the context has been transferred, it MUST re-send the context in the first place, according to the wording above. Personally, I think this is enough, although it does not cover cases (how BTW?) in which those updates would come too late, and the old (stale) value is used at the new AR. So here's my proposal for the wording: 5.5.2 A CT solution MUST minimize inconsistencies in the context's integrity at each receiving AR. For that, any changes of context at the supporting AR MUST be reflected at those ARs that have already received the context for that MN, i.e., a context update MUST be performed through re-sending the context to those ARs. Regards, Dirk >-----Original Message----- >From: ext James Kempf [mailto:kempf@docomolabs-usa.com] >Sent: Thursday, July 11, 2002 6:32 PM >To: Gary Kenward; Trossen Dirk (NRC/Boston); seamoby@ietf.org >Subject: Re: [Seamoby] CT Requirements Comments from IESG > > >Gary/Dirk, > >I think you may be on to something here. I think this might be >what the IESG was talking about it the first point, namely the >lack of discussion of dynamic changes in the context. > >Is there some way we could cook this idea down into a >paragraph that we could insert for this requirement? > > jak > >----- Original Message ----- >From: "Gary Kenward" >To: ; ; > >Sent: Thursday, July 11, 2002 1:56 PM >Subject: RE: [Seamoby] CT Requirements Comments from IESG > > >> Dirk: >> >> A valid point. There is a certain atomic level of >granularity which has to >> be >> dealt with - that is, there's no protocol in the world that >can synchronize >> changes in >> information that occur at the source while the information >is "in-flight" or >> being >> received at the destination. If changes in context while the >context is >> being transferred >> make a different to the successful performance of CT, then >there is no hope. >> >> The problem is most significant for state context >transfer. E.g. counters >> will continue >> to count while CT is moving the context to the destination. >Either these >> changes have no >> significant impact upon the forwarding service provided at >the new AR (e.g. >> it may not >> matter that a policing meter misses a few packet counts), or >a different >> mechanism >> has to be defined for re-establishing the state context. >> >> The handover is real and unavoidable. Mitigating the >disruption to the >> service at the new >> AR is the challenge. It would be nice if the disruption was nil, but >> unlikely. >> >> Gary >> >> -----Original Message----- >> From: Dirk.Trossen@nokia.com [mailto:Dirk.Trossen@nokia.com] >> Sent: July 11, 2002 16:30 >> To: Kenward, Gary [WDLN2:AN10:EXCH]; kempf@docomolabs-usa.com; >> seamoby@ietf.org >> Subject: RE: [Seamoby] CT Requirements Comments from IESG >> >> >> Hi all, >> >> jumping in as somebody who has been an observer so far, >struggling with the >> current discussion on >> 'integrity'. >> >> When I look at the current wording, i.e., >> "5.5.2 A context update MUST preserve the integrity, and >thus the meaning, >> of the context >> at each receiving AR. The context at the AR actually >supporting an MN's >> traffic will change with time. >> For example, the MN may initiate new microflow(s), or >discontinue existing >> microflows. Any change of context >> at the supporting AR must be replicated at those ARs that >have already >> received context for that MN.", >> >> and compare this to the plain integrity of the actually >transmitted data >> (i.e., its bits and therefore its semantics) >> that has been brought to the table as a replacement now, I'm >quite confident >> that this is not what the requirement >> is talking about. >> >> If we remove the word 'meaning' (which is very vague and free for >> interpretation for me as well), it is still the word >> 'integrity' left, which is more than plain integrity of the >transmitted >> data, in particular if we look at the following sentences >> in the requirement, which state what kind of integrity is >meant (which >> probably also builds the bridge to the vague >> term 'meaning'), namely that the integrity of a context must >be preserved in >> the sense that a received context at new >> AR at some point t must be the same as the context at old AR >at the same >> time t. This is by far more than plain data >> integrity of the transmitted data. Even if your data has >been transmitted >> correctly, the context might be stale (and therefore >> its integrity is lost) because it had changed at old AR in >the meanwhile. >> The action to be taken is also given in the text, >> namely the change of context has to be replicated to the new >AR. As you can >> (hopefully) see this is by far more than >> preserving the 'meaning' of each bit. It mandates that >changes in the bit >> values at one end are reflected at the other >> end, i.e., it talks about distributed data integrity in my >interpretation of >> the requirement text. >> >> Hence, the actual concern might have been (just guessing) >whether or not it >> is the task of the CT protocol to >> preserve the abovementioned integrity. Maybe, the IESG wants >to see this >> functionality left to the replication logic that resides >> within each AR. Or on the contrary, they do not see this >important topic >> covered appropriately. >> >> Regards, >> >> >> Dirk >> >> -----Original Message----- >> From: ext Gary Kenward [mailto:gkenward@nortelnetworks.com] >> Sent: Thursday, July 11, 2002 3:48 PM >> To: 'James Kempf'; seamoby@ietf.org >> Subject: RE: [Seamoby] CT Requirements Comments from IESG >> >> >> >> You call it fidelity, I call it data integrity. >> I've seen "data integrity" used in publications >> (no, I cannot quote references). >> >> What we need is a term that everyone, including the >> IESG, can agree upon. >> >> > -----Original Message----- >> > From: James Kempf [ mailto:kempf@docomolabs-usa.com >> ] >> > Sent: July 11, 2002 12:22 >> > To: Kenward, Gary [WDLN2:AN10:EXCH]; seamoby@ietf.org >> > Subject: Re: [Seamoby] CT Requirements Comments from IESG >> > >> > >> > > Perhaps the actual answer is to state exactly what was intended >> > > originally: that the bit order and bit values have to >arrive exactly >> > > as they were transmitted. >> > > >> > >> > So this requirement is talking about transmission fidelity? I >> > sure would not have guessed that from reading it. I thought it >> > intended to talk about usability. >> > >> > I would suggest that the wording you have above is really a >> > lot more precise that what is currently in the spec. >> > >> > Any other comments? Could we substitute Gary's wording above >> > for "meaning" in the current requirement. >> > >> > jak >> > >> > >> >> > > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Fri Jul 12 06:54:20 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16382 for ; Fri, 12 Jul 2002 06:54:20 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA08897; Fri, 12 Jul 2002 06:40:17 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA08842 for ; Fri, 12 Jul 2002 06:40:14 -0400 (EDT) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA15819; Fri, 12 Jul 2002 06:39:18 -0400 (EDT) From: john.loughney@nokia.com Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g6CAefi22956; Fri, 12 Jul 2002 13:40:41 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 12 Jul 2002 13:40:10 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Fri, 12 Jul 2002 13:40:09 +0300 content-class: urn:content-classes:message Subject: RE: [Seamoby] RE: [NSIS] Re: draft-westphal-nsis-qos-mobileip-00. txt MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Date: Fri, 12 Jul 2002 13:40:09 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC65720@esebe004.NOE.Nokia.com> Thread-Topic: [Seamoby] RE: [NSIS] Re: draft-westphal-nsis-qos-mobileip-00. txt Thread-Index: AcIpGEBC0Wbw2LAVTZKu9SixVavevQAXpCkg To: Cc: , X-OriginalArrivalTime: 12 Jul 2002 10:40:09.0504 (UTC) FILETIME=[7E8DB200:01C22990] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id GAA08843 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 8bit Hi James, > > The one step we could take (but not the one that was > suggested) would > > be to investigate into ensuring some commonality between > the formats for > > encapsulating the respective data chunks (i.e. context/NSIS > parameters). > > Or at least, provide for NSIS to carry CT data chunks and > visa versa. > > > > Right, that is in fact the kind of thing I had in mind. If > you don't want to call it QoS context, call it "NSIS context". Just as an FYI, some folks are interest in looking into using NSIS for various things, like QoS, NAT, & firewall traversal, and so forth. For these cases, what parameters NSIS signals are very much service/application specific. This is also true with regards to Context Transfer. What I suggest is that NSIS and CT progress, and since there is some overlap in the interest of both groups, we can try to ensure that whatever solutions we work on do not cause trouble for the different working groups. However, I don't support tightly coupling the solutions. A much better way would be that after CT & NSIS work is well along, someone could make an applicability document of combining both NSIS & CT into a solution for particular deployments. br, John _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Fri Jul 12 06:54:21 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16389 for ; Fri, 12 Jul 2002 06:54:21 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id GAA09259 for seamoby-archive@odin.ietf.org; Fri, 12 Jul 2002 06:55:16 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA08897; Fri, 12 Jul 2002 06:40:17 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA08842 for ; Fri, 12 Jul 2002 06:40:14 -0400 (EDT) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA15819; Fri, 12 Jul 2002 06:39:18 -0400 (EDT) From: john.loughney@nokia.com Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g6CAefi22956; Fri, 12 Jul 2002 13:40:41 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 12 Jul 2002 13:40:10 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Fri, 12 Jul 2002 13:40:09 +0300 content-class: urn:content-classes:message Subject: RE: [Seamoby] RE: [NSIS] Re: draft-westphal-nsis-qos-mobileip-00. txt MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Date: Fri, 12 Jul 2002 13:40:09 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC65720@esebe004.NOE.Nokia.com> Thread-Topic: [Seamoby] RE: [NSIS] Re: draft-westphal-nsis-qos-mobileip-00. txt Thread-Index: AcIpGEBC0Wbw2LAVTZKu9SixVavevQAXpCkg To: Cc: , X-OriginalArrivalTime: 12 Jul 2002 10:40:09.0504 (UTC) FILETIME=[7E8DB200:01C22990] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id GAA08843 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 8bit Hi James, > > The one step we could take (but not the one that was > suggested) would > > be to investigate into ensuring some commonality between > the formats for > > encapsulating the respective data chunks (i.e. context/NSIS > parameters). > > Or at least, provide for NSIS to carry CT data chunks and > visa versa. > > > > Right, that is in fact the kind of thing I had in mind. If > you don't want to call it QoS context, call it "NSIS context". Just as an FYI, some folks are interest in looking into using NSIS for various things, like QoS, NAT, & firewall traversal, and so forth. For these cases, what parameters NSIS signals are very much service/application specific. This is also true with regards to Context Transfer. What I suggest is that NSIS and CT progress, and since there is some overlap in the interest of both groups, we can try to ensure that whatever solutions we work on do not cause trouble for the different working groups. However, I don't support tightly coupling the solutions. A much better way would be that after CT & NSIS work is well along, someone could make an applicability document of combining both NSIS & CT into a solution for particular deployments. br, John _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Fri Jul 12 06:55:14 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16420 for ; Fri, 12 Jul 2002 06:55:14 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA08984; Fri, 12 Jul 2002 06:41:13 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA08955 for ; Fri, 12 Jul 2002 06:41:11 -0400 (EDT) Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA15862 for ; Fri, 12 Jul 2002 06:40:15 -0400 (EDT) From: john.loughney@nokia.com Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x3.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g6CAh8W15691 for ; Fri, 12 Jul 2002 13:43:08 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 12 Jul 2002 13:41:08 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Fri, 12 Jul 2002 13:41:06 +0300 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Seamoby] CT Requirements Comments from IESG X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Date: Fri, 12 Jul 2002 13:41:06 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC65722@esebe004.NOE.Nokia.com> Thread-Topic: [Seamoby] CT Requirements Comments from IESG Thread-Index: AcIpKyOlXLMtbwlIQIyL/TqjLtIb1QATI/bw To: , , , X-OriginalArrivalTime: 12 Jul 2002 10:41:06.0996 (UTC) FILETIME=[A0D24740:01C22990] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id GAA08956 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 8bit Hi James, etc. Would it be OK to say that something along the lines of Information which is dynamic may need to be transfered and any CT solution SHOULD be able to manage or cope with this gracefully. John > -----Original Message----- > From: ext James Kempf [mailto:kempf@docomolabs-usa.com] > Sent: 12 July, 2002 01:32 > To: Gary Kenward; Trossen Dirk (NRC/Boston); seamoby@ietf.org > Subject: Re: [Seamoby] CT Requirements Comments from IESG > > > Gary/Dirk, > > I think you may be on to something here. I think this might > be what the IESG was talking about it the first point, namely the > lack of discussion of dynamic changes in the context. > > Is there some way we could cook this idea down into a > paragraph that we could insert for this requirement? > > jak > > ----- Original Message ----- > From: "Gary Kenward" > To: ; ; > > Sent: Thursday, July 11, 2002 1:56 PM > Subject: RE: [Seamoby] CT Requirements Comments from IESG > > > > Dirk: > > > > A valid point. There is a certain atomic level of > granularity which has to > > be > > dealt with - that is, there's no protocol in the world that > can synchronize > > changes in > > information that occur at the source while the information > is "in-flight" or > > being > > received at the destination. If changes in context while > the context is > > being transferred > > make a different to the successful performance of CT, then > there is no hope. > > > > The problem is most significant for state context > transfer. E.g. counters > > will continue > > to count while CT is moving the context to the destination. > Either these > > changes have no > > significant impact upon the forwarding service provided at > the new AR (e.g. > > it may not > > matter that a policing meter misses a few packet counts), > or a different > > mechanism > > has to be defined for re-establishing the state context. > > > > The handover is real and unavoidable. Mitigating the > disruption to the > > service at the new > > AR is the challenge. It would be nice if the disruption was nil, but > > unlikely. > > > > Gary > > > > -----Original Message----- > > From: Dirk.Trossen@nokia.com [mailto:Dirk.Trossen@nokia.com] > > Sent: July 11, 2002 16:30 > > To: Kenward, Gary [WDLN2:AN10:EXCH]; kempf@docomolabs-usa.com; > > seamoby@ietf.org > > Subject: RE: [Seamoby] CT Requirements Comments from IESG > > > > > > Hi all, > > > > jumping in as somebody who has been an observer so far, > struggling with the > > current discussion on > > 'integrity'. > > > > When I look at the current wording, i.e., > > "5.5.2 A context update MUST preserve the integrity, and > thus the meaning, > > of the context > > at each receiving AR. The context at the AR actually > supporting an MN's > > traffic will change with time. > > For example, the MN may initiate new microflow(s), or > discontinue existing > > microflows. Any change of context > > at the supporting AR must be replicated at those ARs that > have already > > received context for that MN.", > > > > and compare this to the plain integrity of the actually > transmitted data > > (i.e., its bits and therefore its semantics) > > that has been brought to the table as a replacement now, > I'm quite confident > > that this is not what the requirement > > is talking about. > > > > If we remove the word 'meaning' (which is very vague and free for > > interpretation for me as well), it is still the word > > 'integrity' left, which is more than plain integrity of the > transmitted > > data, in particular if we look at the following sentences > > in the requirement, which state what kind of integrity is > meant (which > > probably also builds the bridge to the vague > > term 'meaning'), namely that the integrity of a context > must be preserved in > > the sense that a received context at new > > AR at some point t must be the same as the context at old > AR at the same > > time t. This is by far more than plain data > > integrity of the transmitted data. Even if your data has > been transmitted > > correctly, the context might be stale (and therefore > > its integrity is lost) because it had changed at old AR in > the meanwhile. > > The action to be taken is also given in the text, > > namely the change of context has to be replicated to the > new AR. As you can > > (hopefully) see this is by far more than > > preserving the 'meaning' of each bit. It mandates that > changes in the bit > > values at one end are reflected at the other > > end, i.e., it talks about distributed data integrity in my > interpretation of > > the requirement text. > > > > Hence, the actual concern might have been (just guessing) > whether or not it > > is the task of the CT protocol to > > preserve the abovementioned integrity. Maybe, the IESG > wants to see this > > functionality left to the replication logic that resides > > within each AR. Or on the contrary, they do not see this > important topic > > covered appropriately. > > > > Regards, > > > > > > Dirk > > > > -----Original Message----- > > From: ext Gary Kenward [mailto:gkenward@nortelnetworks.com] > > Sent: Thursday, July 11, 2002 3:48 PM > > To: 'James Kempf'; seamoby@ietf.org > > Subject: RE: [Seamoby] CT Requirements Comments from IESG > > > > > > > > You call it fidelity, I call it data integrity. > > I've seen "data integrity" used in publications > > (no, I cannot quote references). > > > > What we need is a term that everyone, including the > > IESG, can agree upon. > > > > > -----Original Message----- > > > From: James Kempf [ mailto:kempf@docomolabs-usa.com > > ] > > > Sent: July 11, 2002 12:22 > > > To: Kenward, Gary [WDLN2:AN10:EXCH]; seamoby@ietf.org > > > Subject: Re: [Seamoby] CT Requirements Comments from IESG > > > > > > > > > > Perhaps the actual answer is to state exactly what was intended > > > > originally: that the bit order and bit values have to > arrive exactly > > > > as they were transmitted. > > > > > > > > > > So this requirement is talking about transmission fidelity? I > > > sure would not have guessed that from reading it. I thought it > > > intended to talk about usability. > > > > > > I would suggest that the wording you have above is really a > > > lot more precise that what is currently in the spec. > > > > > > Any other comments? Could we substitute Gary's wording above > > > for "meaning" in the current requirement. > > > > > > jak > > > > > > > > > > > > > _______________________________________________ > 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 From daemon@optimus.ietf.org Fri Jul 12 06:55:14 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16426 for ; Fri, 12 Jul 2002 06:55:14 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id GAA09292 for seamoby-archive@odin.ietf.org; Fri, 12 Jul 2002 06:56:09 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA08984; Fri, 12 Jul 2002 06:41:13 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA08955 for ; Fri, 12 Jul 2002 06:41:11 -0400 (EDT) Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA15862 for ; Fri, 12 Jul 2002 06:40:15 -0400 (EDT) From: john.loughney@nokia.com Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x3.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g6CAh8W15691 for ; Fri, 12 Jul 2002 13:43:08 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 12 Jul 2002 13:41:08 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Fri, 12 Jul 2002 13:41:06 +0300 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Seamoby] CT Requirements Comments from IESG X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Date: Fri, 12 Jul 2002 13:41:06 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC65722@esebe004.NOE.Nokia.com> Thread-Topic: [Seamoby] CT Requirements Comments from IESG Thread-Index: AcIpKyOlXLMtbwlIQIyL/TqjLtIb1QATI/bw To: , , , X-OriginalArrivalTime: 12 Jul 2002 10:41:06.0996 (UTC) FILETIME=[A0D24740:01C22990] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id GAA08956 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 8bit Hi James, etc. Would it be OK to say that something along the lines of Information which is dynamic may need to be transfered and any CT solution SHOULD be able to manage or cope with this gracefully. John > -----Original Message----- > From: ext James Kempf [mailto:kempf@docomolabs-usa.com] > Sent: 12 July, 2002 01:32 > To: Gary Kenward; Trossen Dirk (NRC/Boston); seamoby@ietf.org > Subject: Re: [Seamoby] CT Requirements Comments from IESG > > > Gary/Dirk, > > I think you may be on to something here. I think this might > be what the IESG was talking about it the first point, namely the > lack of discussion of dynamic changes in the context. > > Is there some way we could cook this idea down into a > paragraph that we could insert for this requirement? > > jak > > ----- Original Message ----- > From: "Gary Kenward" > To: ; ; > > Sent: Thursday, July 11, 2002 1:56 PM > Subject: RE: [Seamoby] CT Requirements Comments from IESG > > > > Dirk: > > > > A valid point. There is a certain atomic level of > granularity which has to > > be > > dealt with - that is, there's no protocol in the world that > can synchronize > > changes in > > information that occur at the source while the information > is "in-flight" or > > being > > received at the destination. If changes in context while > the context is > > being transferred > > make a different to the successful performance of CT, then > there is no hope. > > > > The problem is most significant for state context > transfer. E.g. counters > > will continue > > to count while CT is moving the context to the destination. > Either these > > changes have no > > significant impact upon the forwarding service provided at > the new AR (e.g. > > it may not > > matter that a policing meter misses a few packet counts), > or a different > > mechanism > > has to be defined for re-establishing the state context. > > > > The handover is real and unavoidable. Mitigating the > disruption to the > > service at the new > > AR is the challenge. It would be nice if the disruption was nil, but > > unlikely. > > > > Gary > > > > -----Original Message----- > > From: Dirk.Trossen@nokia.com [mailto:Dirk.Trossen@nokia.com] > > Sent: July 11, 2002 16:30 > > To: Kenward, Gary [WDLN2:AN10:EXCH]; kempf@docomolabs-usa.com; > > seamoby@ietf.org > > Subject: RE: [Seamoby] CT Requirements Comments from IESG > > > > > > Hi all, > > > > jumping in as somebody who has been an observer so far, > struggling with the > > current discussion on > > 'integrity'. > > > > When I look at the current wording, i.e., > > "5.5.2 A context update MUST preserve the integrity, and > thus the meaning, > > of the context > > at each receiving AR. The context at the AR actually > supporting an MN's > > traffic will change with time. > > For example, the MN may initiate new microflow(s), or > discontinue existing > > microflows. Any change of context > > at the supporting AR must be replicated at those ARs that > have already > > received context for that MN.", > > > > and compare this to the plain integrity of the actually > transmitted data > > (i.e., its bits and therefore its semantics) > > that has been brought to the table as a replacement now, > I'm quite confident > > that this is not what the requirement > > is talking about. > > > > If we remove the word 'meaning' (which is very vague and free for > > interpretation for me as well), it is still the word > > 'integrity' left, which is more than plain integrity of the > transmitted > > data, in particular if we look at the following sentences > > in the requirement, which state what kind of integrity is > meant (which > > probably also builds the bridge to the vague > > term 'meaning'), namely that the integrity of a context > must be preserved in > > the sense that a received context at new > > AR at some point t must be the same as the context at old > AR at the same > > time t. This is by far more than plain data > > integrity of the transmitted data. Even if your data has > been transmitted > > correctly, the context might be stale (and therefore > > its integrity is lost) because it had changed at old AR in > the meanwhile. > > The action to be taken is also given in the text, > > namely the change of context has to be replicated to the > new AR. As you can > > (hopefully) see this is by far more than > > preserving the 'meaning' of each bit. It mandates that > changes in the bit > > values at one end are reflected at the other > > end, i.e., it talks about distributed data integrity in my > interpretation of > > the requirement text. > > > > Hence, the actual concern might have been (just guessing) > whether or not it > > is the task of the CT protocol to > > preserve the abovementioned integrity. Maybe, the IESG > wants to see this > > functionality left to the replication logic that resides > > within each AR. Or on the contrary, they do not see this > important topic > > covered appropriately. > > > > Regards, > > > > > > Dirk > > > > -----Original Message----- > > From: ext Gary Kenward [mailto:gkenward@nortelnetworks.com] > > Sent: Thursday, July 11, 2002 3:48 PM > > To: 'James Kempf'; seamoby@ietf.org > > Subject: RE: [Seamoby] CT Requirements Comments from IESG > > > > > > > > You call it fidelity, I call it data integrity. > > I've seen "data integrity" used in publications > > (no, I cannot quote references). > > > > What we need is a term that everyone, including the > > IESG, can agree upon. > > > > > -----Original Message----- > > > From: James Kempf [ mailto:kempf@docomolabs-usa.com > > ] > > > Sent: July 11, 2002 12:22 > > > To: Kenward, Gary [WDLN2:AN10:EXCH]; seamoby@ietf.org > > > Subject: Re: [Seamoby] CT Requirements Comments from IESG > > > > > > > > > > Perhaps the actual answer is to state exactly what was intended > > > > originally: that the bit order and bit values have to > arrive exactly > > > > as they were transmitted. > > > > > > > > > > So this requirement is talking about transmission fidelity? I > > > sure would not have guessed that from reading it. I thought it > > > intended to talk about usability. > > > > > > I would suggest that the wording you have above is really a > > > lot more precise that what is currently in the spec. > > > > > > Any other comments? Could we substitute Gary's wording above > > > for "meaning" in the current requirement. > > > > > > jak > > > > > > > > > > > > > _______________________________________________ > 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 From seamoby-admin@ietf.org Fri Jul 12 11:55:10 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29459 for ; Fri, 12 Jul 2002 11:55:10 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA28276; Fri, 12 Jul 2002 11:50:05 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA28214 for ; Fri, 12 Jul 2002 11:50:01 -0400 (EDT) Received: from zcars04e.ca.nortel.com (zcars04e.nortelnetworks.com [47.129.242.56]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29132 for ; Fri, 12 Jul 2002 11:49:04 -0400 (EDT) Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g6CFmrg17032; Fri, 12 Jul 2002 11:48:53 -0400 (EDT) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 12 Jul 2002 11:48:53 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA4C17@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'James Kempf'" , Dirk.Trossen@nokia.com, seamoby@ietf.org Subject: RE: [Seamoby] CT Requirements Comments from IESG Date: Fri, 12 Jul 2002 11:48:52 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C229BB.9F2F1000" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C229BB.9F2F1000 Content-Type: text/plain; charset="iso-8859-1" James: Yes, we need to fix it, and I think it is doable. Thanks to Dirk for highlighting the real problem here (I think historically, the integrity requirement came out of the reliability section, and somehow, got lumped with synchronization and updates). I think the requirements need a bit of rewording, and the paragraph should fall out from this. I do believe however, that making the synchronization of context between old and new AR a MUST requirement would be too extreme, and result in a brittle solution. CT should certainly do it's best to provide synchronization, but as was discussed in a recent exchange, it would be impossible to guarantee synchronization at any instant. Any ideas/comments from the wg? Gary > -----Original Message----- > From: James Kempf [mailto:kempf@docomolabs-usa.com] > Sent: July 11, 2002 18:32 > To: Kenward, Gary [WDLN2:AN10:EXCH]; Dirk.Trossen@nokia.com; > seamoby@ietf.org > Subject: Re: [Seamoby] CT Requirements Comments from IESG > > > Gary/Dirk, > > I think you may be on to something here. I think this might > be what the IESG was talking about it the first point, namely the > lack of discussion of dynamic changes in the context. > > Is there some way we could cook this idea down into a > paragraph that we could insert for this requirement? > > jak > > ----- Original Message ----- > From: "Gary Kenward" > To: ; ; > > Sent: Thursday, July 11, 2002 1:56 PM > Subject: RE: [Seamoby] CT Requirements Comments from IESG > > > > Dirk: > > > > A valid point. There is a certain atomic level of > granularity which has to > > be > > dealt with - that is, there's no protocol in the world that > can synchronize > > changes in > > information that occur at the source while the information > is "in-flight" or > > being > > received at the destination. If changes in context while > the context is > > being transferred > > make a different to the successful performance of CT, then > there is no hope. > > > > The problem is most significant for state context > transfer. E.g. counters > > will continue > > to count while CT is moving the context to the destination. > Either these > > changes have no > > significant impact upon the forwarding service provided at > the new AR (e.g. > > it may not > > matter that a policing meter misses a few packet counts), > or a different > > mechanism > > has to be defined for re-establishing the state context. > > > > The handover is real and unavoidable. Mitigating the > disruption to the > > service at the new > > AR is the challenge. It would be nice if the disruption was nil, but > > unlikely. > > > > Gary > > > > -----Original Message----- > > From: Dirk.Trossen@nokia.com [mailto:Dirk.Trossen@nokia.com] > > Sent: July 11, 2002 16:30 > > To: Kenward, Gary [WDLN2:AN10:EXCH]; kempf@docomolabs-usa.com; > > seamoby@ietf.org > > Subject: RE: [Seamoby] CT Requirements Comments from IESG > > > > > > Hi all, > > > > jumping in as somebody who has been an observer so far, > struggling with the > > current discussion on > > 'integrity'. > > > > When I look at the current wording, i.e., > > "5.5.2 A context update MUST preserve the integrity, and > thus the meaning, > > of the context > > at each receiving AR. The context at the AR actually > supporting an MN's > > traffic will change with time. > > For example, the MN may initiate new microflow(s), or > discontinue existing > > microflows. Any change of context > > at the supporting AR must be replicated at those ARs that > have already > > received context for that MN.", > > > > and compare this to the plain integrity of the actually > transmitted data > > (i.e., its bits and therefore its semantics) > > that has been brought to the table as a replacement now, > I'm quite confident > > that this is not what the requirement > > is talking about. > > > > If we remove the word 'meaning' (which is very vague and free for > > interpretation for me as well), it is still the word > > 'integrity' left, which is more than plain integrity of the > transmitted > > data, in particular if we look at the following sentences > > in the requirement, which state what kind of integrity is > meant (which > > probably also builds the bridge to the vague > > term 'meaning'), namely that the integrity of a context > must be preserved in > > the sense that a received context at new > > AR at some point t must be the same as the context at old > AR at the same > > time t. This is by far more than plain data > > integrity of the transmitted data. Even if your data has > been transmitted > > correctly, the context might be stale (and therefore > > its integrity is lost) because it had changed at old AR in > the meanwhile. > > The action to be taken is also given in the text, > > namely the change of context has to be replicated to the > new AR. As you can > > (hopefully) see this is by far more than > > preserving the 'meaning' of each bit. It mandates that > changes in the bit > > values at one end are reflected at the other > > end, i.e., it talks about distributed data integrity in my > interpretation of > > the requirement text. > > > > Hence, the actual concern might have been (just guessing) > whether or not it > > is the task of the CT protocol to > > preserve the abovementioned integrity. Maybe, the IESG > wants to see this > > functionality left to the replication logic that resides > > within each AR. Or on the contrary, they do not see this > important topic > > covered appropriately. > > > > Regards, > > > > > > Dirk > > > > -----Original Message----- > > From: ext Gary Kenward [mailto:gkenward@nortelnetworks.com] > > Sent: Thursday, July 11, 2002 3:48 PM > > To: 'James Kempf'; seamoby@ietf.org > > Subject: RE: [Seamoby] CT Requirements Comments from IESG > > > > > > > > You call it fidelity, I call it data integrity. > > I've seen "data integrity" used in publications > > (no, I cannot quote references). > > > > What we need is a term that everyone, including the > > IESG, can agree upon. > > > > > -----Original Message----- > > > From: James Kempf [ mailto:kempf@docomolabs-usa.com > > ] > > > Sent: July 11, 2002 12:22 > > > To: Kenward, Gary [WDLN2:AN10:EXCH]; seamoby@ietf.org > > > Subject: Re: [Seamoby] CT Requirements Comments from IESG > > > > > > > > > > Perhaps the actual answer is to state exactly what was intended > > > > originally: that the bit order and bit values have to > arrive exactly > > > > as they were transmitted. > > > > > > > > > > So this requirement is talking about transmission fidelity? I > > > sure would not have guessed that from reading it. I thought it > > > intended to talk about usability. > > > > > > I would suggest that the wording you have above is really a > > > lot more precise that what is currently in the spec. > > > > > > Any other comments? Could we substitute Gary's wording above > > > for "meaning" in the current requirement. > > > > > > jak > > > > > > > > > > > > ------_=_NextPart_001_01C229BB.9F2F1000 Content-Type: text/html; charset="iso-8859-1" RE: [Seamoby] CT Requirements Comments from IESG

James:

  Yes, we need to fix it, and I think it is doable.
Thanks to Dirk for highlighting the real problem here
(I think historically, the integrity requirement came out
of the reliability section, and somehow, got lumped with
synchronization and updates).

  I think the requirements need a bit of rewording, and
the paragraph should fall out from this. I do believe
however, that making the synchronization of context between
old and new AR a MUST requirement would be too extreme, and
result in a brittle solution. CT should certainly do it's best to
provide synchronization, but as was discussed in a recent
exchange, it would be impossible to guarantee synchronization
at any instant.

  Any ideas/comments from the wg?

Gary

> -----Original Message-----
> From: James Kempf [mailto:kempf@docomolabs-usa.com]
> Sent: July 11, 2002 18:32
> To: Kenward, Gary [WDLN2:AN10:EXCH]; Dirk.Trossen@nokia.com;
> seamoby@ietf.org
> Subject: Re: [Seamoby] CT Requirements Comments from IESG
>
>
> Gary/Dirk,
>
> I think you may be on to something here. I think this might
> be what the IESG was talking about it the first point, namely the
> lack of discussion of dynamic changes in the context.
>
> Is there some way we could cook this idea down into a
> paragraph that we could insert for this requirement?
>
>             jak
>
> ----- Original Message -----
> From: "Gary Kenward" <gkenward@nortelnetworks.com>
> To: <Dirk.Trossen@nokia.com>; <kempf@docomolabs-usa.com>;
> <seamoby@ietf.org>
> Sent: Thursday, July 11, 2002 1:56 PM
> Subject: RE: [Seamoby] CT Requirements Comments from IESG
>
>
> > Dirk:
> >
> >   A valid point. There is a certain atomic level of
> granularity which has to
> > be
> > dealt with - that is, there's no protocol in the world that
> can synchronize
> > changes in
> > information that occur at the source while the information
> is "in-flight" or
> > being
> > received at the destination. If changes in context while
> the context is
> > being transferred
> > make a different to the successful performance of CT, then
> there is no hope.
> >
> >   The problem is most significant for state context
> transfer. E.g. counters
> > will continue
> > to count while CT is moving the context to the destination.
> Either these
> > changes have no
> > significant impact upon the forwarding service provided at
> the new AR (e.g.
> > it may not
> > matter that a policing meter misses a few packet counts),
> or a different
> > mechanism
> > has to be defined for re-establishing the state context.
> >
> >   The handover is real and unavoidable. Mitigating the
> disruption to the
> > service at the new
> > AR is the challenge. It would be nice if the disruption was nil, but
> > unlikely.
> >
> > Gary
> >
> > -----Original Message-----
> > From: Dirk.Trossen@nokia.com [mailto:Dirk.Trossen@nokia.com]
> > Sent: July 11, 2002 16:30
> > To: Kenward, Gary [WDLN2:AN10:EXCH]; kempf@docomolabs-usa.com;
> > seamoby@ietf.org
> > Subject: RE: [Seamoby] CT Requirements Comments from IESG
> >
> >
> > Hi all,
> >
> > jumping in as somebody who has been an observer so far,
> struggling with the
> > current discussion on
> > 'integrity'.
> >
> > When I look at the current wording, i.e.,
> > "5.5.2 A context update MUST preserve the integrity, and
> thus the meaning,
> > of the context
> > at each receiving AR. The context at the AR actually
> supporting an MN's
> > traffic will change with time.
> > For example, the MN may initiate new microflow(s), or
> discontinue existing
> > microflows. Any change of context
> > at the supporting AR must be replicated at those ARs that
> have already
> > received context for that MN.",
> >
> > and compare this to the plain integrity of the actually
> transmitted data
> > (i.e., its bits and therefore its semantics)
> > that has been brought to the table as a replacement now,
> I'm quite confident
> > that this is not what the requirement
> > is talking about.
> >
> > If we remove the word 'meaning' (which is very vague and free for
> > interpretation for me as well), it is still the word
> > 'integrity' left, which is more than plain integrity of the
> transmitted
> > data, in particular if we look at the following sentences
> > in the requirement, which state what kind of integrity is
> meant (which
> > probably also builds the bridge to the vague
> > term 'meaning'), namely that the integrity of a context
> must be preserved in
> > the sense that a received context at new
> > AR at some point t must be the same as the context at old
> AR at the same
> > time t. This is by far more than plain data
> > integrity of the transmitted data. Even if your data has
> been transmitted
> > correctly, the context might be stale (and therefore
> > its integrity is lost) because it had changed at old AR in
> the meanwhile.
> > The action to be taken is also given in the text,
> > namely the change of context has to be replicated to the
> new AR. As you can
> > (hopefully) see this is by far more than
> > preserving the 'meaning' of each bit. It mandates that
> changes in the bit
> > values at one end are reflected at the other
> > end, i.e., it talks about distributed data integrity in my
> interpretation of
> > the requirement text.
> >
> > Hence, the actual concern might have been (just guessing)
> whether or not it
> > is the task of the CT protocol to
> > preserve the abovementioned integrity. Maybe, the IESG
> wants to see this
> > functionality left to the replication logic that resides
> > within each AR. Or on the contrary, they do not see this
> important topic
> > covered appropriately.
> >
> > Regards,
> >
> >
> > Dirk
> >
> > -----Original Message-----
> > From: ext Gary Kenward [mailto:gkenward@nortelnetworks.com]
> > Sent: Thursday, July 11, 2002 3:48 PM
> > To: 'James Kempf'; seamoby@ietf.org
> > Subject: RE: [Seamoby] CT Requirements Comments from IESG
> >
> >
> >
> > You call it fidelity, I call it data integrity.
> > I've seen "data integrity" used in publications
> > (no, I cannot quote references).
> >
> > What we need is a term that everyone, including the
> > IESG, can agree upon.
> >
> > > -----Original Message-----
> > > From: James Kempf [ mailto:kempf@docomolabs-usa.com
> > <mailto:kempf@docomolabs-usa.com> ]
> > > Sent: July 11, 2002 12:22
> > > To: Kenward, Gary [WDLN2:AN10:EXCH]; seamoby@ietf.org
> > > Subject: Re: [Seamoby] CT Requirements Comments from IESG
> > >
> > >
> > > > Perhaps the actual answer is to state exactly what was intended
> > > > originally: that the bit order and bit values have to
> arrive exactly
> > > > as they were transmitted.
> > > >
> > >
> > > So this requirement is talking about transmission fidelity? I
> > > sure would not have guessed that from reading it. I thought it
> > > intended to talk about usability.
> > >
> > > I would suggest that the wording you have above is really a
> > > lot more precise that what is currently in the spec.
> > >
> > > Any other comments? Could we substitute Gary's wording above
> > > for "meaning" in the current requirement.
> > >
> > >             jak
> > >
> > >
> >
> >
>
>

------_=_NextPart_001_01C229BB.9F2F1000-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Fri Jul 12 11:55:11 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29467 for ; Fri, 12 Jul 2002 11:55:11 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA28624 for seamoby-archive@odin.ietf.org; Fri, 12 Jul 2002 11:56:06 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA28276; Fri, 12 Jul 2002 11:50:05 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA28214 for ; Fri, 12 Jul 2002 11:50:01 -0400 (EDT) Received: from zcars04e.ca.nortel.com (zcars04e.nortelnetworks.com [47.129.242.56]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29132 for ; Fri, 12 Jul 2002 11:49:04 -0400 (EDT) Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g6CFmrg17032; Fri, 12 Jul 2002 11:48:53 -0400 (EDT) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 12 Jul 2002 11:48:53 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA4C17@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'James Kempf'" , Dirk.Trossen@nokia.com, seamoby@ietf.org Subject: RE: [Seamoby] CT Requirements Comments from IESG Date: Fri, 12 Jul 2002 11:48:52 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C229BB.9F2F1000" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C229BB.9F2F1000 Content-Type: text/plain; charset="iso-8859-1" James: Yes, we need to fix it, and I think it is doable. Thanks to Dirk for highlighting the real problem here (I think historically, the integrity requirement came out of the reliability section, and somehow, got lumped with synchronization and updates). I think the requirements need a bit of rewording, and the paragraph should fall out from this. I do believe however, that making the synchronization of context between old and new AR a MUST requirement would be too extreme, and result in a brittle solution. CT should certainly do it's best to provide synchronization, but as was discussed in a recent exchange, it would be impossible to guarantee synchronization at any instant. Any ideas/comments from the wg? Gary > -----Original Message----- > From: James Kempf [mailto:kempf@docomolabs-usa.com] > Sent: July 11, 2002 18:32 > To: Kenward, Gary [WDLN2:AN10:EXCH]; Dirk.Trossen@nokia.com; > seamoby@ietf.org > Subject: Re: [Seamoby] CT Requirements Comments from IESG > > > Gary/Dirk, > > I think you may be on to something here. I think this might > be what the IESG was talking about it the first point, namely the > lack of discussion of dynamic changes in the context. > > Is there some way we could cook this idea down into a > paragraph that we could insert for this requirement? > > jak > > ----- Original Message ----- > From: "Gary Kenward" > To: ; ; > > Sent: Thursday, July 11, 2002 1:56 PM > Subject: RE: [Seamoby] CT Requirements Comments from IESG > > > > Dirk: > > > > A valid point. There is a certain atomic level of > granularity which has to > > be > > dealt with - that is, there's no protocol in the world that > can synchronize > > changes in > > information that occur at the source while the information > is "in-flight" or > > being > > received at the destination. If changes in context while > the context is > > being transferred > > make a different to the successful performance of CT, then > there is no hope. > > > > The problem is most significant for state context > transfer. E.g. counters > > will continue > > to count while CT is moving the context to the destination. > Either these > > changes have no > > significant impact upon the forwarding service provided at > the new AR (e.g. > > it may not > > matter that a policing meter misses a few packet counts), > or a different > > mechanism > > has to be defined for re-establishing the state context. > > > > The handover is real and unavoidable. Mitigating the > disruption to the > > service at the new > > AR is the challenge. It would be nice if the disruption was nil, but > > unlikely. > > > > Gary > > > > -----Original Message----- > > From: Dirk.Trossen@nokia.com [mailto:Dirk.Trossen@nokia.com] > > Sent: July 11, 2002 16:30 > > To: Kenward, Gary [WDLN2:AN10:EXCH]; kempf@docomolabs-usa.com; > > seamoby@ietf.org > > Subject: RE: [Seamoby] CT Requirements Comments from IESG > > > > > > Hi all, > > > > jumping in as somebody who has been an observer so far, > struggling with the > > current discussion on > > 'integrity'. > > > > When I look at the current wording, i.e., > > "5.5.2 A context update MUST preserve the integrity, and > thus the meaning, > > of the context > > at each receiving AR. The context at the AR actually > supporting an MN's > > traffic will change with time. > > For example, the MN may initiate new microflow(s), or > discontinue existing > > microflows. Any change of context > > at the supporting AR must be replicated at those ARs that > have already > > received context for that MN.", > > > > and compare this to the plain integrity of the actually > transmitted data > > (i.e., its bits and therefore its semantics) > > that has been brought to the table as a replacement now, > I'm quite confident > > that this is not what the requirement > > is talking about. > > > > If we remove the word 'meaning' (which is very vague and free for > > interpretation for me as well), it is still the word > > 'integrity' left, which is more than plain integrity of the > transmitted > > data, in particular if we look at the following sentences > > in the requirement, which state what kind of integrity is > meant (which > > probably also builds the bridge to the vague > > term 'meaning'), namely that the integrity of a context > must be preserved in > > the sense that a received context at new > > AR at some point t must be the same as the context at old > AR at the same > > time t. This is by far more than plain data > > integrity of the transmitted data. Even if your data has > been transmitted > > correctly, the context might be stale (and therefore > > its integrity is lost) because it had changed at old AR in > the meanwhile. > > The action to be taken is also given in the text, > > namely the change of context has to be replicated to the > new AR. As you can > > (hopefully) see this is by far more than > > preserving the 'meaning' of each bit. It mandates that > changes in the bit > > values at one end are reflected at the other > > end, i.e., it talks about distributed data integrity in my > interpretation of > > the requirement text. > > > > Hence, the actual concern might have been (just guessing) > whether or not it > > is the task of the CT protocol to > > preserve the abovementioned integrity. Maybe, the IESG > wants to see this > > functionality left to the replication logic that resides > > within each AR. Or on the contrary, they do not see this > important topic > > covered appropriately. > > > > Regards, > > > > > > Dirk > > > > -----Original Message----- > > From: ext Gary Kenward [mailto:gkenward@nortelnetworks.com] > > Sent: Thursday, July 11, 2002 3:48 PM > > To: 'James Kempf'; seamoby@ietf.org > > Subject: RE: [Seamoby] CT Requirements Comments from IESG > > > > > > > > You call it fidelity, I call it data integrity. > > I've seen "data integrity" used in publications > > (no, I cannot quote references). > > > > What we need is a term that everyone, including the > > IESG, can agree upon. > > > > > -----Original Message----- > > > From: James Kempf [ mailto:kempf@docomolabs-usa.com > > ] > > > Sent: July 11, 2002 12:22 > > > To: Kenward, Gary [WDLN2:AN10:EXCH]; seamoby@ietf.org > > > Subject: Re: [Seamoby] CT Requirements Comments from IESG > > > > > > > > > > Perhaps the actual answer is to state exactly what was intended > > > > originally: that the bit order and bit values have to > arrive exactly > > > > as they were transmitted. > > > > > > > > > > So this requirement is talking about transmission fidelity? I > > > sure would not have guessed that from reading it. I thought it > > > intended to talk about usability. > > > > > > I would suggest that the wording you have above is really a > > > lot more precise that what is currently in the spec. > > > > > > Any other comments? Could we substitute Gary's wording above > > > for "meaning" in the current requirement. > > > > > > jak > > > > > > > > > > > > ------_=_NextPart_001_01C229BB.9F2F1000 Content-Type: text/html; charset="iso-8859-1" RE: [Seamoby] CT Requirements Comments from IESG

James:

  Yes, we need to fix it, and I think it is doable.
Thanks to Dirk for highlighting the real problem here
(I think historically, the integrity requirement came out
of the reliability section, and somehow, got lumped with
synchronization and updates).

  I think the requirements need a bit of rewording, and
the paragraph should fall out from this. I do believe
however, that making the synchronization of context between
old and new AR a MUST requirement would be too extreme, and
result in a brittle solution. CT should certainly do it's best to
provide synchronization, but as was discussed in a recent
exchange, it would be impossible to guarantee synchronization
at any instant.

  Any ideas/comments from the wg?

Gary

> -----Original Message-----
> From: James Kempf [mailto:kempf@docomolabs-usa.com]
> Sent: July 11, 2002 18:32
> To: Kenward, Gary [WDLN2:AN10:EXCH]; Dirk.Trossen@nokia.com;
> seamoby@ietf.org
> Subject: Re: [Seamoby] CT Requirements Comments from IESG
>
>
> Gary/Dirk,
>
> I think you may be on to something here. I think this might
> be what the IESG was talking about it the first point, namely the
> lack of discussion of dynamic changes in the context.
>
> Is there some way we could cook this idea down into a
> paragraph that we could insert for this requirement?
>
>             jak
>
> ----- Original Message -----
> From: "Gary Kenward" <gkenward@nortelnetworks.com>
> To: <Dirk.Trossen@nokia.com>; <kempf@docomolabs-usa.com>;
> <seamoby@ietf.org>
> Sent: Thursday, July 11, 2002 1:56 PM
> Subject: RE: [Seamoby] CT Requirements Comments from IESG
>
>
> > Dirk:
> >
> >   A valid point. There is a certain atomic level of
> granularity which has to
> > be
> > dealt with - that is, there's no protocol in the world that
> can synchronize
> > changes in
> > information that occur at the source while the information
> is "in-flight" or
> > being
> > received at the destination. If changes in context while
> the context is
> > being transferred
> > make a different to the successful performance of CT, then
> there is no hope.
> >
> >   The problem is most significant for state context
> transfer. E.g. counters
> > will continue
> > to count while CT is moving the context to the destination.
> Either these
> > changes have no
> > significant impact upon the forwarding service provided at
> the new AR (e.g.
> > it may not
> > matter that a policing meter misses a few packet counts),
> or a different
> > mechanism
> > has to be defined for re-establishing the state context.
> >
> >   The handover is real and unavoidable. Mitigating the
> disruption to the
> > service at the new
> > AR is the challenge. It would be nice if the disruption was nil, but
> > unlikely.
> >
> > Gary
> >
> > -----Original Message-----
> > From: Dirk.Trossen@nokia.com [mailto:Dirk.Trossen@nokia.com]
> > Sent: July 11, 2002 16:30
> > To: Kenward, Gary [WDLN2:AN10:EXCH]; kempf@docomolabs-usa.com;
> > seamoby@ietf.org
> > Subject: RE: [Seamoby] CT Requirements Comments from IESG
> >
> >
> > Hi all,
> >
> > jumping in as somebody who has been an observer so far,
> struggling with the
> > current discussion on
> > 'integrity'.
> >
> > When I look at the current wording, i.e.,
> > "5.5.2 A context update MUST preserve the integrity, and
> thus the meaning,
> > of the context
> > at each receiving AR. The context at the AR actually
> supporting an MN's
> > traffic will change with time.
> > For example, the MN may initiate new microflow(s), or
> discontinue existing
> > microflows. Any change of context
> > at the supporting AR must be replicated at those ARs that
> have already
> > received context for that MN.",
> >
> > and compare this to the plain integrity of the actually
> transmitted data
> > (i.e., its bits and therefore its semantics)
> > that has been brought to the table as a replacement now,
> I'm quite confident
> > that this is not what the requirement
> > is talking about.
> >
> > If we remove the word 'meaning' (which is very vague and free for
> > interpretation for me as well), it is still the word
> > 'integrity' left, which is more than plain integrity of the
> transmitted
> > data, in particular if we look at the following sentences
> > in the requirement, which state what kind of integrity is
> meant (which
> > probably also builds the bridge to the vague
> > term 'meaning'), namely that the integrity of a context
> must be preserved in
> > the sense that a received context at new
> > AR at some point t must be the same as the context at old
> AR at the same
> > time t. This is by far more than plain data
> > integrity of the transmitted data. Even if your data has
> been transmitted
> > correctly, the context might be stale (and therefore
> > its integrity is lost) because it had changed at old AR in
> the meanwhile.
> > The action to be taken is also given in the text,
> > namely the change of context has to be replicated to the
> new AR. As you can
> > (hopefully) see this is by far more than
> > preserving the 'meaning' of each bit. It mandates that
> changes in the bit
> > values at one end are reflected at the other
> > end, i.e., it talks about distributed data integrity in my
> interpretation of
> > the requirement text.
> >
> > Hence, the actual concern might have been (just guessing)
> whether or not it
> > is the task of the CT protocol to
> > preserve the abovementioned integrity. Maybe, the IESG
> wants to see this
> > functionality left to the replication logic that resides
> > within each AR. Or on the contrary, they do not see this
> important topic
> > covered appropriately.
> >
> > Regards,
> >
> >
> > Dirk
> >
> > -----Original Message-----
> > From: ext Gary Kenward [mailto:gkenward@nortelnetworks.com]
> > Sent: Thursday, July 11, 2002 3:48 PM
> > To: 'James Kempf'; seamoby@ietf.org
> > Subject: RE: [Seamoby] CT Requirements Comments from IESG
> >
> >
> >
> > You call it fidelity, I call it data integrity.
> > I've seen "data integrity" used in publications
> > (no, I cannot quote references).
> >
> > What we need is a term that everyone, including the
> > IESG, can agree upon.
> >
> > > -----Original Message-----
> > > From: James Kempf [ mailto:kempf@docomolabs-usa.com
> > <mailto:kempf@docomolabs-usa.com> ]
> > > Sent: July 11, 2002 12:22
> > > To: Kenward, Gary [WDLN2:AN10:EXCH]; seamoby@ietf.org
> > > Subject: Re: [Seamoby] CT Requirements Comments from IESG
> > >
> > >
> > > > Perhaps the actual answer is to state exactly what was intended
> > > > originally: that the bit order and bit values have to
> arrive exactly
> > > > as they were transmitted.
> > > >
> > >
> > > So this requirement is talking about transmission fidelity? I
> > > sure would not have guessed that from reading it. I thought it
> > > intended to talk about usability.
> > >
> > > I would suggest that the wording you have above is really a
> > > lot more precise that what is currently in the spec.
> > >
> > > Any other comments? Could we substitute Gary's wording above
> > > for "meaning" in the current requirement.
> > >
> > >             jak
> > >
> > >
> >
> >
>
>

------_=_NextPart_001_01C229BB.9F2F1000-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Fri Jul 12 12:19:47 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01348 for ; Fri, 12 Jul 2002 12:19:46 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA01732; Fri, 12 Jul 2002 12:15:06 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA01701 for ; Fri, 12 Jul 2002 12:15:04 -0400 (EDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00938 for ; Fri, 12 Jul 2002 12:14:09 -0400 (EDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id JAA26662; Fri, 12 Jul 2002 09:14:32 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g6CGEVR07830; Fri, 12 Jul 2002 09:14:31 -0700 X-mProtect: <200207121614> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdd1MD41; Fri, 12 Jul 2002 09:14:29 PDT Message-ID: <3D2F0066.39127FAF@iprg.nokia.com> Date: Fri, 12 Jul 2002 09:14:30 -0700 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Gary Kenward CC: seamoby@ietf.org Subject: Re: [Seamoby] CT Requirements Comments from IESG References: <9FBD322B7824D511B36900508BF93C9C01AA4C17@zcard031.ca.nortel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit Hello folks, I think we ought to try to get context transfers working correctly without initially worrying about this synchronization problem. In the instances I am familiar with, it is not required. The most stringent case seems to be ROHC, and even for that it is not necessary. We can solve the most urgent problems without having to deal with any additional context synchronization. When the old AR sends it, and the new AR gets it, we should consider the transfer done. In those cases where reliability is at issue, the old AR can retransmit when ACK is not received. In many cases, retransmission of context even once won't be useful. Regards, Charlie P. > Gary Kenward wrote: > > James: > > Yes, we need to fix it, and I think it is doable. > Thanks to Dirk for highlighting the real problem here > (I think historically, the integrity requirement came out > of the reliability section, and somehow, got lumped with > synchronization and updates). > > I think the requirements need a bit of rewording, and > the paragraph should fall out from this. I do believe > however, that making the synchronization of context between > old and new AR a MUST requirement would be too extreme, and > result in a brittle solution. CT should certainly do it's best to > provide synchronization, but as was discussed in a recent > exchange, it would be impossible to guarantee synchronization > at any instant. > > Any ideas/comments from the wg? > > Gary > > > -----Original Message----- > > From: James Kempf [mailto:kempf@docomolabs-usa.com] > > Sent: July 11, 2002 18:32 > > To: Kenward, Gary [WDLN2:AN10:EXCH]; Dirk.Trossen@nokia.com; > > seamoby@ietf.org > > Subject: Re: [Seamoby] CT Requirements Comments from IESG > > > > > > Gary/Dirk, > > > > I think you may be on to something here. I think this might > > be what the IESG was talking about it the first point, namely the > > lack of discussion of dynamic changes in the context. > > > > Is there some way we could cook this idea down into a > > paragraph that we could insert for this requirement? > > > > jak > > > > ----- Original Message ----- > > From: "Gary Kenward" > > To: ; ; > > > > Sent: Thursday, July 11, 2002 1:56 PM > > Subject: RE: [Seamoby] CT Requirements Comments from IESG > > > > > > > Dirk: > > > > > > A valid point. There is a certain atomic level of > > granularity which has to > > > be > > > dealt with - that is, there's no protocol in the world that > > can synchronize > > > changes in > > > information that occur at the source while the information > > is "in-flight" or > > > being > > > received at the destination. If changes in context while > > the context is > > > being transferred > > > make a different to the successful performance of CT, then > > there is no hope. > > > > > > The problem is most significant for state context > > transfer. E.g. counters > > > will continue > > > to count while CT is moving the context to the destination. > > Either these > > > changes have no > > > significant impact upon the forwarding service provided at > > the new AR (e.g. > > > it may not > > > matter that a policing meter misses a few packet counts), > > or a different > > > mechanism > > > has to be defined for re-establishing the state context. > > > > > > The handover is real and unavoidable. Mitigating the > > disruption to the > > > service at the new > > > AR is the challenge. It would be nice if the disruption was nil, but > > > unlikely. > > > > > > Gary > > > > > > -----Original Message----- > > > From: Dirk.Trossen@nokia.com [mailto:Dirk.Trossen@nokia.com] > > > Sent: July 11, 2002 16:30 > > > To: Kenward, Gary [WDLN2:AN10:EXCH]; kempf@docomolabs-usa.com; > > > seamoby@ietf.org > > > Subject: RE: [Seamoby] CT Requirements Comments from IESG > > > > > > > > > Hi all, > > > > > > jumping in as somebody who has been an observer so far, > > struggling with the > > > current discussion on > > > 'integrity'. > > > > > > When I look at the current wording, i.e., > > > "5.5.2 A context update MUST preserve the integrity, and > > thus the meaning, > > > of the context > > > at each receiving AR. The context at the AR actually > > supporting an MN's > > > traffic will change with time. > > > For example, the MN may initiate new microflow(s), or > > discontinue existing > > > microflows. Any change of context > > > at the supporting AR must be replicated at those ARs that > > have already > > > received context for that MN.", > > > > > > and compare this to the plain integrity of the actually > > transmitted data > > > (i.e., its bits and therefore its semantics) > > > that has been brought to the table as a replacement now, > > I'm quite confident > > > that this is not what the requirement > > > is talking about. > > > > > > If we remove the word 'meaning' (which is very vague and free for > > > interpretation for me as well), it is still the word > > > 'integrity' left, which is more than plain integrity of the > > transmitted > > > data, in particular if we look at the following sentences > > > in the requirement, which state what kind of integrity is > > meant (which > > > probably also builds the bridge to the vague > > > term 'meaning'), namely that the integrity of a context > > must be preserved in > > > the sense that a received context at new > > > AR at some point t must be the same as the context at old > > AR at the same > > > time t. This is by far more than plain data > > > integrity of the transmitted data. Even if your data has > > been transmitted > > > correctly, the context might be stale (and therefore > > > its integrity is lost) because it had changed at old AR in > > the meanwhile. > > > The action to be taken is also given in the text, > > > namely the change of context has to be replicated to the > > new AR. As you can > > > (hopefully) see this is by far more than > > > preserving the 'meaning' of each bit. It mandates that > > changes in the bit > > > values at one end are reflected at the other > > > end, i.e., it talks about distributed data integrity in my > > interpretation of > > > the requirement text. > > > > > > Hence, the actual concern might have been (just guessing) > > whether or not it > > > is the task of the CT protocol to > > > preserve the abovementioned integrity. Maybe, the IESG > > wants to see this > > > functionality left to the replication logic that resides > > > within each AR. Or on the contrary, they do not see this > > important topic > > > covered appropriately. > > > > > > Regards, > > > > > > > > > Dirk > > > > > > -----Original Message----- > > > From: ext Gary Kenward [mailto:gkenward@nortelnetworks.com] > > > Sent: Thursday, July 11, 2002 3:48 PM > > > To: 'James Kempf'; seamoby@ietf.org > > > Subject: RE: [Seamoby] CT Requirements Comments from IESG > > > > > > > > > > > > You call it fidelity, I call it data integrity. > > > I've seen "data integrity" used in publications > > > (no, I cannot quote references). > > > > > > What we need is a term that everyone, including the > > > IESG, can agree upon. > > > > > > > -----Original Message----- > > > > From: James Kempf [ mailto:kempf@docomolabs-usa.com > > > ] > > > > Sent: July 11, 2002 12:22 > > > > To: Kenward, Gary [WDLN2:AN10:EXCH]; seamoby@ietf.org > > > > Subject: Re: [Seamoby] CT Requirements Comments from IESG > > > > > > > > > > > > > Perhaps the actual answer is to state exactly what was intended > > > > > originally: that the bit order and bit values have to > > arrive exactly > > > > > as they were transmitted. > > > > > > > > > > > > > So this requirement is talking about transmission fidelity? I > > > > sure would not have guessed that from reading it. I thought it > > > > intended to talk about usability. > > > > > > > > I would suggest that the wording you have above is really a > > > > lot more precise that what is currently in the spec. > > > > > > > > Any other comments? Could we substitute Gary's wording above > > > > for "meaning" in the current requirement. > > > > > > > > jak > > > > > > > > > > > > > > > > > > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Fri Jul 12 12:19:47 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01354 for ; Fri, 12 Jul 2002 12:19:47 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA02179 for seamoby-archive@odin.ietf.org; Fri, 12 Jul 2002 12:20:41 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA01732; Fri, 12 Jul 2002 12:15:06 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA01701 for ; Fri, 12 Jul 2002 12:15:04 -0400 (EDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00938 for ; Fri, 12 Jul 2002 12:14:09 -0400 (EDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id JAA26662; Fri, 12 Jul 2002 09:14:32 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g6CGEVR07830; Fri, 12 Jul 2002 09:14:31 -0700 X-mProtect: <200207121614> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdd1MD41; Fri, 12 Jul 2002 09:14:29 PDT Message-ID: <3D2F0066.39127FAF@iprg.nokia.com> Date: Fri, 12 Jul 2002 09:14:30 -0700 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Gary Kenward CC: seamoby@ietf.org Subject: Re: [Seamoby] CT Requirements Comments from IESG References: <9FBD322B7824D511B36900508BF93C9C01AA4C17@zcard031.ca.nortel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit Hello folks, I think we ought to try to get context transfers working correctly without initially worrying about this synchronization problem. In the instances I am familiar with, it is not required. The most stringent case seems to be ROHC, and even for that it is not necessary. We can solve the most urgent problems without having to deal with any additional context synchronization. When the old AR sends it, and the new AR gets it, we should consider the transfer done. In those cases where reliability is at issue, the old AR can retransmit when ACK is not received. In many cases, retransmission of context even once won't be useful. Regards, Charlie P. > Gary Kenward wrote: > > James: > > Yes, we need to fix it, and I think it is doable. > Thanks to Dirk for highlighting the real problem here > (I think historically, the integrity requirement came out > of the reliability section, and somehow, got lumped with > synchronization and updates). > > I think the requirements need a bit of rewording, and > the paragraph should fall out from this. I do believe > however, that making the synchronization of context between > old and new AR a MUST requirement would be too extreme, and > result in a brittle solution. CT should certainly do it's best to > provide synchronization, but as was discussed in a recent > exchange, it would be impossible to guarantee synchronization > at any instant. > > Any ideas/comments from the wg? > > Gary > > > -----Original Message----- > > From: James Kempf [mailto:kempf@docomolabs-usa.com] > > Sent: July 11, 2002 18:32 > > To: Kenward, Gary [WDLN2:AN10:EXCH]; Dirk.Trossen@nokia.com; > > seamoby@ietf.org > > Subject: Re: [Seamoby] CT Requirements Comments from IESG > > > > > > Gary/Dirk, > > > > I think you may be on to something here. I think this might > > be what the IESG was talking about it the first point, namely the > > lack of discussion of dynamic changes in the context. > > > > Is there some way we could cook this idea down into a > > paragraph that we could insert for this requirement? > > > > jak > > > > ----- Original Message ----- > > From: "Gary Kenward" > > To: ; ; > > > > Sent: Thursday, July 11, 2002 1:56 PM > > Subject: RE: [Seamoby] CT Requirements Comments from IESG > > > > > > > Dirk: > > > > > > A valid point. There is a certain atomic level of > > granularity which has to > > > be > > > dealt with - that is, there's no protocol in the world that > > can synchronize > > > changes in > > > information that occur at the source while the information > > is "in-flight" or > > > being > > > received at the destination. If changes in context while > > the context is > > > being transferred > > > make a different to the successful performance of CT, then > > there is no hope. > > > > > > The problem is most significant for state context > > transfer. E.g. counters > > > will continue > > > to count while CT is moving the context to the destination. > > Either these > > > changes have no > > > significant impact upon the forwarding service provided at > > the new AR (e.g. > > > it may not > > > matter that a policing meter misses a few packet counts), > > or a different > > > mechanism > > > has to be defined for re-establishing the state context. > > > > > > The handover is real and unavoidable. Mitigating the > > disruption to the > > > service at the new > > > AR is the challenge. It would be nice if the disruption was nil, but > > > unlikely. > > > > > > Gary > > > > > > -----Original Message----- > > > From: Dirk.Trossen@nokia.com [mailto:Dirk.Trossen@nokia.com] > > > Sent: July 11, 2002 16:30 > > > To: Kenward, Gary [WDLN2:AN10:EXCH]; kempf@docomolabs-usa.com; > > > seamoby@ietf.org > > > Subject: RE: [Seamoby] CT Requirements Comments from IESG > > > > > > > > > Hi all, > > > > > > jumping in as somebody who has been an observer so far, > > struggling with the > > > current discussion on > > > 'integrity'. > > > > > > When I look at the current wording, i.e., > > > "5.5.2 A context update MUST preserve the integrity, and > > thus the meaning, > > > of the context > > > at each receiving AR. The context at the AR actually > > supporting an MN's > > > traffic will change with time. > > > For example, the MN may initiate new microflow(s), or > > discontinue existing > > > microflows. Any change of context > > > at the supporting AR must be replicated at those ARs that > > have already > > > received context for that MN.", > > > > > > and compare this to the plain integrity of the actually > > transmitted data > > > (i.e., its bits and therefore its semantics) > > > that has been brought to the table as a replacement now, > > I'm quite confident > > > that this is not what the requirement > > > is talking about. > > > > > > If we remove the word 'meaning' (which is very vague and free for > > > interpretation for me as well), it is still the word > > > 'integrity' left, which is more than plain integrity of the > > transmitted > > > data, in particular if we look at the following sentences > > > in the requirement, which state what kind of integrity is > > meant (which > > > probably also builds the bridge to the vague > > > term 'meaning'), namely that the integrity of a context > > must be preserved in > > > the sense that a received context at new > > > AR at some point t must be the same as the context at old > > AR at the same > > > time t. This is by far more than plain data > > > integrity of the transmitted data. Even if your data has > > been transmitted > > > correctly, the context might be stale (and therefore > > > its integrity is lost) because it had changed at old AR in > > the meanwhile. > > > The action to be taken is also given in the text, > > > namely the change of context has to be replicated to the > > new AR. As you can > > > (hopefully) see this is by far more than > > > preserving the 'meaning' of each bit. It mandates that > > changes in the bit > > > values at one end are reflected at the other > > > end, i.e., it talks about distributed data integrity in my > > interpretation of > > > the requirement text. > > > > > > Hence, the actual concern might have been (just guessing) > > whether or not it > > > is the task of the CT protocol to > > > preserve the abovementioned integrity. Maybe, the IESG > > wants to see this > > > functionality left to the replication logic that resides > > > within each AR. Or on the contrary, they do not see this > > important topic > > > covered appropriately. > > > > > > Regards, > > > > > > > > > Dirk > > > > > > -----Original Message----- > > > From: ext Gary Kenward [mailto:gkenward@nortelnetworks.com] > > > Sent: Thursday, July 11, 2002 3:48 PM > > > To: 'James Kempf'; seamoby@ietf.org > > > Subject: RE: [Seamoby] CT Requirements Comments from IESG > > > > > > > > > > > > You call it fidelity, I call it data integrity. > > > I've seen "data integrity" used in publications > > > (no, I cannot quote references). > > > > > > What we need is a term that everyone, including the > > > IESG, can agree upon. > > > > > > > -----Original Message----- > > > > From: James Kempf [ mailto:kempf@docomolabs-usa.com > > > ] > > > > Sent: July 11, 2002 12:22 > > > > To: Kenward, Gary [WDLN2:AN10:EXCH]; seamoby@ietf.org > > > > Subject: Re: [Seamoby] CT Requirements Comments from IESG > > > > > > > > > > > > > Perhaps the actual answer is to state exactly what was intended > > > > > originally: that the bit order and bit values have to > > arrive exactly > > > > > as they were transmitted. > > > > > > > > > > > > > So this requirement is talking about transmission fidelity? I > > > > sure would not have guessed that from reading it. I thought it > > > > intended to talk about usability. > > > > > > > > I would suggest that the wording you have above is really a > > > > lot more precise that what is currently in the spec. > > > > > > > > Any other comments? Could we substitute Gary's wording above > > > > for "meaning" in the current requirement. > > > > > > > > jak > > > > > > > > > > > > > > > > > > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Fri Jul 12 15:55:19 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12002 for ; Fri, 12 Jul 2002 15:55:19 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA15522; Fri, 12 Jul 2002 15:40:07 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA15455 for ; Fri, 12 Jul 2002 15:40:04 -0400 (EDT) Received: from zcars04f.ca.nortel.com (zcars04f.nortelnetworks.com [47.129.242.57]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11330 for ; Fri, 12 Jul 2002 15:39:09 -0400 (EDT) Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04f.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g6CJZRl24542; Fri, 12 Jul 2002 15:35:28 -0400 (EDT) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 12 Jul 2002 15:35:27 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA4C19@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'Charles E. Perkins'" Cc: seamoby@ietf.org Subject: RE: [Seamoby] CT Requirements Comments from IESG Date: Fri, 12 Jul 2002 15:35:26 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C229DB.09DC8EC2" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C229DB.09DC8EC2 Content-Type: text/plain; charset="iso-8859-1" I agree Charlie. However, we have to fix the issue with the requirements. Are you suggesting that we relax the requirement? By how much - clearly, some updates are required (e.g. CT really should try and update when flows come and go). Gary > -----Original Message----- > From: Charles E. Perkins [mailto:charliep@iprg.nokia.com] > Sent: July 12, 2002 12:15 > To: Kenward, Gary [WDLN2:AN10:EXCH] > Cc: seamoby@ietf.org > Subject: Re: [Seamoby] CT Requirements Comments from IESG > > > > > Hello folks, > > I think we ought to try to get context transfers > working correctly without initially worrying about > this synchronization problem. > > In the instances I am familiar with, it is not > required. The most stringent case seems to be > ROHC, and even for that it is not necessary. > > We can solve the most urgent problems without having > to deal with any additional context synchronization. > When the old AR sends it, and the new AR gets it, > we should consider the transfer done. In those > cases where reliability is at issue, the old AR > can retransmit when ACK is not received. In many > cases, retransmission of context even once won't > be useful. > > Regards, > Charlie P. > > > > > Gary Kenward wrote: > > > > James: > > > > Yes, we need to fix it, and I think it is doable. > > Thanks to Dirk for highlighting the real problem here > > (I think historically, the integrity requirement came out > > of the reliability section, and somehow, got lumped with > > synchronization and updates). > > > > I think the requirements need a bit of rewording, and > > the paragraph should fall out from this. I do believe > > however, that making the synchronization of context between > > old and new AR a MUST requirement would be too extreme, and > > result in a brittle solution. CT should certainly do it's best to > > provide synchronization, but as was discussed in a recent > > exchange, it would be impossible to guarantee synchronization > > at any instant. > > > > Any ideas/comments from the wg? > > > > Gary > > > > > -----Original Message----- > > > From: James Kempf [mailto:kempf@docomolabs-usa.com] > > > Sent: July 11, 2002 18:32 > > > To: Kenward, Gary [WDLN2:AN10:EXCH]; Dirk.Trossen@nokia.com; > > > seamoby@ietf.org > > > Subject: Re: [Seamoby] CT Requirements Comments from IESG > > > > > > > > > Gary/Dirk, > > > > > > I think you may be on to something here. I think this might > > > be what the IESG was talking about it the first point, namely the > > > lack of discussion of dynamic changes in the context. > > > > > > Is there some way we could cook this idea down into a > > > paragraph that we could insert for this requirement? > > > > > > jak > > > > > > ----- Original Message ----- > > > From: "Gary Kenward" > > > To: ; ; > > > > > > Sent: Thursday, July 11, 2002 1:56 PM > > > Subject: RE: [Seamoby] CT Requirements Comments from IESG > > > > > > > > > > Dirk: > > > > > > > > A valid point. There is a certain atomic level of > > > granularity which has to > > > > be > > > > dealt with - that is, there's no protocol in the world that > > > can synchronize > > > > changes in > > > > information that occur at the source while the information > > > is "in-flight" or > > > > being > > > > received at the destination. If changes in context while > > > the context is > > > > being transferred > > > > make a different to the successful performance of CT, then > > > there is no hope. > > > > > > > > The problem is most significant for state context > > > transfer. E.g. counters > > > > will continue > > > > to count while CT is moving the context to the destination. > > > Either these > > > > changes have no > > > > significant impact upon the forwarding service provided at > > > the new AR (e.g. > > > > it may not > > > > matter that a policing meter misses a few packet counts), > > > or a different > > > > mechanism > > > > has to be defined for re-establishing the state context. > > > > > > > > The handover is real and unavoidable. Mitigating the > > > disruption to the > > > > service at the new > > > > AR is the challenge. It would be nice if the disruption > was nil, but > > > > unlikely. > > > > > > > > Gary > > > > > > > > -----Original Message----- > > > > From: Dirk.Trossen@nokia.com [mailto:Dirk.Trossen@nokia.com] > > > > Sent: July 11, 2002 16:30 > > > > To: Kenward, Gary [WDLN2:AN10:EXCH]; kempf@docomolabs-usa.com; > > > > seamoby@ietf.org > > > > Subject: RE: [Seamoby] CT Requirements Comments from IESG > > > > > > > > > > > > Hi all, > > > > > > > > jumping in as somebody who has been an observer so far, > > > struggling with the > > > > current discussion on > > > > 'integrity'. > > > > > > > > When I look at the current wording, i.e., > > > > "5.5.2 A context update MUST preserve the integrity, and > > > thus the meaning, > > > > of the context > > > > at each receiving AR. The context at the AR actually > > > supporting an MN's > > > > traffic will change with time. > > > > For example, the MN may initiate new microflow(s), or > > > discontinue existing > > > > microflows. Any change of context > > > > at the supporting AR must be replicated at those ARs that > > > have already > > > > received context for that MN.", > > > > > > > > and compare this to the plain integrity of the actually > > > transmitted data > > > > (i.e., its bits and therefore its semantics) > > > > that has been brought to the table as a replacement now, > > > I'm quite confident > > > > that this is not what the requirement > > > > is talking about. > > > > > > > > If we remove the word 'meaning' (which is very vague > and free for > > > > interpretation for me as well), it is still the word > > > > 'integrity' left, which is more than plain integrity of the > > > transmitted > > > > data, in particular if we look at the following sentences > > > > in the requirement, which state what kind of integrity is > > > meant (which > > > > probably also builds the bridge to the vague > > > > term 'meaning'), namely that the integrity of a context > > > must be preserved in > > > > the sense that a received context at new > > > > AR at some point t must be the same as the context at old > > > AR at the same > > > > time t. This is by far more than plain data > > > > integrity of the transmitted data. Even if your data has > > > been transmitted > > > > correctly, the context might be stale (and therefore > > > > its integrity is lost) because it had changed at old AR in > > > the meanwhile. > > > > The action to be taken is also given in the text, > > > > namely the change of context has to be replicated to the > > > new AR. As you can > > > > (hopefully) see this is by far more than > > > > preserving the 'meaning' of each bit. It mandates that > > > changes in the bit > > > > values at one end are reflected at the other > > > > end, i.e., it talks about distributed data integrity in my > > > interpretation of > > > > the requirement text. > > > > > > > > Hence, the actual concern might have been (just guessing) > > > whether or not it > > > > is the task of the CT protocol to > > > > preserve the abovementioned integrity. Maybe, the IESG > > > wants to see this > > > > functionality left to the replication logic that resides > > > > within each AR. Or on the contrary, they do not see this > > > important topic > > > > covered appropriately. > > > > > > > > Regards, > > > > > > > > > > > > Dirk > > > > > > > > -----Original Message----- > > > > From: ext Gary Kenward [mailto:gkenward@nortelnetworks.com] > > > > Sent: Thursday, July 11, 2002 3:48 PM > > > > To: 'James Kempf'; seamoby@ietf.org > > > > Subject: RE: [Seamoby] CT Requirements Comments from IESG > > > > > > > > > > > > > > > > You call it fidelity, I call it data integrity. > > > > I've seen "data integrity" used in publications > > > > (no, I cannot quote references). > > > > > > > > What we need is a term that everyone, including the > > > > IESG, can agree upon. > > > > > > > > > -----Original Message----- > > > > > From: James Kempf [ mailto:kempf@docomolabs-usa.com > > > > ] > > > > > Sent: July 11, 2002 12:22 > > > > > To: Kenward, Gary [WDLN2:AN10:EXCH]; seamoby@ietf.org > > > > > Subject: Re: [Seamoby] CT Requirements Comments from IESG > > > > > > > > > > > > > > > > Perhaps the actual answer is to state exactly what > was intended > > > > > > originally: that the bit order and bit values have to > > > arrive exactly > > > > > > as they were transmitted. > > > > > > > > > > > > > > > > So this requirement is talking about transmission fidelity? I > > > > > sure would not have guessed that from reading it. I thought it > > > > > intended to talk about usability. > > > > > > > > > > I would suggest that the wording you have above is really a > > > > > lot more precise that what is currently in the spec. > > > > > > > > > > Any other comments? Could we substitute Gary's wording above > > > > > for "meaning" in the current requirement. > > > > > > > > > > jak > > > > > > > > > > > > > > > > > > > > > > > > > ------_=_NextPart_001_01C229DB.09DC8EC2 Content-Type: text/html; charset="iso-8859-1" RE: [Seamoby] CT Requirements Comments from IESG

I agree Charlie. However, we have to fix the issue with
the requirements. Are you suggesting that we relax the
requirement? By how much - clearly, some updates are required
(e.g. CT really should try and update when flows come and go).

Gary

> -----Original Message-----
> From: Charles E. Perkins [mailto:charliep@iprg.nokia.com]
> Sent: July 12, 2002 12:15
> To: Kenward, Gary [WDLN2:AN10:EXCH]
> Cc: seamoby@ietf.org
> Subject: Re: [Seamoby] CT Requirements Comments from IESG
>
>
>
>
> Hello folks,
>
> I think we ought to try to get context transfers
> working correctly without initially worrying about
> this synchronization problem.
>
> In the instances I am familiar with, it is not
> required.  The most stringent case seems to be
> ROHC, and even for that it is not necessary.
>
> We can solve the most urgent problems without having
> to deal with any additional context synchronization.
> When the old AR sends it, and the new AR gets it,
> we should consider the transfer done.  In those
> cases where reliability is at issue, the old AR
> can retransmit when ACK is not received.  In many
> cases, retransmission of context even once won't
> be useful.
>
> Regards,
> Charlie P.
>
>
>
> > Gary Kenward wrote:
> >
> > James:
> >
> >   Yes, we need to fix it, and I think it is doable.
> > Thanks to Dirk for highlighting the real problem here
> > (I think historically, the integrity requirement came out
> > of the reliability section, and somehow, got lumped with
> > synchronization and updates).
> >
> >   I think the requirements need a bit of rewording, and
> > the paragraph should fall out from this. I do believe
> > however, that making the synchronization of context between
> > old and new AR a MUST requirement would be too extreme, and
> > result in a brittle solution. CT should certainly do it's best to
> > provide synchronization, but as was discussed in a recent
> > exchange, it would be impossible to guarantee synchronization
> > at any instant.
> >
> >   Any ideas/comments from the wg?
> >
> > Gary
> >
> > > -----Original Message-----
> > > From: James Kempf [mailto:kempf@docomolabs-usa.com]
> > > Sent: July 11, 2002 18:32
> > > To: Kenward, Gary [WDLN2:AN10:EXCH]; Dirk.Trossen@nokia.com;
> > > seamoby@ietf.org
> > > Subject: Re: [Seamoby] CT Requirements Comments from IESG
> > >
> > >
> > > Gary/Dirk,
> > >
> > > I think you may be on to something here. I think this might
> > > be what the IESG was talking about it the first point, namely the
> > > lack of discussion of dynamic changes in the context.
> > >
> > > Is there some way we could cook this idea down into a
> > > paragraph that we could insert for this requirement?
> > >
> > >             jak
> > >
> > > ----- Original Message -----
> > > From: "Gary Kenward" <gkenward@nortelnetworks.com>
> > > To: <Dirk.Trossen@nokia.com>; <kempf@docomolabs-usa.com>;
> > > <seamoby@ietf.org>
> > > Sent: Thursday, July 11, 2002 1:56 PM
> > > Subject: RE: [Seamoby] CT Requirements Comments from IESG
> > >
> > >
> > > > Dirk:
> > > >
> > > >   A valid point. There is a certain atomic level of
> > > granularity which has to
> > > > be
> > > > dealt with - that is, there's no protocol in the world that
> > > can synchronize
> > > > changes in
> > > > information that occur at the source while the information
> > > is "in-flight" or
> > > > being
> > > > received at the destination. If changes in context while
> > > the context is
> > > > being transferred
> > > > make a different to the successful performance of CT, then
> > > there is no hope.
> > > >
> > > >   The problem is most significant for state context
> > > transfer. E.g. counters
> > > > will continue
> > > > to count while CT is moving the context to the destination.
> > > Either these
> > > > changes have no
> > > > significant impact upon the forwarding service provided at
> > > the new AR (e.g.
> > > > it may not
> > > > matter that a policing meter misses a few packet counts),
> > > or a different
> > > > mechanism
> > > > has to be defined for re-establishing the state context.
> > > >
> > > >   The handover is real and unavoidable. Mitigating the
> > > disruption to the
> > > > service at the new
> > > > AR is the challenge. It would be nice if the disruption
> was nil, but
> > > > unlikely.
> > > >
> > > > Gary
> > > >
> > > > -----Original Message-----
> > > > From: Dirk.Trossen@nokia.com [mailto:Dirk.Trossen@nokia.com]
> > > > Sent: July 11, 2002 16:30
> > > > To: Kenward, Gary [WDLN2:AN10:EXCH]; kempf@docomolabs-usa.com;
> > > > seamoby@ietf.org
> > > > Subject: RE: [Seamoby] CT Requirements Comments from IESG
> > > >
> > > >
> > > > Hi all,
> > > >
> > > > jumping in as somebody who has been an observer so far,
> > > struggling with the
> > > > current discussion on
> > > > 'integrity'.
> > > >
> > > > When I look at the current wording, i.e.,
> > > > "5.5.2 A context update MUST preserve the integrity, and
> > > thus the meaning,
> > > > of the context
> > > > at each receiving AR. The context at the AR actually
> > > supporting an MN's
> > > > traffic will change with time.
> > > > For example, the MN may initiate new microflow(s), or
> > > discontinue existing
> > > > microflows. Any change of context
> > > > at the supporting AR must be replicated at those ARs that
> > > have already
> > > > received context for that MN.",
> > > >
> > > > and compare this to the plain integrity of the actually
> > > transmitted data
> > > > (i.e., its bits and therefore its semantics)
> > > > that has been brought to the table as a replacement now,
> > > I'm quite confident
> > > > that this is not what the requirement
> > > > is talking about.
> > > >
> > > > If we remove the word 'meaning' (which is very vague
> and free for
> > > > interpretation for me as well), it is still the word
> > > > 'integrity' left, which is more than plain integrity of the
> > > transmitted
> > > > data, in particular if we look at the following sentences
> > > > in the requirement, which state what kind of integrity is
> > > meant (which
> > > > probably also builds the bridge to the vague
> > > > term 'meaning'), namely that the integrity of a context
> > > must be preserved in
> > > > the sense that a received context at new
> > > > AR at some point t must be the same as the context at old
> > > AR at the same
> > > > time t. This is by far more than plain data
> > > > integrity of the transmitted data. Even if your data has
> > > been transmitted
> > > > correctly, the context might be stale (and therefore
> > > > its integrity is lost) because it had changed at old AR in
> > > the meanwhile.
> > > > The action to be taken is also given in the text,
> > > > namely the change of context has to be replicated to the
> > > new AR. As you can
> > > > (hopefully) see this is by far more than
> > > > preserving the 'meaning' of each bit. It mandates that
> > > changes in the bit
> > > > values at one end are reflected at the other
> > > > end, i.e., it talks about distributed data integrity in my
> > > interpretation of
> > > > the requirement text.
> > > >
> > > > Hence, the actual concern might have been (just guessing)
> > > whether or not it
> > > > is the task of the CT protocol to
> > > > preserve the abovementioned integrity. Maybe, the IESG
> > > wants to see this
> > > > functionality left to the replication logic that resides
> > > > within each AR. Or on the contrary, they do not see this
> > > important topic
> > > > covered appropriately.
> > > >
> > > > Regards,
> > > >
> > > >
> > > > Dirk
> > > >
> > > > -----Original Message-----
> > > > From: ext Gary Kenward [mailto:gkenward@nortelnetworks.com]
> > > > Sent: Thursday, July 11, 2002 3:48 PM
> > > > To: 'James Kempf'; seamoby@ietf.org
> > > > Subject: RE: [Seamoby] CT Requirements Comments from IESG
> > > >
> > > >
> > > >
> > > > You call it fidelity, I call it data integrity.
> > > > I've seen "data integrity" used in publications
> > > > (no, I cannot quote references).
> > > >
> > > > What we need is a term that everyone, including the
> > > > IESG, can agree upon.
> > > >
> > > > > -----Original Message-----
> > > > > From: James Kempf [ mailto:kempf@docomolabs-usa.com
> > > > <mailto:kempf@docomolabs-usa.com> ]
> > > > > Sent: July 11, 2002 12:22
> > > > > To: Kenward, Gary [WDLN2:AN10:EXCH]; seamoby@ietf.org
> > > > > Subject: Re: [Seamoby] CT Requirements Comments from IESG
> > > > >
> > > > >
> > > > > > Perhaps the actual answer is to state exactly what
> was intended
> > > > > > originally: that the bit order and bit values have to
> > > arrive exactly
> > > > > > as they were transmitted.
> > > > > >
> > > > >
> > > > > So this requirement is talking about transmission fidelity? I
> > > > > sure would not have guessed that from reading it. I thought it
> > > > > intended to talk about usability.
> > > > >
> > > > > I would suggest that the wording you have above is really a
> > > > > lot more precise that what is currently in the spec.
> > > > >
> > > > > Any other comments? Could we substitute Gary's wording above
> > > > > for "meaning" in the current requirement.
> > > > >
> > > > >             jak
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
>

------_=_NextPart_001_01C229DB.09DC8EC2-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Fri Jul 12 15:55:20 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12010 for ; Fri, 12 Jul 2002 15:55:20 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA16000 for seamoby-archive@odin.ietf.org; Fri, 12 Jul 2002 15:56:14 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA15522; Fri, 12 Jul 2002 15:40:07 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA15455 for ; Fri, 12 Jul 2002 15:40:04 -0400 (EDT) Received: from zcars04f.ca.nortel.com (zcars04f.nortelnetworks.com [47.129.242.57]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11330 for ; Fri, 12 Jul 2002 15:39:09 -0400 (EDT) Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04f.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g6CJZRl24542; Fri, 12 Jul 2002 15:35:28 -0400 (EDT) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 12 Jul 2002 15:35:27 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA4C19@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'Charles E. Perkins'" Cc: seamoby@ietf.org Subject: RE: [Seamoby] CT Requirements Comments from IESG Date: Fri, 12 Jul 2002 15:35:26 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C229DB.09DC8EC2" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C229DB.09DC8EC2 Content-Type: text/plain; charset="iso-8859-1" I agree Charlie. However, we have to fix the issue with the requirements. Are you suggesting that we relax the requirement? By how much - clearly, some updates are required (e.g. CT really should try and update when flows come and go). Gary > -----Original Message----- > From: Charles E. Perkins [mailto:charliep@iprg.nokia.com] > Sent: July 12, 2002 12:15 > To: Kenward, Gary [WDLN2:AN10:EXCH] > Cc: seamoby@ietf.org > Subject: Re: [Seamoby] CT Requirements Comments from IESG > > > > > Hello folks, > > I think we ought to try to get context transfers > working correctly without initially worrying about > this synchronization problem. > > In the instances I am familiar with, it is not > required. The most stringent case seems to be > ROHC, and even for that it is not necessary. > > We can solve the most urgent problems without having > to deal with any additional context synchronization. > When the old AR sends it, and the new AR gets it, > we should consider the transfer done. In those > cases where reliability is at issue, the old AR > can retransmit when ACK is not received. In many > cases, retransmission of context even once won't > be useful. > > Regards, > Charlie P. > > > > > Gary Kenward wrote: > > > > James: > > > > Yes, we need to fix it, and I think it is doable. > > Thanks to Dirk for highlighting the real problem here > > (I think historically, the integrity requirement came out > > of the reliability section, and somehow, got lumped with > > synchronization and updates). > > > > I think the requirements need a bit of rewording, and > > the paragraph should fall out from this. I do believe > > however, that making the synchronization of context between > > old and new AR a MUST requirement would be too extreme, and > > result in a brittle solution. CT should certainly do it's best to > > provide synchronization, but as was discussed in a recent > > exchange, it would be impossible to guarantee synchronization > > at any instant. > > > > Any ideas/comments from the wg? > > > > Gary > > > > > -----Original Message----- > > > From: James Kempf [mailto:kempf@docomolabs-usa.com] > > > Sent: July 11, 2002 18:32 > > > To: Kenward, Gary [WDLN2:AN10:EXCH]; Dirk.Trossen@nokia.com; > > > seamoby@ietf.org > > > Subject: Re: [Seamoby] CT Requirements Comments from IESG > > > > > > > > > Gary/Dirk, > > > > > > I think you may be on to something here. I think this might > > > be what the IESG was talking about it the first point, namely the > > > lack of discussion of dynamic changes in the context. > > > > > > Is there some way we could cook this idea down into a > > > paragraph that we could insert for this requirement? > > > > > > jak > > > > > > ----- Original Message ----- > > > From: "Gary Kenward" > > > To: ; ; > > > > > > Sent: Thursday, July 11, 2002 1:56 PM > > > Subject: RE: [Seamoby] CT Requirements Comments from IESG > > > > > > > > > > Dirk: > > > > > > > > A valid point. There is a certain atomic level of > > > granularity which has to > > > > be > > > > dealt with - that is, there's no protocol in the world that > > > can synchronize > > > > changes in > > > > information that occur at the source while the information > > > is "in-flight" or > > > > being > > > > received at the destination. If changes in context while > > > the context is > > > > being transferred > > > > make a different to the successful performance of CT, then > > > there is no hope. > > > > > > > > The problem is most significant for state context > > > transfer. E.g. counters > > > > will continue > > > > to count while CT is moving the context to the destination. > > > Either these > > > > changes have no > > > > significant impact upon the forwarding service provided at > > > the new AR (e.g. > > > > it may not > > > > matter that a policing meter misses a few packet counts), > > > or a different > > > > mechanism > > > > has to be defined for re-establishing the state context. > > > > > > > > The handover is real and unavoidable. Mitigating the > > > disruption to the > > > > service at the new > > > > AR is the challenge. It would be nice if the disruption > was nil, but > > > > unlikely. > > > > > > > > Gary > > > > > > > > -----Original Message----- > > > > From: Dirk.Trossen@nokia.com [mailto:Dirk.Trossen@nokia.com] > > > > Sent: July 11, 2002 16:30 > > > > To: Kenward, Gary [WDLN2:AN10:EXCH]; kempf@docomolabs-usa.com; > > > > seamoby@ietf.org > > > > Subject: RE: [Seamoby] CT Requirements Comments from IESG > > > > > > > > > > > > Hi all, > > > > > > > > jumping in as somebody who has been an observer so far, > > > struggling with the > > > > current discussion on > > > > 'integrity'. > > > > > > > > When I look at the current wording, i.e., > > > > "5.5.2 A context update MUST preserve the integrity, and > > > thus the meaning, > > > > of the context > > > > at each receiving AR. The context at the AR actually > > > supporting an MN's > > > > traffic will change with time. > > > > For example, the MN may initiate new microflow(s), or > > > discontinue existing > > > > microflows. Any change of context > > > > at the supporting AR must be replicated at those ARs that > > > have already > > > > received context for that MN.", > > > > > > > > and compare this to the plain integrity of the actually > > > transmitted data > > > > (i.e., its bits and therefore its semantics) > > > > that has been brought to the table as a replacement now, > > > I'm quite confident > > > > that this is not what the requirement > > > > is talking about. > > > > > > > > If we remove the word 'meaning' (which is very vague > and free for > > > > interpretation for me as well), it is still the word > > > > 'integrity' left, which is more than plain integrity of the > > > transmitted > > > > data, in particular if we look at the following sentences > > > > in the requirement, which state what kind of integrity is > > > meant (which > > > > probably also builds the bridge to the vague > > > > term 'meaning'), namely that the integrity of a context > > > must be preserved in > > > > the sense that a received context at new > > > > AR at some point t must be the same as the context at old > > > AR at the same > > > > time t. This is by far more than plain data > > > > integrity of the transmitted data. Even if your data has > > > been transmitted > > > > correctly, the context might be stale (and therefore > > > > its integrity is lost) because it had changed at old AR in > > > the meanwhile. > > > > The action to be taken is also given in the text, > > > > namely the change of context has to be replicated to the > > > new AR. As you can > > > > (hopefully) see this is by far more than > > > > preserving the 'meaning' of each bit. It mandates that > > > changes in the bit > > > > values at one end are reflected at the other > > > > end, i.e., it talks about distributed data integrity in my > > > interpretation of > > > > the requirement text. > > > > > > > > Hence, the actual concern might have been (just guessing) > > > whether or not it > > > > is the task of the CT protocol to > > > > preserve the abovementioned integrity. Maybe, the IESG > > > wants to see this > > > > functionality left to the replication logic that resides > > > > within each AR. Or on the contrary, they do not see this > > > important topic > > > > covered appropriately. > > > > > > > > Regards, > > > > > > > > > > > > Dirk > > > > > > > > -----Original Message----- > > > > From: ext Gary Kenward [mailto:gkenward@nortelnetworks.com] > > > > Sent: Thursday, July 11, 2002 3:48 PM > > > > To: 'James Kempf'; seamoby@ietf.org > > > > Subject: RE: [Seamoby] CT Requirements Comments from IESG > > > > > > > > > > > > > > > > You call it fidelity, I call it data integrity. > > > > I've seen "data integrity" used in publications > > > > (no, I cannot quote references). > > > > > > > > What we need is a term that everyone, including the > > > > IESG, can agree upon. > > > > > > > > > -----Original Message----- > > > > > From: James Kempf [ mailto:kempf@docomolabs-usa.com > > > > ] > > > > > Sent: July 11, 2002 12:22 > > > > > To: Kenward, Gary [WDLN2:AN10:EXCH]; seamoby@ietf.org > > > > > Subject: Re: [Seamoby] CT Requirements Comments from IESG > > > > > > > > > > > > > > > > Perhaps the actual answer is to state exactly what > was intended > > > > > > originally: that the bit order and bit values have to > > > arrive exactly > > > > > > as they were transmitted. > > > > > > > > > > > > > > > > So this requirement is talking about transmission fidelity? I > > > > > sure would not have guessed that from reading it. I thought it > > > > > intended to talk about usability. > > > > > > > > > > I would suggest that the wording you have above is really a > > > > > lot more precise that what is currently in the spec. > > > > > > > > > > Any other comments? Could we substitute Gary's wording above > > > > > for "meaning" in the current requirement. > > > > > > > > > > jak > > > > > > > > > > > > > > > > > > > > > > > > > ------_=_NextPart_001_01C229DB.09DC8EC2 Content-Type: text/html; charset="iso-8859-1" RE: [Seamoby] CT Requirements Comments from IESG

I agree Charlie. However, we have to fix the issue with
the requirements. Are you suggesting that we relax the
requirement? By how much - clearly, some updates are required
(e.g. CT really should try and update when flows come and go).

Gary

> -----Original Message-----
> From: Charles E. Perkins [mailto:charliep@iprg.nokia.com]
> Sent: July 12, 2002 12:15
> To: Kenward, Gary [WDLN2:AN10:EXCH]
> Cc: seamoby@ietf.org
> Subject: Re: [Seamoby] CT Requirements Comments from IESG
>
>
>
>
> Hello folks,
>
> I think we ought to try to get context transfers
> working correctly without initially worrying about
> this synchronization problem.
>
> In the instances I am familiar with, it is not
> required.  The most stringent case seems to be
> ROHC, and even for that it is not necessary.
>
> We can solve the most urgent problems without having
> to deal with any additional context synchronization.
> When the old AR sends it, and the new AR gets it,
> we should consider the transfer done.  In those
> cases where reliability is at issue, the old AR
> can retransmit when ACK is not received.  In many
> cases, retransmission of context even once won't
> be useful.
>
> Regards,
> Charlie P.
>
>
>
> > Gary Kenward wrote:
> >
> > James:
> >
> >   Yes, we need to fix it, and I think it is doable.
> > Thanks to Dirk for highlighting the real problem here
> > (I think historically, the integrity requirement came out
> > of the reliability section, and somehow, got lumped with
> > synchronization and updates).
> >
> >   I think the requirements need a bit of rewording, and
> > the paragraph should fall out from this. I do believe
> > however, that making the synchronization of context between
> > old and new AR a MUST requirement would be too extreme, and
> > result in a brittle solution. CT should certainly do it's best to
> > provide synchronization, but as was discussed in a recent
> > exchange, it would be impossible to guarantee synchronization
> > at any instant.
> >
> >   Any ideas/comments from the wg?
> >
> > Gary
> >
> > > -----Original Message-----
> > > From: James Kempf [mailto:kempf@docomolabs-usa.com]
> > > Sent: July 11, 2002 18:32
> > > To: Kenward, Gary [WDLN2:AN10:EXCH]; Dirk.Trossen@nokia.com;
> > > seamoby@ietf.org
> > > Subject: Re: [Seamoby] CT Requirements Comments from IESG
> > >
> > >
> > > Gary/Dirk,
> > >
> > > I think you may be on to something here. I think this might
> > > be what the IESG was talking about it the first point, namely the
> > > lack of discussion of dynamic changes in the context.
> > >
> > > Is there some way we could cook this idea down into a
> > > paragraph that we could insert for this requirement?
> > >
> > >             jak
> > >
> > > ----- Original Message -----
> > > From: "Gary Kenward" <gkenward@nortelnetworks.com>
> > > To: <Dirk.Trossen@nokia.com>; <kempf@docomolabs-usa.com>;
> > > <seamoby@ietf.org>
> > > Sent: Thursday, July 11, 2002 1:56 PM
> > > Subject: RE: [Seamoby] CT Requirements Comments from IESG
> > >
> > >
> > > > Dirk:
> > > >
> > > >   A valid point. There is a certain atomic level of
> > > granularity which has to
> > > > be
> > > > dealt with - that is, there's no protocol in the world that
> > > can synchronize
> > > > changes in
> > > > information that occur at the source while the information
> > > is "in-flight" or
> > > > being
> > > > received at the destination. If changes in context while
> > > the context is
> > > > being transferred
> > > > make a different to the successful performance of CT, then
> > > there is no hope.
> > > >
> > > >   The problem is most significant for state context
> > > transfer. E.g. counters
> > > > will continue
> > > > to count while CT is moving the context to the destination.
> > > Either these
> > > > changes have no
> > > > significant impact upon the forwarding service provided at
> > > the new AR (e.g.
> > > > it may not
> > > > matter that a policing meter misses a few packet counts),
> > > or a different
> > > > mechanism
> > > > has to be defined for re-establishing the state context.
> > > >
> > > >   The handover is real and unavoidable. Mitigating the
> > > disruption to the
> > > > service at the new
> > > > AR is the challenge. It would be nice if the disruption
> was nil, but
> > > > unlikely.
> > > >
> > > > Gary
> > > >
> > > > -----Original Message-----
> > > > From: Dirk.Trossen@nokia.com [mailto:Dirk.Trossen@nokia.com]
> > > > Sent: July 11, 2002 16:30
> > > > To: Kenward, Gary [WDLN2:AN10:EXCH]; kempf@docomolabs-usa.com;
> > > > seamoby@ietf.org
> > > > Subject: RE: [Seamoby] CT Requirements Comments from IESG
> > > >
> > > >
> > > > Hi all,
> > > >
> > > > jumping in as somebody who has been an observer so far,
> > > struggling with the
> > > > current discussion on
> > > > 'integrity'.
> > > >
> > > > When I look at the current wording, i.e.,
> > > > "5.5.2 A context update MUST preserve the integrity, and
> > > thus the meaning,
> > > > of the context
> > > > at each receiving AR. The context at the AR actually
> > > supporting an MN's
> > > > traffic will change with time.
> > > > For example, the MN may initiate new microflow(s), or
> > > discontinue existing
> > > > microflows. Any change of context
> > > > at the supporting AR must be replicated at those ARs that
> > > have already
> > > > received context for that MN.",
> > > >
> > > > and compare this to the plain integrity of the actually
> > > transmitted data
> > > > (i.e., its bits and therefore its semantics)
> > > > that has been brought to the table as a replacement now,
> > > I'm quite confident
> > > > that this is not what the requirement
> > > > is talking about.
> > > >
> > > > If we remove the word 'meaning' (which is very vague
> and free for
> > > > interpretation for me as well), it is still the word
> > > > 'integrity' left, which is more than plain integrity of the
> > > transmitted
> > > > data, in particular if we look at the following sentences
> > > > in the requirement, which state what kind of integrity is
> > > meant (which
> > > > probably also builds the bridge to the vague
> > > > term 'meaning'), namely that the integrity of a context
> > > must be preserved in
> > > > the sense that a received context at new
> > > > AR at some point t must be the same as the context at old
> > > AR at the same
> > > > time t. This is by far more than plain data
> > > > integrity of the transmitted data. Even if your data has
> > > been transmitted
> > > > correctly, the context might be stale (and therefore
> > > > its integrity is lost) because it had changed at old AR in
> > > the meanwhile.
> > > > The action to be taken is also given in the text,
> > > > namely the change of context has to be replicated to the
> > > new AR. As you can
> > > > (hopefully) see this is by far more than
> > > > preserving the 'meaning' of each bit. It mandates that
> > > changes in the bit
> > > > values at one end are reflected at the other
> > > > end, i.e., it talks about distributed data integrity in my
> > > interpretation of
> > > > the requirement text.
> > > >
> > > > Hence, the actual concern might have been (just guessing)
> > > whether or not it
> > > > is the task of the CT protocol to
> > > > preserve the abovementioned integrity. Maybe, the IESG
> > > wants to see this
> > > > functionality left to the replication logic that resides
> > > > within each AR. Or on the contrary, they do not see this
> > > important topic
> > > > covered appropriately.
> > > >
> > > > Regards,
> > > >
> > > >
> > > > Dirk
> > > >
> > > > -----Original Message-----
> > > > From: ext Gary Kenward [mailto:gkenward@nortelnetworks.com]
> > > > Sent: Thursday, July 11, 2002 3:48 PM
> > > > To: 'James Kempf'; seamoby@ietf.org
> > > > Subject: RE: [Seamoby] CT Requirements Comments from IESG
> > > >
> > > >
> > > >
> > > > You call it fidelity, I call it data integrity.
> > > > I've seen "data integrity" used in publications
> > > > (no, I cannot quote references).
> > > >
> > > > What we need is a term that everyone, including the
> > > > IESG, can agree upon.
> > > >
> > > > > -----Original Message-----
> > > > > From: James Kempf [ mailto:kempf@docomolabs-usa.com
> > > > <mailto:kempf@docomolabs-usa.com> ]
> > > > > Sent: July 11, 2002 12:22
> > > > > To: Kenward, Gary [WDLN2:AN10:EXCH]; seamoby@ietf.org
> > > > > Subject: Re: [Seamoby] CT Requirements Comments from IESG
> > > > >
> > > > >
> > > > > > Perhaps the actual answer is to state exactly what
> was intended
> > > > > > originally: that the bit order and bit values have to
> > > arrive exactly
> > > > > > as they were transmitted.
> > > > > >
> > > > >
> > > > > So this requirement is talking about transmission fidelity? I
> > > > > sure would not have guessed that from reading it. I thought it
> > > > > intended to talk about usability.
> > > > >
> > > > > I would suggest that the wording you have above is really a
> > > > > lot more precise that what is currently in the spec.
> > > > >
> > > > > Any other comments? Could we substitute Gary's wording above
> > > > > for "meaning" in the current requirement.
> > > > >
> > > > >             jak
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
>

------_=_NextPart_001_01C229DB.09DC8EC2-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Sat Jul 13 00:09:57 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA27871 for ; Sat, 13 Jul 2002 00:09:57 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA06864; Sat, 13 Jul 2002 00:08:07 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA06835 for ; Sat, 13 Jul 2002 00:08:06 -0400 (EDT) Received: from odin.ietf.org ([64.86.155.165]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA27772 for ; Sat, 13 Jul 2002 00:07:08 -0400 (EDT) Message-Id: <200207130407.AAA27772@ietf.org> From: "Dr, Ibrahim Atiku" Date: Fri, 04 Jan 1980 02:55:49 To: seamoby@ietf.org MIME-Version: 1.0 Content-Type: text/plain;charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Seamoby] Investment Business Deal Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit FROM: Dr. Ibrahim Atiku CHIEF FINANCIAL DIRECTOR INDEPENDENT NATIONAL ELECTORAL COMMISSION (INEC) LAGOS – NIGERIA DATE: 9TH May 2002 ATTENTION THE MANAGING DIRECTOR/PRESIDENT. Sir, It is my warmest pleasure writing you this confidential business offer irrespective of the fact that we have not met before or done any thing that will re-impose absolute confidence but nevertheless, an adage says a day begins a story and it is in line of this strong perspective that I am very determined to communicate you with much conviction that you will give my proposal a second thought and consideration. As earlier stated I am Dr. Ibrahim Atiku a financial director working with Inec. My Agency is in charge of conducting all elections in my country Nigeria and by the virtue of my unique position in office as the Chief financial director. I was elevated by the commission to become the chairman of foreign contract tender board committee whose responsibility is to award and supervise foreign contract to ensure it is executed promptly. Consequently, I the chairman of the tender board committee in collaboration with two other top committee members over-invoice certain contract for the supply of electoral equipments needed for the forth-coming elections approaching around August 2002. The initial cost of the contract was pegged at US $ 50 million, but after the feasibility study was done, while submitting my report to the office of the presidency for final approval, we deliberately inflated the cost to an excess amount of US$ 30 million making the cost to be US$ 80 million. Right now, the gist of contacting you is we are constrained to claim the fund due to certain laws enacted by the government guiding civil service code of conduct Bureau which prohibits top civil servants working under Government establishment from operating offshore or foreign Account and this situation has kept us in a fix to openly come forward to claim the outstanding balance of US$ 30 million, hence after series of private meetings we decided to make contact in order to get a reliable foreign partner whom we will forward his or her credentials to claim the fund based on mutual trust and agreement. In a nutshell, we need your assistance and support to claim this fund so that at the later time convenient for us, we will come over to your country after the funds have been transferred to meet you and collect our own percentage while you will keep the rest as yours. For your support and total dedication to realize the objectives of this operation, you shall be entitled to 20% of the sum total while 80% of the fund belongs to the three officials involved in the deal. Note, you are vividly assured that you will not be subjected to any kind of risk for your support and involvement in this venture hence we have piloted a good strategy to ensure the operations goes smoothly of which we have targeted two weeks duration to accomplished our Aim. Kindly treat this matter Absolutely confidential because the officials involved are still in service and some of us intend to resign our appointment immediately after the transaction is finalized. I look forward to hearing positively from you while further details will be given as soon as I get your response. Best Regards Dr. Ibrahim Atiku _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Sat Jul 13 00:09:58 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA27879 for ; Sat, 13 Jul 2002 00:09:58 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id AAA07160 for seamoby-archive@odin.ietf.org; Sat, 13 Jul 2002 00:10:53 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA06864; Sat, 13 Jul 2002 00:08:07 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA06835 for ; Sat, 13 Jul 2002 00:08:06 -0400 (EDT) Received: from odin.ietf.org ([64.86.155.165]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA27772 for ; Sat, 13 Jul 2002 00:07:08 -0400 (EDT) Message-Id: <200207130407.AAA27772@ietf.org> From: "Dr, Ibrahim Atiku" Date: Fri, 04 Jan 1980 02:55:49 To: seamoby@ietf.org MIME-Version: 1.0 Content-Type: text/plain;charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Seamoby] Investment Business Deal Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit FROM: Dr. Ibrahim Atiku CHIEF FINANCIAL DIRECTOR INDEPENDENT NATIONAL ELECTORAL COMMISSION (INEC) LAGOS – NIGERIA DATE: 9TH May 2002 ATTENTION THE MANAGING DIRECTOR/PRESIDENT. Sir, It is my warmest pleasure writing you this confidential business offer irrespective of the fact that we have not met before or done any thing that will re-impose absolute confidence but nevertheless, an adage says a day begins a story and it is in line of this strong perspective that I am very determined to communicate you with much conviction that you will give my proposal a second thought and consideration. As earlier stated I am Dr. Ibrahim Atiku a financial director working with Inec. My Agency is in charge of conducting all elections in my country Nigeria and by the virtue of my unique position in office as the Chief financial director. I was elevated by the commission to become the chairman of foreign contract tender board committee whose responsibility is to award and supervise foreign contract to ensure it is executed promptly. Consequently, I the chairman of the tender board committee in collaboration with two other top committee members over-invoice certain contract for the supply of electoral equipments needed for the forth-coming elections approaching around August 2002. The initial cost of the contract was pegged at US $ 50 million, but after the feasibility study was done, while submitting my report to the office of the presidency for final approval, we deliberately inflated the cost to an excess amount of US$ 30 million making the cost to be US$ 80 million. Right now, the gist of contacting you is we are constrained to claim the fund due to certain laws enacted by the government guiding civil service code of conduct Bureau which prohibits top civil servants working under Government establishment from operating offshore or foreign Account and this situation has kept us in a fix to openly come forward to claim the outstanding balance of US$ 30 million, hence after series of private meetings we decided to make contact in order to get a reliable foreign partner whom we will forward his or her credentials to claim the fund based on mutual trust and agreement. In a nutshell, we need your assistance and support to claim this fund so that at the later time convenient for us, we will come over to your country after the funds have been transferred to meet you and collect our own percentage while you will keep the rest as yours. For your support and total dedication to realize the objectives of this operation, you shall be entitled to 20% of the sum total while 80% of the fund belongs to the three officials involved in the deal. Note, you are vividly assured that you will not be subjected to any kind of risk for your support and involvement in this venture hence we have piloted a good strategy to ensure the operations goes smoothly of which we have targeted two weeks duration to accomplished our Aim. Kindly treat this matter Absolutely confidential because the officials involved are still in service and some of us intend to resign our appointment immediately after the transaction is finalized. I look forward to hearing positively from you while further details will be given as soon as I get your response. Best Regards Dr. Ibrahim Atiku _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Sat Jul 13 08:10:10 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21727 for ; Sat, 13 Jul 2002 08:10:09 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA15758; Sat, 13 Jul 2002 08:05:31 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA15704 for ; Sat, 13 Jul 2002 08:05:26 -0400 (EDT) Received: from fridge.docomolabs-usa.com (fwuser@key1.docomolabs-usa.com [216.98.102.225]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21639; Sat, 13 Jul 2002 08:04:28 -0400 (EDT) Message-ID: <001301c22a65$54f6a930$056015ac@T23KEMPF> From: "James Kempf" To: Cc: , References: <0C1353ABB1DEB74DB067ADFF749C4EEFC65720@esebe004.NOE.Nokia.com> Subject: Re: [Seamoby] RE: [NSIS] Re: draft-westphal-nsis-qos-mobileip-00. txt Date: Fri, 12 Jul 2002 11:04:30 -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-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit That is more or less what I had in mind. The base CT protocol is independent of the particular applications in any event. jak ----- Original Message ----- From: To: Cc: ; Sent: Friday, July 12, 2002 3:40 AM Subject: RE: [Seamoby] RE: [NSIS] Re: draft-westphal-nsis-qos-mobileip-00. txt > Hi James, > > > > The one step we could take (but not the one that was > > suggested) would > > > be to investigate into ensuring some commonality between > > the formats for > > > encapsulating the respective data chunks (i.e. context/NSIS > > parameters). > > > Or at least, provide for NSIS to carry CT data chunks and > > visa versa. > > > > > > > Right, that is in fact the kind of thing I had in mind. If > > you don't want to call it QoS context, call it "NSIS context". > > Just as an FYI, some folks are interest in looking into using > NSIS for various things, like QoS, NAT, & firewall traversal, > and so forth. For these cases, what parameters NSIS signals > are very much service/application specific. This is also > true with regards to Context Transfer. > > What I suggest is that NSIS and CT progress, and since there > is some overlap in the interest of both groups, we can > try to ensure that whatever solutions we work on do not > cause trouble for the different working groups. However, > I don't support tightly coupling the solutions. A much > better way would be that after CT & NSIS work is well > along, someone could make an applicability document of > combining both NSIS & CT into a solution for > particular deployments. > > br, > John > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Sat Jul 13 08:10:11 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21740 for ; Sat, 13 Jul 2002 08:10:11 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA15828 for seamoby-archive@odin.ietf.org; Sat, 13 Jul 2002 08:11:07 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA15758; Sat, 13 Jul 2002 08:05:31 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA15704 for ; Sat, 13 Jul 2002 08:05:26 -0400 (EDT) Received: from fridge.docomolabs-usa.com (fwuser@key1.docomolabs-usa.com [216.98.102.225]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21639; Sat, 13 Jul 2002 08:04:28 -0400 (EDT) Message-ID: <001301c22a65$54f6a930$056015ac@T23KEMPF> From: "James Kempf" To: Cc: , References: <0C1353ABB1DEB74DB067ADFF749C4EEFC65720@esebe004.NOE.Nokia.com> Subject: Re: [Seamoby] RE: [NSIS] Re: draft-westphal-nsis-qos-mobileip-00. txt Date: Fri, 12 Jul 2002 11:04:30 -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-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit That is more or less what I had in mind. The base CT protocol is independent of the particular applications in any event. jak ----- Original Message ----- From: To: Cc: ; Sent: Friday, July 12, 2002 3:40 AM Subject: RE: [Seamoby] RE: [NSIS] Re: draft-westphal-nsis-qos-mobileip-00. txt > Hi James, > > > > The one step we could take (but not the one that was > > suggested) would > > > be to investigate into ensuring some commonality between > > the formats for > > > encapsulating the respective data chunks (i.e. context/NSIS > > parameters). > > > Or at least, provide for NSIS to carry CT data chunks and > > visa versa. > > > > > > > Right, that is in fact the kind of thing I had in mind. If > > you don't want to call it QoS context, call it "NSIS context". > > Just as an FYI, some folks are interest in looking into using > NSIS for various things, like QoS, NAT, & firewall traversal, > and so forth. For these cases, what parameters NSIS signals > are very much service/application specific. This is also > true with regards to Context Transfer. > > What I suggest is that NSIS and CT progress, and since there > is some overlap in the interest of both groups, we can > try to ensure that whatever solutions we work on do not > cause trouble for the different working groups. However, > I don't support tightly coupling the solutions. A much > better way would be that after CT & NSIS work is well > along, someone could make an applicability document of > combining both NSIS & CT into a solution for > particular deployments. > > br, > John > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Sat Jul 13 15:01:56 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00478 for ; Sat, 13 Jul 2002 15:01:55 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA01007; Sat, 13 Jul 2002 15:00:40 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA00968 for ; Sat, 13 Jul 2002 15:00:37 -0400 (EDT) Received: from fridge.docomolabs-usa.com (fwuser@key1.docomolabs-usa.com [216.98.102.225]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00403 for ; Sat, 13 Jul 2002 14:59:39 -0400 (EDT) Message-ID: <000c01c22a9f$5780a310$956015ac@T23KEMPF> From: "James Kempf" To: Date: Sat, 13 Jul 2002 11:58:54 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Seamoby] Proposal on Sync/NoSync Requirement Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit So based on the list discussion so far, I'd like to put out the following proposal for a requirement on synchronization or its lack: 5.5.1 The CT solution SHOULD NOT provide direct support for synchronization of context. However, the CT solution SHOULD allow particular feature contexts that require synchronization to provide that support. Most feature contexts will not require synchronization, however there are a few that may. Header compression, for example, may require that the header compressor on the old access router cease and the compressor on the new router start in synchrony with hand over of routing to the new router; otherwise, the compressor on the new router will not be properly synchronized. Since most contexts don't need synchronization support, the CT solution need not support it, but it should not provide a hinderance to those feature contexts that do. Comments? jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Sat Jul 13 15:01:56 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00487 for ; Sat, 13 Jul 2002 15:01:56 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA01333 for seamoby-archive@odin.ietf.org; Sat, 13 Jul 2002 15:02:52 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA01007; Sat, 13 Jul 2002 15:00:40 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA00968 for ; Sat, 13 Jul 2002 15:00:37 -0400 (EDT) Received: from fridge.docomolabs-usa.com (fwuser@key1.docomolabs-usa.com [216.98.102.225]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00403 for ; Sat, 13 Jul 2002 14:59:39 -0400 (EDT) Message-ID: <000c01c22a9f$5780a310$956015ac@T23KEMPF> From: "James Kempf" To: Date: Sat, 13 Jul 2002 11:58:54 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Seamoby] Proposal on Sync/NoSync Requirement Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit So based on the list discussion so far, I'd like to put out the following proposal for a requirement on synchronization or its lack: 5.5.1 The CT solution SHOULD NOT provide direct support for synchronization of context. However, the CT solution SHOULD allow particular feature contexts that require synchronization to provide that support. Most feature contexts will not require synchronization, however there are a few that may. Header compression, for example, may require that the header compressor on the old access router cease and the compressor on the new router start in synchrony with hand over of routing to the new router; otherwise, the compressor on the new router will not be properly synchronized. Since most contexts don't need synchronization support, the CT solution need not support it, but it should not provide a hinderance to those feature contexts that do. Comments? jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Sat Jul 13 22:31:13 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA11961 for ; Sat, 13 Jul 2002 22:31:13 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA18828; Sat, 13 Jul 2002 22:24:01 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA18663 for ; Sat, 13 Jul 2002 22:23:54 -0400 (EDT) Received: from excite.com (host159150.metrored.net.ar [200.59.159.150] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA11726; Sat, 13 Jul 2002 22:22:51 -0400 (EDT) Received: from 144.90.20.80 ([144.90.20.80]) by asy100.as122.sol-superunderline.com with NNFMP; Sat, 13 Jul 0102 20:23:24 -0200 Received: from mta85.snfc21.pibi.net ([42.202.29.184]) by q4.quickslow.com with smtp; Sat, 13 Jul 0102 18:11:24 +0800 Reply-To: "Clinic" Message-ID: <023b34c04b6b$5856a4a1$4dd53dd7@wgwcmt> From: "Clinic" To: Cc: Date: Sun, 14 Jul 0102 10:15:58 -0800 MiME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_00D0_13B35A0B.B1376E64" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal Subject: [Seamoby] Have you heard of HGH Oral Spray? Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org ------=_NextPart_000_00D0_13B35A0B.B1376E64 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: base64 TXl0aDogYWxsIEhHSCBwcm9kdWN0cyBhcmUgdGhlIHNhbWUNCg0KPGh0bWw+ DQoNCjxoZWFkPg0KDQo8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUi IGNvbnRlbnQ9InRleHQvaHRtbDsgY2hhcnNldD13aW5kb3dzLTEyNTIiPg0K DQo8bWV0YSBuYW1lPSJHRU5FUkFUT1IiIGNvbnRlbnQ9Ik1pY3Jvc29mdCBG cm9udFBhZ2UgNC4wIj4NCg0KPG1ldGEgbmFtZT0iUHJvZ0lkIiBjb250ZW50 PSJGcm9udFBhZ2UuRWRpdG9yLkRvY3VtZW50Ij4NCg0KPHRpdGxlPlRoZXJl IGFyZSB0aHJlZSBkaWZmZXJlbnQgdHlwZXMgb2YgSEdIIHByb2R1Y3RzPC90 aXRsZT4NCg0KPC9oZWFkPg0KDQo8Ym9keSBiYWNrZ3JvdW5kPSJjbG91ZHMu anBnIj4NCg0KPHA+PGZvbnQgc2l6ZT0iNCI+PGZvbnQgY29sb3I9IiM4MDAw MDAiPjxiPlRoZXJlIGFyZSB0aHJlZSBkaWZmZXJlbnQgdHlwZXMgb2YNCg0K SEdIIHByb2R1Y3RzLjwvYj48L2ZvbnQ+PGJyPg0KDQpUaGUgY29uZnVzaW9u IGlzIHRoYXQgYWxsIHRocmVlIGFyZTxicj4NCg0KYWR2ZXJ0aXNlZCBhcyBp ZiB0aGV5IHdlcmUgdGhlIHNhbWUuPC9mb250Pjxicj4NCg0KJm5ic3A7PGJy Pg0KDQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgPHU+VGhlIHRocmVlIHR5cGVzIGFyZTo8L3U+PGJyPg0KDQombmJzcDs8 YnI+DQoNCjxiPjEpPC9iPiAtLS0gPGZvbnQgY29sb3I9IiMwMDAwRkYiPjxi PkhvbWVvcGF0aGljIEhHSDwvYj48L2ZvbnQ+PGJyPg0KDQo8Yj4yKTwvYj4g LS0tIDxmb250IGNvbG9yPSIjMDAwMEZGIj48Yj5QcmUtY3Vyc29yIEhHSDwv Yj48L2ZvbnQ+PGJyPg0KDQo8Yj4zKTwvYj4gLS0tIDxmb250IGNvbG9yPSIj MDAwMEZGIj48Yj5SZWFsIG9yIHN5bnRoZXRpYyBIR0g8L2I+PC9mb250Pg0K DQooZGVsaXZlcmVkIGJ5IGluamVjdGlvbjxicj4NCg0KJm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IG9yLCBieSBhbiBvcmFs IHNwcmF5IG1ldGhvZCkuPGJyPg0KDQombmJzcDs8YnI+DQoNCkRvIHlvdSBr bm93IGRpZmZlcmVuY2VzPzxicj4NCg0KJm5ic3A7PGJyPg0KDQpDYWxsIHVz IGFuZCB3ZSdsbCBleHBsYWluIHRoZW0gdG8geW91Ljxicj4NCg0KJm5ic3A7 PGJyPg0KDQpPdXIgdG9sbCBmcmVlIG51bWJlciBpcyA8Zm9udCBjb2xvcj0i IzAwMDA4MCI+PGI+MS04ODgtNjIxLTczMDA8L2I+PC9mb250Pjxicj4NCg0K QW4gSEdIIHN0YWZmIG1lbWJlciBpcyBhdmFpbGFibGU8YnI+DQoNCjkgdG8g NSBQYWNpZmljIFRpbWUuPGJyPg0KDQpJZiBhZnRlciBob3VycywgcGxlYXNl IGxlYXZlIHlvdSBuYW1lPGJyPg0KDQphbmQgZGF5IGFuZCBldmVuaW5nIHBo b25lIG51bWJlcnMuPGJyPg0KDQpXZSB3aWxsIGNhbGwgeW91IGJhY2sgaW4g YSBubyBwcmVzc3VyZSw8YnI+DQoNCmVkdWNhdGlvbmFsIG1hbm5lci48YnI+ DQoNCklmIHlvdSBhcmUgb3ZlcnNlYXMgY2FsbCB5b3VyIGxvbmcgZGlzdGFu Y2U8YnI+DQoNCm9wZXJhdG9yIGFuZCBhc2sgdG8gYmUgY29ubmVjdGVkIHRv IG91cjxicj4NCg0KcGhvbmUgbnVtYmVyLiZuYnNwOyBXZSB3aWxsIGNhbGwg eW91IGJhY2sgc288YnI+DQoNCndlIGNhbiBwYXkgZm9yIHRoZSBsb25nIGRp c3RhbmNlIGNoYXJnZXMuPGJyPg0KDQombmJzcDs8YnI+DQoNCjxmb250IGNv bG9yPSIjRkYwMDAwIj5Gb3IgbW9yZSBpbmZvcm1hdGlvbiBvbiBIR0ggcmVh ZCBvbi4uLi4uLi4uLi4uLjwvZm9udD48YnI+DQoNCiZuYnNwOzxicj4NCg0K SEFWRSBZT1UgSEVBUkQgT0Y8YnI+DQoNCkhVTUFOIEdST1dUSCBIT1JNT05F IChIR0gpPz8/PGJyPg0KDQombmJzcDs8YnI+DQoNCiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyBSZWxlYXNlZCBieSB5b3VyIG93biBwaXR1aXRhcnkgZ2xh bmQsIEhHSCBzdGFydHMNCg0KZGVjbGluaW5nPGJyPg0KDQppbiB5b3VyIDIw cywgZXZlbiBtb3JlIGluIHlvdXIgMzBzIGFuZCA0MHMsIGV2ZW50dWFsbHkg cmVzdWx0aW5nPGJyPg0KDQppbiB0aGUgc2hyaW5rYWdlIG9mIG1ham9yIG9y Z2FucyAtLSBwbHVzLCBhbGw8YnI+DQoNCm90aGVyIHN5bXB0b21zIHJlbGF0 ZWQgdG8gb2xkIGFnZS48YnI+DQoNCiZuYnNwOzxicj4NCg0KJm5ic3A7PGJy Pg0KDQpJTiBUSE9VU0FORFMgT0YgQ0xJTklDQUwgU1RVRElFUyw8YnI+DQoN CkhHSCBIQVMgQkVFTiBTSE9XTiBUTyBBQ0NPTVBMSVNIIFRIRSBGT0xMT1dJ Tkc6PGJyPg0KDQombmJzcDs8YnI+DQoNCiogUmVkdWNlIEJvZHkgRmF0IGFu ZCBCdWlsZCBMZWFuIE11c2NsZTxicj4NCg0KJm5ic3A7Jm5ic3A7IFdJVEhP VVQgRVhFUkNJU0UhPGJyPg0KDQombmJzcDs8YnI+DQoNCiogRW5oYW5jZSBT ZXh1YWwgUGVyZm9ybWFuY2U8YnI+DQoNCiZuYnNwOzxicj4NCg0KKiBSZW1v dmUgV3JpbmtsZXMgYW5kIENlbGx1bGl0ZTxicj4NCg0KJm5ic3A7PGJyPg0K DQoqIExvd2VyIEJsb29kIFByZXNzdXJlIGFuZCBJbXByb3ZlIENob2xlc3Rl cm9sIFByb2ZpbGU8YnI+DQoNCiZuYnNwOzxicj4NCg0KKiBJbXByb3ZlIFNs ZWVwLCBWaXNpb24gYW5kIE1lbW9yeTxicj4NCg0KJm5ic3A7PGJyPg0KDQoq IFJlc3RvcmUgSGFpciBDb2xvciBhbmQgR3Jvd3RoPGJyPg0KDQombmJzcDs8 YnI+DQoNCiogU3RyZW5ndGhlbiB0aGUgSW1tdW5lIFN5c3RlbTxicj4NCg0K Jm5ic3A7PGJyPg0KDQoqIEluY3JlYXNlIEVuZXJneSBhbmQgQ2FyZGlhYyBP dXRwdXQ8YnI+DQoNCiZuYnNwOzxicj4NCg0KKiBUdXJuIGJhY2sgeW91ciBi b2R5J3MgQmlvbG9naWNhbCBUaW1lIENsb2NrIDEwIC0gMjAgeWVhcnM8YnI+ DQoNCiZuYnNwOzxicj4NCg0KKiBMaXZlIExvbmdlciBBTkQgU3Ryb25nZXI8 YnI+DQoNCiZuYnNwOzxicj4NCg0KQWxsIG5hdHVyYWwgYW5kIG9yZ2FuaWMg cGxhbnQgYmFzZWQ8YnI+DQoNCiZuYnNwOzxicj4NCg0KPGZvbnQgY29sb3I9 IiMwMDAwRkYiPjxiPkZFRUwgMTAgWUVBUlMgWU9VTkdFUiBXSVRIIE9SQUwg U1BSQVkgSEdILjxicj4NCg0KR1VBUkFOVEVFRDwvYj48L2ZvbnQ+PGJyPg0K DQombmJzcDs8YnI+DQoNCiZuYnNwOyZuYnNwOyZuYnNwOyBXZSBhcmUgdGhl IG1hbnVmYWN0dXJlciBhbmQgd2Ugc2VsbCBkaXJlY3RseSB0byBEb2N0b3Jz LDxicj4NCg0KQ2hpcm9wcmFjdG9ycywgYW5kIGNvbnN1bWVycyB3b3JsZCB3 aWRlIHRoZSBoaWdoZXN0IGdyYWRlPGJyPg0KDQombmJzcDtIR0ggT3JhbCBT cHJheSBhdmFpbGFibGUuJm5ic3A7PGJyPg0KDQombmJzcDs8YnI+DQoNCiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBXaXRoIGludGVybmV0IG1hcmtldGlu Zywgd2UgYXJlIGFibGUgdG8gc2F2ZQ0KDQphZHZlcnRpc2luZzxicj4NCg0K Y29zdCBhbmQgcGFzcyB0aG9zZSBzYXZpbmdzIGFsb25nIHRvIHlvdS48YnI+ DQoNCkJ1dCB5b3UgbXVzdCBhY3Qgbm93LiZuYnNwOzxicj4NCg0KJm5ic3A7 PGJyPg0KDQpUbyByZWNlaXZlIG1vcmUgaW5mb3JtYXRpb24gY2FsbCZuYnNw OyB1cyBub3cuPGJyPg0KDQombmJzcDs8YnI+DQoNCiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyBUT0xMIEZSRUUgPGI+PGZvbnQgY29sb3I9IiMwMDAwODAiPjEt ODg4LTYyMS03MzAwPC9mb250PjwvYj48YnI+DQoNCiZuYnNwOzxicj4NCg0K V2UgbXVzdCBzcGVhayB0byB5b3UgaW4gcGVyc29uIHRvIHF1YWxpZnkgeW91 ciB1c2FnZS48YnI+DQoNCiZuYnNwOzxicj4NCg0KJm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IEFsbCBvZiB5b3VyIHF1ZXN0aW9ucyB3aWxsIGJlIGFkZHJl c3NlZCBhbmQgYW5zd2VyZWQgaW4NCg0KYSBmcmllbmRseSw8YnI+DQoNCm5v IHByZXNzdXJlIG1hbm5lci4mbmJzcDsgT3VyIG1haW4gcHVycG9zZSBpcyB0 byBwcm92aWRlIHlvdSB3aXRoPGJyPg0KDQombmJzcDtpbmZvcm1hdGlvbiBz byB5b3UgY2FuIG1ha2UgYW4gZWR1Y2F0ZWQgZGVjaXNpb24uPGJyPg0KDQom bmJzcDs8YnI+DQoNCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBGb3IgbW9y ZSBpbmZvcm1hdGlvbiBjYWxsPGJyPg0KDQombmJzcDs8YnI+DQoNCiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyA8Yj48Zm9udCBjb2xvcj0iIzAwMDA4MCI+MS04 ODgtNjIxLTczMDA8L2ZvbnQ+PC9iPjxicj4NCg0KJm5ic3A7PGJyPg0KDQom bmJzcDtJZiB5b3UgYXJlIG9uIGxpbmUgd3JpdGUgZG93biBvdXI8YnI+DQoN CnBob25lIG51bWJlciBhbmQgY2FsbCB1cyB3aGVuIHlvdSBjYW4uPGJyPg0K DQombmJzcDs8YnI+DQoNClNvb24sIHlvdSBhbmQgeW91ciBsb3ZlZCBvbmVz IHdpbGwgYmUgdmVyeSBnbGFkIHlvdSBkaWQuPGJyPg0KDQombmJzcDs8YnI+ DQoNClJlYWQgd2hhdCBwZW9wbGUgYXJlIHNheWluZzo8YnI+DQoNCiZuYnNw Ozxicj4NCg0KJnF1b3Q7VGhlIGVmZmVjdHMgb2YgNiBtb250aHMgb2YgR0gg b248YnI+DQoNCmxlYW4gYm9keSBtYXNzIGFuZCBmYXQgd2VyZSBlcXVpdmFs ZW50PGJyPg0KDQppbiBtYWduaXR1ZGUgdG8gdGhlIGNoYW5nZXMgaW5jdXJy ZWQ8YnI+DQoNCmR1cmluZyAxMC0yMCB5ZWFycyBvZiBhZ2luZy4mcXVvdDs8 YnI+DQoNCkRyLiBEYW5pZWwgUnVkbWFuLCBNRCw8YnI+DQoNCk5ldyBFbmds YW5kIEpvdXJuYWwgb2YgTWVkaWNpbmUuPGJyPg0KDQombmJzcDs8YnI+DQoN CiZxdW90O1dpdGhpbiBmb3VyIG1vbnRocywgbXkgYm9keSBmYXQgZGVjcmVh c2VkPGJyPg0KDQombmJzcDtmb3JtIDMwJSBkb3duIHRvIDIxJSEgSSBub3Rp Y2VkIG15IHNraW48YnI+DQoNCiZuYnNwO2lzIG1vcmUgc3VwcGxlIGFuZCBt eSBvdmVyYWxsIG1lbnRhbDxicj4NCg0KJm5ic3A7b3V0bG9vayBpbXByb3Zl ZCBzaWduaWZpY2FudGx5LiZxdW90Ozxicj4NCg0KJm5ic3A7RC5XLiwgTmV3 IEplcnNleTxicj4NCg0KJm5ic3A7PGJyPg0KDQomcXVvdDtXZSBoYXZlIGJl ZW4gb24gdGhlIHNwcmF5IGZvciBqdXN0IDMgd2Vla3M8YnI+DQoNCm5vdywg YW5kIGJlc2lkZXMgdGhlIHRyZW1lbmRvdXMgZW5lcmd5IHdlPGJyPg0KDQpi b3RoIGZlZWwsIG15IGh1c2JhbmRzIGFsbGVyZ2llcyBhbmQgc3BlbGxzPGJy Pg0KDQpvZiBkZXByZXNzaW9uIGhhdmUgbGlmdGVkLiBJIGFtIGhlYWxpbmc8 YnI+DQoNCmV4dHJlbWVseSBmYXN0IGFmdGVyIGFuIGFjY2lkZW50IGFuZCBo YXZlPGJyPg0KDQpsb3N0IDcgbGJzLiB3aXRob3V0IHRyeWluZyEmcXVvdDs8 YnI+DQoNCkMuQi4sIEZsYWdzdGFmZi4gQVo8YnI+DQoNCiZuYnNwOzxicj4N Cg0KVGhhbmtzIGZvciByZWFkaW5nIG91ciBsZXR0ZXIsPGJyPg0KDQpUaGUg SEdIIFN0YWZmPGJyPg0KDQpVU0EgRGl2aXNpb248YnI+DQoNCiZuYnNwOzxi cj4NCg0KUFM6Jm5ic3A7IFRoZSBIR0ggU3RhZmYgZ3VhcmFudGVlcyB0aGU8 YnI+DQoNCmhpZ2hlc3QgcXVhbGl0eSBhbmQgbG93ZXN0IHByaWNlLjxicj4N Cg0KJm5ic3A7PGJyPg0KDQombmJzcDtXZSBtYW51ZmFjdHVyZSBhbmQgc2hp cCBkaXJlY3RseSB0byB5b3VyIGRvb3IuPGJyPg0KDQombmJzcDs8YnI+DQoN CkNhbGwgdXMgbm93IDxiPjxmb250IGNvbG9yPSIjMDAwMDgwIj4xLTg4OC02 MjEtNzMwMDwvZm9udD48L2I+PGJyPg0KDQombmJzcDs8YnI+DQoNCj09PT09 PT0mbmJzcDsmbmJzcDsgRW5kIG9mIG1lc3NhZ2UgPT09PT09PT0mbmJzcDs8 YnI+DQoNCiZuYnNwOzxicj4NCg0KJm5ic3A7Jm5ic3A7IFRoZSBmb2xsb3dp bmcgc3RhdGVtZW50IGlzIHByb3ZpZGVkIHRvIGJlPGJyPg0KDQppbiBjb21w bGlhbmNlIHdpdGggY29tbWVyY2lhbCBlbWFpbCBsYXdzLjxicj4NCg0KJm5i c3A7PGJyPg0KDQombmJzcDsmbmJzcDsgSWYgeW91IGRvIG5vdCB3aXNoIHRv IHJlY2VpdmUgZnVydGhlcjxicj4NCg0KbWFpbGluZ3MsIHBsZWFzZSBjbGlj ayByZXBseSB0bzogIHRoZV9oZ2hfY2xpbmljQGJ0YW1haWwubmV0LmNuICBh bmQgdHlwZSByZW1vdmUgaW4gdGhlIHN1YmplY3QgYm94Ljxicj4NCg0KVGhl biBjbGljayBzZW5kLjxicj4NCg0KJm5ic3A7PGJyPg0KDQombmJzcDsmbmJz cDsgVGhpcyBtZXNzYWdlIGlzIGluIGZ1bGwgY29tcGxpYW5jZSB3aXRoPGJy Pg0KDQpVLlMuIEZlZGVyYWwgcmVxdWlyZW1lbnRzIGZvciBjb21tZXJjaWFs PGJyPg0KDQplbWFpbCB1bmRlciBiaWxsIFMuMTYxOCBUaXRsZSBsbGwsIFNl Y3Rpb24gMzAxLDxicj4NCg0KUGFyYWdyYXBoIChhKSgyKShDKSBwYXNzZWQg YnkgdGhlIDEwNXRoIFUuUy48YnI+DQoNCkNvbmdyZXNzIGFuZCBpcyBub3Qg Y29uc2lkZXJlZCBTUEFNPGJyPg0KDQpzaW5jZSBpdCBpbmNsdWRlcyBhIHJl bW92ZSBtZWNoYW5pc20uKjxicj4NCg0KVGhpcyBtZXNzYWdlIGlzIG5vdCBp bnRlbmRlZCBmb3IgcmVzaWRlbnRzIGluIHRoZTxicj4NCg0Kc3RhdGVzIG9m IENBLCBOQywgTlYsIFJJLCBUTiwgVkEgJmFtcDsgV0EuPGJyPg0KDQpTY3Jl ZW5pbmcgb2YgYWRkcmVzc2VzIGhhcyBiZWVuIGRvbmUgdG8gdGhlIGJlc3Q8 YnI+DQoNCm9mIG91ciB0ZWNobmljYWwgYWJpbGl0eS48YnI+DQoNCiZuYnNw Ozxicj4NCg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IENhbGwgdXMN Cg0Kbm93IDxiPjxmb250IGNvbG9yPSIjMDAwMDgwIj4xLTg4OC02MjEtNzMw MDwvZm9udD48L2I+IGZvciB5b3VyPGJyPg0KDQombmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgZnJlZQ0KDQpIR0ggY29uc3VsdGF0aW9uLjwvcD4NCg0K PHA+PGJyPg0KDQpUaGFuayB5b3U8L3A+DQoNCjwvYm9keT4NCg0KPC9odG1s Pg0KDQogDQogDQogDQogDQogDQogDQogDQogDQogDQogDQogDQogDQogDQog DQogDQogDQogDQogDQogDQogDQogDQogDQogDQogDQogDQogDQogDQogDQog DQogDQogDQogDQogDQogDQogDQogDQogDQogDQogDQogDQogDQogDQogDQog DQogDQoNCi0tDQoNCjY3MTNBaGd6OS0zNTFvUVNjNTgwNU1pdk0yLTczMExZ emQxNTQ4ak9ibDM5 ------=_NextPart_000_00D0_13B35A0B.B1376E64-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Sat Jul 13 22:31:14 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA11969 for ; Sat, 13 Jul 2002 22:31:13 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id WAA19453 for seamoby-archive@odin.ietf.org; Sat, 13 Jul 2002 22:32:08 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA18828; Sat, 13 Jul 2002 22:24:01 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA18663 for ; Sat, 13 Jul 2002 22:23:54 -0400 (EDT) Received: from excite.com (host159150.metrored.net.ar [200.59.159.150] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA11726; Sat, 13 Jul 2002 22:22:51 -0400 (EDT) Received: from 144.90.20.80 ([144.90.20.80]) by asy100.as122.sol-superunderline.com with NNFMP; Sat, 13 Jul 0102 20:23:24 -0200 Received: from mta85.snfc21.pibi.net ([42.202.29.184]) by q4.quickslow.com with smtp; Sat, 13 Jul 0102 18:11:24 +0800 Reply-To: "Clinic" Message-ID: <023b34c04b6b$5856a4a1$4dd53dd7@wgwcmt> From: "Clinic" To: Cc: Date: Sun, 14 Jul 0102 10:15:58 -0800 MiME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_00D0_13B35A0B.B1376E64" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal Subject: [Seamoby] Have you heard of HGH Oral Spray? Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org ------=_NextPart_000_00D0_13B35A0B.B1376E64 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: base64 TXl0aDogYWxsIEhHSCBwcm9kdWN0cyBhcmUgdGhlIHNhbWUNCg0KPGh0bWw+ DQoNCjxoZWFkPg0KDQo8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUi IGNvbnRlbnQ9InRleHQvaHRtbDsgY2hhcnNldD13aW5kb3dzLTEyNTIiPg0K DQo8bWV0YSBuYW1lPSJHRU5FUkFUT1IiIGNvbnRlbnQ9Ik1pY3Jvc29mdCBG cm9udFBhZ2UgNC4wIj4NCg0KPG1ldGEgbmFtZT0iUHJvZ0lkIiBjb250ZW50 PSJGcm9udFBhZ2UuRWRpdG9yLkRvY3VtZW50Ij4NCg0KPHRpdGxlPlRoZXJl IGFyZSB0aHJlZSBkaWZmZXJlbnQgdHlwZXMgb2YgSEdIIHByb2R1Y3RzPC90 aXRsZT4NCg0KPC9oZWFkPg0KDQo8Ym9keSBiYWNrZ3JvdW5kPSJjbG91ZHMu anBnIj4NCg0KPHA+PGZvbnQgc2l6ZT0iNCI+PGZvbnQgY29sb3I9IiM4MDAw MDAiPjxiPlRoZXJlIGFyZSB0aHJlZSBkaWZmZXJlbnQgdHlwZXMgb2YNCg0K SEdIIHByb2R1Y3RzLjwvYj48L2ZvbnQ+PGJyPg0KDQpUaGUgY29uZnVzaW9u IGlzIHRoYXQgYWxsIHRocmVlIGFyZTxicj4NCg0KYWR2ZXJ0aXNlZCBhcyBp ZiB0aGV5IHdlcmUgdGhlIHNhbWUuPC9mb250Pjxicj4NCg0KJm5ic3A7PGJy Pg0KDQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgPHU+VGhlIHRocmVlIHR5cGVzIGFyZTo8L3U+PGJyPg0KDQombmJzcDs8 YnI+DQoNCjxiPjEpPC9iPiAtLS0gPGZvbnQgY29sb3I9IiMwMDAwRkYiPjxi PkhvbWVvcGF0aGljIEhHSDwvYj48L2ZvbnQ+PGJyPg0KDQo8Yj4yKTwvYj4g LS0tIDxmb250IGNvbG9yPSIjMDAwMEZGIj48Yj5QcmUtY3Vyc29yIEhHSDwv Yj48L2ZvbnQ+PGJyPg0KDQo8Yj4zKTwvYj4gLS0tIDxmb250IGNvbG9yPSIj MDAwMEZGIj48Yj5SZWFsIG9yIHN5bnRoZXRpYyBIR0g8L2I+PC9mb250Pg0K DQooZGVsaXZlcmVkIGJ5IGluamVjdGlvbjxicj4NCg0KJm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IG9yLCBieSBhbiBvcmFs IHNwcmF5IG1ldGhvZCkuPGJyPg0KDQombmJzcDs8YnI+DQoNCkRvIHlvdSBr bm93IGRpZmZlcmVuY2VzPzxicj4NCg0KJm5ic3A7PGJyPg0KDQpDYWxsIHVz IGFuZCB3ZSdsbCBleHBsYWluIHRoZW0gdG8geW91Ljxicj4NCg0KJm5ic3A7 PGJyPg0KDQpPdXIgdG9sbCBmcmVlIG51bWJlciBpcyA8Zm9udCBjb2xvcj0i IzAwMDA4MCI+PGI+MS04ODgtNjIxLTczMDA8L2I+PC9mb250Pjxicj4NCg0K QW4gSEdIIHN0YWZmIG1lbWJlciBpcyBhdmFpbGFibGU8YnI+DQoNCjkgdG8g NSBQYWNpZmljIFRpbWUuPGJyPg0KDQpJZiBhZnRlciBob3VycywgcGxlYXNl IGxlYXZlIHlvdSBuYW1lPGJyPg0KDQphbmQgZGF5IGFuZCBldmVuaW5nIHBo b25lIG51bWJlcnMuPGJyPg0KDQpXZSB3aWxsIGNhbGwgeW91IGJhY2sgaW4g YSBubyBwcmVzc3VyZSw8YnI+DQoNCmVkdWNhdGlvbmFsIG1hbm5lci48YnI+ DQoNCklmIHlvdSBhcmUgb3ZlcnNlYXMgY2FsbCB5b3VyIGxvbmcgZGlzdGFu Y2U8YnI+DQoNCm9wZXJhdG9yIGFuZCBhc2sgdG8gYmUgY29ubmVjdGVkIHRv IG91cjxicj4NCg0KcGhvbmUgbnVtYmVyLiZuYnNwOyBXZSB3aWxsIGNhbGwg eW91IGJhY2sgc288YnI+DQoNCndlIGNhbiBwYXkgZm9yIHRoZSBsb25nIGRp c3RhbmNlIGNoYXJnZXMuPGJyPg0KDQombmJzcDs8YnI+DQoNCjxmb250IGNv bG9yPSIjRkYwMDAwIj5Gb3IgbW9yZSBpbmZvcm1hdGlvbiBvbiBIR0ggcmVh ZCBvbi4uLi4uLi4uLi4uLjwvZm9udD48YnI+DQoNCiZuYnNwOzxicj4NCg0K SEFWRSBZT1UgSEVBUkQgT0Y8YnI+DQoNCkhVTUFOIEdST1dUSCBIT1JNT05F IChIR0gpPz8/PGJyPg0KDQombmJzcDs8YnI+DQoNCiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyBSZWxlYXNlZCBieSB5b3VyIG93biBwaXR1aXRhcnkgZ2xh bmQsIEhHSCBzdGFydHMNCg0KZGVjbGluaW5nPGJyPg0KDQppbiB5b3VyIDIw cywgZXZlbiBtb3JlIGluIHlvdXIgMzBzIGFuZCA0MHMsIGV2ZW50dWFsbHkg cmVzdWx0aW5nPGJyPg0KDQppbiB0aGUgc2hyaW5rYWdlIG9mIG1ham9yIG9y Z2FucyAtLSBwbHVzLCBhbGw8YnI+DQoNCm90aGVyIHN5bXB0b21zIHJlbGF0 ZWQgdG8gb2xkIGFnZS48YnI+DQoNCiZuYnNwOzxicj4NCg0KJm5ic3A7PGJy Pg0KDQpJTiBUSE9VU0FORFMgT0YgQ0xJTklDQUwgU1RVRElFUyw8YnI+DQoN CkhHSCBIQVMgQkVFTiBTSE9XTiBUTyBBQ0NPTVBMSVNIIFRIRSBGT0xMT1dJ Tkc6PGJyPg0KDQombmJzcDs8YnI+DQoNCiogUmVkdWNlIEJvZHkgRmF0IGFu ZCBCdWlsZCBMZWFuIE11c2NsZTxicj4NCg0KJm5ic3A7Jm5ic3A7IFdJVEhP VVQgRVhFUkNJU0UhPGJyPg0KDQombmJzcDs8YnI+DQoNCiogRW5oYW5jZSBT ZXh1YWwgUGVyZm9ybWFuY2U8YnI+DQoNCiZuYnNwOzxicj4NCg0KKiBSZW1v dmUgV3JpbmtsZXMgYW5kIENlbGx1bGl0ZTxicj4NCg0KJm5ic3A7PGJyPg0K DQoqIExvd2VyIEJsb29kIFByZXNzdXJlIGFuZCBJbXByb3ZlIENob2xlc3Rl cm9sIFByb2ZpbGU8YnI+DQoNCiZuYnNwOzxicj4NCg0KKiBJbXByb3ZlIFNs ZWVwLCBWaXNpb24gYW5kIE1lbW9yeTxicj4NCg0KJm5ic3A7PGJyPg0KDQoq IFJlc3RvcmUgSGFpciBDb2xvciBhbmQgR3Jvd3RoPGJyPg0KDQombmJzcDs8 YnI+DQoNCiogU3RyZW5ndGhlbiB0aGUgSW1tdW5lIFN5c3RlbTxicj4NCg0K Jm5ic3A7PGJyPg0KDQoqIEluY3JlYXNlIEVuZXJneSBhbmQgQ2FyZGlhYyBP dXRwdXQ8YnI+DQoNCiZuYnNwOzxicj4NCg0KKiBUdXJuIGJhY2sgeW91ciBi b2R5J3MgQmlvbG9naWNhbCBUaW1lIENsb2NrIDEwIC0gMjAgeWVhcnM8YnI+ DQoNCiZuYnNwOzxicj4NCg0KKiBMaXZlIExvbmdlciBBTkQgU3Ryb25nZXI8 YnI+DQoNCiZuYnNwOzxicj4NCg0KQWxsIG5hdHVyYWwgYW5kIG9yZ2FuaWMg cGxhbnQgYmFzZWQ8YnI+DQoNCiZuYnNwOzxicj4NCg0KPGZvbnQgY29sb3I9 IiMwMDAwRkYiPjxiPkZFRUwgMTAgWUVBUlMgWU9VTkdFUiBXSVRIIE9SQUwg U1BSQVkgSEdILjxicj4NCg0KR1VBUkFOVEVFRDwvYj48L2ZvbnQ+PGJyPg0K DQombmJzcDs8YnI+DQoNCiZuYnNwOyZuYnNwOyZuYnNwOyBXZSBhcmUgdGhl IG1hbnVmYWN0dXJlciBhbmQgd2Ugc2VsbCBkaXJlY3RseSB0byBEb2N0b3Jz LDxicj4NCg0KQ2hpcm9wcmFjdG9ycywgYW5kIGNvbnN1bWVycyB3b3JsZCB3 aWRlIHRoZSBoaWdoZXN0IGdyYWRlPGJyPg0KDQombmJzcDtIR0ggT3JhbCBT cHJheSBhdmFpbGFibGUuJm5ic3A7PGJyPg0KDQombmJzcDs8YnI+DQoNCiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBXaXRoIGludGVybmV0IG1hcmtldGlu Zywgd2UgYXJlIGFibGUgdG8gc2F2ZQ0KDQphZHZlcnRpc2luZzxicj4NCg0K Y29zdCBhbmQgcGFzcyB0aG9zZSBzYXZpbmdzIGFsb25nIHRvIHlvdS48YnI+ DQoNCkJ1dCB5b3UgbXVzdCBhY3Qgbm93LiZuYnNwOzxicj4NCg0KJm5ic3A7 PGJyPg0KDQpUbyByZWNlaXZlIG1vcmUgaW5mb3JtYXRpb24gY2FsbCZuYnNw OyB1cyBub3cuPGJyPg0KDQombmJzcDs8YnI+DQoNCiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyBUT0xMIEZSRUUgPGI+PGZvbnQgY29sb3I9IiMwMDAwODAiPjEt ODg4LTYyMS03MzAwPC9mb250PjwvYj48YnI+DQoNCiZuYnNwOzxicj4NCg0K V2UgbXVzdCBzcGVhayB0byB5b3UgaW4gcGVyc29uIHRvIHF1YWxpZnkgeW91 ciB1c2FnZS48YnI+DQoNCiZuYnNwOzxicj4NCg0KJm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IEFsbCBvZiB5b3VyIHF1ZXN0aW9ucyB3aWxsIGJlIGFkZHJl c3NlZCBhbmQgYW5zd2VyZWQgaW4NCg0KYSBmcmllbmRseSw8YnI+DQoNCm5v IHByZXNzdXJlIG1hbm5lci4mbmJzcDsgT3VyIG1haW4gcHVycG9zZSBpcyB0 byBwcm92aWRlIHlvdSB3aXRoPGJyPg0KDQombmJzcDtpbmZvcm1hdGlvbiBz byB5b3UgY2FuIG1ha2UgYW4gZWR1Y2F0ZWQgZGVjaXNpb24uPGJyPg0KDQom bmJzcDs8YnI+DQoNCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBGb3IgbW9y ZSBpbmZvcm1hdGlvbiBjYWxsPGJyPg0KDQombmJzcDs8YnI+DQoNCiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyA8Yj48Zm9udCBjb2xvcj0iIzAwMDA4MCI+MS04 ODgtNjIxLTczMDA8L2ZvbnQ+PC9iPjxicj4NCg0KJm5ic3A7PGJyPg0KDQom bmJzcDtJZiB5b3UgYXJlIG9uIGxpbmUgd3JpdGUgZG93biBvdXI8YnI+DQoN CnBob25lIG51bWJlciBhbmQgY2FsbCB1cyB3aGVuIHlvdSBjYW4uPGJyPg0K DQombmJzcDs8YnI+DQoNClNvb24sIHlvdSBhbmQgeW91ciBsb3ZlZCBvbmVz IHdpbGwgYmUgdmVyeSBnbGFkIHlvdSBkaWQuPGJyPg0KDQombmJzcDs8YnI+ DQoNClJlYWQgd2hhdCBwZW9wbGUgYXJlIHNheWluZzo8YnI+DQoNCiZuYnNw Ozxicj4NCg0KJnF1b3Q7VGhlIGVmZmVjdHMgb2YgNiBtb250aHMgb2YgR0gg b248YnI+DQoNCmxlYW4gYm9keSBtYXNzIGFuZCBmYXQgd2VyZSBlcXVpdmFs ZW50PGJyPg0KDQppbiBtYWduaXR1ZGUgdG8gdGhlIGNoYW5nZXMgaW5jdXJy ZWQ8YnI+DQoNCmR1cmluZyAxMC0yMCB5ZWFycyBvZiBhZ2luZy4mcXVvdDs8 YnI+DQoNCkRyLiBEYW5pZWwgUnVkbWFuLCBNRCw8YnI+DQoNCk5ldyBFbmds YW5kIEpvdXJuYWwgb2YgTWVkaWNpbmUuPGJyPg0KDQombmJzcDs8YnI+DQoN CiZxdW90O1dpdGhpbiBmb3VyIG1vbnRocywgbXkgYm9keSBmYXQgZGVjcmVh c2VkPGJyPg0KDQombmJzcDtmb3JtIDMwJSBkb3duIHRvIDIxJSEgSSBub3Rp Y2VkIG15IHNraW48YnI+DQoNCiZuYnNwO2lzIG1vcmUgc3VwcGxlIGFuZCBt eSBvdmVyYWxsIG1lbnRhbDxicj4NCg0KJm5ic3A7b3V0bG9vayBpbXByb3Zl ZCBzaWduaWZpY2FudGx5LiZxdW90Ozxicj4NCg0KJm5ic3A7RC5XLiwgTmV3 IEplcnNleTxicj4NCg0KJm5ic3A7PGJyPg0KDQomcXVvdDtXZSBoYXZlIGJl ZW4gb24gdGhlIHNwcmF5IGZvciBqdXN0IDMgd2Vla3M8YnI+DQoNCm5vdywg YW5kIGJlc2lkZXMgdGhlIHRyZW1lbmRvdXMgZW5lcmd5IHdlPGJyPg0KDQpi b3RoIGZlZWwsIG15IGh1c2JhbmRzIGFsbGVyZ2llcyBhbmQgc3BlbGxzPGJy Pg0KDQpvZiBkZXByZXNzaW9uIGhhdmUgbGlmdGVkLiBJIGFtIGhlYWxpbmc8 YnI+DQoNCmV4dHJlbWVseSBmYXN0IGFmdGVyIGFuIGFjY2lkZW50IGFuZCBo YXZlPGJyPg0KDQpsb3N0IDcgbGJzLiB3aXRob3V0IHRyeWluZyEmcXVvdDs8 YnI+DQoNCkMuQi4sIEZsYWdzdGFmZi4gQVo8YnI+DQoNCiZuYnNwOzxicj4N Cg0KVGhhbmtzIGZvciByZWFkaW5nIG91ciBsZXR0ZXIsPGJyPg0KDQpUaGUg SEdIIFN0YWZmPGJyPg0KDQpVU0EgRGl2aXNpb248YnI+DQoNCiZuYnNwOzxi cj4NCg0KUFM6Jm5ic3A7IFRoZSBIR0ggU3RhZmYgZ3VhcmFudGVlcyB0aGU8 YnI+DQoNCmhpZ2hlc3QgcXVhbGl0eSBhbmQgbG93ZXN0IHByaWNlLjxicj4N Cg0KJm5ic3A7PGJyPg0KDQombmJzcDtXZSBtYW51ZmFjdHVyZSBhbmQgc2hp cCBkaXJlY3RseSB0byB5b3VyIGRvb3IuPGJyPg0KDQombmJzcDs8YnI+DQoN CkNhbGwgdXMgbm93IDxiPjxmb250IGNvbG9yPSIjMDAwMDgwIj4xLTg4OC02 MjEtNzMwMDwvZm9udD48L2I+PGJyPg0KDQombmJzcDs8YnI+DQoNCj09PT09 PT0mbmJzcDsmbmJzcDsgRW5kIG9mIG1lc3NhZ2UgPT09PT09PT0mbmJzcDs8 YnI+DQoNCiZuYnNwOzxicj4NCg0KJm5ic3A7Jm5ic3A7IFRoZSBmb2xsb3dp bmcgc3RhdGVtZW50IGlzIHByb3ZpZGVkIHRvIGJlPGJyPg0KDQppbiBjb21w bGlhbmNlIHdpdGggY29tbWVyY2lhbCBlbWFpbCBsYXdzLjxicj4NCg0KJm5i c3A7PGJyPg0KDQombmJzcDsmbmJzcDsgSWYgeW91IGRvIG5vdCB3aXNoIHRv IHJlY2VpdmUgZnVydGhlcjxicj4NCg0KbWFpbGluZ3MsIHBsZWFzZSBjbGlj ayByZXBseSB0bzogIHRoZV9oZ2hfY2xpbmljQGJ0YW1haWwubmV0LmNuICBh bmQgdHlwZSByZW1vdmUgaW4gdGhlIHN1YmplY3QgYm94Ljxicj4NCg0KVGhl biBjbGljayBzZW5kLjxicj4NCg0KJm5ic3A7PGJyPg0KDQombmJzcDsmbmJz cDsgVGhpcyBtZXNzYWdlIGlzIGluIGZ1bGwgY29tcGxpYW5jZSB3aXRoPGJy Pg0KDQpVLlMuIEZlZGVyYWwgcmVxdWlyZW1lbnRzIGZvciBjb21tZXJjaWFs PGJyPg0KDQplbWFpbCB1bmRlciBiaWxsIFMuMTYxOCBUaXRsZSBsbGwsIFNl Y3Rpb24gMzAxLDxicj4NCg0KUGFyYWdyYXBoIChhKSgyKShDKSBwYXNzZWQg YnkgdGhlIDEwNXRoIFUuUy48YnI+DQoNCkNvbmdyZXNzIGFuZCBpcyBub3Qg Y29uc2lkZXJlZCBTUEFNPGJyPg0KDQpzaW5jZSBpdCBpbmNsdWRlcyBhIHJl bW92ZSBtZWNoYW5pc20uKjxicj4NCg0KVGhpcyBtZXNzYWdlIGlzIG5vdCBp bnRlbmRlZCBmb3IgcmVzaWRlbnRzIGluIHRoZTxicj4NCg0Kc3RhdGVzIG9m IENBLCBOQywgTlYsIFJJLCBUTiwgVkEgJmFtcDsgV0EuPGJyPg0KDQpTY3Jl ZW5pbmcgb2YgYWRkcmVzc2VzIGhhcyBiZWVuIGRvbmUgdG8gdGhlIGJlc3Q8 YnI+DQoNCm9mIG91ciB0ZWNobmljYWwgYWJpbGl0eS48YnI+DQoNCiZuYnNw Ozxicj4NCg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IENhbGwgdXMN Cg0Kbm93IDxiPjxmb250IGNvbG9yPSIjMDAwMDgwIj4xLTg4OC02MjEtNzMw MDwvZm9udD48L2I+IGZvciB5b3VyPGJyPg0KDQombmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgZnJlZQ0KDQpIR0ggY29uc3VsdGF0aW9uLjwvcD4NCg0K PHA+PGJyPg0KDQpUaGFuayB5b3U8L3A+DQoNCjwvYm9keT4NCg0KPC9odG1s Pg0KDQogDQogDQogDQogDQogDQogDQogDQogDQogDQogDQogDQogDQogDQog DQogDQogDQogDQogDQogDQogDQogDQogDQogDQogDQogDQogDQogDQogDQog DQogDQogDQogDQogDQogDQogDQogDQogDQogDQogDQogDQogDQogDQogDQog DQogDQoNCi0tDQoNCjY3MTNBaGd6OS0zNTFvUVNjNTgwNU1pdk0yLTczMExZ emQxNTQ4ak9ibDM5 ------=_NextPart_000_00D0_13B35A0B.B1376E64-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Sun Jul 14 07:08:52 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA01608 for ; Sun, 14 Jul 2002 07:08:52 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA15657; Sun, 14 Jul 2002 07:05:53 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA15626 for ; Sun, 14 Jul 2002 07:05:49 -0400 (EDT) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA01510 for ; Sun, 14 Jul 2002 07:04:52 -0400 (EDT) From: john.loughney@nokia.com Received: from esvir02nok.ntc.nokia.com (esvir02nokt.ntc.nokia.com [172.21.143.34]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g6EB6Hi21775 for ; Sun, 14 Jul 2002 14:06:17 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir02nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Sun, 14 Jul 2002 14:05:46 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Sun, 14 Jul 2002 14:05:46 +0300 Subject: RE: [Seamoby] Proposal on Sync/NoSync Requirement MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Sun, 14 Jul 2002 14:05:48 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEF01130811@esebe004.NOE.Nokia.com> content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Thread-Topic: [Seamoby] Proposal on Sync/NoSync Requirement Thread-Index: AcIqoM8VdpRkgGA2R065rxswZqasWgANHgKA To: , X-OriginalArrivalTime: 14 Jul 2002 11:05:46.0236 (UTC) FILETIME=[6757E3C0:01C22B26] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id HAA15627 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 8bit Hi James, > So based on the list discussion so far, I'd like to put out > the following proposal for a requirement on synchronization or > its lack: > > 5.5.1 The CT solution SHOULD NOT provide direct support for > synchronization of context. However, the CT solution SHOULD allow > particular feature contexts that require synchronization to > provide that support. > > Most feature contexts will not require synchronization, however there are a > few that may. Header compression, for example, may require that the header > compressor on the old access router cease and the compressor on the new > router start in synchrony with hand over of routing to the new router; > otherwise, the compressor on the new router will not be properly synchronized. > Since most contexts don't need synchronization support, the CT solution need > not support it, but it should not provide a hinderance to those feature contexts > that do. I would rather like it stated that Context Synchronization is out of scope for this work. However, we should note that many contexts don't require it, but some might. John _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@ns.ietf.org Sun Jul 14 07:56:09 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA01616 for ; Sun, 14 Jul 2002 07:08:52 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA15727 for seamoby-archive@odin.ietf.org; Sun, 14 Jul 2002 07:09:49 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA15657; Sun, 14 Jul 2002 07:05:53 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA15626 for ; Sun, 14 Jul 2002 07:05:49 -0400 (EDT) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA01510 for ; Sun, 14 Jul 2002 07:04:52 -0400 (EDT) From: john.loughney@nokia.com Received: from esvir02nok.ntc.nokia.com (esvir02nokt.ntc.nokia.com [172.21.143.34]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g6EB6Hi21775 for ; Sun, 14 Jul 2002 14:06:17 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir02nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Sun, 14 Jul 2002 14:05:46 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Sun, 14 Jul 2002 14:05:46 +0300 Subject: RE: [Seamoby] Proposal on Sync/NoSync Requirement MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Sun, 14 Jul 2002 14:05:48 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEF01130811@esebe004.NOE.Nokia.com> content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Thread-Topic: [Seamoby] Proposal on Sync/NoSync Requirement Thread-Index: AcIqoM8VdpRkgGA2R065rxswZqasWgANHgKA To: , X-OriginalArrivalTime: 14 Jul 2002 11:05:46.0236 (UTC) FILETIME=[6757E3C0:01C22B26] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id HAA15627 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 8bit Hi James, > So based on the list discussion so far, I'd like to put out > the following proposal for a requirement on synchronization or > its lack: > > 5.5.1 The CT solution SHOULD NOT provide direct support for > synchronization of context. However, the CT solution SHOULD allow > particular feature contexts that require synchronization to > provide that support. > > Most feature contexts will not require synchronization, however there are a > few that may. Header compression, for example, may require that the header > compressor on the old access router cease and the compressor on the new > router start in synchrony with hand over of routing to the new router; > otherwise, the compressor on the new router will not be properly synchronized. > Since most contexts don't need synchronization support, the CT solution need > not support it, but it should not provide a hinderance to those feature contexts > that do. I would rather like it stated that Context Synchronization is out of scope for this work. However, we should note that many contexts don't require it, but some might. John _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Sun Jul 14 17:50:16 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17933 for ; Sun, 14 Jul 2002 17:50:16 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA07632; Sun, 14 Jul 2002 17:40:54 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA07603 for ; Sun, 14 Jul 2002 17:40:52 -0400 (EDT) Received: from fridge.docomolabs-usa.com (fwuser@key1.docomolabs-usa.com [216.98.102.225]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17681 for ; Sun, 14 Jul 2002 17:39:55 -0400 (EDT) Message-ID: <007001c22b7e$e3d891d0$0e6015ac@T23KEMPF> From: "James Kempf" To: "John Loughney" , References: <0C1353ABB1DEB74DB067ADFF749C4EEF01130811@esebe004.NOE.Nokia.com> Subject: Re: [Seamoby] Proposal on Sync/NoSync Requirement Date: Sun, 14 Jul 2002 14:39:09 -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-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit John, "Out of scope" is typically WG charter language. I know the SHOULD/SHOULD NOT sounds a bit funny, but I think we need to express this in a way that is more requirements language. jak ----- Original Message ----- From: To: ; Sent: Sunday, July 14, 2002 4:05 AM Subject: RE: [Seamoby] Proposal on Sync/NoSync Requirement > Hi James, > > > So based on the list discussion so far, I'd like to put out > > the following proposal for a requirement on synchronization or > > its lack: > > > > 5.5.1 The CT solution SHOULD NOT provide direct support for > > synchronization of context. However, the CT solution SHOULD allow > > particular feature contexts that require synchronization to > > provide that support. > > > > Most feature contexts will not require synchronization, however there are a > > few that may. Header compression, for example, may require that the header > > compressor on the old access router cease and the compressor on the new > > router start in synchrony with hand over of routing to the new router; > > otherwise, the compressor on the new router will not be properly synchronized. > > Since most contexts don't need synchronization support, the CT solution need > > not support it, but it should not provide a hinderance to those feature contexts > > that do. > > I would rather like it stated that Context Synchronization is out of > scope for this work. However, we should note that many contexts > don't require it, but some might. > > John > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@ns.ietf.org Sun Jul 14 17:50:17 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17942 for ; Sun, 14 Jul 2002 17:50:17 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA07829 for seamoby-archive@odin.ietf.org; Sun, 14 Jul 2002 17:51:13 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA07632; Sun, 14 Jul 2002 17:40:54 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA07603 for ; Sun, 14 Jul 2002 17:40:52 -0400 (EDT) Received: from fridge.docomolabs-usa.com (fwuser@key1.docomolabs-usa.com [216.98.102.225]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17681 for ; Sun, 14 Jul 2002 17:39:55 -0400 (EDT) Message-ID: <007001c22b7e$e3d891d0$0e6015ac@T23KEMPF> From: "James Kempf" To: "John Loughney" , References: <0C1353ABB1DEB74DB067ADFF749C4EEF01130811@esebe004.NOE.Nokia.com> Subject: Re: [Seamoby] Proposal on Sync/NoSync Requirement Date: Sun, 14 Jul 2002 14:39:09 -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-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit John, "Out of scope" is typically WG charter language. I know the SHOULD/SHOULD NOT sounds a bit funny, but I think we need to express this in a way that is more requirements language. jak ----- Original Message ----- From: To: ; Sent: Sunday, July 14, 2002 4:05 AM Subject: RE: [Seamoby] Proposal on Sync/NoSync Requirement > Hi James, > > > So based on the list discussion so far, I'd like to put out > > the following proposal for a requirement on synchronization or > > its lack: > > > > 5.5.1 The CT solution SHOULD NOT provide direct support for > > synchronization of context. However, the CT solution SHOULD allow > > particular feature contexts that require synchronization to > > provide that support. > > > > Most feature contexts will not require synchronization, however there are a > > few that may. Header compression, for example, may require that the header > > compressor on the old access router cease and the compressor on the new > > router start in synchrony with hand over of routing to the new router; > > otherwise, the compressor on the new router will not be properly synchronized. > > Since most contexts don't need synchronization support, the CT solution need > > not support it, but it should not provide a hinderance to those feature contexts > > that do. > > I would rather like it stated that Context Synchronization is out of > scope for this work. However, we should note that many contexts > don't require it, but some might. > > John > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Sun Jul 14 18:08:55 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18484 for ; Sun, 14 Jul 2002 18:08:54 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA08767; Sun, 14 Jul 2002 18:01:27 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA08732 for ; Sun, 14 Jul 2002 18:01:25 -0400 (EDT) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18261 for ; Sun, 14 Jul 2002 18:00:29 -0400 (EDT) From: john.loughney@nokia.com Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g6EM1ri07695 for ; Mon, 15 Jul 2002 01:01:53 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 15 Jul 2002 01:01:23 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Mon, 15 Jul 2002 01:01:22 +0300 content-class: urn:content-classes:message Subject: RE: [Seamoby] Proposal on Sync/NoSync Requirement MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Mon, 15 Jul 2002 01:01:22 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFD38EC2@esebe004.NOE.Nokia.com> Thread-Topic: [Seamoby] Proposal on Sync/NoSync Requirement Thread-Index: AcIrfx7Kw2nHmcEKTWWI4+NF0z9YWQAAfF5Q To: , X-OriginalArrivalTime: 14 Jul 2002 22:01:22.0978 (UTC) FILETIME=[FDDE6020:01C22B81] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id SAA08733 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 8bit Hi James, > "Out of scope" is typically WG charter language. I know the > SHOULD/SHOULD NOT sounds a bit funny, but I think we need to > express this in a way that is more requirements language. Then how about changing: ... the CT solution need not support it, but it should not provide a hinderance to those feature contexts that do. to: ... the CT solution is not requireed to directly support synchronization, but may support simple methods for the synchronization context for feature contexts that do. John _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@ns.ietf.org Sun Jul 14 18:08:55 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18491 for ; Sun, 14 Jul 2002 18:08:55 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA08969 for seamoby-archive@odin.ietf.org; Sun, 14 Jul 2002 18:09:50 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA08767; Sun, 14 Jul 2002 18:01:27 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA08732 for ; Sun, 14 Jul 2002 18:01:25 -0400 (EDT) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18261 for ; Sun, 14 Jul 2002 18:00:29 -0400 (EDT) From: john.loughney@nokia.com Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g6EM1ri07695 for ; Mon, 15 Jul 2002 01:01:53 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 15 Jul 2002 01:01:23 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Mon, 15 Jul 2002 01:01:22 +0300 content-class: urn:content-classes:message Subject: RE: [Seamoby] Proposal on Sync/NoSync Requirement MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Mon, 15 Jul 2002 01:01:22 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFD38EC2@esebe004.NOE.Nokia.com> Thread-Topic: [Seamoby] Proposal on Sync/NoSync Requirement Thread-Index: AcIrfx7Kw2nHmcEKTWWI4+NF0z9YWQAAfF5Q To: , X-OriginalArrivalTime: 14 Jul 2002 22:01:22.0978 (UTC) FILETIME=[FDDE6020:01C22B81] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id SAA08733 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 8bit Hi James, > "Out of scope" is typically WG charter language. I know the > SHOULD/SHOULD NOT sounds a bit funny, but I think we need to > express this in a way that is more requirements language. Then how about changing: ... the CT solution need not support it, but it should not provide a hinderance to those feature contexts that do. to: ... the CT solution is not requireed to directly support synchronization, but may support simple methods for the synchronization context for feature contexts that do. John _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Sun Jul 14 19:04:07 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20107 for ; Sun, 14 Jul 2002 19:04:07 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA10905; Sun, 14 Jul 2002 18:56:38 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA10874 for ; Sun, 14 Jul 2002 18:56:36 -0400 (EDT) Received: from fridge.docomolabs-usa.com (fwuser@key1.docomolabs-usa.com [216.98.102.225]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19895 for ; Sun, 14 Jul 2002 18:55:40 -0400 (EDT) Message-ID: <001c01c22b89$788b1550$056015ac@T23KEMPF> From: "James Kempf" To: , References: <0C1353ABB1DEB74DB067ADFF749C4EEFD38EC2@esebe004.NOE.Nokia.com> Subject: Re: [Seamoby] Proposal on Sync/NoSync Requirement Date: Sun, 14 Jul 2002 15:51:35 -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-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit That sounds better. jak ----- Original Message ----- From: To: ; Sent: Sunday, July 14, 2002 3:01 PM Subject: RE: [Seamoby] Proposal on Sync/NoSync Requirement > Hi James, > > > "Out of scope" is typically WG charter language. I know the > > SHOULD/SHOULD NOT sounds a bit funny, but I think we need to > > express this in a way that is more requirements language. > > Then how about changing: > > ... the CT solution need > not support it, but it should not provide a hinderance to those feature contexts > that do. > > to: > ... the CT solution is not requireed to directly support synchronization, but > may support simple methods for the synchronization context for feature contexts > that do. > > John > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@ns.ietf.org Sun Jul 14 19:04:08 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20113 for ; Sun, 14 Jul 2002 19:04:08 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id TAA11680 for seamoby-archive@odin.ietf.org; Sun, 14 Jul 2002 19:05:03 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA10905; Sun, 14 Jul 2002 18:56:38 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA10874 for ; Sun, 14 Jul 2002 18:56:36 -0400 (EDT) Received: from fridge.docomolabs-usa.com (fwuser@key1.docomolabs-usa.com [216.98.102.225]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19895 for ; Sun, 14 Jul 2002 18:55:40 -0400 (EDT) Message-ID: <001c01c22b89$788b1550$056015ac@T23KEMPF> From: "James Kempf" To: , References: <0C1353ABB1DEB74DB067ADFF749C4EEFD38EC2@esebe004.NOE.Nokia.com> Subject: Re: [Seamoby] Proposal on Sync/NoSync Requirement Date: Sun, 14 Jul 2002 15:51:35 -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-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit That sounds better. jak ----- Original Message ----- From: To: ; Sent: Sunday, July 14, 2002 3:01 PM Subject: RE: [Seamoby] Proposal on Sync/NoSync Requirement > Hi James, > > > "Out of scope" is typically WG charter language. I know the > > SHOULD/SHOULD NOT sounds a bit funny, but I think we need to > > express this in a way that is more requirements language. > > Then how about changing: > > ... the CT solution need > not support it, but it should not provide a hinderance to those feature contexts > that do. > > to: > ... the CT solution is not requireed to directly support synchronization, but > may support simple methods for the synchronization context for feature contexts > that do. > > John > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Mon Jul 15 03:40:19 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA15180 for ; Mon, 15 Jul 2002 03:40:19 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA05279; Mon, 15 Jul 2002 03:35:10 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA05229 for ; Mon, 15 Jul 2002 03:35:08 -0400 (EDT) Received: from mail1.telekom.de (mail1.telekom.de [62.225.183.235]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA15021; Mon, 15 Jul 2002 03:34:10 -0400 (EDT) Received: from g8pbr.blf01.telekom.de by G8SBV.dmz.telekom.de with ESMTP; Mon, 15 Jul 2002 09:33:51 +0200 Received: by G8PBR.blf01.telekom.de with Internet Mail Service (5.5.2653.19) id <38ZSFW8J>; Mon, 15 Jul 2002 09:34:26 +0200 Message-Id: From: "Geib, Ruediger" To: john.loughney@nokia.com Cc: seamoby@ietf.org, nsis@ietf.org Subject: RE: [Seamoby] RE: [NSIS] Re: draft-westphal-nsis-qos-mobileip-00. txt Date: Mon, 15 Jul 2002 09:34:25 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id DAA05232 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 8bit Hi John, >>> The one step we could take (but not the one that was >>> suggested) would be to investigate into ensuring >>> some commonality between the formats for >>> encapsulating the respective data chunks (i.e. >>> context/NSIS parameters). Or at least, provide >>> for NSIS to carry CT data chunks and visa versa. > What I suggest is that NSIS and CT progress, and since there > is some overlap in the interest of both groups, we can > try to ensure that whatever solutions we work on do not > cause trouble for the different working groups. However, > I don't support tightly coupling the solutions. A much > better way would be that after CT & NSIS work is well > along, someone could make an applicability document of > combining both NSIS & CT into a solution for > particular deployments. Both points completely represent my expectations on a loose but useful cooperation of NSIS and SEAMOBY. Regards, Rüdiger _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Mon Jul 15 04:26:16 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA15188 for ; Mon, 15 Jul 2002 03:40:19 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id DAA05462 for seamoby-archive@odin.ietf.org; Mon, 15 Jul 2002 03:41:15 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA05279; Mon, 15 Jul 2002 03:35:10 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA05229 for ; Mon, 15 Jul 2002 03:35:08 -0400 (EDT) Received: from mail1.telekom.de (mail1.telekom.de [62.225.183.235]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA15021; Mon, 15 Jul 2002 03:34:10 -0400 (EDT) Received: from g8pbr.blf01.telekom.de by G8SBV.dmz.telekom.de with ESMTP; Mon, 15 Jul 2002 09:33:51 +0200 Received: by G8PBR.blf01.telekom.de with Internet Mail Service (5.5.2653.19) id <38ZSFW8J>; Mon, 15 Jul 2002 09:34:26 +0200 Message-Id: From: "Geib, Ruediger" To: john.loughney@nokia.com Cc: seamoby@ietf.org, nsis@ietf.org Subject: RE: [Seamoby] RE: [NSIS] Re: draft-westphal-nsis-qos-mobileip-00. txt Date: Mon, 15 Jul 2002 09:34:25 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id DAA05232 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 8bit Hi John, >>> The one step we could take (but not the one that was >>> suggested) would be to investigate into ensuring >>> some commonality between the formats for >>> encapsulating the respective data chunks (i.e. >>> context/NSIS parameters). Or at least, provide >>> for NSIS to carry CT data chunks and visa versa. > What I suggest is that NSIS and CT progress, and since there > is some overlap in the interest of both groups, we can > try to ensure that whatever solutions we work on do not > cause trouble for the different working groups. However, > I don't support tightly coupling the solutions. A much > better way would be that after CT & NSIS work is well > along, someone could make an applicability document of > combining both NSIS & CT into a solution for > particular deployments. Both points completely represent my expectations on a loose but useful cooperation of NSIS and SEAMOBY. Regards, Rüdiger _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Mon Jul 15 10:31:10 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05904 for ; Mon, 15 Jul 2002 10:31:10 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA28792; Mon, 15 Jul 2002 10:28:57 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA28736 for ; Mon, 15 Jul 2002 10:28:53 -0400 (EDT) Received: from hercules.ellemedia.com (hercules.ellemedia.com [212.205.129.4]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05706; Mon, 15 Jul 2002 10:27:54 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by hercules.ellemedia.com (Postfix) with ESMTP id E21D414F22; Mon, 15 Jul 2002 16:26:05 +0300 (EEST) Received: from ellemedia.com (hermes.ellemedia.com [212.205.129.5]) by hercules.ellemedia.com (Postfix) with ESMTP id BAB2614F20; Mon, 15 Jul 2002 16:26:00 +0300 (EEST) Received: from hplaptop (dhcp-219.ellemedia.com [212.205.129.219]) by ellemedia.com (8.10.2+Sun/8.9.3) with SMTP id g6FERYs18858; Mon, 15 Jul 2002 17:27:34 +0300 (EET DST) Message-ID: <002b01c22c0b$f0a988a0$db81cdd4@ellemedia.com> From: "Theodore Zahariadis" To: , , Cc: "Theodore Zahariadis" Date: Mon, 15 Jul 2002 17:28:51 +0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0028_01C22C25.15DE56A0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 X-Virus-Scanned: by AMaViS perl-11 Subject: [Seamoby] ACM/Sigmobile MC2R Special Issue CFP on "Wireless Home Networking" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_0028_01C22C25.15DE56A0 Content-Type: text/plain; charset="iso-8859-7" Content-Transfer-Encoding: quoted-printable Dear all, Apologies if you receive this message more than once. I would like to inform you that ACM/Sigmobile MC2R publication has = announced a Special Issue CFP with subject: "Wireless Home Networking". http://www.cs.columbia.edu/~wenyu/research/cfp/docs/whome.doc Best Regards, Theodore Zahariadis ------=_NextPart_000_0028_01C22C25.15DE56A0 Content-Type: text/html; charset="iso-8859-7" Content-Transfer-Encoding: quoted-printable
Dear all,
 
Apologies if you receive this message = more than=20 once.
 
I would like to inform you that = ACM/Sigmobile MC2R=20 publication has announced a Special Issue CFP with subject: "Wireless Home Networking".
ht= tp://www.cs.columbia.edu/~wenyu/research/cfp/docs/whome.doc
 
Best Regards,
Theodore Zahariadis
 
 
 
------=_NextPart_000_0028_01C22C25.15DE56A0-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Mon Jul 15 10:31:10 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05913 for ; Mon, 15 Jul 2002 10:31:10 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA29459 for seamoby-archive@odin.ietf.org; Mon, 15 Jul 2002 10:32:05 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA28792; Mon, 15 Jul 2002 10:28:57 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA28736 for ; Mon, 15 Jul 2002 10:28:53 -0400 (EDT) Received: from hercules.ellemedia.com (hercules.ellemedia.com [212.205.129.4]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05706; Mon, 15 Jul 2002 10:27:54 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by hercules.ellemedia.com (Postfix) with ESMTP id E21D414F22; Mon, 15 Jul 2002 16:26:05 +0300 (EEST) Received: from ellemedia.com (hermes.ellemedia.com [212.205.129.5]) by hercules.ellemedia.com (Postfix) with ESMTP id BAB2614F20; Mon, 15 Jul 2002 16:26:00 +0300 (EEST) Received: from hplaptop (dhcp-219.ellemedia.com [212.205.129.219]) by ellemedia.com (8.10.2+Sun/8.9.3) with SMTP id g6FERYs18858; Mon, 15 Jul 2002 17:27:34 +0300 (EET DST) Message-ID: <002b01c22c0b$f0a988a0$db81cdd4@ellemedia.com> From: "Theodore Zahariadis" To: , , Cc: "Theodore Zahariadis" Date: Mon, 15 Jul 2002 17:28:51 +0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0028_01C22C25.15DE56A0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 X-Virus-Scanned: by AMaViS perl-11 Subject: [Seamoby] ACM/Sigmobile MC2R Special Issue CFP on "Wireless Home Networking" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_0028_01C22C25.15DE56A0 Content-Type: text/plain; charset="iso-8859-7" Content-Transfer-Encoding: quoted-printable Dear all, Apologies if you receive this message more than once. I would like to inform you that ACM/Sigmobile MC2R publication has = announced a Special Issue CFP with subject: "Wireless Home Networking". http://www.cs.columbia.edu/~wenyu/research/cfp/docs/whome.doc Best Regards, Theodore Zahariadis ------=_NextPart_000_0028_01C22C25.15DE56A0 Content-Type: text/html; charset="iso-8859-7" Content-Transfer-Encoding: quoted-printable
Dear all,
 
Apologies if you receive this message = more than=20 once.
 
I would like to inform you that = ACM/Sigmobile MC2R=20 publication has announced a Special Issue CFP with subject: "Wireless Home Networking".
ht= tp://www.cs.columbia.edu/~wenyu/research/cfp/docs/whome.doc
 
Best Regards,
Theodore Zahariadis
 
 
 
------=_NextPart_000_0028_01C22C25.15DE56A0-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Mon Jul 15 10:58:59 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07331 for ; Mon, 15 Jul 2002 10:58:59 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA00254; Mon, 15 Jul 2002 10:57:16 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA00225 for ; Mon, 15 Jul 2002 10:57:14 -0400 (EDT) Received: from zcars04e.ca.nortel.com (zcars04e.nortelnetworks.com [47.129.242.56]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07217 for ; Mon, 15 Jul 2002 10:56:18 -0400 (EDT) Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g6FEuGc12535; Mon, 15 Jul 2002 10:56:16 -0400 (EDT) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 15 Jul 2002 10:56:15 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA4C1D@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'James Kempf'" , john.loughney@nokia.com, seamoby@ietf.org Subject: RE: [Seamoby] Proposal on Sync/NoSync Requirement Date: Mon, 15 Jul 2002 10:56:06 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C22C0F.BF361780" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C22C0F.BF361780 Content-Type: text/plain; charset="iso-8859-1" I don't think this requirement really resolves much of the issue that has been under discussion, namely the level of synchronization that is to be possible using CT. CT for updates (as a result of new flows, or flows being discontinued) is, I think, pretty straightforward. CT for state maintenance where the state may change while a transfer is in progress is a much harder problem. It matters not whether we say that CT solves this latter problem, or provides the support mechanisms, the demands that this would impose on the protocol are extreme. We need a requirement that clearly identifies what is meant by CT synchronization: Currently: 5.5 Context Update and Synchronization 5.5.1 The context transfer protocol MUST be capable of updating context information when it changes. 5.5.2 A context update MUST preserve the integrity, and thus the meaning, of the context at each receiving AR. The context at the AR actually supporting an MN's traffic will change with time. For example, the MN may initiate new microflow(s), or discontinue existing microflows. Any change of context at the supporting AR must be replicated at those ARs that have already received context for that MN. Proposed: 5.5 Context Update and Synchronization 5.5.1 The context transfer protocol MUST be capable of supporting the updates to context information when it changes. 5.5.2 Context updates SHOULD complete before the context is needed at the receiving AR. The context at the AR actually supporting an MN's traffic will change with time. For example, the MN may initiate new microflow(s), or discontinue existing microflows. Any change of context at the supporting AR must be replicated at those ARs that have already received context for that MN. However, context changes are often driven by events external to the sending AR, and will thus be asynchronous to any on-going context updates. Given that context transfers will take a finite amount of time to complete, it is possible that a change in context cannot be conveyed in time to the destination AR to avoid any impact on a possible handover. The objective of the context transfer design must be to make the likelihood of this delay, and its magnitude, as low as possible. This is not perfect: the desire to avoid a requirement for an extreme degree of synchronization is only implied by the soft "SHOULD" in 5.5.2. Regards, Gary > -----Original Message----- > From: James Kempf [mailto:kempf@docomolabs-usa.com] > Sent: July 14, 2002 18:52 > To: john.loughney@nokia.com; seamoby@ietf.org > Subject: Re: [Seamoby] Proposal on Sync/NoSync Requirement > > > That sounds better. > > jak > > ----- Original Message ----- > From: > To: ; > Sent: Sunday, July 14, 2002 3:01 PM > Subject: RE: [Seamoby] Proposal on Sync/NoSync Requirement > > > > Hi James, > > > > > "Out of scope" is typically WG charter language. I know the > > > SHOULD/SHOULD NOT sounds a bit funny, but I think we need to > > > express this in a way that is more requirements language. > > > > Then how about changing: > > > > ... the CT solution need > > not support it, but it should not provide a > hinderance to those feature contexts > > that do. > > > > to: > > ... the CT solution is not requireed to directly > support synchronization, but > > may support simple methods for the synchronization > context for feature contexts > > that do. > > > > John > > > > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > ------_=_NextPart_001_01C22C0F.BF361780 Content-Type: text/html; charset="iso-8859-1" RE: [Seamoby] Proposal on Sync/NoSync Requirement

I don't think this requirement really resolves much of the issue
that has been under discussion, namely the level of synchronization
that is to be possible using CT.

CT for updates (as a result of new flows, or flows being discontinued)
is, I think, pretty straightforward. CT for state maintenance where the
state may change while a transfer is in progress is a much harder problem.

It matters not whether we say that CT solves this latter problem, or provides
the support mechanisms, the demands that this would impose on the protocol
are extreme.

We need a requirement that clearly identifies what is meant by CT synchronization:

Currently:

5.5 Context Update and Synchronization

5.5.1 The context transfer protocol MUST be capable of updating
      context information when it changes.

5.5.2 A context update MUST preserve the integrity, and thus the
      meaning, of the context at each receiving AR.

   The context at the AR actually supporting an MN's traffic will
   change with time. For example, the MN may initiate new microflow(s),
   or discontinue existing microflows. Any change of context at the
   supporting AR must be replicated at those ARs that have already
   received context for that MN.

Proposed:

5.5 Context Update and Synchronization

5.5.1 The context transfer protocol MUST be capable of supporting the
      updates to context information when it changes.

5.5.2 Context updates SHOULD complete before the context is needed at
      the receiving AR.

   The context at the AR actually supporting an MN's traffic will
   change with time. For example, the MN may initiate new microflow(s),
   or discontinue existing microflows. Any change of context at the
   supporting AR must be replicated at those ARs that have already
   received context for that MN.

   However, context changes are often driven by events external to the
   sending AR, and will thus be asynchronous to any on-going context
   updates. Given that context transfers will take a finite amount of
   time to complete, it is possible that a change in context cannot be
   conveyed in time to the destination AR to avoid any impact on a possible
   handover. The objective of the context transfer design must be to make
   the likelihood of this delay, and its magnitude, as low as possible.


This is not perfect: the desire to avoid a requirement for an extreme degree
of synchronization is only implied by the soft "SHOULD" in 5.5.2.

Regards,
Gary


> -----Original Message-----
> From: James Kempf [mailto:kempf@docomolabs-usa.com]
> Sent: July 14, 2002 18:52
> To: john.loughney@nokia.com; seamoby@ietf.org
> Subject: Re: [Seamoby] Proposal on Sync/NoSync Requirement
>
>
> That sounds better.
>
>             jak
>
> ----- Original Message -----
> From: <john.loughney@nokia.com>
> To: <kempf@docomolabs-usa.com>; <seamoby@ietf.org>
> Sent: Sunday, July 14, 2002 3:01 PM
> Subject: RE: [Seamoby] Proposal on Sync/NoSync Requirement
>
>
> > Hi James,
> >
> > > "Out of scope" is typically WG charter language. I know the
> > > SHOULD/SHOULD NOT sounds a bit funny, but I think we need to
> > > express this in a way that is more requirements language.
> >
> > Then how about changing:
> >
> >       ... the CT solution need
> >       not support it, but it should not provide a
> hinderance to those feature contexts
> >       that do.
> >
> > to:
> >       ... the CT solution is not requireed to directly
> support synchronization, but
> >       may support simple methods for the synchronization
> context for feature contexts
> >       that do.
> >
> > John
> >
>
>
> _______________________________________________
> Seamoby mailing list
> Seamoby@ietf.org
> https://www1.ietf.org/mailman/listinfo/seamoby
>

------_=_NextPart_001_01C22C0F.BF361780-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Mon Jul 15 10:59:00 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07341 for ; Mon, 15 Jul 2002 10:59:00 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA00342 for seamoby-archive@odin.ietf.org; Mon, 15 Jul 2002 10:59:54 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA00254; Mon, 15 Jul 2002 10:57:16 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA00225 for ; Mon, 15 Jul 2002 10:57:14 -0400 (EDT) Received: from zcars04e.ca.nortel.com (zcars04e.nortelnetworks.com [47.129.242.56]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07217 for ; Mon, 15 Jul 2002 10:56:18 -0400 (EDT) Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g6FEuGc12535; Mon, 15 Jul 2002 10:56:16 -0400 (EDT) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 15 Jul 2002 10:56:15 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA4C1D@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'James Kempf'" , john.loughney@nokia.com, seamoby@ietf.org Subject: RE: [Seamoby] Proposal on Sync/NoSync Requirement Date: Mon, 15 Jul 2002 10:56:06 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C22C0F.BF361780" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C22C0F.BF361780 Content-Type: text/plain; charset="iso-8859-1" I don't think this requirement really resolves much of the issue that has been under discussion, namely the level of synchronization that is to be possible using CT. CT for updates (as a result of new flows, or flows being discontinued) is, I think, pretty straightforward. CT for state maintenance where the state may change while a transfer is in progress is a much harder problem. It matters not whether we say that CT solves this latter problem, or provides the support mechanisms, the demands that this would impose on the protocol are extreme. We need a requirement that clearly identifies what is meant by CT synchronization: Currently: 5.5 Context Update and Synchronization 5.5.1 The context transfer protocol MUST be capable of updating context information when it changes. 5.5.2 A context update MUST preserve the integrity, and thus the meaning, of the context at each receiving AR. The context at the AR actually supporting an MN's traffic will change with time. For example, the MN may initiate new microflow(s), or discontinue existing microflows. Any change of context at the supporting AR must be replicated at those ARs that have already received context for that MN. Proposed: 5.5 Context Update and Synchronization 5.5.1 The context transfer protocol MUST be capable of supporting the updates to context information when it changes. 5.5.2 Context updates SHOULD complete before the context is needed at the receiving AR. The context at the AR actually supporting an MN's traffic will change with time. For example, the MN may initiate new microflow(s), or discontinue existing microflows. Any change of context at the supporting AR must be replicated at those ARs that have already received context for that MN. However, context changes are often driven by events external to the sending AR, and will thus be asynchronous to any on-going context updates. Given that context transfers will take a finite amount of time to complete, it is possible that a change in context cannot be conveyed in time to the destination AR to avoid any impact on a possible handover. The objective of the context transfer design must be to make the likelihood of this delay, and its magnitude, as low as possible. This is not perfect: the desire to avoid a requirement for an extreme degree of synchronization is only implied by the soft "SHOULD" in 5.5.2. Regards, Gary > -----Original Message----- > From: James Kempf [mailto:kempf@docomolabs-usa.com] > Sent: July 14, 2002 18:52 > To: john.loughney@nokia.com; seamoby@ietf.org > Subject: Re: [Seamoby] Proposal on Sync/NoSync Requirement > > > That sounds better. > > jak > > ----- Original Message ----- > From: > To: ; > Sent: Sunday, July 14, 2002 3:01 PM > Subject: RE: [Seamoby] Proposal on Sync/NoSync Requirement > > > > Hi James, > > > > > "Out of scope" is typically WG charter language. I know the > > > SHOULD/SHOULD NOT sounds a bit funny, but I think we need to > > > express this in a way that is more requirements language. > > > > Then how about changing: > > > > ... the CT solution need > > not support it, but it should not provide a > hinderance to those feature contexts > > that do. > > > > to: > > ... the CT solution is not requireed to directly > support synchronization, but > > may support simple methods for the synchronization > context for feature contexts > > that do. > > > > John > > > > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > ------_=_NextPart_001_01C22C0F.BF361780 Content-Type: text/html; charset="iso-8859-1" RE: [Seamoby] Proposal on Sync/NoSync Requirement

I don't think this requirement really resolves much of the issue
that has been under discussion, namely the level of synchronization
that is to be possible using CT.

CT for updates (as a result of new flows, or flows being discontinued)
is, I think, pretty straightforward. CT for state maintenance where the
state may change while a transfer is in progress is a much harder problem.

It matters not whether we say that CT solves this latter problem, or provides
the support mechanisms, the demands that this would impose on the protocol
are extreme.

We need a requirement that clearly identifies what is meant by CT synchronization:

Currently:

5.5 Context Update and Synchronization

5.5.1 The context transfer protocol MUST be capable of updating
      context information when it changes.

5.5.2 A context update MUST preserve the integrity, and thus the
      meaning, of the context at each receiving AR.

   The context at the AR actually supporting an MN's traffic will
   change with time. For example, the MN may initiate new microflow(s),
   or discontinue existing microflows. Any change of context at the
   supporting AR must be replicated at those ARs that have already
   received context for that MN.

Proposed:

5.5 Context Update and Synchronization

5.5.1 The context transfer protocol MUST be capable of supporting the
      updates to context information when it changes.

5.5.2 Context updates SHOULD complete before the context is needed at
      the receiving AR.

   The context at the AR actually supporting an MN's traffic will
   change with time. For example, the MN may initiate new microflow(s),
   or discontinue existing microflows. Any change of context at the
   supporting AR must be replicated at those ARs that have already
   received context for that MN.

   However, context changes are often driven by events external to the
   sending AR, and will thus be asynchronous to any on-going context
   updates. Given that context transfers will take a finite amount of
   time to complete, it is possible that a change in context cannot be
   conveyed in time to the destination AR to avoid any impact on a possible
   handover. The objective of the context transfer design must be to make
   the likelihood of this delay, and its magnitude, as low as possible.


This is not perfect: the desire to avoid a requirement for an extreme degree
of synchronization is only implied by the soft "SHOULD" in 5.5.2.

Regards,
Gary


> -----Original Message-----
> From: James Kempf [mailto:kempf@docomolabs-usa.com]
> Sent: July 14, 2002 18:52
> To: john.loughney@nokia.com; seamoby@ietf.org
> Subject: Re: [Seamoby] Proposal on Sync/NoSync Requirement
>
>
> That sounds better.
>
>             jak
>
> ----- Original Message -----
> From: <john.loughney@nokia.com>
> To: <kempf@docomolabs-usa.com>; <seamoby@ietf.org>
> Sent: Sunday, July 14, 2002 3:01 PM
> Subject: RE: [Seamoby] Proposal on Sync/NoSync Requirement
>
>
> > Hi James,
> >
> > > "Out of scope" is typically WG charter language. I know the
> > > SHOULD/SHOULD NOT sounds a bit funny, but I think we need to
> > > express this in a way that is more requirements language.
> >
> > Then how about changing:
> >
> >       ... the CT solution need
> >       not support it, but it should not provide a
> hinderance to those feature contexts
> >       that do.
> >
> > to:
> >       ... the CT solution is not requireed to directly
> support synchronization, but
> >       may support simple methods for the synchronization
> context for feature contexts
> >       that do.
> >
> > John
> >
>
>
> _______________________________________________
> Seamoby mailing list
> Seamoby@ietf.org
> https://www1.ietf.org/mailman/listinfo/seamoby
>

------_=_NextPart_001_01C22C0F.BF361780-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Mon Jul 15 21:18:45 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA22661 for ; Mon, 15 Jul 2002 21:18:45 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA10468; Mon, 15 Jul 2002 21:17:03 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA10437 for ; Mon, 15 Jul 2002 21:17:01 -0400 (EDT) Received: from fridge.docomolabs-usa.com (fwuser@key1.docomolabs-usa.com [216.98.102.225]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA22554 for ; Mon, 15 Jul 2002 21:16:03 -0400 (EDT) Message-ID: <007801c22c66$3c9cf1c0$256015ac@T23KEMPF> From: "James Kempf" To: "Gary Kenward" , , References: <9FBD322B7824D511B36900508BF93C9C01AA4C1D@zcard031.ca.nortel.com> Subject: Re: [Seamoby] Proposal on Sync/NoSync Requirement Date: Mon, 15 Jul 2002 18:12:27 -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-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit Gary, I'm fine with your proposed changes. Any further comments from the WG? jak ----- Original Message ----- From: "Gary Kenward" To: "'James Kempf'" ; ; Sent: Monday, July 15, 2002 7:56 AM Subject: RE: [Seamoby] Proposal on Sync/NoSync Requirement > I don't think this requirement really resolves much of the issue > that has been under discussion, namely the level of synchronization > that is to be possible using CT. > > CT for updates (as a result of new flows, or flows being discontinued) > is, I think, pretty straightforward. CT for state maintenance where the > state may change while a transfer is in progress is a much harder problem. > > It matters not whether we say that CT solves this latter problem, or > provides > the support mechanisms, the demands that this would impose on the protocol > are extreme. > > We need a requirement that clearly identifies what is meant by CT > synchronization: > > Currently: > > 5.5 Context Update and Synchronization > > 5.5.1 The context transfer protocol MUST be capable of updating > context information when it changes. > > 5.5.2 A context update MUST preserve the integrity, and thus the > meaning, of the context at each receiving AR. > > The context at the AR actually supporting an MN's traffic will > change with time. For example, the MN may initiate new microflow(s), > or discontinue existing microflows. Any change of context at the > supporting AR must be replicated at those ARs that have already > received context for that MN. > > Proposed: > > 5.5 Context Update and Synchronization > > 5.5.1 The context transfer protocol MUST be capable of supporting the > updates to context information when it changes. > > 5.5.2 Context updates SHOULD complete before the context is needed at > the receiving AR. > > The context at the AR actually supporting an MN's traffic will > change with time. For example, the MN may initiate new microflow(s), > or discontinue existing microflows. Any change of context at the > supporting AR must be replicated at those ARs that have already > received context for that MN. > > However, context changes are often driven by events external to the > sending AR, and will thus be asynchronous to any on-going context > updates. Given that context transfers will take a finite amount of > time to complete, it is possible that a change in context cannot be > conveyed in time to the destination AR to avoid any impact on a possible > handover. The objective of the context transfer design must be to make > the likelihood of this delay, and its magnitude, as low as possible. > > > This is not perfect: the desire to avoid a requirement for an extreme degree > of synchronization is only implied by the soft "SHOULD" in 5.5.2. > > Regards, > Gary > > > > -----Original Message----- > > From: James Kempf [mailto:kempf@docomolabs-usa.com] > > Sent: July 14, 2002 18:52 > > To: john.loughney@nokia.com; seamoby@ietf.org > > Subject: Re: [Seamoby] Proposal on Sync/NoSync Requirement > > > > > > That sounds better. > > > > jak > > > > ----- Original Message ----- > > From: > > To: ; > > Sent: Sunday, July 14, 2002 3:01 PM > > Subject: RE: [Seamoby] Proposal on Sync/NoSync Requirement > > > > > > > Hi James, > > > > > > > "Out of scope" is typically WG charter language. I know the > > > > SHOULD/SHOULD NOT sounds a bit funny, but I think we need to > > > > express this in a way that is more requirements language. > > > > > > Then how about changing: > > > > > > ... the CT solution need > > > not support it, but it should not provide a > > hinderance to those feature contexts > > > that do. > > > > > > to: > > > ... the CT solution is not requireed to directly > > support synchronization, but > > > may support simple methods for the synchronization > > context for feature contexts > > > that do. > > > > > > John > > > > > > > > > _______________________________________________ > > 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 From daemon@optimus.ietf.org Mon Jul 15 21:18:46 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA22667 for ; Mon, 15 Jul 2002 21:18:45 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id VAA10594 for seamoby-archive@odin.ietf.org; Mon, 15 Jul 2002 21:19:42 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA10468; Mon, 15 Jul 2002 21:17:03 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA10437 for ; Mon, 15 Jul 2002 21:17:01 -0400 (EDT) Received: from fridge.docomolabs-usa.com (fwuser@key1.docomolabs-usa.com [216.98.102.225]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA22554 for ; Mon, 15 Jul 2002 21:16:03 -0400 (EDT) Message-ID: <007801c22c66$3c9cf1c0$256015ac@T23KEMPF> From: "James Kempf" To: "Gary Kenward" , , References: <9FBD322B7824D511B36900508BF93C9C01AA4C1D@zcard031.ca.nortel.com> Subject: Re: [Seamoby] Proposal on Sync/NoSync Requirement Date: Mon, 15 Jul 2002 18:12:27 -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-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit Gary, I'm fine with your proposed changes. Any further comments from the WG? jak ----- Original Message ----- From: "Gary Kenward" To: "'James Kempf'" ; ; Sent: Monday, July 15, 2002 7:56 AM Subject: RE: [Seamoby] Proposal on Sync/NoSync Requirement > I don't think this requirement really resolves much of the issue > that has been under discussion, namely the level of synchronization > that is to be possible using CT. > > CT for updates (as a result of new flows, or flows being discontinued) > is, I think, pretty straightforward. CT for state maintenance where the > state may change while a transfer is in progress is a much harder problem. > > It matters not whether we say that CT solves this latter problem, or > provides > the support mechanisms, the demands that this would impose on the protocol > are extreme. > > We need a requirement that clearly identifies what is meant by CT > synchronization: > > Currently: > > 5.5 Context Update and Synchronization > > 5.5.1 The context transfer protocol MUST be capable of updating > context information when it changes. > > 5.5.2 A context update MUST preserve the integrity, and thus the > meaning, of the context at each receiving AR. > > The context at the AR actually supporting an MN's traffic will > change with time. For example, the MN may initiate new microflow(s), > or discontinue existing microflows. Any change of context at the > supporting AR must be replicated at those ARs that have already > received context for that MN. > > Proposed: > > 5.5 Context Update and Synchronization > > 5.5.1 The context transfer protocol MUST be capable of supporting the > updates to context information when it changes. > > 5.5.2 Context updates SHOULD complete before the context is needed at > the receiving AR. > > The context at the AR actually supporting an MN's traffic will > change with time. For example, the MN may initiate new microflow(s), > or discontinue existing microflows. Any change of context at the > supporting AR must be replicated at those ARs that have already > received context for that MN. > > However, context changes are often driven by events external to the > sending AR, and will thus be asynchronous to any on-going context > updates. Given that context transfers will take a finite amount of > time to complete, it is possible that a change in context cannot be > conveyed in time to the destination AR to avoid any impact on a possible > handover. The objective of the context transfer design must be to make > the likelihood of this delay, and its magnitude, as low as possible. > > > This is not perfect: the desire to avoid a requirement for an extreme degree > of synchronization is only implied by the soft "SHOULD" in 5.5.2. > > Regards, > Gary > > > > -----Original Message----- > > From: James Kempf [mailto:kempf@docomolabs-usa.com] > > Sent: July 14, 2002 18:52 > > To: john.loughney@nokia.com; seamoby@ietf.org > > Subject: Re: [Seamoby] Proposal on Sync/NoSync Requirement > > > > > > That sounds better. > > > > jak > > > > ----- Original Message ----- > > From: > > To: ; > > Sent: Sunday, July 14, 2002 3:01 PM > > Subject: RE: [Seamoby] Proposal on Sync/NoSync Requirement > > > > > > > Hi James, > > > > > > > "Out of scope" is typically WG charter language. I know the > > > > SHOULD/SHOULD NOT sounds a bit funny, but I think we need to > > > > express this in a way that is more requirements language. > > > > > > Then how about changing: > > > > > > ... the CT solution need > > > not support it, but it should not provide a > > hinderance to those feature contexts > > > that do. > > > > > > to: > > > ... the CT solution is not requireed to directly > > support synchronization, but > > > may support simple methods for the synchronization > > context for feature contexts > > > that do. > > > > > > John > > > > > > > > > _______________________________________________ > > 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 From seamoby-admin@ietf.org Mon Jul 15 22:41:16 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA26044 for ; Mon, 15 Jul 2002 22:41:16 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA15057; Mon, 15 Jul 2002 22:40:07 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA15028 for ; Mon, 15 Jul 2002 22:40:05 -0400 (EDT) Received: from mx1.ustc.edu.cn ([61.132.182.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA25909 for ; Mon, 15 Jul 2002 22:39:08 -0400 (EDT) Received: from luster ([202.38.75.76]) by mx1.ustc.edu.cn (8.8.7/8.8.6) with SMTP id KAA03746 for ; Tue, 16 Jul 2002 10:28:11 +0800 Message-ID: <005b01c22c70$99fd0350$2006a8c0@luster> From: "Wang Hui" To: Date: Tue, 16 Jul 2002 10:29:24 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by optimus.ietf.org id WAA15029 Subject: [Seamoby] Hi, is there a URL acting as seamoby WG drafts center? Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 8bit Hi folks here, I am newbie to seamoby. My interest are focused on working with the CT protocols and machinisms. First thing I want to do is get an overview of what's going on currently in this WG. Now I wonder if there is a web page containing all the drafts of the SEAMOBY WG. I browsed the chapter webpage on ietf.org , but in which there is no the personal drafts. Thanks in advance. best, Wang Hui _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Mon Jul 15 22:41:16 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA26055 for ; Mon, 15 Jul 2002 22:41:16 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id WAA15153 for seamoby-archive@odin.ietf.org; Mon, 15 Jul 2002 22:42:12 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA15057; Mon, 15 Jul 2002 22:40:07 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA15028 for ; Mon, 15 Jul 2002 22:40:05 -0400 (EDT) Received: from mx1.ustc.edu.cn ([61.132.182.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA25909 for ; Mon, 15 Jul 2002 22:39:08 -0400 (EDT) Received: from luster ([202.38.75.76]) by mx1.ustc.edu.cn (8.8.7/8.8.6) with SMTP id KAA03746 for ; Tue, 16 Jul 2002 10:28:11 +0800 Message-ID: <005b01c22c70$99fd0350$2006a8c0@luster> From: "Wang Hui" To: Date: Tue, 16 Jul 2002 10:29:24 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by optimus.ietf.org id WAA15029 Subject: [Seamoby] Hi, is there a URL acting as seamoby WG drafts center? Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 8bit Hi folks here, I am newbie to seamoby. My interest are focused on working with the CT protocols and machinisms. First thing I want to do is get an overview of what's going on currently in this WG. Now I wonder if there is a web page containing all the drafts of the SEAMOBY WG. I browsed the chapter webpage on ietf.org , but in which there is no the personal drafts. Thanks in advance. best, Wang Hui _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Tue Jul 16 01:37:49 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA00167 for ; Tue, 16 Jul 2002 01:37:49 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA02302; Tue, 16 Jul 2002 01:33:41 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA02273 for ; Tue, 16 Jul 2002 01:33:38 -0400 (EDT) Received: from wusr3 (sdsl-64-139-4-113.dsl.sca.megapath.net [64.139.4.113]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA29975 for ; Tue, 16 Jul 2002 01:32:40 -0400 (EDT) Received: from obsoft.com (IDENT:dsardana@localhost [127.0.0.1]) by wusr3 (8.9.3/8.9.3) with ESMTP id WAA29235; Mon, 15 Jul 2002 22:51:03 -0700 Message-ID: <3D33B447.67A1AF39@obsoft.com> Date: Mon, 15 Jul 2002 22:51:03 -0700 From: Bobby Sardana Organization: ObjectSoftware, Inc. X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14-5.0 i686) X-Accept-Language: en MIME-Version: 1.0 To: Wang Hui CC: seamoby@ietf.org Subject: Re: [Seamoby] Hi, is there a URL acting as seamoby WG drafts center? References: <005b01c22c70$99fd0350$2006a8c0@luster> Content-Type: multipart/mixed; boundary="------------446FC1622441D398B98A3C5E" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org This is a multi-part message in MIME format. --------------446FC1622441D398B98A3C5E Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit See if the following provides what you seek: http://carmen.ipv6.cselt.it/idxwg/seamoby.html regards, Bobby Sardana. sardana@obsoft.com Wang Hui wrote: > Hi folks here, I am newbie to seamoby. My interest are focused on working with the CT protocols and machinisms. > > First thing I want to do is get an overview of what's going on currently in this WG. Now I wonder if there is a web page containing all the drafts of the SEAMOBY WG. I browsed the chapter webpage on ietf.org , but in which there is no the personal drafts. > > Thanks in advance. > > best, > Wang Hui > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby --------------446FC1622441D398B98A3C5E Content-Type: text/x-vcard; charset=us-ascii; name="sardana.vcf" Content-Description: Card for Bobby Sardana Content-Disposition: attachment; filename="sardana.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Sardana;Bobby x-mozilla-html:FALSE org:ObjectSoftware, Inc.;R & D adr:;;;;;; version:2.1 email;internet:sardana@obsoft.com title:Engineer x-mozilla-cpt:;4320 fn:Bobby Sardana end:vcard --------------446FC1622441D398B98A3C5E-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Tue Jul 16 01:37:50 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA00179 for ; Tue, 16 Jul 2002 01:37:50 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id BAA02450 for seamoby-archive@odin.ietf.org; Tue, 16 Jul 2002 01:38:47 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA02302; Tue, 16 Jul 2002 01:33:41 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA02273 for ; Tue, 16 Jul 2002 01:33:38 -0400 (EDT) Received: from wusr3 (sdsl-64-139-4-113.dsl.sca.megapath.net [64.139.4.113]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA29975 for ; Tue, 16 Jul 2002 01:32:40 -0400 (EDT) Received: from obsoft.com (IDENT:dsardana@localhost [127.0.0.1]) by wusr3 (8.9.3/8.9.3) with ESMTP id WAA29235; Mon, 15 Jul 2002 22:51:03 -0700 Message-ID: <3D33B447.67A1AF39@obsoft.com> Date: Mon, 15 Jul 2002 22:51:03 -0700 From: Bobby Sardana Organization: ObjectSoftware, Inc. X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14-5.0 i686) X-Accept-Language: en MIME-Version: 1.0 To: Wang Hui CC: seamoby@ietf.org Subject: Re: [Seamoby] Hi, is there a URL acting as seamoby WG drafts center? References: <005b01c22c70$99fd0350$2006a8c0@luster> Content-Type: multipart/mixed; boundary="------------446FC1622441D398B98A3C5E" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org This is a multi-part message in MIME format. --------------446FC1622441D398B98A3C5E Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit See if the following provides what you seek: http://carmen.ipv6.cselt.it/idxwg/seamoby.html regards, Bobby Sardana. sardana@obsoft.com Wang Hui wrote: > Hi folks here, I am newbie to seamoby. My interest are focused on working with the CT protocols and machinisms. > > First thing I want to do is get an overview of what's going on currently in this WG. Now I wonder if there is a web page containing all the drafts of the SEAMOBY WG. I browsed the chapter webpage on ietf.org , but in which there is no the personal drafts. > > Thanks in advance. > > best, > Wang Hui > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby --------------446FC1622441D398B98A3C5E Content-Type: text/x-vcard; charset=us-ascii; name="sardana.vcf" Content-Description: Card for Bobby Sardana Content-Disposition: attachment; filename="sardana.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Sardana;Bobby x-mozilla-html:FALSE org:ObjectSoftware, Inc.;R & D adr:;;;;;; version:2.1 email;internet:sardana@obsoft.com title:Engineer x-mozilla-cpt:;4320 fn:Bobby Sardana end:vcard --------------446FC1622441D398B98A3C5E-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Tue Jul 16 02:55:31 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA11739 for ; Tue, 16 Jul 2002 02:55:31 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA06580; Tue, 16 Jul 2002 02:54:47 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA06548 for ; Tue, 16 Jul 2002 02:54:45 -0400 (EDT) Received: from fridge.docomolabs-usa.com (fwuser@key1.docomolabs-usa.com [216.98.102.225]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA11700 for ; Tue, 16 Jul 2002 02:53:46 -0400 (EDT) Message-ID: <004801c22c95$66aeb4b0$8e6015ac@T23KEMPF> From: "James Kempf" To: "Wang Hui" , References: <005b01c22c70$99fd0350$2006a8c0@luster> Subject: Re: [Seamoby] Hi, is there a URL acting as seamoby WG drafts center? Date: Mon, 15 Jul 2002 23:50:57 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit Only WG drafts are allowed on the Web page. If you want to find personal drafts, go to the drafts page and search for "seamoby". jak ----- Original Message ----- From: "Wang Hui" To: Sent: Monday, July 15, 2002 7:29 PM Subject: [Seamoby] Hi, is there a URL acting as seamoby WG drafts center? > Hi folks here, I am newbie to seamoby. My interest are focused on working with the CT protocols and machinisms. > > First thing I want to do is get an overview of what's going on currently in this WG. Now I wonder if there is a web page containing all the drafts of the SEAMOBY WG. I browsed the chapter webpage on ietf.org , but in which there is no the personal drafts. > > Thanks in advance. > > best, > Wang Hui > > _______________________________________________ > 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 From daemon@optimus.ietf.org Tue Jul 16 02:55:31 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA11747 for ; Tue, 16 Jul 2002 02:55:31 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id CAA06749 for seamoby-archive@odin.ietf.org; Tue, 16 Jul 2002 02:56:29 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA06580; Tue, 16 Jul 2002 02:54:47 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA06548 for ; Tue, 16 Jul 2002 02:54:45 -0400 (EDT) Received: from fridge.docomolabs-usa.com (fwuser@key1.docomolabs-usa.com [216.98.102.225]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA11700 for ; Tue, 16 Jul 2002 02:53:46 -0400 (EDT) Message-ID: <004801c22c95$66aeb4b0$8e6015ac@T23KEMPF> From: "James Kempf" To: "Wang Hui" , References: <005b01c22c70$99fd0350$2006a8c0@luster> Subject: Re: [Seamoby] Hi, is there a URL acting as seamoby WG drafts center? Date: Mon, 15 Jul 2002 23:50:57 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit Only WG drafts are allowed on the Web page. If you want to find personal drafts, go to the drafts page and search for "seamoby". jak ----- Original Message ----- From: "Wang Hui" To: Sent: Monday, July 15, 2002 7:29 PM Subject: [Seamoby] Hi, is there a URL acting as seamoby WG drafts center? > Hi folks here, I am newbie to seamoby. My interest are focused on working with the CT protocols and machinisms. > > First thing I want to do is get an overview of what's going on currently in this WG. Now I wonder if there is a web page containing all the drafts of the SEAMOBY WG. I browsed the chapter webpage on ietf.org , but in which there is no the personal drafts. > > Thanks in advance. > > best, > Wang Hui > > _______________________________________________ > 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 From seamoby-admin@ietf.org Wed Jul 17 14:25:19 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25913 for ; Wed, 17 Jul 2002 14:25:19 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA20216; Wed, 17 Jul 2002 14:23:45 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA20185 for ; Wed, 17 Jul 2002 14:23:43 -0400 (EDT) Received: from odin.ietf.org ([64.86.155.135]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA25814 for ; Wed, 17 Jul 2002 14:22:42 -0400 (EDT) Message-Id: <200207171822.OAA25814@ietf.org> From: "MR. WILLIAM DURU" Date: Wed, 17 Jul 2002 07:50:22 To: seamoby@ietf.org MIME-Version: 1.0 Content-Type: text/plain;charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Seamoby] GOOD DAY FROM MR. WILLIAM DURU Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit CHALLENGE SECURITIES LTD. LAGOS, NIGERIA phone:234-803-3004455. ATTENTION:SIR/MADAM I am MR. WILLIAM DURU, the Director of Operations CHALLENGE SECURITIES LTD,LAGOS NIGERIA. Here in NIGERIA Our firm is a security company of high repute with years of outstanding service to the people of Africa. I have resolved to contact you through this medium based on business proposal that will be of mutual benefit to both of us. I got your particulars through a consultant company base on my research for a trustworthy and established person that understands investment ethic for entering into a life time profitable joint partnership investment and also co-operation with confidence and trust that you will keep the contents secret and divulged to any third party. To be explicit and straight to the point. Some time early 1997, a reputable client of ours deposited a consignment in our company\'s vault for safe keeping. And since then our client has failed to come forward to claim his consignment, which has accumulated a considerable amount of money in demurrage. Consequently, in our bide to contact this client to redeem the demurrage which his consignment had accumulated we discovered that our client was the former president of the Federal Republic of Zaire, who died of illness after he was de-throwed in the same year the consignment was entrusted into our care. Since the death of our client President Mobutou Seseseko, none of his benefactors has come forward to claim the consignment with us, which means that non of his relatives or aids had any knowledge of this consignment. Hence out of curiosity I decided to secretly open the two boxes that our client deposited in our vault. And to my surprise I discovered that the two boxes that were registered as treasurer by our client actually contained a considerable amount of money in United States Dollars amounting to about US$30 million Dollar. Since this development I have been nursing plans secretly. I also found out from enquiries and the foreign media that our late client siphoned a lot of money from his country while he was in office as head of state. It is my conviction that the consignment in our vault was part of the money that our client siphoned and now that he is dead there is no race to this money in our care. I am now soliciting your noble assistance to assist me in transferring this money out of nigeria to your country for immediate investment with your assistance. I have also decided that you will generously be entitled to 30% of the total amount. Upon my receipt of your reply confirming your willingness to assist me of this transaction, I will immediately arrange and transfer all the rights of ownership of this consignment to your name to facilitate your easy clearance and transfer of the complete funds to your country. you have nothing to worry about, as I will be there to assist you in anyway necessary with all proper documentation. This transaction is 100% risk free. Please maintain absolute confidentiality on this matter. Please reply to the above email address with your telephone and fax so can call you. Thanks. Yours faithfully. MR. WILLIAM DURU _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Wed Jul 17 15:11:34 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25920 for ; Wed, 17 Jul 2002 14:25:20 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA20553 for seamoby-archive@odin.ietf.org; Wed, 17 Jul 2002 14:26:17 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA20216; Wed, 17 Jul 2002 14:23:45 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA20185 for ; Wed, 17 Jul 2002 14:23:43 -0400 (EDT) Received: from odin.ietf.org ([64.86.155.135]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA25814 for ; Wed, 17 Jul 2002 14:22:42 -0400 (EDT) Message-Id: <200207171822.OAA25814@ietf.org> From: "MR. WILLIAM DURU" Date: Wed, 17 Jul 2002 07:50:22 To: seamoby@ietf.org MIME-Version: 1.0 Content-Type: text/plain;charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Seamoby] GOOD DAY FROM MR. WILLIAM DURU Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit CHALLENGE SECURITIES LTD. LAGOS, NIGERIA phone:234-803-3004455. ATTENTION:SIR/MADAM I am MR. WILLIAM DURU, the Director of Operations CHALLENGE SECURITIES LTD,LAGOS NIGERIA. Here in NIGERIA Our firm is a security company of high repute with years of outstanding service to the people of Africa. I have resolved to contact you through this medium based on business proposal that will be of mutual benefit to both of us. I got your particulars through a consultant company base on my research for a trustworthy and established person that understands investment ethic for entering into a life time profitable joint partnership investment and also co-operation with confidence and trust that you will keep the contents secret and divulged to any third party. To be explicit and straight to the point. Some time early 1997, a reputable client of ours deposited a consignment in our company\'s vault for safe keeping. And since then our client has failed to come forward to claim his consignment, which has accumulated a considerable amount of money in demurrage. Consequently, in our bide to contact this client to redeem the demurrage which his consignment had accumulated we discovered that our client was the former president of the Federal Republic of Zaire, who died of illness after he was de-throwed in the same year the consignment was entrusted into our care. Since the death of our client President Mobutou Seseseko, none of his benefactors has come forward to claim the consignment with us, which means that non of his relatives or aids had any knowledge of this consignment. Hence out of curiosity I decided to secretly open the two boxes that our client deposited in our vault. And to my surprise I discovered that the two boxes that were registered as treasurer by our client actually contained a considerable amount of money in United States Dollars amounting to about US$30 million Dollar. Since this development I have been nursing plans secretly. I also found out from enquiries and the foreign media that our late client siphoned a lot of money from his country while he was in office as head of state. It is my conviction that the consignment in our vault was part of the money that our client siphoned and now that he is dead there is no race to this money in our care. I am now soliciting your noble assistance to assist me in transferring this money out of nigeria to your country for immediate investment with your assistance. I have also decided that you will generously be entitled to 30% of the total amount. Upon my receipt of your reply confirming your willingness to assist me of this transaction, I will immediately arrange and transfer all the rights of ownership of this consignment to your name to facilitate your easy clearance and transfer of the complete funds to your country. you have nothing to worry about, as I will be there to assist you in anyway necessary with all proper documentation. This transaction is 100% risk free. Please maintain absolute confidentiality on this matter. Please reply to the above email address with your telephone and fax so can call you. Thanks. Yours faithfully. MR. WILLIAM DURU _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Jul 17 19:24:52 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA02282 for ; Wed, 17 Jul 2002 19:24:52 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA06735; Wed, 17 Jul 2002 19:22:11 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA06708 for ; Wed, 17 Jul 2002 19:22:09 -0400 (EDT) Received: from motgate3.mot.com (motgate3.mot.com [144.189.100.103]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA02222 for ; Wed, 17 Jul 2002 19:21:12 -0400 (EDT) Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate3.mot.com (motgate3 2.1) with ESMTP id QAA22954 for ; Wed, 17 Jul 2002 16:21:07 -0700 (MST)] Received: [from il27exb01.cig.mot.com (il27exb01.cig.mot.com [136.182.15.100]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id QAA19779 for ; Wed, 17 Jul 2002 16:22:08 -0700 (MST)] Received: by il27exb01.cig.mot.com with Internet Mail Service (5.5.2654.52) id ; Wed, 17 Jul 2002 18:22:08 -0500 Message-ID: <35DBB8B7AC89D4118E98009027B1009B08AD55B7@IL27EXM10.cig.mot.com> From: Nakhjiri Madjid-MNAKHJI1 To: "'Charles E. Perkins'" , Gary Kenward Cc: seamoby@ietf.org Subject: RE: [Seamoby] CT Requirements Comments from IESG Date: Wed, 17 Jul 2002 18:22:07 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.52) Content-Type: text/plain Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Sorry for coming in too late and I haven't gone through the rest of emails so I hope I am not repeating somebody's point. I agree with Charlie that once the context gets to newAR, the job of CT is done. otherwise the oldAR needs to know about the data path, propagation delay and all sorts of things. We are really worried about dynamic context, we can simply have the old AR add lifetime info into the latest context data and let the newAR decide whether it needs a refresh or not, and don't make it the responsibility of oldAR to guess the validity of context at the time of arrival at new AR We should not forget that CT is optimization for handover, trying to reduce the latency, we can't keep on sending refreshes and retransmissions forever. Madjid -----Original Message----- From: Charles E. Perkins [mailto:charliep@iprg.nokia.com] Sent: Friday, July 12, 2002 11:15 AM To: Gary Kenward Cc: seamoby@ietf.org Subject: Re: [Seamoby] CT Requirements Comments from IESG Hello folks, I think we ought to try to get context transfers working correctly without initially worrying about this synchronization problem. In the instances I am familiar with, it is not required. The most stringent case seems to be ROHC, and even for that it is not necessary. We can solve the most urgent problems without having to deal with any additional context synchronization. When the old AR sends it, and the new AR gets it, we should consider the transfer done. In those cases where reliability is at issue, the old AR can retransmit when ACK is not received. In many cases, retransmission of context even once won't be useful. Regards, Charlie P. > Gary Kenward wrote: > > James: > > Yes, we need to fix it, and I think it is doable. > Thanks to Dirk for highlighting the real problem here > (I think historically, the integrity requirement came out > of the reliability section, and somehow, got lumped with > synchronization and updates). > > I think the requirements need a bit of rewording, and > the paragraph should fall out from this. I do believe > however, that making the synchronization of context between > old and new AR a MUST requirement would be too extreme, and > result in a brittle solution. CT should certainly do it's best to > provide synchronization, but as was discussed in a recent > exchange, it would be impossible to guarantee synchronization > at any instant. > > Any ideas/comments from the wg? > > Gary > > > -----Original Message----- > > From: James Kempf [mailto:kempf@docomolabs-usa.com] > > Sent: July 11, 2002 18:32 > > To: Kenward, Gary [WDLN2:AN10:EXCH]; Dirk.Trossen@nokia.com; > > seamoby@ietf.org > > Subject: Re: [Seamoby] CT Requirements Comments from IESG > > > > > > Gary/Dirk, > > > > I think you may be on to something here. I think this might > > be what the IESG was talking about it the first point, namely the > > lack of discussion of dynamic changes in the context. > > > > Is there some way we could cook this idea down into a > > paragraph that we could insert for this requirement? > > > > jak > > > > ----- Original Message ----- > > From: "Gary Kenward" > > To: ; ; > > > > Sent: Thursday, July 11, 2002 1:56 PM > > Subject: RE: [Seamoby] CT Requirements Comments from IESG > > > > > > > Dirk: > > > > > > A valid point. There is a certain atomic level of > > granularity which has to > > > be > > > dealt with - that is, there's no protocol in the world that > > can synchronize > > > changes in > > > information that occur at the source while the information > > is "in-flight" or > > > being > > > received at the destination. If changes in context while > > the context is > > > being transferred > > > make a different to the successful performance of CT, then > > there is no hope. > > > > > > The problem is most significant for state context > > transfer. E.g. counters > > > will continue > > > to count while CT is moving the context to the destination. > > Either these > > > changes have no > > > significant impact upon the forwarding service provided at > > the new AR (e.g. > > > it may not > > > matter that a policing meter misses a few packet counts), > > or a different > > > mechanism > > > has to be defined for re-establishing the state context. > > > > > > The handover is real and unavoidable. Mitigating the > > disruption to the > > > service at the new > > > AR is the challenge. It would be nice if the disruption was nil, but > > > unlikely. > > > > > > Gary > > > > > > -----Original Message----- > > > From: Dirk.Trossen@nokia.com [mailto:Dirk.Trossen@nokia.com] > > > Sent: July 11, 2002 16:30 > > > To: Kenward, Gary [WDLN2:AN10:EXCH]; kempf@docomolabs-usa.com; > > > seamoby@ietf.org > > > Subject: RE: [Seamoby] CT Requirements Comments from IESG > > > > > > > > > Hi all, > > > > > > jumping in as somebody who has been an observer so far, > > struggling with the > > > current discussion on > > > 'integrity'. > > > > > > When I look at the current wording, i.e., > > > "5.5.2 A context update MUST preserve the integrity, and > > thus the meaning, > > > of the context > > > at each receiving AR. The context at the AR actually > > supporting an MN's > > > traffic will change with time. > > > For example, the MN may initiate new microflow(s), or > > discontinue existing > > > microflows. Any change of context > > > at the supporting AR must be replicated at those ARs that > > have already > > > received context for that MN.", > > > > > > and compare this to the plain integrity of the actually > > transmitted data > > > (i.e., its bits and therefore its semantics) > > > that has been brought to the table as a replacement now, > > I'm quite confident > > > that this is not what the requirement > > > is talking about. > > > > > > If we remove the word 'meaning' (which is very vague and free for > > > interpretation for me as well), it is still the word > > > 'integrity' left, which is more than plain integrity of the > > transmitted > > > data, in particular if we look at the following sentences > > > in the requirement, which state what kind of integrity is > > meant (which > > > probably also builds the bridge to the vague > > > term 'meaning'), namely that the integrity of a context > > must be preserved in > > > the sense that a received context at new > > > AR at some point t must be the same as the context at old > > AR at the same > > > time t. This is by far more than plain data > > > integrity of the transmitted data. Even if your data has > > been transmitted > > > correctly, the context might be stale (and therefore > > > its integrity is lost) because it had changed at old AR in > > the meanwhile. > > > The action to be taken is also given in the text, > > > namely the change of context has to be replicated to the > > new AR. As you can > > > (hopefully) see this is by far more than > > > preserving the 'meaning' of each bit. It mandates that > > changes in the bit > > > values at one end are reflected at the other > > > end, i.e., it talks about distributed data integrity in my > > interpretation of > > > the requirement text. > > > > > > Hence, the actual concern might have been (just guessing) > > whether or not it > > > is the task of the CT protocol to > > > preserve the abovementioned integrity. Maybe, the IESG > > wants to see this > > > functionality left to the replication logic that resides > > > within each AR. Or on the contrary, they do not see this > > important topic > > > covered appropriately. > > > > > > Regards, > > > > > > > > > Dirk > > > > > > -----Original Message----- > > > From: ext Gary Kenward [mailto:gkenward@nortelnetworks.com] > > > Sent: Thursday, July 11, 2002 3:48 PM > > > To: 'James Kempf'; seamoby@ietf.org > > > Subject: RE: [Seamoby] CT Requirements Comments from IESG > > > > > > > > > > > > You call it fidelity, I call it data integrity. > > > I've seen "data integrity" used in publications > > > (no, I cannot quote references). > > > > > > What we need is a term that everyone, including the > > > IESG, can agree upon. > > > > > > > -----Original Message----- > > > > From: James Kempf [ mailto:kempf@docomolabs-usa.com > > > ] > > > > Sent: July 11, 2002 12:22 > > > > To: Kenward, Gary [WDLN2:AN10:EXCH]; seamoby@ietf.org > > > > Subject: Re: [Seamoby] CT Requirements Comments from IESG > > > > > > > > > > > > > Perhaps the actual answer is to state exactly what was intended > > > > > originally: that the bit order and bit values have to > > arrive exactly > > > > > as they were transmitted. > > > > > > > > > > > > > So this requirement is talking about transmission fidelity? I > > > > sure would not have guessed that from reading it. I thought it > > > > intended to talk about usability. > > > > > > > > I would suggest that the wording you have above is really a > > > > lot more precise that what is currently in the spec. > > > > > > > > Any other comments? Could we substitute Gary's wording above > > > > for "meaning" in the current requirement. > > > > > > > > jak > > > > > > > > > > > > > > > > > > _______________________________________________ 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 From daemon@optimus.ietf.org Wed Jul 17 19:24:52 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA02289 for ; Wed, 17 Jul 2002 19:24:52 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id TAA06946 for seamoby-archive@odin.ietf.org; Wed, 17 Jul 2002 19:25:49 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA06735; Wed, 17 Jul 2002 19:22:11 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA06708 for ; Wed, 17 Jul 2002 19:22:09 -0400 (EDT) Received: from motgate3.mot.com (motgate3.mot.com [144.189.100.103]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA02222 for ; Wed, 17 Jul 2002 19:21:12 -0400 (EDT) Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate3.mot.com (motgate3 2.1) with ESMTP id QAA22954 for ; Wed, 17 Jul 2002 16:21:07 -0700 (MST)] Received: [from il27exb01.cig.mot.com (il27exb01.cig.mot.com [136.182.15.100]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id QAA19779 for ; Wed, 17 Jul 2002 16:22:08 -0700 (MST)] Received: by il27exb01.cig.mot.com with Internet Mail Service (5.5.2654.52) id ; Wed, 17 Jul 2002 18:22:08 -0500 Message-ID: <35DBB8B7AC89D4118E98009027B1009B08AD55B7@IL27EXM10.cig.mot.com> From: Nakhjiri Madjid-MNAKHJI1 To: "'Charles E. Perkins'" , Gary Kenward Cc: seamoby@ietf.org Subject: RE: [Seamoby] CT Requirements Comments from IESG Date: Wed, 17 Jul 2002 18:22:07 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.52) Content-Type: text/plain Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Sorry for coming in too late and I haven't gone through the rest of emails so I hope I am not repeating somebody's point. I agree with Charlie that once the context gets to newAR, the job of CT is done. otherwise the oldAR needs to know about the data path, propagation delay and all sorts of things. We are really worried about dynamic context, we can simply have the old AR add lifetime info into the latest context data and let the newAR decide whether it needs a refresh or not, and don't make it the responsibility of oldAR to guess the validity of context at the time of arrival at new AR We should not forget that CT is optimization for handover, trying to reduce the latency, we can't keep on sending refreshes and retransmissions forever. Madjid -----Original Message----- From: Charles E. Perkins [mailto:charliep@iprg.nokia.com] Sent: Friday, July 12, 2002 11:15 AM To: Gary Kenward Cc: seamoby@ietf.org Subject: Re: [Seamoby] CT Requirements Comments from IESG Hello folks, I think we ought to try to get context transfers working correctly without initially worrying about this synchronization problem. In the instances I am familiar with, it is not required. The most stringent case seems to be ROHC, and even for that it is not necessary. We can solve the most urgent problems without having to deal with any additional context synchronization. When the old AR sends it, and the new AR gets it, we should consider the transfer done. In those cases where reliability is at issue, the old AR can retransmit when ACK is not received. In many cases, retransmission of context even once won't be useful. Regards, Charlie P. > Gary Kenward wrote: > > James: > > Yes, we need to fix it, and I think it is doable. > Thanks to Dirk for highlighting the real problem here > (I think historically, the integrity requirement came out > of the reliability section, and somehow, got lumped with > synchronization and updates). > > I think the requirements need a bit of rewording, and > the paragraph should fall out from this. I do believe > however, that making the synchronization of context between > old and new AR a MUST requirement would be too extreme, and > result in a brittle solution. CT should certainly do it's best to > provide synchronization, but as was discussed in a recent > exchange, it would be impossible to guarantee synchronization > at any instant. > > Any ideas/comments from the wg? > > Gary > > > -----Original Message----- > > From: James Kempf [mailto:kempf@docomolabs-usa.com] > > Sent: July 11, 2002 18:32 > > To: Kenward, Gary [WDLN2:AN10:EXCH]; Dirk.Trossen@nokia.com; > > seamoby@ietf.org > > Subject: Re: [Seamoby] CT Requirements Comments from IESG > > > > > > Gary/Dirk, > > > > I think you may be on to something here. I think this might > > be what the IESG was talking about it the first point, namely the > > lack of discussion of dynamic changes in the context. > > > > Is there some way we could cook this idea down into a > > paragraph that we could insert for this requirement? > > > > jak > > > > ----- Original Message ----- > > From: "Gary Kenward" > > To: ; ; > > > > Sent: Thursday, July 11, 2002 1:56 PM > > Subject: RE: [Seamoby] CT Requirements Comments from IESG > > > > > > > Dirk: > > > > > > A valid point. There is a certain atomic level of > > granularity which has to > > > be > > > dealt with - that is, there's no protocol in the world that > > can synchronize > > > changes in > > > information that occur at the source while the information > > is "in-flight" or > > > being > > > received at the destination. If changes in context while > > the context is > > > being transferred > > > make a different to the successful performance of CT, then > > there is no hope. > > > > > > The problem is most significant for state context > > transfer. E.g. counters > > > will continue > > > to count while CT is moving the context to the destination. > > Either these > > > changes have no > > > significant impact upon the forwarding service provided at > > the new AR (e.g. > > > it may not > > > matter that a policing meter misses a few packet counts), > > or a different > > > mechanism > > > has to be defined for re-establishing the state context. > > > > > > The handover is real and unavoidable. Mitigating the > > disruption to the > > > service at the new > > > AR is the challenge. It would be nice if the disruption was nil, but > > > unlikely. > > > > > > Gary > > > > > > -----Original Message----- > > > From: Dirk.Trossen@nokia.com [mailto:Dirk.Trossen@nokia.com] > > > Sent: July 11, 2002 16:30 > > > To: Kenward, Gary [WDLN2:AN10:EXCH]; kempf@docomolabs-usa.com; > > > seamoby@ietf.org > > > Subject: RE: [Seamoby] CT Requirements Comments from IESG > > > > > > > > > Hi all, > > > > > > jumping in as somebody who has been an observer so far, > > struggling with the > > > current discussion on > > > 'integrity'. > > > > > > When I look at the current wording, i.e., > > > "5.5.2 A context update MUST preserve the integrity, and > > thus the meaning, > > > of the context > > > at each receiving AR. The context at the AR actually > > supporting an MN's > > > traffic will change with time. > > > For example, the MN may initiate new microflow(s), or > > discontinue existing > > > microflows. Any change of context > > > at the supporting AR must be replicated at those ARs that > > have already > > > received context for that MN.", > > > > > > and compare this to the plain integrity of the actually > > transmitted data > > > (i.e., its bits and therefore its semantics) > > > that has been brought to the table as a replacement now, > > I'm quite confident > > > that this is not what the requirement > > > is talking about. > > > > > > If we remove the word 'meaning' (which is very vague and free for > > > interpretation for me as well), it is still the word > > > 'integrity' left, which is more than plain integrity of the > > transmitted > > > data, in particular if we look at the following sentences > > > in the requirement, which state what kind of integrity is > > meant (which > > > probably also builds the bridge to the vague > > > term 'meaning'), namely that the integrity of a context > > must be preserved in > > > the sense that a received context at new > > > AR at some point t must be the same as the context at old > > AR at the same > > > time t. This is by far more than plain data > > > integrity of the transmitted data. Even if your data has > > been transmitted > > > correctly, the context might be stale (and therefore > > > its integrity is lost) because it had changed at old AR in > > the meanwhile. > > > The action to be taken is also given in the text, > > > namely the change of context has to be replicated to the > > new AR. As you can > > > (hopefully) see this is by far more than > > > preserving the 'meaning' of each bit. It mandates that > > changes in the bit > > > values at one end are reflected at the other > > > end, i.e., it talks about distributed data integrity in my > > interpretation of > > > the requirement text. > > > > > > Hence, the actual concern might have been (just guessing) > > whether or not it > > > is the task of the CT protocol to > > > preserve the abovementioned integrity. Maybe, the IESG > > wants to see this > > > functionality left to the replication logic that resides > > > within each AR. Or on the contrary, they do not see this > > important topic > > > covered appropriately. > > > > > > Regards, > > > > > > > > > Dirk > > > > > > -----Original Message----- > > > From: ext Gary Kenward [mailto:gkenward@nortelnetworks.com] > > > Sent: Thursday, July 11, 2002 3:48 PM > > > To: 'James Kempf'; seamoby@ietf.org > > > Subject: RE: [Seamoby] CT Requirements Comments from IESG > > > > > > > > > > > > You call it fidelity, I call it data integrity. > > > I've seen "data integrity" used in publications > > > (no, I cannot quote references). > > > > > > What we need is a term that everyone, including the > > > IESG, can agree upon. > > > > > > > -----Original Message----- > > > > From: James Kempf [ mailto:kempf@docomolabs-usa.com > > > ] > > > > Sent: July 11, 2002 12:22 > > > > To: Kenward, Gary [WDLN2:AN10:EXCH]; seamoby@ietf.org > > > > Subject: Re: [Seamoby] CT Requirements Comments from IESG > > > > > > > > > > > > > Perhaps the actual answer is to state exactly what was intended > > > > > originally: that the bit order and bit values have to > > arrive exactly > > > > > as they were transmitted. > > > > > > > > > > > > > So this requirement is talking about transmission fidelity? I > > > > sure would not have guessed that from reading it. I thought it > > > > intended to talk about usability. > > > > > > > > I would suggest that the wording you have above is really a > > > > lot more precise that what is currently in the spec. > > > > > > > > Any other comments? Could we substitute Gary's wording above > > > > for "meaning" in the current requirement. > > > > > > > > jak > > > > > > > > > > > > > > > > > > _______________________________________________ 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 From seamoby-admin@ietf.org Wed Jul 17 19:27:11 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA02320 for ; Wed, 17 Jul 2002 19:27:11 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA06901; Wed, 17 Jul 2002 19:24:53 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA06833 for ; Wed, 17 Jul 2002 19:24:49 -0400 (EDT) Received: from motgate4.mot.com (motgate4.mot.com [144.189.100.102]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA02269 for ; Wed, 17 Jul 2002 19:23:52 -0400 (EDT) Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate4.mot.com (motgate4 2.1) with ESMTP id QAA11536 for ; Wed, 17 Jul 2002 16:24:49 -0700 (MST)] Received: [from il27exb01.cig.mot.com (il27exb01.cig.mot.com [136.182.15.100]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id QAA20383 for ; Wed, 17 Jul 2002 16:24:48 -0700 (MST)] Received: by il27exb01.cig.mot.com with Internet Mail Service (5.5.2654.52) id ; Wed, 17 Jul 2002 18:24:48 -0500 Message-ID: <35DBB8B7AC89D4118E98009027B1009B08AD55B8@IL27EXM10.cig.mot.com> From: Nakhjiri Madjid-MNAKHJI1 To: "'Gary Kenward'" , "'Charles E. Perkins'" Cc: seamoby@ietf.org Subject: RE: [Seamoby] CT Requirements Comments from IESG Date: Wed, 17 Jul 2002 18:24:48 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.52) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C22DE9.249BDEE0" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C22DE9.249BDEE0 Content-Type: text/plain; charset="iso-8859-1" Well, not trying to regurgitate (as you said) but we never agreed on timing and reliability requirements and maybe that was ok, because they depend on the scenario and protocols. So why talk about sending updates after CT is done? Madjid -----Original Message----- From: Gary Kenward [mailto:gkenward@nortelnetworks.com] Sent: Friday, July 12, 2002 2:35 PM To: 'Charles E. Perkins' Cc: seamoby@ietf.org Subject: RE: [Seamoby] CT Requirements Comments from IESG I agree Charlie. However, we have to fix the issue with the requirements. Are you suggesting that we relax the requirement? By how much - clearly, some updates are required (e.g. CT really should try and update when flows come and go). Gary > -----Original Message----- > From: Charles E. Perkins [ mailto:charliep@iprg.nokia.com ] > Sent: July 12, 2002 12:15 > To: Kenward, Gary [WDLN2:AN10:EXCH] > Cc: seamoby@ietf.org > Subject: Re: [Seamoby] CT Requirements Comments from IESG > > > > > Hello folks, > > I think we ought to try to get context transfers > working correctly without initially worrying about > this synchronization problem. > > In the instances I am familiar with, it is not > required. The most stringent case seems to be > ROHC, and even for that it is not necessary. > > We can solve the most urgent problems without having > to deal with any additional context synchronization. > When the old AR sends it, and the new AR gets it, > we should consider the transfer done. In those > cases where reliability is at issue, the old AR > can retransmit when ACK is not received. In many > cases, retransmission of context even once won't > be useful. > > Regards, > Charlie P. > > > > > Gary Kenward wrote: > > > > James: > > > > Yes, we need to fix it, and I think it is doable. > > Thanks to Dirk for highlighting the real problem here > > (I think historically, the integrity requirement came out > > of the reliability section, and somehow, got lumped with > > synchronization and updates). > > > > I think the requirements need a bit of rewording, and > > the paragraph should fall out from this. I do believe > > however, that making the synchronization of context between > > old and new AR a MUST requirement would be too extreme, and > > result in a brittle solution. CT should certainly do it's best to > > provide synchronization, but as was discussed in a recent > > exchange, it would be impossible to guarantee synchronization > > at any instant. > > > > Any ideas/comments from the wg? > > > > Gary > > > > > -----Original Message----- > > > From: James Kempf [ mailto:kempf@docomolabs-usa.com ] > > > Sent: July 11, 2002 18:32 > > > To: Kenward, Gary [WDLN2:AN10:EXCH]; Dirk.Trossen@nokia.com; > > > seamoby@ietf.org > > > Subject: Re: [Seamoby] CT Requirements Comments from IESG > > > > > > > > > Gary/Dirk, > > > > > > I think you may be on to something here. I think this might > > > be what the IESG was talking about it the first point, namely the > > > lack of discussion of dynamic changes in the context. > > > > > > Is there some way we could cook this idea down into a > > > paragraph that we could insert for this requirement? > > > > > > jak > > > > > > ----- Original Message ----- > > > From: "Gary Kenward" > > > To: ; ; > > > > > > Sent: Thursday, July 11, 2002 1:56 PM > > > Subject: RE: [Seamoby] CT Requirements Comments from IESG > > > > > > > > > > Dirk: > > > > > > > > A valid point. There is a certain atomic level of > > > granularity which has to > > > > be > > > > dealt with - that is, there's no protocol in the world that > > > can synchronize > > > > changes in > > > > information that occur at the source while the information > > > is "in-flight" or > > > > being > > > > received at the destination. If changes in context while > > > the context is > > > > being transferred > > > > make a different to the successful performance of CT, then > > > there is no hope. > > > > > > > > The problem is most significant for state context > > > transfer. E.g. counters > > > > will continue > > > > to count while CT is moving the context to the destination. > > > Either these > > > > changes have no > > > > significant impact upon the forwarding service provided at > > > the new AR (e.g. > > > > it may not > > > > matter that a policing meter misses a few packet counts), > > > or a different > > > > mechanism > > > > has to be defined for re-establishing the state context. > > > > > > > > The handover is real and unavoidable. Mitigating the > > > disruption to the > > > > service at the new > > > > AR is the challenge. It would be nice if the disruption > was nil, but > > > > unlikely. > > > > > > > > Gary > > > > > > > > -----Original Message----- > > > > From: Dirk.Trossen@nokia.com [ mailto:Dirk.Trossen@nokia.com ] > > > > Sent: July 11, 2002 16:30 > > > > To: Kenward, Gary [WDLN2:AN10:EXCH]; kempf@docomolabs-usa.com; > > > > seamoby@ietf.org > > > > Subject: RE: [Seamoby] CT Requirements Comments from IESG > > > > > > > > > > > > Hi all, > > > > > > > > jumping in as somebody who has been an observer so far, > > > struggling with the > > > > current discussion on > > > > 'integrity'. > > > > > > > > When I look at the current wording, i.e., > > > > "5.5.2 A context update MUST preserve the integrity, and > > > thus the meaning, > > > > of the context > > > > at each receiving AR. The context at the AR actually > > > supporting an MN's > > > > traffic will change with time. > > > > For example, the MN may initiate new microflow(s), or > > > discontinue existing > > > > microflows. Any change of context > > > > at the supporting AR must be replicated at those ARs that > > > have already > > > > received context for that MN.", > > > > > > > > and compare this to the plain integrity of the actually > > > transmitted data > > > > (i.e., its bits and therefore its semantics) > > > > that has been brought to the table as a replacement now, > > > I'm quite confident > > > > that this is not what the requirement > > > > is talking about. > > > > > > > > If we remove the word 'meaning' (which is very vague > and free for > > > > interpretation for me as well), it is still the word > > > > 'integrity' left, which is more than plain integrity of the > > > transmitted > > > > data, in particular if we look at the following sentences > > > > in the requirement, which state what kind of integrity is > > > meant (which > > > > probably also builds the bridge to the vague > > > > term 'meaning'), namely that the integrity of a context > > > must be preserved in > > > > the sense that a received context at new > > > > AR at some point t must be the same as the context at old > > > AR at the same > > > > time t. This is by far more than plain data > > > > integrity of the transmitted data. Even if your data has > > > been transmitted > > > > correctly, the context might be stale (and therefore > > > > its integrity is lost) because it had changed at old AR in > > > the meanwhile. > > > > The action to be taken is also given in the text, > > > > namely the change of context has to be replicated to the > > > new AR. As you can > > > > (hopefully) see this is by far more than > > > > preserving the 'meaning' of each bit. It mandates that > > > changes in the bit > > > > values at one end are reflected at the other > > > > end, i.e., it talks about distributed data integrity in my > > > interpretation of > > > > the requirement text. > > > > > > > > Hence, the actual concern might have been (just guessing) > > > whether or not it > > > > is the task of the CT protocol to > > > > preserve the abovementioned integrity. Maybe, the IESG > > > wants to see this > > > > functionality left to the replication logic that resides > > > > within each AR. Or on the contrary, they do not see this > > > important topic > > > > covered appropriately. > > > > > > > > Regards, > > > > > > > > > > > > Dirk > > > > > > > > -----Original Message----- > > > > From: ext Gary Kenward [ mailto:gkenward@nortelnetworks.com ] > > > > Sent: Thursday, July 11, 2002 3:48 PM > > > > To: 'James Kempf'; seamoby@ietf.org > > > > Subject: RE: [Seamoby] CT Requirements Comments from IESG > > > > > > > > > > > > > > > > You call it fidelity, I call it data integrity. > > > > I've seen "data integrity" used in publications > > > > (no, I cannot quote references). > > > > > > > > What we need is a term that everyone, including the > > > > IESG, can agree upon. > > > > > > > > > -----Original Message----- > > > > > From: James Kempf [ mailto:kempf@docomolabs-usa.com > > > > < mailto:kempf@docomolabs-usa.com > ] > > > > > Sent: July 11, 2002 12:22 > > > > > To: Kenward, Gary [WDLN2:AN10:EXCH]; seamoby@ietf.org > > > > > Subject: Re: [Seamoby] CT Requirements Comments from IESG > > > > > > > > > > > > > > > > Perhaps the actual answer is to state exactly what > was intended > > > > > > originally: that the bit order and bit values have to > > > arrive exactly > > > > > > as they were transmitted. > > > > > > > > > > > > > > > > So this requirement is talking about transmission fidelity? I > > > > > sure would not have guessed that from reading it. I thought it > > > > > intended to talk about usability. > > > > > > > > > > I would suggest that the wording you have above is really a > > > > > lot more precise that what is currently in the spec. > > > > > > > > > > Any other comments? Could we substitute Gary's wording above > > > > > for "meaning" in the current requirement. > > > > > > > > > > jak > > > > > > > > > > > > > > > > > > > > > > > > > ------_=_NextPart_001_01C22DE9.249BDEE0 Content-Type: text/html; charset="iso-8859-1" RE: [Seamoby] CT Requirements Comments from IESG
Well, not trying to regurgitate (as you said)
but we never agreed on timing and reliability requirements and maybe
that was ok, because they depend on the scenario and protocols.
So why talk about sending updates after CT is done?
 
 
Madjid
-----Original Message-----
From: Gary Kenward [mailto:gkenward@nortelnetworks.com]
Sent: Friday, July 12, 2002 2:35 PM
To: 'Charles E. Perkins'
Cc: seamoby@ietf.org
Subject: RE: [Seamoby] CT Requirements Comments from IESG

I agree Charlie. However, we have to fix the issue with
the requirements. Are you suggesting that we relax the
requirement? By how much - clearly, some updates are required
(e.g. CT really should try and update when flows come and go).

Gary

> -----Original Message-----
> From: Charles E. Perkins [mailto:charliep@iprg.nokia.com]
> Sent: July 12, 2002 12:15
> To: Kenward, Gary [WDLN2:AN10:EXCH]
> Cc: seamoby@ietf.org
> Subject: Re: [Seamoby] CT Requirements Comments from IESG
>
>
>
>
> Hello folks,
>
> I think we ought to try to get context transfers
> working correctly without initially worrying about
> this synchronization problem.
>
> In the instances I am familiar with, it is not
> required.  The most stringent case seems to be
> ROHC, and even for that it is not necessary.
>
> We can solve the most urgent problems without having
> to deal with any additional context synchronization.
> When the old AR sends it, and the new AR gets it,
> we should consider the transfer done.  In those
> cases where reliability is at issue, the old AR
> can retransmit when ACK is not received.  In many
> cases, retransmission of context even once won't
> be useful.
>
> Regards,
> Charlie P.
>
>
>
> > Gary Kenward wrote:
> >
> > James:
> >
> >   Yes, we need to fix it, and I think it is doable.
> > Thanks to Dirk for highlighting the real problem here
> > (I think historically, the integrity requirement came out
> > of the reliability section, and somehow, got lumped with
> > synchronization and updates).
> >
> >   I think the requirements need a bit of rewording, and
> > the paragraph should fall out from this. I do believe
> > however, that making the synchronization of context between
> > old and new AR a MUST requirement would be too extreme, and
> > result in a brittle solution. CT should certainly do it's best to
> > provide synchronization, but as was discussed in a recent
> > exchange, it would be impossible to guarantee synchronization
> > at any instant.
> >
> >   Any ideas/comments from the wg?
> >
> > Gary
> >
> > > -----Original Message-----
> > > From: James Kempf [mailto:kempf@docomolabs-usa.com]
> > > Sent: July 11, 2002 18:32
> > > To: Kenward, Gary [WDLN2:AN10:EXCH]; Dirk.Trossen@nokia.com;
> > > seamoby@ietf.org
> > > Subject: Re: [Seamoby] CT Requirements Comments from IESG
> > >
> > >
> > > Gary/Dirk,
> > >
> > > I think you may be on to something here. I think this might
> > > be what the IESG was talking about it the first point, namely the
> > > lack of discussion of dynamic changes in the context.
> > >
> > > Is there some way we could cook this idea down into a
> > > paragraph that we could insert for this requirement?
> > >
> > >             jak
> > >
> > > ----- Original Message -----
> > > From: "Gary Kenward" <gkenward@nortelnetworks.com>
> > > To: <Dirk.Trossen@nokia.com>; <kempf@docomolabs-usa.com>;
> > > <seamoby@ietf.org>
> > > Sent: Thursday, July 11, 2002 1:56 PM
> > > Subject: RE: [Seamoby] CT Requirements Comments from IESG
> > >
> > >
> > > > Dirk:
> > > >
> > > >   A valid point. There is a certain atomic level of
> > > granularity which has to
> > > > be
> > > > dealt with - that is, there's no protocol in the world that
> > > can synchronize
> > > > changes in
> > > > information that occur at the source while the information
> > > is "in-flight" or
> > > > being
> > > > received at the destination. If changes in context while
> > > the context is
> > > > being transferred
> > > > make a different to the successful performance of CT, then
> > > there is no hope.
> > > >
> > > >   The problem is most significant for state context
> > > transfer. E.g. counters
> > > > will continue
> > > > to count while CT is moving the context to the destination.
> > > Either these
> > > > changes have no
> > > > significant impact upon the forwarding service provided at
> > > the new AR (e.g.
> > > > it may not
> > > > matter that a policing meter misses a few packet counts),
> > > or a different
> > > > mechanism
> > > > has to be defined for re-establishing the state context.
> > > >
> > > >   The handover is real and unavoidable. Mitigating the
> > > disruption to the
> > > > service at the new
> > > > AR is the challenge. It would be nice if the disruption
> was nil, but
> > > > unlikely.
> > > >
> > > > Gary
> > > >
> > > > -----Original Message-----
> > > > From: Dirk.Trossen@nokia.com [mailto:Dirk.Trossen@nokia.com]
> > > > Sent: July 11, 2002 16:30
> > > > To: Kenward, Gary [WDLN2:AN10:EXCH]; kempf@docomolabs-usa.com;
> > > > seamoby@ietf.org
> > > > Subject: RE: [Seamoby] CT Requirements Comments from IESG
> > > >
> > > >
> > > > Hi all,
> > > >
> > > > jumping in as somebody who has been an observer so far,
> > > struggling with the
> > > > current discussion on
> > > > 'integrity'.
> > > >
> > > > When I look at the current wording, i.e.,
> > > > "5.5.2 A context update MUST preserve the integrity, and
> > > thus the meaning,
> > > > of the context
> > > > at each receiving AR. The context at the AR actually
> > > supporting an MN's
> > > > traffic will change with time.
> > > > For example, the MN may initiate new microflow(s), or
> > > discontinue existing
> > > > microflows. Any change of context
> > > > at the supporting AR must be replicated at those ARs that
> > > have already
> > > > received context for that MN.",
> > > >
> > > > and compare this to the plain integrity of the actually
> > > transmitted data
> > > > (i.e., its bits and therefore its semantics)
> > > > that has been brought to the table as a replacement now,
> > > I'm quite confident
> > > > that this is not what the requirement
> > > > is talking about.
> > > >
> > > > If we remove the word 'meaning' (which is very vague
> and free for
> > > > interpretation for me as well), it is still the word
> > > > 'integrity' left, which is more than plain integrity of the
> > > transmitted
> > > > data, in particular if we look at the following sentences
> > > > in the requirement, which state what kind of integrity is
> > > meant (which
> > > > probably also builds the bridge to the vague
> > > > term 'meaning'), namely that the integrity of a context
> > > must be preserved in
> > > > the sense that a received context at new
> > > > AR at some point t must be the same as the context at old
> > > AR at the same
> > > > time t. This is by far more than plain data
> > > > integrity of the transmitted data. Even if your data has
> > > been transmitted
> > > > correctly, the context might be stale (and therefore
> > > > its integrity is lost) because it had changed at old AR in
> > > the meanwhile.
> > > > The action to be taken is also given in the text,
> > > > namely the change of context has to be replicated to the
> > > new AR. As you can
> > > > (hopefully) see this is by far more than
> > > > preserving the 'meaning' of each bit. It mandates that
> > > changes in the bit
> > > > values at one end are reflected at the other
> > > > end, i.e., it talks about distributed data integrity in my
> > > interpretation of
> > > > the requirement text.
> > > >
> > > > Hence, the actual concern might have been (just guessing)
> > > whether or not it
> > > > is the task of the CT protocol to
> > > > preserve the abovementioned integrity. Maybe, the IESG
> > > wants to see this
> > > > functionality left to the replication logic that resides
> > > > within each AR. Or on the contrary, they do not see this
> > > important topic
> > > > covered appropriately.
> > > >
> > > > Regards,
> > > >
> > > >
> > > > Dirk
> > > >
> > > > -----Original Message-----
> > > > From: ext Gary Kenward [mailto:gkenward@nortelnetworks.com]
> > > > Sent: Thursday, July 11, 2002 3:48 PM
> > > > To: 'James Kempf'; seamoby@ietf.org
> > > > Subject: RE: [Seamoby] CT Requirements Comments from IESG
> > > >
> > > >
> > > >
> > > > You call it fidelity, I call it data integrity.
> > > > I've seen "data integrity" used in publications
> > > > (no, I cannot quote references).
> > > >
> > > > What we need is a term that everyone, including the
> > > > IESG, can agree upon.
> > > >
> > > > > -----Original Message-----
> > > > > From: James Kempf [ mailto:kempf@docomolabs-usa.com
> > > > <mailto:kempf@docomolabs-usa.com> ]
> > > > > Sent: July 11, 2002 12:22
> > > > > To: Kenward, Gary [WDLN2:AN10:EXCH]; seamoby@ietf.org
> > > > > Subject: Re: [Seamoby] CT Requirements Comments from IESG
> > > > >
> > > > >
> > > > > > Perhaps the actual answer is to state exactly what
> was intended
> > > > > > originally: that the bit order and bit values have to
> > > arrive exactly
> > > > > > as they were transmitted.
> > > > > >
> > > > >
> > > > > So this requirement is talking about transmission fidelity? I
> > > > > sure would not have guessed that from reading it. I thought it
> > > > > intended to talk about usability.
> > > > >
> > > > > I would suggest that the wording you have above is really a
> > > > > lot more precise that what is currently in the spec.
> > > > >
> > > > > Any other comments? Could we substitute Gary's wording above
> > > > > for "meaning" in the current requirement.
> > > > >
> > > > >             jak
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
>

------_=_NextPart_001_01C22DE9.249BDEE0-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Wed Jul 17 19:27:12 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA02327 for ; Wed, 17 Jul 2002 19:27:12 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id TAA06984 for seamoby-archive@odin.ietf.org; Wed, 17 Jul 2002 19:28:08 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA06901; Wed, 17 Jul 2002 19:24:53 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA06833 for ; Wed, 17 Jul 2002 19:24:49 -0400 (EDT) Received: from motgate4.mot.com (motgate4.mot.com [144.189.100.102]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA02269 for ; Wed, 17 Jul 2002 19:23:52 -0400 (EDT) Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate4.mot.com (motgate4 2.1) with ESMTP id QAA11536 for ; Wed, 17 Jul 2002 16:24:49 -0700 (MST)] Received: [from il27exb01.cig.mot.com (il27exb01.cig.mot.com [136.182.15.100]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id QAA20383 for ; Wed, 17 Jul 2002 16:24:48 -0700 (MST)] Received: by il27exb01.cig.mot.com with Internet Mail Service (5.5.2654.52) id ; Wed, 17 Jul 2002 18:24:48 -0500 Message-ID: <35DBB8B7AC89D4118E98009027B1009B08AD55B8@IL27EXM10.cig.mot.com> From: Nakhjiri Madjid-MNAKHJI1 To: "'Gary Kenward'" , "'Charles E. Perkins'" Cc: seamoby@ietf.org Subject: RE: [Seamoby] CT Requirements Comments from IESG Date: Wed, 17 Jul 2002 18:24:48 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.52) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C22DE9.249BDEE0" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C22DE9.249BDEE0 Content-Type: text/plain; charset="iso-8859-1" Well, not trying to regurgitate (as you said) but we never agreed on timing and reliability requirements and maybe that was ok, because they depend on the scenario and protocols. So why talk about sending updates after CT is done? Madjid -----Original Message----- From: Gary Kenward [mailto:gkenward@nortelnetworks.com] Sent: Friday, July 12, 2002 2:35 PM To: 'Charles E. Perkins' Cc: seamoby@ietf.org Subject: RE: [Seamoby] CT Requirements Comments from IESG I agree Charlie. However, we have to fix the issue with the requirements. Are you suggesting that we relax the requirement? By how much - clearly, some updates are required (e.g. CT really should try and update when flows come and go). Gary > -----Original Message----- > From: Charles E. Perkins [ mailto:charliep@iprg.nokia.com ] > Sent: July 12, 2002 12:15 > To: Kenward, Gary [WDLN2:AN10:EXCH] > Cc: seamoby@ietf.org > Subject: Re: [Seamoby] CT Requirements Comments from IESG > > > > > Hello folks, > > I think we ought to try to get context transfers > working correctly without initially worrying about > this synchronization problem. > > In the instances I am familiar with, it is not > required. The most stringent case seems to be > ROHC, and even for that it is not necessary. > > We can solve the most urgent problems without having > to deal with any additional context synchronization. > When the old AR sends it, and the new AR gets it, > we should consider the transfer done. In those > cases where reliability is at issue, the old AR > can retransmit when ACK is not received. In many > cases, retransmission of context even once won't > be useful. > > Regards, > Charlie P. > > > > > Gary Kenward wrote: > > > > James: > > > > Yes, we need to fix it, and I think it is doable. > > Thanks to Dirk for highlighting the real problem here > > (I think historically, the integrity requirement came out > > of the reliability section, and somehow, got lumped with > > synchronization and updates). > > > > I think the requirements need a bit of rewording, and > > the paragraph should fall out from this. I do believe > > however, that making the synchronization of context between > > old and new AR a MUST requirement would be too extreme, and > > result in a brittle solution. CT should certainly do it's best to > > provide synchronization, but as was discussed in a recent > > exchange, it would be impossible to guarantee synchronization > > at any instant. > > > > Any ideas/comments from the wg? > > > > Gary > > > > > -----Original Message----- > > > From: James Kempf [ mailto:kempf@docomolabs-usa.com ] > > > Sent: July 11, 2002 18:32 > > > To: Kenward, Gary [WDLN2:AN10:EXCH]; Dirk.Trossen@nokia.com; > > > seamoby@ietf.org > > > Subject: Re: [Seamoby] CT Requirements Comments from IESG > > > > > > > > > Gary/Dirk, > > > > > > I think you may be on to something here. I think this might > > > be what the IESG was talking about it the first point, namely the > > > lack of discussion of dynamic changes in the context. > > > > > > Is there some way we could cook this idea down into a > > > paragraph that we could insert for this requirement? > > > > > > jak > > > > > > ----- Original Message ----- > > > From: "Gary Kenward" > > > To: ; ; > > > > > > Sent: Thursday, July 11, 2002 1:56 PM > > > Subject: RE: [Seamoby] CT Requirements Comments from IESG > > > > > > > > > > Dirk: > > > > > > > > A valid point. There is a certain atomic level of > > > granularity which has to > > > > be > > > > dealt with - that is, there's no protocol in the world that > > > can synchronize > > > > changes in > > > > information that occur at the source while the information > > > is "in-flight" or > > > > being > > > > received at the destination. If changes in context while > > > the context is > > > > being transferred > > > > make a different to the successful performance of CT, then > > > there is no hope. > > > > > > > > The problem is most significant for state context > > > transfer. E.g. counters > > > > will continue > > > > to count while CT is moving the context to the destination. > > > Either these > > > > changes have no > > > > significant impact upon the forwarding service provided at > > > the new AR (e.g. > > > > it may not > > > > matter that a policing meter misses a few packet counts), > > > or a different > > > > mechanism > > > > has to be defined for re-establishing the state context. > > > > > > > > The handover is real and unavoidable. Mitigating the > > > disruption to the > > > > service at the new > > > > AR is the challenge. It would be nice if the disruption > was nil, but > > > > unlikely. > > > > > > > > Gary > > > > > > > > -----Original Message----- > > > > From: Dirk.Trossen@nokia.com [ mailto:Dirk.Trossen@nokia.com ] > > > > Sent: July 11, 2002 16:30 > > > > To: Kenward, Gary [WDLN2:AN10:EXCH]; kempf@docomolabs-usa.com; > > > > seamoby@ietf.org > > > > Subject: RE: [Seamoby] CT Requirements Comments from IESG > > > > > > > > > > > > Hi all, > > > > > > > > jumping in as somebody who has been an observer so far, > > > struggling with the > > > > current discussion on > > > > 'integrity'. > > > > > > > > When I look at the current wording, i.e., > > > > "5.5.2 A context update MUST preserve the integrity, and > > > thus the meaning, > > > > of the context > > > > at each receiving AR. The context at the AR actually > > > supporting an MN's > > > > traffic will change with time. > > > > For example, the MN may initiate new microflow(s), or > > > discontinue existing > > > > microflows. Any change of context > > > > at the supporting AR must be replicated at those ARs that > > > have already > > > > received context for that MN.", > > > > > > > > and compare this to the plain integrity of the actually > > > transmitted data > > > > (i.e., its bits and therefore its semantics) > > > > that has been brought to the table as a replacement now, > > > I'm quite confident > > > > that this is not what the requirement > > > > is talking about. > > > > > > > > If we remove the word 'meaning' (which is very vague > and free for > > > > interpretation for me as well), it is still the word > > > > 'integrity' left, which is more than plain integrity of the > > > transmitted > > > > data, in particular if we look at the following sentences > > > > in the requirement, which state what kind of integrity is > > > meant (which > > > > probably also builds the bridge to the vague > > > > term 'meaning'), namely that the integrity of a context > > > must be preserved in > > > > the sense that a received context at new > > > > AR at some point t must be the same as the context at old > > > AR at the same > > > > time t. This is by far more than plain data > > > > integrity of the transmitted data. Even if your data has > > > been transmitted > > > > correctly, the context might be stale (and therefore > > > > its integrity is lost) because it had changed at old AR in > > > the meanwhile. > > > > The action to be taken is also given in the text, > > > > namely the change of context has to be replicated to the > > > new AR. As you can > > > > (hopefully) see this is by far more than > > > > preserving the 'meaning' of each bit. It mandates that > > > changes in the bit > > > > values at one end are reflected at the other > > > > end, i.e., it talks about distributed data integrity in my > > > interpretation of > > > > the requirement text. > > > > > > > > Hence, the actual concern might have been (just guessing) > > > whether or not it > > > > is the task of the CT protocol to > > > > preserve the abovementioned integrity. Maybe, the IESG > > > wants to see this > > > > functionality left to the replication logic that resides > > > > within each AR. Or on the contrary, they do not see this > > > important topic > > > > covered appropriately. > > > > > > > > Regards, > > > > > > > > > > > > Dirk > > > > > > > > -----Original Message----- > > > > From: ext Gary Kenward [ mailto:gkenward@nortelnetworks.com ] > > > > Sent: Thursday, July 11, 2002 3:48 PM > > > > To: 'James Kempf'; seamoby@ietf.org > > > > Subject: RE: [Seamoby] CT Requirements Comments from IESG > > > > > > > > > > > > > > > > You call it fidelity, I call it data integrity. > > > > I've seen "data integrity" used in publications > > > > (no, I cannot quote references). > > > > > > > > What we need is a term that everyone, including the > > > > IESG, can agree upon. > > > > > > > > > -----Original Message----- > > > > > From: James Kempf [ mailto:kempf@docomolabs-usa.com > > > > < mailto:kempf@docomolabs-usa.com > ] > > > > > Sent: July 11, 2002 12:22 > > > > > To: Kenward, Gary [WDLN2:AN10:EXCH]; seamoby@ietf.org > > > > > Subject: Re: [Seamoby] CT Requirements Comments from IESG > > > > > > > > > > > > > > > > Perhaps the actual answer is to state exactly what > was intended > > > > > > originally: that the bit order and bit values have to > > > arrive exactly > > > > > > as they were transmitted. > > > > > > > > > > > > > > > > So this requirement is talking about transmission fidelity? I > > > > > sure would not have guessed that from reading it. I thought it > > > > > intended to talk about usability. > > > > > > > > > > I would suggest that the wording you have above is really a > > > > > lot more precise that what is currently in the spec. > > > > > > > > > > Any other comments? Could we substitute Gary's wording above > > > > > for "meaning" in the current requirement. > > > > > > > > > > jak > > > > > > > > > > > > > > > > > > > > > > > > > ------_=_NextPart_001_01C22DE9.249BDEE0 Content-Type: text/html; charset="iso-8859-1" RE: [Seamoby] CT Requirements Comments from IESG
Well, not trying to regurgitate (as you said)
but we never agreed on timing and reliability requirements and maybe
that was ok, because they depend on the scenario and protocols.
So why talk about sending updates after CT is done?
 
 
Madjid
-----Original Message-----
From: Gary Kenward [mailto:gkenward@nortelnetworks.com]
Sent: Friday, July 12, 2002 2:35 PM
To: 'Charles E. Perkins'
Cc: seamoby@ietf.org
Subject: RE: [Seamoby] CT Requirements Comments from IESG

I agree Charlie. However, we have to fix the issue with
the requirements. Are you suggesting that we relax the
requirement? By how much - clearly, some updates are required
(e.g. CT really should try and update when flows come and go).

Gary

> -----Original Message-----
> From: Charles E. Perkins [mailto:charliep@iprg.nokia.com]
> Sent: July 12, 2002 12:15
> To: Kenward, Gary [WDLN2:AN10:EXCH]
> Cc: seamoby@ietf.org
> Subject: Re: [Seamoby] CT Requirements Comments from IESG
>
>
>
>
> Hello folks,
>
> I think we ought to try to get context transfers
> working correctly without initially worrying about
> this synchronization problem.
>
> In the instances I am familiar with, it is not
> required.  The most stringent case seems to be
> ROHC, and even for that it is not necessary.
>
> We can solve the most urgent problems without having
> to deal with any additional context synchronization.
> When the old AR sends it, and the new AR gets it,
> we should consider the transfer done.  In those
> cases where reliability is at issue, the old AR
> can retransmit when ACK is not received.  In many
> cases, retransmission of context even once won't
> be useful.
>
> Regards,
> Charlie P.
>
>
>
> > Gary Kenward wrote:
> >
> > James:
> >
> >   Yes, we need to fix it, and I think it is doable.
> > Thanks to Dirk for highlighting the real problem here
> > (I think historically, the integrity requirement came out
> > of the reliability section, and somehow, got lumped with
> > synchronization and updates).
> >
> >   I think the requirements need a bit of rewording, and
> > the paragraph should fall out from this. I do believe
> > however, that making the synchronization of context between
> > old and new AR a MUST requirement would be too extreme, and
> > result in a brittle solution. CT should certainly do it's best to
> > provide synchronization, but as was discussed in a recent
> > exchange, it would be impossible to guarantee synchronization
> > at any instant.
> >
> >   Any ideas/comments from the wg?
> >
> > Gary
> >
> > > -----Original Message-----
> > > From: James Kempf [mailto:kempf@docomolabs-usa.com]
> > > Sent: July 11, 2002 18:32
> > > To: Kenward, Gary [WDLN2:AN10:EXCH]; Dirk.Trossen@nokia.com;
> > > seamoby@ietf.org
> > > Subject: Re: [Seamoby] CT Requirements Comments from IESG
> > >
> > >
> > > Gary/Dirk,
> > >
> > > I think you may be on to something here. I think this might
> > > be what the IESG was talking about it the first point, namely the
> > > lack of discussion of dynamic changes in the context.
> > >
> > > Is there some way we could cook this idea down into a
> > > paragraph that we could insert for this requirement?
> > >
> > >             jak
> > >
> > > ----- Original Message -----
> > > From: "Gary Kenward" <gkenward@nortelnetworks.com>
> > > To: <Dirk.Trossen@nokia.com>; <kempf@docomolabs-usa.com>;
> > > <seamoby@ietf.org>
> > > Sent: Thursday, July 11, 2002 1:56 PM
> > > Subject: RE: [Seamoby] CT Requirements Comments from IESG
> > >
> > >
> > > > Dirk:
> > > >
> > > >   A valid point. There is a certain atomic level of
> > > granularity which has to
> > > > be
> > > > dealt with - that is, there's no protocol in the world that
> > > can synchronize
> > > > changes in
> > > > information that occur at the source while the information
> > > is "in-flight" or
> > > > being
> > > > received at the destination. If changes in context while
> > > the context is
> > > > being transferred
> > > > make a different to the successful performance of CT, then
> > > there is no hope.
> > > >
> > > >   The problem is most significant for state context
> > > transfer. E.g. counters
> > > > will continue
> > > > to count while CT is moving the context to the destination.
> > > Either these
> > > > changes have no
> > > > significant impact upon the forwarding service provided at
> > > the new AR (e.g.
> > > > it may not
> > > > matter that a policing meter misses a few packet counts),
> > > or a different
> > > > mechanism
> > > > has to be defined for re-establishing the state context.
> > > >
> > > >   The handover is real and unavoidable. Mitigating the
> > > disruption to the
> > > > service at the new
> > > > AR is the challenge. It would be nice if the disruption
> was nil, but
> > > > unlikely.
> > > >
> > > > Gary
> > > >
> > > > -----Original Message-----
> > > > From: Dirk.Trossen@nokia.com [mailto:Dirk.Trossen@nokia.com]
> > > > Sent: July 11, 2002 16:30
> > > > To: Kenward, Gary [WDLN2:AN10:EXCH]; kempf@docomolabs-usa.com;
> > > > seamoby@ietf.org
> > > > Subject: RE: [Seamoby] CT Requirements Comments from IESG
> > > >
> > > >
> > > > Hi all,
> > > >
> > > > jumping in as somebody who has been an observer so far,
> > > struggling with the
> > > > current discussion on
> > > > 'integrity'.
> > > >
> > > > When I look at the current wording, i.e.,
> > > > "5.5.2 A context update MUST preserve the integrity, and
> > > thus the meaning,
> > > > of the context
> > > > at each receiving AR. The context at the AR actually
> > > supporting an MN's
> > > > traffic will change with time.
> > > > For example, the MN may initiate new microflow(s), or
> > > discontinue existing
> > > > microflows. Any change of context
> > > > at the supporting AR must be replicated at those ARs that
> > > have already
> > > > received context for that MN.",
> > > >
> > > > and compare this to the plain integrity of the actually
> > > transmitted data
> > > > (i.e., its bits and therefore its semantics)
> > > > that has been brought to the table as a replacement now,
> > > I'm quite confident
> > > > that this is not what the requirement
> > > > is talking about.
> > > >
> > > > If we remove the word 'meaning' (which is very vague
> and free for
> > > > interpretation for me as well), it is still the word
> > > > 'integrity' left, which is more than plain integrity of the
> > > transmitted
> > > > data, in particular if we look at the following sentences
> > > > in the requirement, which state what kind of integrity is
> > > meant (which
> > > > probably also builds the bridge to the vague
> > > > term 'meaning'), namely that the integrity of a context
> > > must be preserved in
> > > > the sense that a received context at new
> > > > AR at some point t must be the same as the context at old
> > > AR at the same
> > > > time t. This is by far more than plain data
> > > > integrity of the transmitted data. Even if your data has
> > > been transmitted
> > > > correctly, the context might be stale (and therefore
> > > > its integrity is lost) because it had changed at old AR in
> > > the meanwhile.
> > > > The action to be taken is also given in the text,
> > > > namely the change of context has to be replicated to the
> > > new AR. As you can
> > > > (hopefully) see this is by far more than
> > > > preserving the 'meaning' of each bit. It mandates that
> > > changes in the bit
> > > > values at one end are reflected at the other
> > > > end, i.e., it talks about distributed data integrity in my
> > > interpretation of
> > > > the requirement text.
> > > >
> > > > Hence, the actual concern might have been (just guessing)
> > > whether or not it
> > > > is the task of the CT protocol to
> > > > preserve the abovementioned integrity. Maybe, the IESG
> > > wants to see this
> > > > functionality left to the replication logic that resides
> > > > within each AR. Or on the contrary, they do not see this
> > > important topic
> > > > covered appropriately.
> > > >
> > > > Regards,
> > > >
> > > >
> > > > Dirk
> > > >
> > > > -----Original Message-----
> > > > From: ext Gary Kenward [mailto:gkenward@nortelnetworks.com]
> > > > Sent: Thursday, July 11, 2002 3:48 PM
> > > > To: 'James Kempf'; seamoby@ietf.org
> > > > Subject: RE: [Seamoby] CT Requirements Comments from IESG
> > > >
> > > >
> > > >
> > > > You call it fidelity, I call it data integrity.
> > > > I've seen "data integrity" used in publications
> > > > (no, I cannot quote references).
> > > >
> > > > What we need is a term that everyone, including the
> > > > IESG, can agree upon.
> > > >
> > > > > -----Original Message-----
> > > > > From: James Kempf [ mailto:kempf@docomolabs-usa.com
> > > > <mailto:kempf@docomolabs-usa.com> ]
> > > > > Sent: July 11, 2002 12:22
> > > > > To: Kenward, Gary [WDLN2:AN10:EXCH]; seamoby@ietf.org
> > > > > Subject: Re: [Seamoby] CT Requirements Comments from IESG
> > > > >
> > > > >
> > > > > > Perhaps the actual answer is to state exactly what
> was intended
> > > > > > originally: that the bit order and bit values have to
> > > arrive exactly
> > > > > > as they were transmitted.
> > > > > >
> > > > >
> > > > > So this requirement is talking about transmission fidelity? I
> > > > > sure would not have guessed that from reading it. I thought it
> > > > > intended to talk about usability.
> > > > >
> > > > > I would suggest that the wording you have above is really a
> > > > > lot more precise that what is currently in the spec.
> > > > >
> > > > > Any other comments? Could we substitute Gary's wording above
> > > > > for "meaning" in the current requirement.
> > > > >
> > > > >             jak
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
>

------_=_NextPart_001_01C22DE9.249BDEE0-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Jul 17 19:38:10 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA02474 for ; Wed, 17 Jul 2002 19:38:06 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA07691; Wed, 17 Jul 2002 19:36:18 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA07663 for ; Wed, 17 Jul 2002 19:36:16 -0400 (EDT) Received: from motgate.mot.com (motgate.mot.com [129.188.136.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA02426 for ; Wed, 17 Jul 2002 19:35:19 -0400 (EDT) Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate.mot.com (motgate 2.1) with ESMTP id QAA14118 for ; Wed, 17 Jul 2002 16:36:16 -0700 (MST)] Received: [from il27exb01.cig.mot.com (il27exb01.cig.mot.com [136.182.15.100]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id QAA22439 for ; Wed, 17 Jul 2002 16:36:16 -0700 (MST)] Received: by il27exb01.cig.mot.com with Internet Mail Service (5.5.2654.52) id ; Wed, 17 Jul 2002 18:36:16 -0500 Message-ID: <35DBB8B7AC89D4118E98009027B1009B08AD55B9@IL27EXM10.cig.mot.com> From: Nakhjiri Madjid-MNAKHJI1 To: "'James Kempf'" , seamoby@ietf.org Subject: RE: [Seamoby] Proposal on Sync/NoSync Requirement Date: Wed, 17 Jul 2002 18:36:15 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.52) Content-Type: text/plain; charset="iso-8859-1" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Don't know if we can use NEED Not (certainly fits for the first SHOULD NOT, since that one sounds like we are advising against it). How would you allow particular features get synch service, if there is no inbuild mechanisms in CT? I think we can talk about synchronization when there are two copies at two different places. I think the solutions should seriously avoid this, as we did in our proposal. Care should be taken so that you don't have to update a context at both oldAR and newAR. I think as you said for header compression context, you should have the context updated only at one location and when it is only at one location, how can we call it synchronization? You would on the other hand get problem with dynamic context, if some context that you sent over, gets lost or corrupted. Once this happen then, you can see whether the context has changed (in which case you need a refresh) or not (you only need a retx). Madjid -----Original Message----- From: James Kempf [mailto:kempf@docomolabs-usa.com] Sent: Saturday, July 13, 2002 1:59 PM To: seamoby@ietf.org Subject: [Seamoby] Proposal on Sync/NoSync Requirement So based on the list discussion so far, I'd like to put out the following proposal for a requirement on synchronization or its lack: 5.5.1 The CT solution SHOULD NOT provide direct support for synchronization of context. However, the CT solution SHOULD allow particular feature contexts that require synchronization to provide that support. Most feature contexts will not require synchronization, however there are a few that may. Header compression, for example, may require that the header compressor on the old access router cease and the compressor on the new router start in synchrony with hand over of routing to the new router; otherwise, the compressor on the new router will not be properly synchronized. Since most contexts don't need synchronization support, the CT solution need not support it, but it should not provide a hinderance to those feature contexts that do. Comments? jak _______________________________________________ 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 From daemon@optimus.ietf.org Wed Jul 17 19:38:11 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA02481 for ; Wed, 17 Jul 2002 19:38:11 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id TAA07759 for seamoby-archive@odin.ietf.org; Wed, 17 Jul 2002 19:39:07 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA07691; Wed, 17 Jul 2002 19:36:18 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA07663 for ; Wed, 17 Jul 2002 19:36:16 -0400 (EDT) Received: from motgate.mot.com (motgate.mot.com [129.188.136.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA02426 for ; Wed, 17 Jul 2002 19:35:19 -0400 (EDT) Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate.mot.com (motgate 2.1) with ESMTP id QAA14118 for ; Wed, 17 Jul 2002 16:36:16 -0700 (MST)] Received: [from il27exb01.cig.mot.com (il27exb01.cig.mot.com [136.182.15.100]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id QAA22439 for ; Wed, 17 Jul 2002 16:36:16 -0700 (MST)] Received: by il27exb01.cig.mot.com with Internet Mail Service (5.5.2654.52) id ; Wed, 17 Jul 2002 18:36:16 -0500 Message-ID: <35DBB8B7AC89D4118E98009027B1009B08AD55B9@IL27EXM10.cig.mot.com> From: Nakhjiri Madjid-MNAKHJI1 To: "'James Kempf'" , seamoby@ietf.org Subject: RE: [Seamoby] Proposal on Sync/NoSync Requirement Date: Wed, 17 Jul 2002 18:36:15 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.52) Content-Type: text/plain; charset="iso-8859-1" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Don't know if we can use NEED Not (certainly fits for the first SHOULD NOT, since that one sounds like we are advising against it). How would you allow particular features get synch service, if there is no inbuild mechanisms in CT? I think we can talk about synchronization when there are two copies at two different places. I think the solutions should seriously avoid this, as we did in our proposal. Care should be taken so that you don't have to update a context at both oldAR and newAR. I think as you said for header compression context, you should have the context updated only at one location and when it is only at one location, how can we call it synchronization? You would on the other hand get problem with dynamic context, if some context that you sent over, gets lost or corrupted. Once this happen then, you can see whether the context has changed (in which case you need a refresh) or not (you only need a retx). Madjid -----Original Message----- From: James Kempf [mailto:kempf@docomolabs-usa.com] Sent: Saturday, July 13, 2002 1:59 PM To: seamoby@ietf.org Subject: [Seamoby] Proposal on Sync/NoSync Requirement So based on the list discussion so far, I'd like to put out the following proposal for a requirement on synchronization or its lack: 5.5.1 The CT solution SHOULD NOT provide direct support for synchronization of context. However, the CT solution SHOULD allow particular feature contexts that require synchronization to provide that support. Most feature contexts will not require synchronization, however there are a few that may. Header compression, for example, may require that the header compressor on the old access router cease and the compressor on the new router start in synchrony with hand over of routing to the new router; otherwise, the compressor on the new router will not be properly synchronized. Since most contexts don't need synchronization support, the CT solution need not support it, but it should not provide a hinderance to those feature contexts that do. Comments? jak _______________________________________________ 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 From seamoby-admin@ietf.org Wed Jul 17 19:44:23 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA02649 for ; Wed, 17 Jul 2002 19:44:23 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA07883; Wed, 17 Jul 2002 19:42:30 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA07856 for ; Wed, 17 Jul 2002 19:42:28 -0400 (EDT) Received: from motgate4.mot.com (motgate4.mot.com [144.189.100.102]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA02590 for ; Wed, 17 Jul 2002 19:41:31 -0400 (EDT) Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate4.mot.com (motgate4 2.1) with ESMTP id QAA20472 for ; Wed, 17 Jul 2002 16:42:28 -0700 (MST)] Received: [from il27exm07.cig.mot.com (IL27EXM07.cig.mot.com [136.182.15.116]) by mothost.mot.com (MOT-pobox 2.0) with ESMTP id QAA27564 for ; Wed, 17 Jul 2002 16:42:41 -0700 (MST)] Received: by IL27EXM07.cig.mot.com with Internet Mail Service (5.5.2654.52) id <3FLZX801>; Wed, 17 Jul 2002 18:42:26 -0500 Message-ID: <35DBB8B7AC89D4118E98009027B1009B08AD55BA@IL27EXM10.cig.mot.com> From: Nakhjiri Madjid-MNAKHJI1 To: "'john.loughney@nokia.com'" , kempf@docomolabs-usa.com, seamoby@ietf.org Subject: RE: [Seamoby] Proposal on Sync/NoSync Requirement Date: Wed, 17 Jul 2002 18:42:24 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.52) Content-Type: text/plain; charset="iso-8859-1" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org -----Original Message----- From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] Sent: Sunday, July 14, 2002 5:01 PM To: kempf@docomolabs-usa.com; seamoby@ietf.org Subject: RE: [Seamoby] Proposal on Sync/NoSync Requirement Hi James, > "Out of scope" is typically WG charter language. I know the > SHOULD/SHOULD NOT sounds a bit funny, but I think we need to > express this in a way that is more requirements language. Then how about changing: ... the CT solution need not support it, but it should not provide a hinderance to those feature contexts that do. Madjid>> I knew I should read some more :) Need not is better. to: ... the CT solution is not requireed to directly support synchronization, but may support simple methods for the synchronization context for feature contexts that do. Madjid>> Don't know what purpose "simple" feels, it's vague and creates caos later. I prefer "methods for providing updated context..." instead of synchronization, of reasons I mentioned. John _______________________________________________ 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 From daemon@optimus.ietf.org Wed Jul 17 19:44:24 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA02657 for ; Wed, 17 Jul 2002 19:44:24 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id TAA07926 for seamoby-archive@odin.ietf.org; Wed, 17 Jul 2002 19:45:20 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA07883; Wed, 17 Jul 2002 19:42:30 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA07856 for ; Wed, 17 Jul 2002 19:42:28 -0400 (EDT) Received: from motgate4.mot.com (motgate4.mot.com [144.189.100.102]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA02590 for ; Wed, 17 Jul 2002 19:41:31 -0400 (EDT) Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate4.mot.com (motgate4 2.1) with ESMTP id QAA20472 for ; Wed, 17 Jul 2002 16:42:28 -0700 (MST)] Received: [from il27exm07.cig.mot.com (IL27EXM07.cig.mot.com [136.182.15.116]) by mothost.mot.com (MOT-pobox 2.0) with ESMTP id QAA27564 for ; Wed, 17 Jul 2002 16:42:41 -0700 (MST)] Received: by IL27EXM07.cig.mot.com with Internet Mail Service (5.5.2654.52) id <3FLZX801>; Wed, 17 Jul 2002 18:42:26 -0500 Message-ID: <35DBB8B7AC89D4118E98009027B1009B08AD55BA@IL27EXM10.cig.mot.com> From: Nakhjiri Madjid-MNAKHJI1 To: "'john.loughney@nokia.com'" , kempf@docomolabs-usa.com, seamoby@ietf.org Subject: RE: [Seamoby] Proposal on Sync/NoSync Requirement Date: Wed, 17 Jul 2002 18:42:24 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.52) Content-Type: text/plain; charset="iso-8859-1" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org -----Original Message----- From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] Sent: Sunday, July 14, 2002 5:01 PM To: kempf@docomolabs-usa.com; seamoby@ietf.org Subject: RE: [Seamoby] Proposal on Sync/NoSync Requirement Hi James, > "Out of scope" is typically WG charter language. I know the > SHOULD/SHOULD NOT sounds a bit funny, but I think we need to > express this in a way that is more requirements language. Then how about changing: ... the CT solution need not support it, but it should not provide a hinderance to those feature contexts that do. Madjid>> I knew I should read some more :) Need not is better. to: ... the CT solution is not requireed to directly support synchronization, but may support simple methods for the synchronization context for feature contexts that do. Madjid>> Don't know what purpose "simple" feels, it's vague and creates caos later. I prefer "methods for providing updated context..." instead of synchronization, of reasons I mentioned. John _______________________________________________ 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 From seamoby-admin@ietf.org Wed Jul 17 20:18:13 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA03450 for ; Wed, 17 Jul 2002 20:18:12 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA09452; Wed, 17 Jul 2002 20:12:01 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA09412 for ; Wed, 17 Jul 2002 20:11:59 -0400 (EDT) Received: from motgate.mot.com (motgate.mot.com [129.188.136.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA03159 for ; Wed, 17 Jul 2002 20:11:01 -0400 (EDT) Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate.mot.com (motgate 2.1) with ESMTP id RAA20823 for ; Wed, 17 Jul 2002 17:11:59 -0700 (MST)] Received: [from il27exm07.cig.mot.com (IL27EXM07.cig.mot.com [136.182.15.116]) by mothost.mot.com (MOT-pobox 2.0) with ESMTP id RAA02827 for ; Wed, 17 Jul 2002 17:12:12 -0700 (MST)] Received: by IL27EXM07.cig.mot.com with Internet Mail Service (5.5.2654.52) id <3FLZX9N1>; Wed, 17 Jul 2002 19:11:59 -0500 Message-ID: <35DBB8B7AC89D4118E98009027B1009B08AD55BB@IL27EXM10.cig.mot.com> From: Nakhjiri Madjid-MNAKHJI1 To: "'Gary Kenward'" , "'James Kempf'" , john.loughney@nokia.com, seamoby@ietf.org Subject: RE: [Seamoby] Proposal on Sync/NoSync Requirement Date: Wed, 17 Jul 2002 19:11:59 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.52) Content-Type: text/plain; charset="iso-8859-1" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Gary, thanks for the suggestions, please see my comments below. Madjid Proposed: 5.5 Context Update and Synchronization 5.5.1 The context transfer protocol MUST be capable of supporting the updates to context information when it changes. Madjid>> Ok, this takes care of the dynamic context, however,we need to be clarify that we are not requiring the oldAR sends updates to context features it has already transmitted while it is transmitting context for other features, otherwise CT might never end. Since, some folks have brought that up, I want to make sure that we are not reading that in the requirement. Updates initiated by oldAR should only be based on outside triggers such as new flow, flow terminations or messages from central entities... 5.5.2 Context updates SHOULD complete before the context is needed at the receiving AR. Madjid>> How do we know when the context is needed at the receiving AR? I find this more like a design guidance than a requirement. The following text can with some exceptions added to the explanation of 5.5.2. The context at the AR actually supporting an MN's traffic will change with time. For example, the MN may initiate new microflow(s), or discontinue existing microflows. Madjid>> the above is good. Any change of context at the supporting AR must be replicated at those ARs that have already received context for that MN. Madjid>> MUSt is too strong. 5.5.1 is SHOULD, so should this one be (sorry for too many shoulds :)) There are ways to avoid having to do this through CT. However, context changes are often driven by events external to the sending AR, and will thus be asynchronous to any on-going context updates. Given that context transfers will take a finite amount of time to complete, it is possible that a change in context cannot be conveyed in time to the destination AR to avoid any impact on a possible handover. The objective of the context transfer design must be to make the likelihood of this delay, and its magnitude, as low as possible. Madjid>> The above is good. This is not perfect: the desire to avoid a requirement for an extreme degree of synchronization is only implied by the soft "SHOULD" in 5.5.2. Regards, Gary > -----Original Message----- > From: James Kempf [mailto:kempf@docomolabs-usa.com] > Sent: July 14, 2002 18:52 > To: john.loughney@nokia.com; seamoby@ietf.org > Subject: Re: [Seamoby] Proposal on Sync/NoSync Requirement > > > That sounds better. > > jak > > ----- Original Message ----- > From: > To: ; > Sent: Sunday, July 14, 2002 3:01 PM > Subject: RE: [Seamoby] Proposal on Sync/NoSync Requirement > > > > Hi James, > > > > > "Out of scope" is typically WG charter language. I know the > > > SHOULD/SHOULD NOT sounds a bit funny, but I think we need to > > > express this in a way that is more requirements language. > > > > Then how about changing: > > > > ... the CT solution need > > not support it, but it should not provide a > hinderance to those feature contexts > > that do. > > > > to: > > ... the CT solution is not requireed to directly > support synchronization, but > > may support simple methods for the synchronization > context for feature contexts > > that do. > > > > John > > > > > _______________________________________________ > 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 From daemon@optimus.ietf.org Wed Jul 17 20:18:13 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA03459 for ; Wed, 17 Jul 2002 20:18:13 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id UAA09842 for seamoby-archive@odin.ietf.org; Wed, 17 Jul 2002 20:19:10 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA09452; Wed, 17 Jul 2002 20:12:01 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA09412 for ; Wed, 17 Jul 2002 20:11:59 -0400 (EDT) Received: from motgate.mot.com (motgate.mot.com [129.188.136.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA03159 for ; Wed, 17 Jul 2002 20:11:01 -0400 (EDT) Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate.mot.com (motgate 2.1) with ESMTP id RAA20823 for ; Wed, 17 Jul 2002 17:11:59 -0700 (MST)] Received: [from il27exm07.cig.mot.com (IL27EXM07.cig.mot.com [136.182.15.116]) by mothost.mot.com (MOT-pobox 2.0) with ESMTP id RAA02827 for ; Wed, 17 Jul 2002 17:12:12 -0700 (MST)] Received: by IL27EXM07.cig.mot.com with Internet Mail Service (5.5.2654.52) id <3FLZX9N1>; Wed, 17 Jul 2002 19:11:59 -0500 Message-ID: <35DBB8B7AC89D4118E98009027B1009B08AD55BB@IL27EXM10.cig.mot.com> From: Nakhjiri Madjid-MNAKHJI1 To: "'Gary Kenward'" , "'James Kempf'" , john.loughney@nokia.com, seamoby@ietf.org Subject: RE: [Seamoby] Proposal on Sync/NoSync Requirement Date: Wed, 17 Jul 2002 19:11:59 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.52) Content-Type: text/plain; charset="iso-8859-1" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Gary, thanks for the suggestions, please see my comments below. Madjid Proposed: 5.5 Context Update and Synchronization 5.5.1 The context transfer protocol MUST be capable of supporting the updates to context information when it changes. Madjid>> Ok, this takes care of the dynamic context, however,we need to be clarify that we are not requiring the oldAR sends updates to context features it has already transmitted while it is transmitting context for other features, otherwise CT might never end. Since, some folks have brought that up, I want to make sure that we are not reading that in the requirement. Updates initiated by oldAR should only be based on outside triggers such as new flow, flow terminations or messages from central entities... 5.5.2 Context updates SHOULD complete before the context is needed at the receiving AR. Madjid>> How do we know when the context is needed at the receiving AR? I find this more like a design guidance than a requirement. The following text can with some exceptions added to the explanation of 5.5.2. The context at the AR actually supporting an MN's traffic will change with time. For example, the MN may initiate new microflow(s), or discontinue existing microflows. Madjid>> the above is good. Any change of context at the supporting AR must be replicated at those ARs that have already received context for that MN. Madjid>> MUSt is too strong. 5.5.1 is SHOULD, so should this one be (sorry for too many shoulds :)) There are ways to avoid having to do this through CT. However, context changes are often driven by events external to the sending AR, and will thus be asynchronous to any on-going context updates. Given that context transfers will take a finite amount of time to complete, it is possible that a change in context cannot be conveyed in time to the destination AR to avoid any impact on a possible handover. The objective of the context transfer design must be to make the likelihood of this delay, and its magnitude, as low as possible. Madjid>> The above is good. This is not perfect: the desire to avoid a requirement for an extreme degree of synchronization is only implied by the soft "SHOULD" in 5.5.2. Regards, Gary > -----Original Message----- > From: James Kempf [mailto:kempf@docomolabs-usa.com] > Sent: July 14, 2002 18:52 > To: john.loughney@nokia.com; seamoby@ietf.org > Subject: Re: [Seamoby] Proposal on Sync/NoSync Requirement > > > That sounds better. > > jak > > ----- Original Message ----- > From: > To: ; > Sent: Sunday, July 14, 2002 3:01 PM > Subject: RE: [Seamoby] Proposal on Sync/NoSync Requirement > > > > Hi James, > > > > > "Out of scope" is typically WG charter language. I know the > > > SHOULD/SHOULD NOT sounds a bit funny, but I think we need to > > > express this in a way that is more requirements language. > > > > Then how about changing: > > > > ... the CT solution need > > not support it, but it should not provide a > hinderance to those feature contexts > > that do. > > > > to: > > ... the CT solution is not requireed to directly > support synchronization, but > > may support simple methods for the synchronization > context for feature contexts > > that do. > > > > John > > > > > _______________________________________________ > 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 From seamoby-admin@ietf.org Wed Jul 17 20:34:33 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA03881 for ; Wed, 17 Jul 2002 20:34:33 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA10103; Wed, 17 Jul 2002 20:27:11 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA10074 for ; Wed, 17 Jul 2002 20:27:09 -0400 (EDT) Received: from motgate4.mot.com (motgate4.mot.com [144.189.100.102]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA03637 for ; Wed, 17 Jul 2002 20:26:12 -0400 (EDT) Received: [from pobox4.mot.com (pobox4.mot.com [10.64.251.243]) by motgate4.mot.com (motgate4 2.1) with ESMTP id RAA13089 for ; Wed, 17 Jul 2002 17:27:09 -0700 (MST)] Received: [from il75exm04.cig.mot.com ([136.182.110.113]) by pobox4.mot.com (MOT-pobox4 2.0) with ESMTP id RAA14805 for ; Wed, 17 Jul 2002 17:27:09 -0700 (MST)] Received: by IL75EXM04 with Internet Mail Service (5.5.2654.52) id ; Wed, 17 Jul 2002 19:27:08 -0500 Message-ID: <35DBB8B7AC89D4118E98009027B1009B08AD55BC@IL27EXM10.cig.mot.com> From: Nakhjiri Madjid-MNAKHJI1 To: Nakhjiri Madjid-MNAKHJI1 , "'Gary Kenward'" , "'James Kempf'" , john.loughney@nokia.com, seamoby@ietf.org Subject: RE: [Seamoby] Proposal on Sync/NoSync Requirement Date: Wed, 17 Jul 2002 19:25:41 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.52) Content-Type: text/plain; charset="iso-8859-1" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Sorry, one correction in my previous email: Any change of context at the supporting AR must be replicated at those ARs that have already received context for that MN. Madjid>> MUSt is too strong. 5.5.1 is SHOULD, so should this one be (sorry for too many shoulds :)) There are ways to avoid having to do this through CT. Here I meant 5.5.1 only says MUST be capable of supporting (which I consider as a "should", i.e. individual feature may or may not use it. In any case I think, it should say: Any change of context at the supporting AR SHOULD be replicated at those ARs that have already received context for that MN. _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Wed Jul 17 20:34:34 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA03888 for ; Wed, 17 Jul 2002 20:34:33 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id UAA11106 for seamoby-archive@odin.ietf.org; Wed, 17 Jul 2002 20:35:30 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA10103; Wed, 17 Jul 2002 20:27:11 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA10074 for ; Wed, 17 Jul 2002 20:27:09 -0400 (EDT) Received: from motgate4.mot.com (motgate4.mot.com [144.189.100.102]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA03637 for ; Wed, 17 Jul 2002 20:26:12 -0400 (EDT) Received: [from pobox4.mot.com (pobox4.mot.com [10.64.251.243]) by motgate4.mot.com (motgate4 2.1) with ESMTP id RAA13089 for ; Wed, 17 Jul 2002 17:27:09 -0700 (MST)] Received: [from il75exm04.cig.mot.com ([136.182.110.113]) by pobox4.mot.com (MOT-pobox4 2.0) with ESMTP id RAA14805 for ; Wed, 17 Jul 2002 17:27:09 -0700 (MST)] Received: by IL75EXM04 with Internet Mail Service (5.5.2654.52) id ; Wed, 17 Jul 2002 19:27:08 -0500 Message-ID: <35DBB8B7AC89D4118E98009027B1009B08AD55BC@IL27EXM10.cig.mot.com> From: Nakhjiri Madjid-MNAKHJI1 To: Nakhjiri Madjid-MNAKHJI1 , "'Gary Kenward'" , "'James Kempf'" , john.loughney@nokia.com, seamoby@ietf.org Subject: RE: [Seamoby] Proposal on Sync/NoSync Requirement Date: Wed, 17 Jul 2002 19:25:41 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.52) Content-Type: text/plain; charset="iso-8859-1" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Sorry, one correction in my previous email: Any change of context at the supporting AR must be replicated at those ARs that have already received context for that MN. Madjid>> MUSt is too strong. 5.5.1 is SHOULD, so should this one be (sorry for too many shoulds :)) There are ways to avoid having to do this through CT. Here I meant 5.5.1 only says MUST be capable of supporting (which I consider as a "should", i.e. individual feature may or may not use it. In any case I think, it should say: Any change of context at the supporting AR SHOULD be replicated at those ARs that have already received context for that MN. _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Thu Jul 18 07:18:25 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28594 for ; Thu, 18 Jul 2002 07:18:25 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA26393; Thu, 18 Jul 2002 07:16:35 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA26355 for ; Thu, 18 Jul 2002 07:16:33 -0400 (EDT) Received: from fridge.docomolabs-usa.com (fwuser@key1.docomolabs-usa.com [216.98.102.225]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28539 for ; Thu, 18 Jul 2002 07:15:34 -0400 (EDT) Message-ID: <001a01c22e4c$578dfaf0$926015ac@T23KEMPF> From: "James Kempf" To: Date: Thu, 18 Jul 2002 03:55:12 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Seamoby] Terminology Draft Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit Hi, In Salt Lake, we agreed to make draft-manner-seamoby-terms-04.txt a working group document. This contains mobility related turns in common use within the IETF at this time. Is there any objection to making this draft a working group draft? jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@ns.ietf.org Thu Jul 18 07:18:27 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28607 for ; Thu, 18 Jul 2002 07:18:26 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA26617 for seamoby-archive@odin.ietf.org; Thu, 18 Jul 2002 07:19:24 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA26393; Thu, 18 Jul 2002 07:16:35 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA26355 for ; Thu, 18 Jul 2002 07:16:33 -0400 (EDT) Received: from fridge.docomolabs-usa.com (fwuser@key1.docomolabs-usa.com [216.98.102.225]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28539 for ; Thu, 18 Jul 2002 07:15:34 -0400 (EDT) Message-ID: <001a01c22e4c$578dfaf0$926015ac@T23KEMPF> From: "James Kempf" To: Date: Thu, 18 Jul 2002 03:55:12 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Seamoby] Terminology Draft Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit Hi, In Salt Lake, we agreed to make draft-manner-seamoby-terms-04.txt a working group document. This contains mobility related turns in common use within the IETF at this time. Is there any objection to making this draft a working group draft? jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Thu Jul 18 07:18:29 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28620 for ; Thu, 18 Jul 2002 07:18:29 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA26419; Thu, 18 Jul 2002 07:16:38 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA26364 for ; Thu, 18 Jul 2002 07:16:34 -0400 (EDT) Received: from fridge.docomolabs-usa.com (fwuser@key1.docomolabs-usa.com [216.98.102.225]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28542 for ; Thu, 18 Jul 2002 07:15:35 -0400 (EDT) Message-ID: <001b01c22e4c$584d0530$926015ac@T23KEMPF> From: "James Kempf" To: Cc: Date: Thu, 18 Jul 2002 04:14:16 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Seamoby] Section 5.2 in CT Requirements Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit Folks, So recently I had another look at the CT Requirements document and I was suprised to find Section 5.2. It says this: 5.2 Transport Reliability This section is intentionally left blank as the working group is waiting for a questionnaire from the transport directorate. The result of the questionnaire will create requirements that will be added in this section in a later revision of this specification. It is completely unacceptable that we sent this document to the IESG with this section in it. When a document passes through last call, it should be complete. As WG chairs, Pat and I naturally must accept responsibility for this, but this should really have been caught in WG Last Call. I would like suggest replacing Section 5.2 with the following: 5.2 Transport Requirements This section contains requirements on the context transfer transport. 5.1 Independence of Underlying Transport The context transfer solution MUST be independent of the underlying transport. It SHOULD be possible to transfer context directly on top of reliable transports, such as TCP or SCTP, unreliable transports, such as UDP, or as an option or extention on another protocol, such as handover signaling. Comments? jak u _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@ns.ietf.org Thu Jul 18 07:18:30 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28629 for ; Thu, 18 Jul 2002 07:18:29 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA26628 for seamoby-archive@odin.ietf.org; Thu, 18 Jul 2002 07:19:27 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA26419; Thu, 18 Jul 2002 07:16:38 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA26364 for ; Thu, 18 Jul 2002 07:16:34 -0400 (EDT) Received: from fridge.docomolabs-usa.com (fwuser@key1.docomolabs-usa.com [216.98.102.225]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28542 for ; Thu, 18 Jul 2002 07:15:35 -0400 (EDT) Message-ID: <001b01c22e4c$584d0530$926015ac@T23KEMPF> From: "James Kempf" To: Cc: Date: Thu, 18 Jul 2002 04:14:16 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Seamoby] Section 5.2 in CT Requirements Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit Folks, So recently I had another look at the CT Requirements document and I was suprised to find Section 5.2. It says this: 5.2 Transport Reliability This section is intentionally left blank as the working group is waiting for a questionnaire from the transport directorate. The result of the questionnaire will create requirements that will be added in this section in a later revision of this specification. It is completely unacceptable that we sent this document to the IESG with this section in it. When a document passes through last call, it should be complete. As WG chairs, Pat and I naturally must accept responsibility for this, but this should really have been caught in WG Last Call. I would like suggest replacing Section 5.2 with the following: 5.2 Transport Requirements This section contains requirements on the context transfer transport. 5.1 Independence of Underlying Transport The context transfer solution MUST be independent of the underlying transport. It SHOULD be possible to transfer context directly on top of reliable transports, such as TCP or SCTP, unreliable transports, such as UDP, or as an option or extention on another protocol, such as handover signaling. Comments? jak u _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Thu Jul 18 07:53:26 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA29551 for ; Thu, 18 Jul 2002 07:53:26 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA28478; Thu, 18 Jul 2002 07:48:29 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA28449 for ; Thu, 18 Jul 2002 07:48:27 -0400 (EDT) Received: from porsta.cs.Helsinki.FI (root@porsta.cs.Helsinki.FI [128.214.48.124]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA29453 for ; Thu, 18 Jul 2002 07:47:28 -0400 (EDT) Received: from melkinpaasi.cs.Helsinki.FI (IDENT:jmanner@melkinpaasi.cs.Helsinki.FI [128.214.10.13]) by porsta.cs.Helsinki.FI (8.11.6/8.11.6) with ESMTP id g6IBmPk32516 for ; Thu, 18 Jul 2002 14:48:25 +0300 Date: Thu, 18 Jul 2002 14:48:21 +0300 (EEST) From: Jukka MJ Manner To: seamoby@ietf.org Subject: Re: [Seamoby] Terminology Draft In-Reply-To: <001a01c22e4c$578dfaf0$926015ac@T23KEMPF> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Hi, related to James' email, here is the actual announcement from June. Additions to a next version could include some of the very basic terminology from NEMO. Regards, Jim A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Mobility Related Terminology Author(s) : J. Manner, M. Kojo Filename : draft-manner-seamoby-terms-04.txt Pages : 29 Date : 31-May-02 There is a need for common definitions of terminology in the work to be done around IP mobility. This memo defines terms for mobility related terminology. It is intended as a living document for use by the Seamoby working group, and especially for use in Seamoby drafts and in WG discussions. Other working groups dealing with mobility may also take advantage of this terminology A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-manner-seamoby-terms-04.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-manner-seamoby-terms-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-manner-seamoby-terms-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. On Thu, 18 Jul 2002, James Kempf wrote: > Hi, > > In Salt Lake, we agreed to make draft-manner-seamoby-terms-04.txt a working > group document. This contains mobility related turns in common use within the > IETF at this time. > > Is there any objection to making this draft a working group draft? > > jak > > > _______________________________________________ > 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 From daemon@ns.ietf.org Thu Jul 18 07:53:26 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA29558 for ; Thu, 18 Jul 2002 07:53:26 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA28695 for seamoby-archive@odin.ietf.org; Thu, 18 Jul 2002 07:54:24 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA28478; Thu, 18 Jul 2002 07:48:29 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA28449 for ; Thu, 18 Jul 2002 07:48:27 -0400 (EDT) Received: from porsta.cs.Helsinki.FI (root@porsta.cs.Helsinki.FI [128.214.48.124]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA29453 for ; Thu, 18 Jul 2002 07:47:28 -0400 (EDT) Received: from melkinpaasi.cs.Helsinki.FI (IDENT:jmanner@melkinpaasi.cs.Helsinki.FI [128.214.10.13]) by porsta.cs.Helsinki.FI (8.11.6/8.11.6) with ESMTP id g6IBmPk32516 for ; Thu, 18 Jul 2002 14:48:25 +0300 Date: Thu, 18 Jul 2002 14:48:21 +0300 (EEST) From: Jukka MJ Manner To: seamoby@ietf.org Subject: Re: [Seamoby] Terminology Draft In-Reply-To: <001a01c22e4c$578dfaf0$926015ac@T23KEMPF> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Hi, related to James' email, here is the actual announcement from June. Additions to a next version could include some of the very basic terminology from NEMO. Regards, Jim A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Mobility Related Terminology Author(s) : J. Manner, M. Kojo Filename : draft-manner-seamoby-terms-04.txt Pages : 29 Date : 31-May-02 There is a need for common definitions of terminology in the work to be done around IP mobility. This memo defines terms for mobility related terminology. It is intended as a living document for use by the Seamoby working group, and especially for use in Seamoby drafts and in WG discussions. Other working groups dealing with mobility may also take advantage of this terminology A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-manner-seamoby-terms-04.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-manner-seamoby-terms-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-manner-seamoby-terms-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. On Thu, 18 Jul 2002, James Kempf wrote: > Hi, > > In Salt Lake, we agreed to make draft-manner-seamoby-terms-04.txt a working > group document. This contains mobility related turns in common use within the > IETF at this time. > > Is there any objection to making this draft a working group draft? > > jak > > > _______________________________________________ > 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 From seamoby-admin@ietf.org Thu Jul 18 11:02:26 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04188 for ; Thu, 18 Jul 2002 11:02:26 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA11638; Thu, 18 Jul 2002 10:56:44 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA11573 for ; Thu, 18 Jul 2002 10:56:40 -0400 (EDT) Received: from zcars04e.ca.nortel.com (zcars04e.nortelnetworks.com [47.129.242.56]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03964 for ; Thu, 18 Jul 2002 10:55:42 -0400 (EDT) Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g6IEq4W28734; Thu, 18 Jul 2002 10:52:04 -0400 (EDT) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 18 Jul 2002 10:52:04 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA4C39@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'Nakhjiri Madjid-MNAKHJI1'" , "'Charles E. Perkins'" Cc: seamoby@ietf.org Subject: RE: [Seamoby] CT Requirements Comments from IESG Date: Thu, 18 Jul 2002 10:52:02 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C22E69.E28B694A" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C22E69.E28B694A Content-Type: text/plain; charset="iso-8859-1" Define "done"? Seriously, if CT is performed during or after a handover (reactively) then, yes, there's not much more that can be done. If the context at the destination is out of synch with changes in the source context, there is an increased risk that the seamlessness of the handover will be degraded. However, if CT is performed before a handover begins (proactively), and changes occur at the source AR, then it would seem reasonable to attempt updates. There is a presumption here that there is something to be gained in handover performance by performing CT in advance of an actual handover. It could turn out that CT (and the subsequent installion of context at the destination AR) is so fast, that leaving the transfer of context until a handover occurs (i.e. no proactive, only reactive) is a sufficient, and simpler solution. We really won't know whether this is the case until the wg starts looking at CT solutions. Cheers, Gary -----Original Message----- From: Nakhjiri Madjid-MNAKHJI1 [mailto:Madjid.Nakhjiri@motorola.com] Sent: July 17, 2002 19:25 To: Kenward, Gary [WDLN2:AN10:EXCH]; 'Charles E. Perkins' Cc: seamoby@ietf.org Subject: RE: [Seamoby] CT Requirements Comments from IESG Well, not trying to regurgitate (as you said) but we never agreed on timing and reliability requirements and maybe that was ok, because they depend on the scenario and protocols. So why talk about sending updates after CT is done? Madjid -----Original Message----- From: Gary Kenward [mailto:gkenward@nortelnetworks.com] Sent: Friday, July 12, 2002 2:35 PM To: 'Charles E. Perkins' Cc: seamoby@ietf.org Subject: RE: [Seamoby] CT Requirements Comments from IESG I agree Charlie. However, we have to fix the issue with the requirements. Are you suggesting that we relax the requirement? By how much - clearly, some updates are required (e.g. CT really should try and update when flows come and go). Gary > -----Original Message----- > From: Charles E. Perkins [ mailto:charliep@iprg.nokia.com ] > Sent: July 12, 2002 12:15 > To: Kenward, Gary [WDLN2:AN10:EXCH] > Cc: seamoby@ietf.org > Subject: Re: [Seamoby] CT Requirements Comments from IESG > > > > > Hello folks, > > I think we ought to try to get context transfers > working correctly without initially worrying about > this synchronization problem. > > In the instances I am familiar with, it is not > required. The most stringent case seems to be > ROHC, and even for that it is not necessary. > > We can solve the most urgent problems without having > to deal with any additional context synchronization. > When the old AR sends it, and the new AR gets it, > we should consider the transfer done. In those > cases where reliability is at issue, the old AR > can retransmit when ACK is not received. In many > cases, retransmission of context even once won't > be useful. > > Regards, > Charlie P. > > > > > Gary Kenward wrote: > > > > James: > > > > Yes, we need to fix it, and I think it is doable. > > Thanks to Dirk for highlighting the real problem here > > (I think historically, the integrity requirement came out > > of the reliability section, and somehow, got lumped with > > synchronization and updates). > > > > I think the requirements need a bit of rewording, and > > the paragraph should fall out from this. I do believe > > however, that making the synchronization of context between > > old and new AR a MUST requirement would be too extreme, and > > result in a brittle solution. CT should certainly do it's best to > > provide synchronization, but as was discussed in a recent > > exchange, it would be impossible to guarantee synchronization > > at any instant. > > > > Any ideas/comments from the wg? > > > > Gary > > > > > -----Original Message----- > > > From: James Kempf [ mailto:kempf@docomolabs-usa.com ] > > > Sent: July 11, 2002 18:32 > > > To: Kenward, Gary [WDLN2:AN10:EXCH]; Dirk.Trossen@nokia.com; > > > seamoby@ietf.org > > > Subject: Re: [Seamoby] CT Requirements Comments from IESG > > > > > > > > > Gary/Dirk, > > > > > > I think you may be on to something here. I think this might > > > be what the IESG was talking about it the first point, namely the > > > lack of discussion of dynamic changes in the context. > > > > > > Is there some way we could cook this idea down into a > > > paragraph that we could insert for this requirement? > > > > > > jak > > > > > > ----- Original Message ----- > > > From: "Gary Kenward" > > > To: ; ; > > > > > > Sent: Thursday, July 11, 2002 1:56 PM > > > Subject: RE: [Seamoby] CT Requirements Comments from IESG > > > > > > > > > > Dirk: > > > > > > > > A valid point. There is a certain atomic level of > > > granularity which has to > > > > be > > > > dealt with - that is, there's no protocol in the world that > > > can synchronize > > > > changes in > > > > information that occur at the source while the information > > > is "in-flight" or > > > > being > > > > received at the destination. If changes in context while > > > the context is > > > > being transferred > > > > make a different to the successful performance of CT, then > > > there is no hope. > > > > > > > > The problem is most significant for state context > > > transfer. E.g. counters > > > > will continue > > > > to count while CT is moving the context to the destination. > > > Either these > > > > changes have no > > > > significant impact upon the forwarding service provided at > > > the new AR (e.g. > > > > it may not > > > > matter that a policing meter misses a few packet counts), > > > or a different > > > > mechanism > > > > has to be defined for re-establishing the state context. > > > > > > > > The handover is real and unavoidable. Mitigating the > > > disruption to the > > > > service at the new > > > > AR is the challenge. It would be nice if the disruption > was nil, but > > > > unlikely. > > > > > > > > Gary > > > > > > > > -----Original Message----- > > > > From: Dirk.Trossen@nokia.com [ mailto:Dirk.Trossen@nokia.com ] > > > > Sent: July 11, 2002 16:30 > > > > To: Kenward, Gary [WDLN2:AN10:EXCH]; kempf@docomolabs-usa.com; > > > > seamoby@ietf.org > > > > Subject: RE: [Seamoby] CT Requirements Comments from IESG > > > > > > > > > > > > Hi all, > > > > > > > > jumping in as somebody who has been an observer so far, > > > struggling with the > > > > current discussion on > > > > 'integrity'. > > > > > > > > When I look at the current wording, i.e., > > > > "5.5.2 A context update MUST preserve the integrity, and > > > thus the meaning, > > > > of the context > > > > at each receiving AR. The context at the AR actually > > > supporting an MN's > > > > traffic will change with time. > > > > For example, the MN may initiate new microflow(s), or > > > discontinue existing > > > > microflows. Any change of context > > > > at the supporting AR must be replicated at those ARs that > > > have already > > > > received context for that MN.", > > > > > > > > and compare this to the plain integrity of the actually > > > transmitted data > > > > (i.e., its bits and therefore its semantics) > > > > that has been brought to the table as a replacement now, > > > I'm quite confident > > > > that this is not what the requirement > > > > is talking about. > > > > > > > > If we remove the word 'meaning' (which is very vague > and free for > > > > interpretation for me as well), it is still the word > > > > 'integrity' left, which is more than plain integrity of the > > > transmitted > > > > data, in particular if we look at the following sentences > > > > in the requirement, which state what kind of integrity is > > > meant (which > > > > probably also builds the bridge to the vague > > > > term 'meaning'), namely that the integrity of a context > > > must be preserved in > > > > the sense that a received context at new > > > > AR at some point t must be the same as the context at old > > > AR at the same > > > > time t. This is by far more than plain data > > > > integrity of the transmitted data. Even if your data has > > > been transmitted > > > > correctly, the context might be stale (and therefore > > > > its integrity is lost) because it had changed at old AR in > > > the meanwhile. > > > > The action to be taken is also given in the text, > > > > namely the change of context has to be replicated to the > > > new AR. As you can > > > > (hopefully) see this is by far more than > > > > preserving the 'meaning' of each bit. It mandates that > > > changes in the bit > > > > values at one end are reflected at the other > > > > end, i.e., it talks about distributed data integrity in my > > > interpretation of > > > > the requirement text. > > > > > > > > Hence, the actual concern might have been (just guessing) > > > whether or not it > > > > is the task of the CT protocol to > > > > preserve the abovementioned integrity. Maybe, the IESG > > > wants to see this > > > > functionality left to the replication logic that resides > > > > within each AR. Or on the contrary, they do not see this > > > important topic > > > > covered appropriately. > > > > > > > > Regards, > > > > > > > > > > > > Dirk > > > > > > > > -----Original Message----- > > > > From: ext Gary Kenward [ mailto:gkenward@nortelnetworks.com ] > > > > Sent: Thursday, July 11, 2002 3:48 PM > > > > To: 'James Kempf'; seamoby@ietf.org > > > > Subject: RE: [Seamoby] CT Requirements Comments from IESG > > > > > > > > > > > > > > > > You call it fidelity, I call it data integrity. > > > > I've seen "data integrity" used in publications > > > > (no, I cannot quote references). > > > > > > > > What we need is a term that everyone, including the > > > > IESG, can agree upon. > > > > > > > > > -----Original Message----- > > > > > From: James Kempf [ mailto:kempf@docomolabs-usa.com > > > > < mailto:kempf@docomolabs-usa.com > ] > > > > > Sent: July 11, 2002 12:22 > > > > > To: Kenward, Gary [WDLN2:AN10:EXCH]; seamoby@ietf.org > > > > > Subject: Re: [Seamoby] CT Requirements Comments from IESG > > > > > > > > > > > > > > > > Perhaps the actual answer is to state exactly what > was intended > > > > > > originally: that the bit order and bit values have to > > > arrive exactly > > > > > > as they were transmitted. > > > > > > > > > > > > > > > > So this requirement is talking about transmission fidelity? I > > > > > sure would not have guessed that from reading it. I thought it > > > > > intended to talk about usability. > > > > > > > > > > I would suggest that the wording you have above is really a > > > > > lot more precise that what is currently in the spec. > > > > > > > > > > Any other comments? Could we substitute Gary's wording above > > > > > for "meaning" in the current requirement. > > > > > > > > > > jak > > > > > > > > > > > > > > > > > > > > > > > > > ------_=_NextPart_001_01C22E69.E28B694A Content-Type: text/html; charset="iso-8859-1" RE: [Seamoby] CT Requirements Comments from IESG
Define "done"?
 
Seriously, if CT is performed during or after a handover (reactively)
then, yes, there's not much more that can be done. If the context at
the destination is out of synch with changes in the source context,
there is an increased risk that the seamlessness of the handover will
be degraded.
 
However, if CT is performed before a handover begins (proactively),
and changes occur at the source AR, then it would seem reasonable to
attempt updates. There is a presumption here that there is something
to be gained in handover performance by performing CT in advance of
an actual handover. It could turn out that CT (and the subsequent installion
of context at the destination AR) is so fast, that leaving the transfer
of context until a handover occurs (i.e. no proactive, only reactive) is
a sufficient, and simpler solution. We really won't know whether this
is the case until the wg starts looking at CT solutions.

Cheers,
Gary
-----Original Message-----
From: Nakhjiri Madjid-MNAKHJI1 [mailto:Madjid.Nakhjiri@motorola.com]
Sent: July 17, 2002 19:25
To: Kenward, Gary [WDLN2:AN10:EXCH]; 'Charles E. Perkins'
Cc: seamoby@ietf.org
Subject: RE: [Seamoby] CT Requirements Comments from IESG

Well, not trying to regurgitate (as you said)
but we never agreed on timing and reliability requirements and maybe
that was ok, because they depend on the scenario and protocols.
So why talk about sending updates after CT is done?
 
 
Madjid
-----Original Message-----
From: Gary Kenward [mailto:gkenward@nortelnetworks.com]
Sent: Friday, July 12, 2002 2:35 PM
To: 'Charles E. Perkins'
Cc: seamoby@ietf.org
Subject: RE: [Seamoby] CT Requirements Comments from IESG

I agree Charlie. However, we have to fix the issue with
the requirements. Are you suggesting that we relax the
requirement? By how much - clearly, some updates are required
(e.g. CT really should try and update when flows come and go).

Gary

> -----Original Message-----
> From: Charles E. Perkins [mailto:charliep@iprg.nokia.com]
> Sent: July 12, 2002 12:15
> To: Kenward, Gary [WDLN2:AN10:EXCH]
> Cc: seamoby@ietf.org
> Subject: Re: [Seamoby] CT Requirements Comments from IESG
>
>
>
>
> Hello folks,
>
> I think we ought to try to get context transfers
> working correctly without initially worrying about
> this synchronization problem.
>
> In the instances I am familiar with, it is not
> required.  The most stringent case seems to be
> ROHC, and even for that it is not necessary.
>
> We can solve the most urgent problems without having
> to deal with any additional context synchronization.
> When the old AR sends it, and the new AR gets it,
> we should consider the transfer done.  In those
> cases where reliability is at issue, the old AR
> can retransmit when ACK is not received.  In many
> cases, retransmission of context even once won't
> be useful.
>
> Regards,
> Charlie P.
>
>
>
> > Gary Kenward wrote:
> >
> > James:
> >
> >   Yes, we need to fix it, and I think it is doable.
> > Thanks to Dirk for highlighting the real problem here
> > (I think historically, the integrity requirement came out
> > of the reliability section, and somehow, got lumped with
> > synchronization and updates).
> >
> >   I think the requirements need a bit of rewording, and
> > the paragraph should fall out from this. I do believe
> > however, that making the synchronization of context between
> > old and new AR a MUST requirement would be too extreme, and
> > result in a brittle solution. CT should certainly do it's best to
> > provide synchronization, but as was discussed in a recent
> > exchange, it would be impossible to guarantee synchronization
> > at any instant.
> >
> >   Any ideas/comments from the wg?
> >
> > Gary
> >
> > > -----Original Message-----
> > > From: James Kempf [mailto:kempf@docomolabs-usa.com]
> > > Sent: July 11, 2002 18:32
> > > To: Kenward, Gary [WDLN2:AN10:EXCH]; Dirk.Trossen@nokia.com;
> > > seamoby@ietf.org
> > > Subject: Re: [Seamoby] CT Requirements Comments from IESG
> > >
> > >
> > > Gary/Dirk,
> > >
> > > I think you may be on to something here. I think this might
> > > be what the IESG was talking about it the first point, namely the
> > > lack of discussion of dynamic changes in the context.
> > >
> > > Is there some way we could cook this idea down into a
> > > paragraph that we could insert for this requirement?
> > >
> > >             jak
> > >
> > > ----- Original Message -----
> > > From: "Gary Kenward" <gkenward@nortelnetworks.com>
> > > To: <Dirk.Trossen@nokia.com>; <kempf@docomolabs-usa.com>;
> > > <seamoby@ietf.org>
> > > Sent: Thursday, July 11, 2002 1:56 PM
> > > Subject: RE: [Seamoby] CT Requirements Comments from IESG
> > >
> > >
> > > > Dirk:
> > > >
> > > >   A valid point. There is a certain atomic level of
> > > granularity which has to
> > > > be
> > > > dealt with - that is, there's no protocol in the world that
> > > can synchronize
> > > > changes in
> > > > information that occur at the source while the information
> > > is "in-flight" or
> > > > being
> > > > received at the destination. If changes in context while
> > > the context is
> > > > being transferred
> > > > make a different to the successful performance of CT, then
> > > there is no hope.
> > > >
> > > >   The problem is most significant for state context
> > > transfer. E.g. counters
> > > > will continue
> > > > to count while CT is moving the context to the destination.
> > > Either these
> > > > changes have no
> > > > significant impact upon the forwarding service provided at
> > > the new AR (e.g.
> > > > it may not
> > > > matter that a policing meter misses a few packet counts),
> > > or a different
> > > > mechanism
> > > > has to be defined for re-establishing the state context.
> > > >
> > > >   The handover is real and unavoidable. Mitigating the
> > > disruption to the
> > > > service at the new
> > > > AR is the challenge. It would be nice if the disruption
> was nil, but
> > > > unlikely.
> > > >
> > > > Gary
> > > >
> > > > -----Original Message-----
> > > > From: Dirk.Trossen@nokia.com [mailto:Dirk.Trossen@nokia.com]
> > > > Sent: July 11, 2002 16:30
> > > > To: Kenward, Gary [WDLN2:AN10:EXCH]; kempf@docomolabs-usa.com;
> > > > seamoby@ietf.org
> > > > Subject: RE: [Seamoby] CT Requirements Comments from IESG
> > > >
> > > >
> > > > Hi all,
> > > >
> > > > jumping in as somebody who has been an observer so far,
> > > struggling with the
> > > > current discussion on
> > > > 'integrity'.
> > > >
> > > > When I look at the current wording, i.e.,
> > > > "5.5.2 A context update MUST preserve the integrity, and
> > > thus the meaning,
> > > > of the context
> > > > at each receiving AR. The context at the AR actually
> > > supporting an MN's
> > > > traffic will change with time.
> > > > For example, the MN may initiate new microflow(s), or
> > > discontinue existing
> > > > microflows. Any change of context
> > > > at the supporting AR must be replicated at those ARs that
> > > have already
> > > > received context for that MN.",
> > > >
> > > > and compare this to the plain integrity of the actually
> > > transmitted data
> > > > (i.e., its bits and therefore its semantics)
> > > > that has been brought to the table as a replacement now,
> > > I'm quite confident
> > > > that this is not what the requirement
> > > > is talking about.
> > > >
> > > > If we remove the word 'meaning' (which is very vague
> and free for
> > > > interpretation for me as well), it is still the word
> > > > 'integrity' left, which is more than plain integrity of the
> > > transmitted
> > > > data, in particular if we look at the following sentences
> > > > in the requirement, which state what kind of integrity is
> > > meant (which
> > > > probably also builds the bridge to the vague
> > > > term 'meaning'), namely that the integrity of a context
> > > must be preserved in
> > > > the sense that a received context at new
> > > > AR at some point t must be the same as the context at old
> > > AR at the same
> > > > time t. This is by far more than plain data
> > > > integrity of the transmitted data. Even if your data has
> > > been transmitted
> > > > correctly, the context might be stale (and therefore
> > > > its integrity is lost) because it had changed at old AR in
> > > the meanwhile.
> > > > The action to be taken is also given in the text,
> > > > namely the change of context has to be replicated to the
> > > new AR. As you can
> > > > (hopefully) see this is by far more than
> > > > preserving the 'meaning' of each bit. It mandates that
> > > changes in the bit
> > > > values at one end are reflected at the other
> > > > end, i.e., it talks about distributed data integrity in my
> > > interpretation of
> > > > the requirement text.
> > > >
> > > > Hence, the actual concern might have been (just guessing)
> > > whether or not it
> > > > is the task of the CT protocol to
> > > > preserve the abovementioned integrity. Maybe, the IESG
> > > wants to see this
> > > > functionality left to the replication logic that resides
> > > > within each AR. Or on the contrary, they do not see this
> > > important topic
> > > > covered appropriately.
> > > >
> > > > Regards,
> > > >
> > > >
> > > > Dirk
> > > >
> > > > -----Original Message-----
> > > > From: ext Gary Kenward [mailto:gkenward@nortelnetworks.com]
> > > > Sent: Thursday, July 11, 2002 3:48 PM
> > > > To: 'James Kempf'; seamoby@ietf.org
> > > > Subject: RE: [Seamoby] CT Requirements Comments from IESG
> > > >
> > > >
> > > >
> > > > You call it fidelity, I call it data integrity.
> > > > I've seen "data integrity" used in publications
> > > > (no, I cannot quote references).
> > > >
> > > > What we need is a term that everyone, including the
> > > > IESG, can agree upon.
> > > >
> > > > > -----Original Message-----
> > > > > From: James Kempf [ mailto:kempf@docomolabs-usa.com
> > > > <mailto:kempf@docomolabs-usa.com> ]
> > > > > Sent: July 11, 2002 12:22
> > > > > To: Kenward, Gary [WDLN2:AN10:EXCH]; seamoby@ietf.org
> > > > > Subject: Re: [Seamoby] CT Requirements Comments from IESG
> > > > >
> > > > >
> > > > > > Perhaps the actual answer is to state exactly what
> was intended
> > > > > > originally: that the bit order and bit values have to
> > > arrive exactly
> > > > > > as they were transmitted.
> > > > > >
> > > > >
> > > > > So this requirement is talking about transmission fidelity? I
> > > > > sure would not have guessed that from reading it. I thought it
> > > > > intended to talk about usability.
> > > > >
> > > > > I would suggest that the wording you have above is really a
> > > > > lot more precise that what is currently in the spec.
> > > > >
> > > > > Any other comments? Could we substitute Gary's wording above
> > > > > for "meaning" in the current requirement.
> > > > >
> > > > >             jak
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
>

------_=_NextPart_001_01C22E69.E28B694A-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Thu Jul 18 11:02:26 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04194 for ; Thu, 18 Jul 2002 11:02:26 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA12552 for seamoby-archive@odin.ietf.org; Thu, 18 Jul 2002 11:03:24 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA11638; Thu, 18 Jul 2002 10:56:44 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA11573 for ; Thu, 18 Jul 2002 10:56:40 -0400 (EDT) Received: from zcars04e.ca.nortel.com (zcars04e.nortelnetworks.com [47.129.242.56]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03964 for ; Thu, 18 Jul 2002 10:55:42 -0400 (EDT) Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g6IEq4W28734; Thu, 18 Jul 2002 10:52:04 -0400 (EDT) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 18 Jul 2002 10:52:04 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA4C39@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'Nakhjiri Madjid-MNAKHJI1'" , "'Charles E. Perkins'" Cc: seamoby@ietf.org Subject: RE: [Seamoby] CT Requirements Comments from IESG Date: Thu, 18 Jul 2002 10:52:02 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C22E69.E28B694A" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C22E69.E28B694A Content-Type: text/plain; charset="iso-8859-1" Define "done"? Seriously, if CT is performed during or after a handover (reactively) then, yes, there's not much more that can be done. If the context at the destination is out of synch with changes in the source context, there is an increased risk that the seamlessness of the handover will be degraded. However, if CT is performed before a handover begins (proactively), and changes occur at the source AR, then it would seem reasonable to attempt updates. There is a presumption here that there is something to be gained in handover performance by performing CT in advance of an actual handover. It could turn out that CT (and the subsequent installion of context at the destination AR) is so fast, that leaving the transfer of context until a handover occurs (i.e. no proactive, only reactive) is a sufficient, and simpler solution. We really won't know whether this is the case until the wg starts looking at CT solutions. Cheers, Gary -----Original Message----- From: Nakhjiri Madjid-MNAKHJI1 [mailto:Madjid.Nakhjiri@motorola.com] Sent: July 17, 2002 19:25 To: Kenward, Gary [WDLN2:AN10:EXCH]; 'Charles E. Perkins' Cc: seamoby@ietf.org Subject: RE: [Seamoby] CT Requirements Comments from IESG Well, not trying to regurgitate (as you said) but we never agreed on timing and reliability requirements and maybe that was ok, because they depend on the scenario and protocols. So why talk about sending updates after CT is done? Madjid -----Original Message----- From: Gary Kenward [mailto:gkenward@nortelnetworks.com] Sent: Friday, July 12, 2002 2:35 PM To: 'Charles E. Perkins' Cc: seamoby@ietf.org Subject: RE: [Seamoby] CT Requirements Comments from IESG I agree Charlie. However, we have to fix the issue with the requirements. Are you suggesting that we relax the requirement? By how much - clearly, some updates are required (e.g. CT really should try and update when flows come and go). Gary > -----Original Message----- > From: Charles E. Perkins [ mailto:charliep@iprg.nokia.com ] > Sent: July 12, 2002 12:15 > To: Kenward, Gary [WDLN2:AN10:EXCH] > Cc: seamoby@ietf.org > Subject: Re: [Seamoby] CT Requirements Comments from IESG > > > > > Hello folks, > > I think we ought to try to get context transfers > working correctly without initially worrying about > this synchronization problem. > > In the instances I am familiar with, it is not > required. The most stringent case seems to be > ROHC, and even for that it is not necessary. > > We can solve the most urgent problems without having > to deal with any additional context synchronization. > When the old AR sends it, and the new AR gets it, > we should consider the transfer done. In those > cases where reliability is at issue, the old AR > can retransmit when ACK is not received. In many > cases, retransmission of context even once won't > be useful. > > Regards, > Charlie P. > > > > > Gary Kenward wrote: > > > > James: > > > > Yes, we need to fix it, and I think it is doable. > > Thanks to Dirk for highlighting the real problem here > > (I think historically, the integrity requirement came out > > of the reliability section, and somehow, got lumped with > > synchronization and updates). > > > > I think the requirements need a bit of rewording, and > > the paragraph should fall out from this. I do believe > > however, that making the synchronization of context between > > old and new AR a MUST requirement would be too extreme, and > > result in a brittle solution. CT should certainly do it's best to > > provide synchronization, but as was discussed in a recent > > exchange, it would be impossible to guarantee synchronization > > at any instant. > > > > Any ideas/comments from the wg? > > > > Gary > > > > > -----Original Message----- > > > From: James Kempf [ mailto:kempf@docomolabs-usa.com ] > > > Sent: July 11, 2002 18:32 > > > To: Kenward, Gary [WDLN2:AN10:EXCH]; Dirk.Trossen@nokia.com; > > > seamoby@ietf.org > > > Subject: Re: [Seamoby] CT Requirements Comments from IESG > > > > > > > > > Gary/Dirk, > > > > > > I think you may be on to something here. I think this might > > > be what the IESG was talking about it the first point, namely the > > > lack of discussion of dynamic changes in the context. > > > > > > Is there some way we could cook this idea down into a > > > paragraph that we could insert for this requirement? > > > > > > jak > > > > > > ----- Original Message ----- > > > From: "Gary Kenward" > > > To: ; ; > > > > > > Sent: Thursday, July 11, 2002 1:56 PM > > > Subject: RE: [Seamoby] CT Requirements Comments from IESG > > > > > > > > > > Dirk: > > > > > > > > A valid point. There is a certain atomic level of > > > granularity which has to > > > > be > > > > dealt with - that is, there's no protocol in the world that > > > can synchronize > > > > changes in > > > > information that occur at the source while the information > > > is "in-flight" or > > > > being > > > > received at the destination. If changes in context while > > > the context is > > > > being transferred > > > > make a different to the successful performance of CT, then > > > there is no hope. > > > > > > > > The problem is most significant for state context > > > transfer. E.g. counters > > > > will continue > > > > to count while CT is moving the context to the destination. > > > Either these > > > > changes have no > > > > significant impact upon the forwarding service provided at > > > the new AR (e.g. > > > > it may not > > > > matter that a policing meter misses a few packet counts), > > > or a different > > > > mechanism > > > > has to be defined for re-establishing the state context. > > > > > > > > The handover is real and unavoidable. Mitigating the > > > disruption to the > > > > service at the new > > > > AR is the challenge. It would be nice if the disruption > was nil, but > > > > unlikely. > > > > > > > > Gary > > > > > > > > -----Original Message----- > > > > From: Dirk.Trossen@nokia.com [ mailto:Dirk.Trossen@nokia.com ] > > > > Sent: July 11, 2002 16:30 > > > > To: Kenward, Gary [WDLN2:AN10:EXCH]; kempf@docomolabs-usa.com; > > > > seamoby@ietf.org > > > > Subject: RE: [Seamoby] CT Requirements Comments from IESG > > > > > > > > > > > > Hi all, > > > > > > > > jumping in as somebody who has been an observer so far, > > > struggling with the > > > > current discussion on > > > > 'integrity'. > > > > > > > > When I look at the current wording, i.e., > > > > "5.5.2 A context update MUST preserve the integrity, and > > > thus the meaning, > > > > of the context > > > > at each receiving AR. The context at the AR actually > > > supporting an MN's > > > > traffic will change with time. > > > > For example, the MN may initiate new microflow(s), or > > > discontinue existing > > > > microflows. Any change of context > > > > at the supporting AR must be replicated at those ARs that > > > have already > > > > received context for that MN.", > > > > > > > > and compare this to the plain integrity of the actually > > > transmitted data > > > > (i.e., its bits and therefore its semantics) > > > > that has been brought to the table as a replacement now, > > > I'm quite confident > > > > that this is not what the requirement > > > > is talking about. > > > > > > > > If we remove the word 'meaning' (which is very vague > and free for > > > > interpretation for me as well), it is still the word > > > > 'integrity' left, which is more than plain integrity of the > > > transmitted > > > > data, in particular if we look at the following sentences > > > > in the requirement, which state what kind of integrity is > > > meant (which > > > > probably also builds the bridge to the vague > > > > term 'meaning'), namely that the integrity of a context > > > must be preserved in > > > > the sense that a received context at new > > > > AR at some point t must be the same as the context at old > > > AR at the same > > > > time t. This is by far more than plain data > > > > integrity of the transmitted data. Even if your data has > > > been transmitted > > > > correctly, the context might be stale (and therefore > > > > its integrity is lost) because it had changed at old AR in > > > the meanwhile. > > > > The action to be taken is also given in the text, > > > > namely the change of context has to be replicated to the > > > new AR. As you can > > > > (hopefully) see this is by far more than > > > > preserving the 'meaning' of each bit. It mandates that > > > changes in the bit > > > > values at one end are reflected at the other > > > > end, i.e., it talks about distributed data integrity in my > > > interpretation of > > > > the requirement text. > > > > > > > > Hence, the actual concern might have been (just guessing) > > > whether or not it > > > > is the task of the CT protocol to > > > > preserve the abovementioned integrity. Maybe, the IESG > > > wants to see this > > > > functionality left to the replication logic that resides > > > > within each AR. Or on the contrary, they do not see this > > > important topic > > > > covered appropriately. > > > > > > > > Regards, > > > > > > > > > > > > Dirk > > > > > > > > -----Original Message----- > > > > From: ext Gary Kenward [ mailto:gkenward@nortelnetworks.com ] > > > > Sent: Thursday, July 11, 2002 3:48 PM > > > > To: 'James Kempf'; seamoby@ietf.org > > > > Subject: RE: [Seamoby] CT Requirements Comments from IESG > > > > > > > > > > > > > > > > You call it fidelity, I call it data integrity. > > > > I've seen "data integrity" used in publications > > > > (no, I cannot quote references). > > > > > > > > What we need is a term that everyone, including the > > > > IESG, can agree upon. > > > > > > > > > -----Original Message----- > > > > > From: James Kempf [ mailto:kempf@docomolabs-usa.com > > > > < mailto:kempf@docomolabs-usa.com > ] > > > > > Sent: July 11, 2002 12:22 > > > > > To: Kenward, Gary [WDLN2:AN10:EXCH]; seamoby@ietf.org > > > > > Subject: Re: [Seamoby] CT Requirements Comments from IESG > > > > > > > > > > > > > > > > Perhaps the actual answer is to state exactly what > was intended > > > > > > originally: that the bit order and bit values have to > > > arrive exactly > > > > > > as they were transmitted. > > > > > > > > > > > > > > > > So this requirement is talking about transmission fidelity? I > > > > > sure would not have guessed that from reading it. I thought it > > > > > intended to talk about usability. > > > > > > > > > > I would suggest that the wording you have above is really a > > > > > lot more precise that what is currently in the spec. > > > > > > > > > > Any other comments? Could we substitute Gary's wording above > > > > > for "meaning" in the current requirement. > > > > > > > > > > jak > > > > > > > > > > > > > > > > > > > > > > > > > ------_=_NextPart_001_01C22E69.E28B694A Content-Type: text/html; charset="iso-8859-1" RE: [Seamoby] CT Requirements Comments from IESG
Define "done"?
 
Seriously, if CT is performed during or after a handover (reactively)
then, yes, there's not much more that can be done. If the context at
the destination is out of synch with changes in the source context,
there is an increased risk that the seamlessness of the handover will
be degraded.
 
However, if CT is performed before a handover begins (proactively),
and changes occur at the source AR, then it would seem reasonable to
attempt updates. There is a presumption here that there is something
to be gained in handover performance by performing CT in advance of
an actual handover. It could turn out that CT (and the subsequent installion
of context at the destination AR) is so fast, that leaving the transfer
of context until a handover occurs (i.e. no proactive, only reactive) is
a sufficient, and simpler solution. We really won't know whether this
is the case until the wg starts looking at CT solutions.

Cheers,
Gary
-----Original Message-----
From: Nakhjiri Madjid-MNAKHJI1 [mailto:Madjid.Nakhjiri@motorola.com]
Sent: July 17, 2002 19:25
To: Kenward, Gary [WDLN2:AN10:EXCH]; 'Charles E. Perkins'
Cc: seamoby@ietf.org
Subject: RE: [Seamoby] CT Requirements Comments from IESG

Well, not trying to regurgitate (as you said)
but we never agreed on timing and reliability requirements and maybe
that was ok, because they depend on the scenario and protocols.
So why talk about sending updates after CT is done?
 
 
Madjid
-----Original Message-----
From: Gary Kenward [mailto:gkenward@nortelnetworks.com]
Sent: Friday, July 12, 2002 2:35 PM
To: 'Charles E. Perkins'
Cc: seamoby@ietf.org
Subject: RE: [Seamoby] CT Requirements Comments from IESG

I agree Charlie. However, we have to fix the issue with
the requirements. Are you suggesting that we relax the
requirement? By how much - clearly, some updates are required
(e.g. CT really should try and update when flows come and go).

Gary

> -----Original Message-----
> From: Charles E. Perkins [mailto:charliep@iprg.nokia.com]
> Sent: July 12, 2002 12:15
> To: Kenward, Gary [WDLN2:AN10:EXCH]
> Cc: seamoby@ietf.org
> Subject: Re: [Seamoby] CT Requirements Comments from IESG
>
>
>
>
> Hello folks,
>
> I think we ought to try to get context transfers
> working correctly without initially worrying about
> this synchronization problem.
>
> In the instances I am familiar with, it is not
> required.  The most stringent case seems to be
> ROHC, and even for that it is not necessary.
>
> We can solve the most urgent problems without having
> to deal with any additional context synchronization.
> When the old AR sends it, and the new AR gets it,
> we should consider the transfer done.  In those
> cases where reliability is at issue, the old AR
> can retransmit when ACK is not received.  In many
> cases, retransmission of context even once won't
> be useful.
>
> Regards,
> Charlie P.
>
>
>
> > Gary Kenward wrote:
> >
> > James:
> >
> >   Yes, we need to fix it, and I think it is doable.
> > Thanks to Dirk for highlighting the real problem here
> > (I think historically, the integrity requirement came out
> > of the reliability section, and somehow, got lumped with
> > synchronization and updates).
> >
> >   I think the requirements need a bit of rewording, and
> > the paragraph should fall out from this. I do believe
> > however, that making the synchronization of context between
> > old and new AR a MUST requirement would be too extreme, and
> > result in a brittle solution. CT should certainly do it's best to
> > provide synchronization, but as was discussed in a recent
> > exchange, it would be impossible to guarantee synchronization
> > at any instant.
> >
> >   Any ideas/comments from the wg?
> >
> > Gary
> >
> > > -----Original Message-----
> > > From: James Kempf [mailto:kempf@docomolabs-usa.com]
> > > Sent: July 11, 2002 18:32
> > > To: Kenward, Gary [WDLN2:AN10:EXCH]; Dirk.Trossen@nokia.com;
> > > seamoby@ietf.org
> > > Subject: Re: [Seamoby] CT Requirements Comments from IESG
> > >
> > >
> > > Gary/Dirk,
> > >
> > > I think you may be on to something here. I think this might
> > > be what the IESG was talking about it the first point, namely the
> > > lack of discussion of dynamic changes in the context.
> > >
> > > Is there some way we could cook this idea down into a
> > > paragraph that we could insert for this requirement?
> > >
> > >             jak
> > >
> > > ----- Original Message -----
> > > From: "Gary Kenward" <gkenward@nortelnetworks.com>
> > > To: <Dirk.Trossen@nokia.com>; <kempf@docomolabs-usa.com>;
> > > <seamoby@ietf.org>
> > > Sent: Thursday, July 11, 2002 1:56 PM
> > > Subject: RE: [Seamoby] CT Requirements Comments from IESG
> > >
> > >
> > > > Dirk:
> > > >
> > > >   A valid point. There is a certain atomic level of
> > > granularity which has to
> > > > be
> > > > dealt with - that is, there's no protocol in the world that
> > > can synchronize
> > > > changes in
> > > > information that occur at the source while the information
> > > is "in-flight" or
> > > > being
> > > > received at the destination. If changes in context while
> > > the context is
> > > > being transferred
> > > > make a different to the successful performance of CT, then
> > > there is no hope.
> > > >
> > > >   The problem is most significant for state context
> > > transfer. E.g. counters
> > > > will continue
> > > > to count while CT is moving the context to the destination.
> > > Either these
> > > > changes have no
> > > > significant impact upon the forwarding service provided at
> > > the new AR (e.g.
> > > > it may not
> > > > matter that a policing meter misses a few packet counts),
> > > or a different
> > > > mechanism
> > > > has to be defined for re-establishing the state context.
> > > >
> > > >   The handover is real and unavoidable. Mitigating the
> > > disruption to the
> > > > service at the new
> > > > AR is the challenge. It would be nice if the disruption
> was nil, but
> > > > unlikely.
> > > >
> > > > Gary
> > > >
> > > > -----Original Message-----
> > > > From: Dirk.Trossen@nokia.com [mailto:Dirk.Trossen@nokia.com]
> > > > Sent: July 11, 2002 16:30
> > > > To: Kenward, Gary [WDLN2:AN10:EXCH]; kempf@docomolabs-usa.com;
> > > > seamoby@ietf.org
> > > > Subject: RE: [Seamoby] CT Requirements Comments from IESG
> > > >
> > > >
> > > > Hi all,
> > > >
> > > > jumping in as somebody who has been an observer so far,
> > > struggling with the
> > > > current discussion on
> > > > 'integrity'.
> > > >
> > > > When I look at the current wording, i.e.,
> > > > "5.5.2 A context update MUST preserve the integrity, and
> > > thus the meaning,
> > > > of the context
> > > > at each receiving AR. The context at the AR actually
> > > supporting an MN's
> > > > traffic will change with time.
> > > > For example, the MN may initiate new microflow(s), or
> > > discontinue existing
> > > > microflows. Any change of context
> > > > at the supporting AR must be replicated at those ARs that
> > > have already
> > > > received context for that MN.",
> > > >
> > > > and compare this to the plain integrity of the actually
> > > transmitted data
> > > > (i.e., its bits and therefore its semantics)
> > > > that has been brought to the table as a replacement now,
> > > I'm quite confident
> > > > that this is not what the requirement
> > > > is talking about.
> > > >
> > > > If we remove the word 'meaning' (which is very vague
> and free for
> > > > interpretation for me as well), it is still the word
> > > > 'integrity' left, which is more than plain integrity of the
> > > transmitted
> > > > data, in particular if we look at the following sentences
> > > > in the requirement, which state what kind of integrity is
> > > meant (which
> > > > probably also builds the bridge to the vague
> > > > term 'meaning'), namely that the integrity of a context
> > > must be preserved in
> > > > the sense that a received context at new
> > > > AR at some point t must be the same as the context at old
> > > AR at the same
> > > > time t. This is by far more than plain data
> > > > integrity of the transmitted data. Even if your data has
> > > been transmitted
> > > > correctly, the context might be stale (and therefore
> > > > its integrity is lost) because it had changed at old AR in
> > > the meanwhile.
> > > > The action to be taken is also given in the text,
> > > > namely the change of context has to be replicated to the
> > > new AR. As you can
> > > > (hopefully) see this is by far more than
> > > > preserving the 'meaning' of each bit. It mandates that
> > > changes in the bit
> > > > values at one end are reflected at the other
> > > > end, i.e., it talks about distributed data integrity in my
> > > interpretation of
> > > > the requirement text.
> > > >
> > > > Hence, the actual concern might have been (just guessing)
> > > whether or not it
> > > > is the task of the CT protocol to
> > > > preserve the abovementioned integrity. Maybe, the IESG
> > > wants to see this
> > > > functionality left to the replication logic that resides
> > > > within each AR. Or on the contrary, they do not see this
> > > important topic
> > > > covered appropriately.
> > > >
> > > > Regards,
> > > >
> > > >
> > > > Dirk
> > > >
> > > > -----Original Message-----
> > > > From: ext Gary Kenward [mailto:gkenward@nortelnetworks.com]
> > > > Sent: Thursday, July 11, 2002 3:48 PM
> > > > To: 'James Kempf'; seamoby@ietf.org
> > > > Subject: RE: [Seamoby] CT Requirements Comments from IESG
> > > >
> > > >
> > > >
> > > > You call it fidelity, I call it data integrity.
> > > > I've seen "data integrity" used in publications
> > > > (no, I cannot quote references).
> > > >
> > > > What we need is a term that everyone, including the
> > > > IESG, can agree upon.
> > > >
> > > > > -----Original Message-----
> > > > > From: James Kempf [ mailto:kempf@docomolabs-usa.com
> > > > <mailto:kempf@docomolabs-usa.com> ]
> > > > > Sent: July 11, 2002 12:22
> > > > > To: Kenward, Gary [WDLN2:AN10:EXCH]; seamoby@ietf.org
> > > > > Subject: Re: [Seamoby] CT Requirements Comments from IESG
> > > > >
> > > > >
> > > > > > Perhaps the actual answer is to state exactly what
> was intended
> > > > > > originally: that the bit order and bit values have to
> > > arrive exactly
> > > > > > as they were transmitted.
> > > > > >
> > > > >
> > > > > So this requirement is talking about transmission fidelity? I
> > > > > sure would not have guessed that from reading it. I thought it
> > > > > intended to talk about usability.
> > > > >
> > > > > I would suggest that the wording you have above is really a
> > > > > lot more precise that what is currently in the spec.
> > > > >
> > > > > Any other comments? Could we substitute Gary's wording above
> > > > > for "meaning" in the current requirement.
> > > > >
> > > > >             jak
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
>

------_=_NextPart_001_01C22E69.E28B694A-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Thu Jul 18 11:21:50 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04669 for ; Thu, 18 Jul 2002 11:21:50 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA12994; Thu, 18 Jul 2002 11:17:12 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA12967 for ; Thu, 18 Jul 2002 11:17:10 -0400 (EDT) Received: from zcars04f.ca.nortel.com (zcars04f.nortelnetworks.com [47.129.242.57]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04490 for ; Thu, 18 Jul 2002 11:16:11 -0400 (EDT) Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04f.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g6IFGRp07175; Thu, 18 Jul 2002 11:16:28 -0400 (EDT) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 18 Jul 2002 11:16:27 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA4C3C@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'James Kempf'" , seamoby@ietf.org Cc: mankin@psg.com Subject: RE: [Seamoby] Section 5.2 in CT Requirements Date: Thu, 18 Jul 2002 11:16:26 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C22E6D.AC1DD768" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C22E6D.AC1DD768 Content-Type: text/plain; charset="iso-8859-1" James: There was a long and arduous debate over transport reliability. The wording you are objecting to was, I believe, Allison's suggestion. At the very lease, it was inserted with her approval in order to move the requirements forward. Of course, you can open the debate again, but I don't expect it to be resolved any better then it was the last time through. The problem is that there seems to be some very different ideas in the wg as to what the CT protocol looks like, with contradicting assumptions as to what is needed from a transport layer. Gary > -----Original Message----- > From: James Kempf [mailto:kempf@docomolabs-usa.com] > Sent: July 18, 2002 07:14 > To: seamoby@ietf.org > Cc: mankin@psg.com > Subject: [Seamoby] Section 5.2 in CT Requirements > > > Folks, > > So recently I had another look at the CT Requirements > document and I was > suprised to find Section 5.2. It says this: > > 5.2 Transport Reliability > > This section is intentionally left blank as the > working group is > waiting for a questionnaire from the transport > directorate. The result > of the questionnaire will create requirements that > will be added in this > section in a later revision of this specification. > > It is completely unacceptable that we sent this document to > the IESG with this > section in it. When a document passes through last call, it > should be complete. > As WG chairs, Pat and I naturally must accept responsibility > for this, but this > should really have been caught in WG Last Call. > > I would like suggest replacing Section 5.2 with the following: > > 5.2 Transport Requirements > > This section contains requirements on the context > transfer transport. > > 5.1 Independence of Underlying Transport > > The context transfer solution MUST be independent of > the underlying > transport. It SHOULD be possible to transfer > context directly on top of reliable transports, such > as TCP or SCTP, > unreliable transports, such as UDP, or as an > option or extention on another protocol, such as > handover signaling. > > Comments? > > > jak > u > > > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > ------_=_NextPart_001_01C22E6D.AC1DD768 Content-Type: text/html; charset="iso-8859-1" RE: [Seamoby] Section 5.2 in CT Requirements

James:

 There was a long and arduous debate over transport reliability.
The wording you are objecting to was, I believe, Allison's suggestion.
At the very lease, it was inserted with her approval in order to move
the requirements forward.

 Of course, you can open the debate again, but I don't expect it to
be resolved any better then it was the last time through. The problem
is that there seems to be some very different ideas in the wg as to
what the CT protocol looks like, with contradicting assumptions as
to what is needed from a transport layer.

Gary

> -----Original Message-----
> From: James Kempf [mailto:kempf@docomolabs-usa.com]
> Sent: July 18, 2002 07:14
> To: seamoby@ietf.org
> Cc: mankin@psg.com
> Subject: [Seamoby] Section 5.2 in CT Requirements
>
>
> Folks,
>
> So recently I had another look at the CT Requirements
> document and I was
> suprised to find Section 5.2. It says this:
>
>     5.2 Transport Reliability
>
>        This section is intentionally left blank as the
> working group is
>        waiting for a questionnaire from the transport
> directorate. The result
>        of the questionnaire will create requirements that
> will be added in this
>        section in a later revision of this specification.
>
> It is completely unacceptable that we sent this document to
> the IESG with this
> section in it. When a document passes through last call, it
> should be complete.
> As WG chairs, Pat and I naturally must accept responsibility
> for this, but this
> should really have been caught in WG Last Call.
>
> I would like suggest replacing Section 5.2 with the following:
>
>     5.2 Transport Requirements
>
>         This section contains requirements on the context
> transfer transport.
>
>     5.1 Independence of Underlying Transport
>
>         The context transfer solution MUST be independent of
> the underlying
> transport. It SHOULD be possible to transfer
>         context directly on top of reliable transports, such
> as TCP or SCTP,
> unreliable transports, such as UDP, or as an
>         option or extention on another protocol, such as
> handover signaling.
>
> Comments?
>
>
>             jak
>    u
>
>
>
> _______________________________________________
> Seamoby mailing list
> Seamoby@ietf.org
> https://www1.ietf.org/mailman/listinfo/seamoby
>

------_=_NextPart_001_01C22E6D.AC1DD768-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Thu Jul 18 11:21:55 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04675 for ; Thu, 18 Jul 2002 11:21:51 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA13355 for seamoby-archive@odin.ietf.org; Thu, 18 Jul 2002 11:22:49 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA12994; Thu, 18 Jul 2002 11:17:12 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA12967 for ; Thu, 18 Jul 2002 11:17:10 -0400 (EDT) Received: from zcars04f.ca.nortel.com (zcars04f.nortelnetworks.com [47.129.242.57]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04490 for ; Thu, 18 Jul 2002 11:16:11 -0400 (EDT) Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04f.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g6IFGRp07175; Thu, 18 Jul 2002 11:16:28 -0400 (EDT) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 18 Jul 2002 11:16:27 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA4C3C@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'James Kempf'" , seamoby@ietf.org Cc: mankin@psg.com Subject: RE: [Seamoby] Section 5.2 in CT Requirements Date: Thu, 18 Jul 2002 11:16:26 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C22E6D.AC1DD768" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C22E6D.AC1DD768 Content-Type: text/plain; charset="iso-8859-1" James: There was a long and arduous debate over transport reliability. The wording you are objecting to was, I believe, Allison's suggestion. At the very lease, it was inserted with her approval in order to move the requirements forward. Of course, you can open the debate again, but I don't expect it to be resolved any better then it was the last time through. The problem is that there seems to be some very different ideas in the wg as to what the CT protocol looks like, with contradicting assumptions as to what is needed from a transport layer. Gary > -----Original Message----- > From: James Kempf [mailto:kempf@docomolabs-usa.com] > Sent: July 18, 2002 07:14 > To: seamoby@ietf.org > Cc: mankin@psg.com > Subject: [Seamoby] Section 5.2 in CT Requirements > > > Folks, > > So recently I had another look at the CT Requirements > document and I was > suprised to find Section 5.2. It says this: > > 5.2 Transport Reliability > > This section is intentionally left blank as the > working group is > waiting for a questionnaire from the transport > directorate. The result > of the questionnaire will create requirements that > will be added in this > section in a later revision of this specification. > > It is completely unacceptable that we sent this document to > the IESG with this > section in it. When a document passes through last call, it > should be complete. > As WG chairs, Pat and I naturally must accept responsibility > for this, but this > should really have been caught in WG Last Call. > > I would like suggest replacing Section 5.2 with the following: > > 5.2 Transport Requirements > > This section contains requirements on the context > transfer transport. > > 5.1 Independence of Underlying Transport > > The context transfer solution MUST be independent of > the underlying > transport. It SHOULD be possible to transfer > context directly on top of reliable transports, such > as TCP or SCTP, > unreliable transports, such as UDP, or as an > option or extention on another protocol, such as > handover signaling. > > Comments? > > > jak > u > > > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > ------_=_NextPart_001_01C22E6D.AC1DD768 Content-Type: text/html; charset="iso-8859-1" RE: [Seamoby] Section 5.2 in CT Requirements

James:

 There was a long and arduous debate over transport reliability.
The wording you are objecting to was, I believe, Allison's suggestion.
At the very lease, it was inserted with her approval in order to move
the requirements forward.

 Of course, you can open the debate again, but I don't expect it to
be resolved any better then it was the last time through. The problem
is that there seems to be some very different ideas in the wg as to
what the CT protocol looks like, with contradicting assumptions as
to what is needed from a transport layer.

Gary

> -----Original Message-----
> From: James Kempf [mailto:kempf@docomolabs-usa.com]
> Sent: July 18, 2002 07:14
> To: seamoby@ietf.org
> Cc: mankin@psg.com
> Subject: [Seamoby] Section 5.2 in CT Requirements
>
>
> Folks,
>
> So recently I had another look at the CT Requirements
> document and I was
> suprised to find Section 5.2. It says this:
>
>     5.2 Transport Reliability
>
>        This section is intentionally left blank as the
> working group is
>        waiting for a questionnaire from the transport
> directorate. The result
>        of the questionnaire will create requirements that
> will be added in this
>        section in a later revision of this specification.
>
> It is completely unacceptable that we sent this document to
> the IESG with this
> section in it. When a document passes through last call, it
> should be complete.
> As WG chairs, Pat and I naturally must accept responsibility
> for this, but this
> should really have been caught in WG Last Call.
>
> I would like suggest replacing Section 5.2 with the following:
>
>     5.2 Transport Requirements
>
>         This section contains requirements on the context
> transfer transport.
>
>     5.1 Independence of Underlying Transport
>
>         The context transfer solution MUST be independent of
> the underlying
> transport. It SHOULD be possible to transfer
>         context directly on top of reliable transports, such
> as TCP or SCTP,
> unreliable transports, such as UDP, or as an
>         option or extention on another protocol, such as
> handover signaling.
>
> Comments?
>
>
>             jak
>    u
>
>
>
> _______________________________________________
> Seamoby mailing list
> Seamoby@ietf.org
> https://www1.ietf.org/mailman/listinfo/seamoby
>

------_=_NextPart_001_01C22E6D.AC1DD768-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Thu Jul 18 11:24:36 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04808 for ; Thu, 18 Jul 2002 11:24:36 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA12831; Thu, 18 Jul 2002 11:12:06 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA12805 for ; Thu, 18 Jul 2002 11:12:05 -0400 (EDT) Received: from zcars04f.ca.nortel.com (zcars04f.nortelnetworks.com [47.129.242.57]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04359 for ; Thu, 18 Jul 2002 11:11:06 -0400 (EDT) Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04f.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g6IFBCp06645; Thu, 18 Jul 2002 11:11:12 -0400 (EDT) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 18 Jul 2002 11:11:11 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA4C3A@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'Nakhjiri Madjid-MNAKHJI1'" , "'James Kempf'" , john.loughney@nokia.com, seamoby@ietf.org Subject: RE: [Seamoby] Proposal on Sync/NoSync Requirement Date: Thu, 18 Jul 2002 11:11:09 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C22E6D.58DFFD24" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C22E6D.58DFFD24 Content-Type: text/plain; charset="iso-8859-1" Madjid: Comments included: > -----Original Message----- > From: Nakhjiri Madjid-MNAKHJI1 [mailto:Madjid.Nakhjiri@motorola.com] > Sent: July 17, 2002 20:12 > To: Kenward, Gary [WDLN2:AN10:EXCH]; 'James Kempf'; > john.loughney@nokia.com; seamoby@ietf.org > Subject: RE: [Seamoby] Proposal on Sync/NoSync Requirement > > > Gary, > > thanks for the suggestions, please see my comments below. > > Madjid > > Proposed: > 5.5 Context Update and Synchronization > 5.5.1 The context transfer protocol MUST be capable of supporting the > updates to context information when it changes. > > Madjid>> Ok, this takes care of the dynamic context, however, we Actually, the real concern I have is not for dynamic context as it is for changes in the makeup of the traffic for the MN - i.e. the arrival and departure of microflows. This would change the configuration (aka static) context. > need to be clarify that we are not requiring the oldAR sends updates > to context features it has already transmitted while it is > transmitting > context for other features, otherwise CT might never end. I absolutely agree with you. > Since, some folks have brought that up, I want to make sure that we > are not reading that in the requirement. Updates initiated by oldAR > should only be based on outside triggers such as new flow, > flow terminations > or messages from central entities... There seems to be a concern that CT will not be able to guarantee perfect synchronization of the configuration and state of both ARs. My response to this concern is, of course not, CT was never intended to do such a think. This is not distributed computing, it is handover optimization. Perhaps a new requirement would help clarify this, something like: 5.5.x Context transfer SHALL NOT attempt to guarantee perfect synchronization of context. The purpose of CT is to improve handover as best as it can. Given the complexity and overheads needed to synchronize distributed state machines, it is expected that occasionally, the context of the source and destination AR will not agree. The CT solution must minimize the likelihood of this happening. 5.5.x+1 Context transfer WILL NOT attempt to mitigate the effects of stale context at the receiving AR. To me, this all seems like responding to "what if" scenarios, which if we got to far into this mode, could cause the number of requirements to explode. However, perhaps this is one distinction we should emphasize. > > 5.5.2 Context updates SHOULD complete before the context is needed at > the receiving AR. > > Madjid>> How do we know when the context is needed at the > receiving AR? > I find this more like a design guidance than a requirement. Well, a requirement is a design guide. The wg has debated this extensively, Madjid, with, if I recall, no better resolution then the current wording. If you have a recommendation for wording of a requirement that would identify when CT should be complete, please submit it. > The following > text > can with some exceptions added to the explanation of 5.5.2. > > The context at the AR actually supporting an MN's traffic will > change with time. For example, the MN may initiate new > microflow(s), > or discontinue existing microflows. > Madjid>> the above is good. > > Any change of context at the > supporting AR must be replicated at those ARs that have already > received context for that MN. > Madjid>> MUSt is too strong. 5.5.1 is SHOULD, so should this one be > (sorry for too many shoulds :)) There are ways to avoid having to do > this through CT. Hmmm. Could you expand on the "many ways"? I am curious. As for MUST versus SHOULD: I think there is an issue here with interpretation. My interpretation is that CT MUST ATTEMPT to convey context changes at the ARs. That is, CT must provide the mechanisms to transfer context changes to all ARs that received the context originally. I agree that it is too extreme to state that the changes MUST make it to all ARs. Perhaps some rewording is needed. > > However, context changes are often driven by events > external to the > sending AR, and will thus be asynchronous to any on-going context > updates. Given that context transfers will take a finite amount of > time to complete, it is possible that a change in context > cannot be > conveyed in time to the destination AR to avoid any impact > on a possible > handover. The objective of the context transfer design > must be to make > the likelihood of this delay, and its magnitude, as low as > possible. > > Madjid>> The above is good. > > This is not perfect: the desire to avoid a requirement for an > extreme degree > > of synchronization is only implied by the soft "SHOULD" in 5.5.2. > Regards, > Gary > > > > -----Original Message----- Thanks for the response; very useful input. Gary ------_=_NextPart_001_01C22E6D.58DFFD24 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Seamoby] Proposal on Sync/NoSync Requirement

Madjid:
  
  Comments included:

> -----Original Message-----
> From: Nakhjiri Madjid-MNAKHJI1 [mailto:Madjid.Nakhjiri@moto= rola.com]
> Sent: July 17, 2002 20:12
> To: Kenward, Gary [WDLN2:AN10:EXCH]; 'James = Kempf';
> john.loughney@nokia.com; = seamoby@ietf.org
> Subject: RE: [Seamoby] Proposal on Sync/NoSync = Requirement
>
>
> Gary,
>
> thanks for the suggestions, please see my = comments below.
>
> Madjid
>
> Proposed:
> 5.5 Context Update and Synchronization
> 5.5.1 The context transfer protocol MUST be = capable of supporting the
>       updates to = context information when it changes. 
>
>  Madjid>> Ok, this takes care of the = dynamic context, however, we

Actually, the real concern I have is not for dynamic = context as it is
for changes in the makeup of the traffic for the MN = - i.e. the arrival
and departure of microflows. This would change the = configuration (aka
static) context.

> need to be clarify that we are not requiring the = oldAR sends updates
> to context features it has already transmitted = while it is
> transmitting
> context for other features, otherwise CT might = never end.

I absolutely agree with you.

> Since, some folks have brought that up, I want = to make sure that we
>  are not reading that in the requirement. = Updates initiated by oldAR
> should only be based on outside triggers such = as new flow,
> flow terminations
> or messages from central entities...

There seems to be a concern that CT will not be able = to guarantee perfect
synchronization of the configuration and state of = both ARs. My response to
this concern is, of course not, CT was never = intended to do such a think.
This is not distributed computing, it is handover = optimization.

Perhaps a new requirement would help clarify this, = something like:

5.5.x Context transfer SHALL NOT attempt to guarantee = perfect synchronization
of context. The purpose of CT is to improve handover = as best as it can. Given
the complexity and overheads needed to synchronize = distributed state machines,
it is expected that occasionally, the context of the = source and destination
AR will not agree. The CT solution must minimize the = likelihood of this happening.

5.5.x+1 Context transfer WILL NOT attempt to mitigate = the effects of stale context
        at the = receiving AR.


To me, this all seems like responding to "what = if" scenarios, which if we got
to far into this mode, could cause the number of = requirements to explode.
However, perhaps this is one distinction we should = emphasize.

>
> 5.5.2 Context updates SHOULD complete before = the context is needed at
>       the = receiving AR.
>
> Madjid>> How do we know when the context = is needed at the
> receiving AR?
> I find this more like a design guidance than a = requirement.

Well, a requirement is a design guide. The wg has = debated this extensively,
Madjid, with, if I recall, no better resolution then = the current wording.
If you have a recommendation for wording of a = requirement that would identify
when CT should be complete, please submit it.

> The following
> text
> can with some exceptions added to the = explanation of 5.5.2.
>
>    The context at the AR = actually supporting an MN's traffic will
>    change with time. For = example, the MN may initiate new
> microflow(s),
>    or discontinue existing = microflows.
> Madjid>> the above is good.
>
> Any change of context at the
>    supporting AR must be = replicated at those ARs that have already
>    received context for that = MN.
> Madjid>> MUSt is too strong. 5.5.1 is = SHOULD, so should this one be
> (sorry for too many shoulds :)) There are ways = to avoid having to do
> this through CT.

Hmmm. Could you expand on the "many ways"? = I am curious.

As for MUST versus SHOULD: I think there is an issue = here with interpretation.
My interpretation is that CT MUST ATTEMPT to convey = context changes at the ARs.
That is, CT must provide the mechanisms to transfer = context changes to all ARs
that received the context originally. I agree that = it is too extreme to state
that the changes MUST make it to all ARs. Perhaps = some rewording is needed.

> 
>    However, context changes are = often driven by events
> external to the
>    sending AR, and will thus be = asynchronous to any on-going context
>    updates. Given that context = transfers will take a finite amount of
>    time to complete, it is = possible that a change in context
> cannot be
>    conveyed in time to the = destination AR to avoid any impact
> on a possible
>    handover. The objective of = the context transfer design
> must be to make
>    the likelihood of this delay, = and its magnitude, as low as
> possible.
>
> Madjid>> The above is good.
>
> This is not perfect: the desire to avoid a = requirement for an
> extreme degree
>
> of synchronization is only implied by the soft = "SHOULD" in 5.5.2.
> Regards,
> Gary
>
>
> > -----Original Message-----

Thanks for the response; very useful input.

Gary

------_=_NextPart_001_01C22E6D.58DFFD24-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Thu Jul 18 11:24:37 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04815 for ; Thu, 18 Jul 2002 11:24:37 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA13951 for seamoby-archive@odin.ietf.org; Thu, 18 Jul 2002 11:25:35 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA12831; Thu, 18 Jul 2002 11:12:06 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA12805 for ; Thu, 18 Jul 2002 11:12:05 -0400 (EDT) Received: from zcars04f.ca.nortel.com (zcars04f.nortelnetworks.com [47.129.242.57]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04359 for ; Thu, 18 Jul 2002 11:11:06 -0400 (EDT) Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04f.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g6IFBCp06645; Thu, 18 Jul 2002 11:11:12 -0400 (EDT) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 18 Jul 2002 11:11:11 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA4C3A@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'Nakhjiri Madjid-MNAKHJI1'" , "'James Kempf'" , john.loughney@nokia.com, seamoby@ietf.org Subject: RE: [Seamoby] Proposal on Sync/NoSync Requirement Date: Thu, 18 Jul 2002 11:11:09 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C22E6D.58DFFD24" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C22E6D.58DFFD24 Content-Type: text/plain; charset="iso-8859-1" Madjid: Comments included: > -----Original Message----- > From: Nakhjiri Madjid-MNAKHJI1 [mailto:Madjid.Nakhjiri@motorola.com] > Sent: July 17, 2002 20:12 > To: Kenward, Gary [WDLN2:AN10:EXCH]; 'James Kempf'; > john.loughney@nokia.com; seamoby@ietf.org > Subject: RE: [Seamoby] Proposal on Sync/NoSync Requirement > > > Gary, > > thanks for the suggestions, please see my comments below. > > Madjid > > Proposed: > 5.5 Context Update and Synchronization > 5.5.1 The context transfer protocol MUST be capable of supporting the > updates to context information when it changes. > > Madjid>> Ok, this takes care of the dynamic context, however, we Actually, the real concern I have is not for dynamic context as it is for changes in the makeup of the traffic for the MN - i.e. the arrival and departure of microflows. This would change the configuration (aka static) context. > need to be clarify that we are not requiring the oldAR sends updates > to context features it has already transmitted while it is > transmitting > context for other features, otherwise CT might never end. I absolutely agree with you. > Since, some folks have brought that up, I want to make sure that we > are not reading that in the requirement. Updates initiated by oldAR > should only be based on outside triggers such as new flow, > flow terminations > or messages from central entities... There seems to be a concern that CT will not be able to guarantee perfect synchronization of the configuration and state of both ARs. My response to this concern is, of course not, CT was never intended to do such a think. This is not distributed computing, it is handover optimization. Perhaps a new requirement would help clarify this, something like: 5.5.x Context transfer SHALL NOT attempt to guarantee perfect synchronization of context. The purpose of CT is to improve handover as best as it can. Given the complexity and overheads needed to synchronize distributed state machines, it is expected that occasionally, the context of the source and destination AR will not agree. The CT solution must minimize the likelihood of this happening. 5.5.x+1 Context transfer WILL NOT attempt to mitigate the effects of stale context at the receiving AR. To me, this all seems like responding to "what if" scenarios, which if we got to far into this mode, could cause the number of requirements to explode. However, perhaps this is one distinction we should emphasize. > > 5.5.2 Context updates SHOULD complete before the context is needed at > the receiving AR. > > Madjid>> How do we know when the context is needed at the > receiving AR? > I find this more like a design guidance than a requirement. Well, a requirement is a design guide. The wg has debated this extensively, Madjid, with, if I recall, no better resolution then the current wording. If you have a recommendation for wording of a requirement that would identify when CT should be complete, please submit it. > The following > text > can with some exceptions added to the explanation of 5.5.2. > > The context at the AR actually supporting an MN's traffic will > change with time. For example, the MN may initiate new > microflow(s), > or discontinue existing microflows. > Madjid>> the above is good. > > Any change of context at the > supporting AR must be replicated at those ARs that have already > received context for that MN. > Madjid>> MUSt is too strong. 5.5.1 is SHOULD, so should this one be > (sorry for too many shoulds :)) There are ways to avoid having to do > this through CT. Hmmm. Could you expand on the "many ways"? I am curious. As for MUST versus SHOULD: I think there is an issue here with interpretation. My interpretation is that CT MUST ATTEMPT to convey context changes at the ARs. That is, CT must provide the mechanisms to transfer context changes to all ARs that received the context originally. I agree that it is too extreme to state that the changes MUST make it to all ARs. Perhaps some rewording is needed. > > However, context changes are often driven by events > external to the > sending AR, and will thus be asynchronous to any on-going context > updates. Given that context transfers will take a finite amount of > time to complete, it is possible that a change in context > cannot be > conveyed in time to the destination AR to avoid any impact > on a possible > handover. The objective of the context transfer design > must be to make > the likelihood of this delay, and its magnitude, as low as > possible. > > Madjid>> The above is good. > > This is not perfect: the desire to avoid a requirement for an > extreme degree > > of synchronization is only implied by the soft "SHOULD" in 5.5.2. > Regards, > Gary > > > > -----Original Message----- Thanks for the response; very useful input. Gary ------_=_NextPart_001_01C22E6D.58DFFD24 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Seamoby] Proposal on Sync/NoSync Requirement

Madjid:
  
  Comments included:

> -----Original Message-----
> From: Nakhjiri Madjid-MNAKHJI1 [mailto:Madjid.Nakhjiri@moto= rola.com]
> Sent: July 17, 2002 20:12
> To: Kenward, Gary [WDLN2:AN10:EXCH]; 'James = Kempf';
> john.loughney@nokia.com; = seamoby@ietf.org
> Subject: RE: [Seamoby] Proposal on Sync/NoSync = Requirement
>
>
> Gary,
>
> thanks for the suggestions, please see my = comments below.
>
> Madjid
>
> Proposed:
> 5.5 Context Update and Synchronization
> 5.5.1 The context transfer protocol MUST be = capable of supporting the
>       updates to = context information when it changes. 
>
>  Madjid>> Ok, this takes care of the = dynamic context, however, we

Actually, the real concern I have is not for dynamic = context as it is
for changes in the makeup of the traffic for the MN = - i.e. the arrival
and departure of microflows. This would change the = configuration (aka
static) context.

> need to be clarify that we are not requiring the = oldAR sends updates
> to context features it has already transmitted = while it is
> transmitting
> context for other features, otherwise CT might = never end.

I absolutely agree with you.

> Since, some folks have brought that up, I want = to make sure that we
>  are not reading that in the requirement. = Updates initiated by oldAR
> should only be based on outside triggers such = as new flow,
> flow terminations
> or messages from central entities...

There seems to be a concern that CT will not be able = to guarantee perfect
synchronization of the configuration and state of = both ARs. My response to
this concern is, of course not, CT was never = intended to do such a think.
This is not distributed computing, it is handover = optimization.

Perhaps a new requirement would help clarify this, = something like:

5.5.x Context transfer SHALL NOT attempt to guarantee = perfect synchronization
of context. The purpose of CT is to improve handover = as best as it can. Given
the complexity and overheads needed to synchronize = distributed state machines,
it is expected that occasionally, the context of the = source and destination
AR will not agree. The CT solution must minimize the = likelihood of this happening.

5.5.x+1 Context transfer WILL NOT attempt to mitigate = the effects of stale context
        at the = receiving AR.


To me, this all seems like responding to "what = if" scenarios, which if we got
to far into this mode, could cause the number of = requirements to explode.
However, perhaps this is one distinction we should = emphasize.

>
> 5.5.2 Context updates SHOULD complete before = the context is needed at
>       the = receiving AR.
>
> Madjid>> How do we know when the context = is needed at the
> receiving AR?
> I find this more like a design guidance than a = requirement.

Well, a requirement is a design guide. The wg has = debated this extensively,
Madjid, with, if I recall, no better resolution then = the current wording.
If you have a recommendation for wording of a = requirement that would identify
when CT should be complete, please submit it.

> The following
> text
> can with some exceptions added to the = explanation of 5.5.2.
>
>    The context at the AR = actually supporting an MN's traffic will
>    change with time. For = example, the MN may initiate new
> microflow(s),
>    or discontinue existing = microflows.
> Madjid>> the above is good.
>
> Any change of context at the
>    supporting AR must be = replicated at those ARs that have already
>    received context for that = MN.
> Madjid>> MUSt is too strong. 5.5.1 is = SHOULD, so should this one be
> (sorry for too many shoulds :)) There are ways = to avoid having to do
> this through CT.

Hmmm. Could you expand on the "many ways"? = I am curious.

As for MUST versus SHOULD: I think there is an issue = here with interpretation.
My interpretation is that CT MUST ATTEMPT to convey = context changes at the ARs.
That is, CT must provide the mechanisms to transfer = context changes to all ARs
that received the context originally. I agree that = it is too extreme to state
that the changes MUST make it to all ARs. Perhaps = some rewording is needed.

> 
>    However, context changes are = often driven by events
> external to the
>    sending AR, and will thus be = asynchronous to any on-going context
>    updates. Given that context = transfers will take a finite amount of
>    time to complete, it is = possible that a change in context
> cannot be
>    conveyed in time to the = destination AR to avoid any impact
> on a possible
>    handover. The objective of = the context transfer design
> must be to make
>    the likelihood of this delay, = and its magnitude, as low as
> possible.
>
> Madjid>> The above is good.
>
> This is not perfect: the desire to avoid a = requirement for an
> extreme degree
>
> of synchronization is only implied by the soft = "SHOULD" in 5.5.2.
> Regards,
> Gary
>
>
> > -----Original Message-----

Thanks for the response; very useful input.

Gary

------_=_NextPart_001_01C22E6D.58DFFD24-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Thu Jul 18 12:08:32 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06572 for ; Thu, 18 Jul 2002 12:08:32 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA22177; Thu, 18 Jul 2002 12:06:30 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA22146 for ; Thu, 18 Jul 2002 12:06:28 -0400 (EDT) Received: from hotmail.com (f68.law9.hotmail.com [64.4.9.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06482 for ; Thu, 18 Jul 2002 12:05:31 -0400 (EDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 18 Jul 2002 09:05:57 -0700 Received: from 63.78.179.5 by lw9fd.law9.hotmail.msn.com with HTTP; Thu, 18 Jul 2002 16:05:57 GMT X-Originating-IP: [63.78.179.5] From: "Govind Krishnamurthi" To: kempf@docomolabs-usa.com, seamoby@ietf.org Subject: Re: [Seamoby] Terminology Draft Date: Thu, 18 Jul 2002 12:05:57 -0400 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 18 Jul 2002 16:05:57.0878 (UTC) FILETIME=[00C55960:01C22E75] Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Hi Jim, I would hope that Jukka incorporates some of the changes that were made to the CAR Discovery Issues document. I think the definition of some terms may have been changed. Thanks, Govind. >Hi, > >In Salt Lake, we agreed to make draft-manner-seamoby-terms-04.txt a working >group document. This contains mobility related turns in common use within >the >IETF at this time. > >Is there any objection to making this draft a working group draft? > > jak > > >_______________________________________________ >Seamoby mailing list >Seamoby@ietf.org >https://www1.ietf.org/mailman/listinfo/seamoby _________________________________________________________________ Join the world’s largest e-mail service with MSN Hotmail. http://www.hotmail.com _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Thu Jul 18 12:08:33 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06578 for ; Thu, 18 Jul 2002 12:08:33 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA22458 for seamoby-archive@odin.ietf.org; Thu, 18 Jul 2002 12:09:29 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA22177; Thu, 18 Jul 2002 12:06:30 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA22146 for ; Thu, 18 Jul 2002 12:06:28 -0400 (EDT) Received: from hotmail.com (f68.law9.hotmail.com [64.4.9.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06482 for ; Thu, 18 Jul 2002 12:05:31 -0400 (EDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 18 Jul 2002 09:05:57 -0700 Received: from 63.78.179.5 by lw9fd.law9.hotmail.msn.com with HTTP; Thu, 18 Jul 2002 16:05:57 GMT X-Originating-IP: [63.78.179.5] From: "Govind Krishnamurthi" To: kempf@docomolabs-usa.com, seamoby@ietf.org Subject: Re: [Seamoby] Terminology Draft Date: Thu, 18 Jul 2002 12:05:57 -0400 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 18 Jul 2002 16:05:57.0878 (UTC) FILETIME=[00C55960:01C22E75] Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Hi Jim, I would hope that Jukka incorporates some of the changes that were made to the CAR Discovery Issues document. I think the definition of some terms may have been changed. Thanks, Govind. >Hi, > >In Salt Lake, we agreed to make draft-manner-seamoby-terms-04.txt a working >group document. This contains mobility related turns in common use within >the >IETF at this time. > >Is there any objection to making this draft a working group draft? > > jak > > >_______________________________________________ >Seamoby mailing list >Seamoby@ietf.org >https://www1.ietf.org/mailman/listinfo/seamoby _________________________________________________________________ Join the world’s largest e-mail service with MSN Hotmail. http://www.hotmail.com _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Thu Jul 18 17:12:01 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12785 for ; Thu, 18 Jul 2002 17:12:01 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA11326; Thu, 18 Jul 2002 17:00:40 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA11285 for ; Thu, 18 Jul 2002 17:00:37 -0400 (EDT) Received: from motgate4.mot.com (motgate4.mot.com [144.189.100.102]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12636 for ; Thu, 18 Jul 2002 16:59:37 -0400 (EDT) Received: [from pobox4.mot.com (pobox4.mot.com [10.64.251.243]) by motgate4.mot.com (motgate4 2.1) with ESMTP id OAA08464 for ; Thu, 18 Jul 2002 14:00:34 -0700 (MST)] Received: [from il75exm04.cig.mot.com ([136.182.110.113]) by pobox4.mot.com (MOT-pobox4 2.0) with ESMTP id OAA27611 for ; Thu, 18 Jul 2002 14:00:34 -0700 (MST)] Received: by IL75EXM04 with Internet Mail Service (5.5.2654.52) id ; Thu, 18 Jul 2002 16:00:33 -0500 Message-ID: <35DBB8B7AC89D4118E98009027B1009B08AD55C5@IL27EXM10.cig.mot.com> From: Nakhjiri Madjid-MNAKHJI1 To: "'James Kempf'" , seamoby@ietf.org Cc: mankin@psg.com Subject: RE: [Seamoby] Section 5.2 in CT Requirements Date: Thu, 18 Jul 2002 16:00:19 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.52) Content-Type: text/plain; charset="iso-8859-1" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org -----Original Message----- From: James Kempf [mailto:kempf@docomolabs-usa.com] Sent: Thursday, July 18, 2002 6:14 AM To: seamoby@ietf.org Cc: mankin@psg.com Subject: [Seamoby] Section 5.2 in CT Requirements Folks, So recently I had another look at the CT Requirements document and I was suprised to find Section 5.2. It says this: 5.2 Transport Reliability This section is intentionally left blank as the working group is waiting for a questionnaire from the transport directorate. The result of the questionnaire will create requirements that will be added in this section in a later revision of this specification. It is completely unacceptable that we sent this document to the IESG with this section in it. When a document passes through last call, it should be complete. As WG chairs, Pat and I naturally must accept responsibility for this, but this should really have been caught in WG Last Call. I would like suggest replacing Section 5.2 with the following: 5.2 Transport Requirements This section contains requirements on the context transfer transport. 5.1 Independence of Underlying Transport The context transfer solution MUST be independent of the underlying transport. It SHOULD be possible to transfer context directly on top of reliable transports, such as TCP or SCTP, unreliable transports, such as UDP, or as an option or extention on another protocol, such as handover signaling. Comments? Madjid>> I second Gary's comments. The wording was suggested to us. I also remember the very long debate of reliability and the fact that some folks wanted reliability and some didn't. Our TEXT proposal shows that you can add reliability to CT if you want it and is not offered to you. Good suggestion on 5.1. I am ok with your 5.1 formulation, I think it should make everybody happy by leaving enough flexibility there. However, I am not sure how I can prove independance of transport for our proposal even, i.e. the first MUST in 5.1. Don't know why the 5.2 (This section....) is still there. Madjid jak u _______________________________________________ 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 From seamoby-admin@ietf.org Thu Jul 18 17:19:55 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12927 for ; Thu, 18 Jul 2002 17:19:55 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA12182; Thu, 18 Jul 2002 17:16:44 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA12109 for ; Thu, 18 Jul 2002 17:16:40 -0400 (EDT) Received: from ftpbox.mot.com (ftpbox.mot.com [129.188.136.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12839 for ; Thu, 18 Jul 2002 17:15:40 -0400 (EDT) Received: [from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id OAA03402 for ; Thu, 18 Jul 2002 14:16:37 -0700 (MST)] Received: [from il27exm07.cig.mot.com (IL27EXM07.cig.mot.com [136.182.15.116]) by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id OAA01961 for ; Thu, 18 Jul 2002 14:15:19 -0700 (MST)] Received: by IL27EXM07.cig.mot.com with Internet Mail Service (5.5.2654.52) id <3FLZY4YM>; Thu, 18 Jul 2002 16:16:35 -0500 Message-ID: <35DBB8B7AC89D4118E98009027B1009B08AD55C6@IL27EXM10.cig.mot.com> From: Nakhjiri Madjid-MNAKHJI1 To: "'Gary Kenward'" , Nakhjiri Madjid-MNAKHJI1 , "'Charles E. Perkins'" Cc: seamoby@ietf.org Subject: RE: [Seamoby] CT Requirements Comments from IESG Date: Thu, 18 Jul 2002 16:16:33 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.52) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C22EA0.64955AF0" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C22EA0.64955AF0 Content-Type: text/plain; charset="iso-8859-1" -----Original Message----- From: Gary Kenward [mailto:gkenward@nortelnetworks.com] Sent: Thursday, July 18, 2002 9:52 AM To: 'Nakhjiri Madjid-MNAKHJI1'; 'Charles E. Perkins' Cc: seamoby@ietf.org Subject: RE: [Seamoby] CT Requirements Comments from IESG Define "done"? Madjid>> Exactly my point, if you keep sending updates while you're sending other context, you are never done. Seriously, if CT is performed during or after a handover (reactively) then, yes, there's not much more that can be done. If the context at the destination is out of synch with changes in the source context, there is an increased risk that the seamlessness of the handover will be degraded. Madjid>> Yes, assuming you mean L3 handover, and this is the most critical use of CT: optimization of handovers. I can't have CT add to feature disruption by getting into an endless cycle of updates. However, if CT is performed before a handover begins (proactively), and changes occur at the source AR, then it would seem reasonable to attempt updates. There is a presumption here that there is something to be gained in handover performance by performing CT in advance of an actual handover. It could turn out that CT (and the subsequent installion of context at the destination AR) is so fast, that leaving the transfer of context until a handover occurs (i.e. no proactive, only reactive) is a sufficient, and simpler solution. We really won't know whether this is the case until the wg starts looking at CT solutions. Madjid>>sure, but this is not a time-critical CT and CT needs to send updates because it started too early on a dynamic context. Cheers, Gary -----Original Message----- From: Nakhjiri Madjid-MNAKHJI1 [mailto:Madjid.Nakhjiri@motorola.com] Sent: July 17, 2002 19:25 To: Kenward, Gary [WDLN2:AN10:EXCH]; 'Charles E. Perkins' Cc: seamoby@ietf.org Subject: RE: [Seamoby] CT Requirements Comments from IESG Well, not trying to regurgitate (as you said) but we never agreed on timing and reliability requirements and maybe that was ok, because they depend on the scenario and protocols. So why talk about sending updates after CT is done? Madjid -----Original Message----- From: Gary Kenward [mailto:gkenward@nortelnetworks.com] Sent: Friday, July 12, 2002 2:35 PM To: 'Charles E. Perkins' Cc: seamoby@ietf.org Subject: RE: [Seamoby] CT Requirements Comments from IESG I agree Charlie. However, we have to fix the issue with the requirements. Are you suggesting that we relax the requirement? By how much - clearly, some updates are required (e.g. CT really should try and update when flows come and go). Gary > -----Original Message----- > From: Charles E. Perkins [ mailto:charliep@iprg.nokia.com ] > Sent: July 12, 2002 12:15 > To: Kenward, Gary [WDLN2:AN10:EXCH] > Cc: seamoby@ietf.org > Subject: Re: [Seamoby] CT Requirements Comments from IESG > > > > > Hello folks, > > I think we ought to try to get context transfers > working correctly without initially worrying about > this synchronization problem. > > In the instances I am familiar with, it is not > required. The most stringent case seems to be > ROHC, and even for that it is not necessary. > > We can solve the most urgent problems without having > to deal with any additional context synchronization. > When the old AR sends it, and the new AR gets it, > we should consider the transfer done. In those > cases where reliability is at issue, the old AR > can retransmit when ACK is not received. In many > cases, retransmission of context even once won't > be useful. > > Regards, > Charlie P. > > > > > Gary Kenward wrote: > > > > James: > > > > Yes, we need to fix it, and I think it is doable. > > Thanks to Dirk for highlighting the real problem here > > (I think historically, the integrity requirement came out > > of the reliability section, and somehow, got lumped with > > synchronization and updates). > > > > I think the requirements need a bit of rewording, and > > the paragraph should fall out from this. I do believe > > however, that making the synchronization of context between > > old and new AR a MUST requirement would be too extreme, and > > result in a brittle solution. CT should certainly do it's best to > > provide synchronization, but as was discussed in a recent > > exchange, it would be impossible to guarantee synchronization > > at any instant. > > > > Any ideas/comments from the wg? > > > > Gary > > > > > -----Original Message----- > > > From: James Kempf [ mailto:kempf@docomolabs-usa.com ] > > > Sent: July 11, 2002 18:32 > > > To: Kenward, Gary [WDLN2:AN10:EXCH]; Dirk.Trossen@nokia.com; > > > seamoby@ietf.org > > > Subject: Re: [Seamoby] CT Requirements Comments from IESG > > > > > > > > > Gary/Dirk, > > > > > > I think you may be on to something here. I think this might > > > be what the IESG was talking about it the first point, namely the > > > lack of discussion of dynamic changes in the context. > > > > > > Is there some way we could cook this idea down into a > > > paragraph that we could insert for this requirement? > > > > > > jak > > > > > > ----- Original Message ----- > > > From: "Gary Kenward" > > > To: ; ; > > > > > > Sent: Thursday, July 11, 2002 1:56 PM > > > Subject: RE: [Seamoby] CT Requirements Comments from IESG > > > > > > > > > > Dirk: > > > > > > > > A valid point. There is a certain atomic level of > > > granularity which has to > > > > be > > > > dealt with - that is, there's no protocol in the world that > > > can synchronize > > > > changes in > > > > information that occur at the source while the information > > > is "in-flight" or > > > > being > > > > received at the destination. If changes in context while > > > the context is > > > > being transferred > > > > make a different to the successful performance of CT, then > > > there is no hope. > > > > > > > > The problem is most significant for state context > > > transfer. E.g. counters > > > > will continue > > > > to count while CT is moving the context to the destination. > > > Either these > > > > changes have no > > > > significant impact upon the forwarding service provided at > > > the new AR (e.g. > > > > it may not > > > > matter that a policing meter misses a few packet counts), > > > or a different > > > > mechanism > > > > has to be defined for re-establishing the state context. > > > > > > > > The handover is real and unavoidable. Mitigating the > > > disruption to the > > > > service at the new > > > > AR is the challenge. It would be nice if the disruption > was nil, but > > > > unlikely. > > > > > > > > Gary > > > > > > > > -----Original Message----- > > > > From: Dirk.Trossen@nokia.com [ mailto:Dirk.Trossen@nokia.com ] > > > > Sent: July 11, 2002 16:30 > > > > To: Kenward, Gary [WDLN2:AN10:EXCH]; kempf@docomolabs-usa.com; > > > > seamoby@ietf.org > > > > Subject: RE: [Seamoby] CT Requirements Comments from IESG > > > > > > > > > > > > Hi all, > > > > > > > > jumping in as somebody who has been an observer so far, > > > struggling with the > > > > current discussion on > > > > 'integrity'. > > > > > > > > When I look at the current wording, i.e., > > > > "5.5.2 A context update MUST preserve the integrity, and > > > thus the meaning, > > > > of the context > > > > at each receiving AR. The context at the AR actually > > > supporting an MN's > > > > traffic will change with time. > > > > For example, the MN may initiate new microflow(s), or > > > discontinue existing > > > > microflows. Any change of context > > > > at the supporting AR must be replicated at those ARs that > > > have already > > > > received context for that MN.", > > > > > > > > and compare this to the plain integrity of the actually > > > transmitted data > > > > (i.e., its bits and therefore its semantics) > > > > that has been brought to the table as a replacement now, > > > I'm quite confident > > > > that this is not what the requirement > > > > is talking about. > > > > > > > > If we remove the word 'meaning' (which is very vague > and free for > > > > interpretation for me as well), it is still the word > > > > 'integrity' left, which is more than plain integrity of the > > > transmitted > > > > data, in particular if we look at the following sentences > > > > in the requirement, which state what kind of integrity is > > > meant (which > > > > probably also builds the bridge to the vague > > > > term 'meaning'), namely that the integrity of a context > > > must be preserved in > > > > the sense that a received context at new > > > > AR at some point t must be the same as the context at old > > > AR at the same > > > > time t. This is by far more than plain data > > > > integrity of the transmitted data. Even if your data has > > > been transmitted > > > > correctly, the context might be stale (and therefore > > > > its integrity is lost) because it had changed at old AR in > > > the meanwhile. > > > > The action to be taken is also given in the text, > > > > namely the change of context has to be replicated to the > > > new AR. As you can > > > > (hopefully) see this is by far more than > > > > preserving the 'meaning' of each bit. It mandates that > > > changes in the bit > > > > values at one end are reflected at the other > > > > end, i.e., it talks about distributed data integrity in my > > > interpretation of > > > > the requirement text. > > > > > > > > Hence, the actual concern might have been (just guessing) > > > whether or not it > > > > is the task of the CT protocol to > > > > preserve the abovementioned integrity. Maybe, the IESG > > > wants to see this > > > > functionality left to the replication logic that resides > > > > within each AR. Or on the contrary, they do not see this > > > important topic > > > > covered appropriately. > > > > > > > > Regards, > > > > > > > > > > > > Dirk > > > > > > > > -----Original Message----- > > > > From: ext Gary Kenward [ mailto:gkenward@nortelnetworks.com ] > > > > Sent: Thursday, July 11, 2002 3:48 PM > > > > To: 'James Kempf'; seamoby@ietf.org > > > > Subject: RE: [Seamoby] CT Requirements Comments from IESG > > > > > > > > > > > > > > > > You call it fidelity, I call it data integrity. > > > > I've seen "data integrity" used in publications > > > > (no, I cannot quote references). > > > > > > > > What we need is a term that everyone, including the > > > > IESG, can agree upon. > > > > > > > > > -----Original Message----- > > > > > From: James Kempf [ mailto:kempf@docomolabs-usa.com > > > > < mailto:kempf@docomolabs-usa.com > ] > > > > > Sent: July 11, 2002 12:22 > > > > > To: Kenward, Gary [WDLN2:AN10:EXCH]; seamoby@ietf.org > > > > > Subject: Re: [Seamoby] CT Requirements Comments from IESG > > > > > > > > > > > > > > > > Perhaps the actual answer is to state exactly what > was intended > > > > > > originally: that the bit order and bit values have to > > > arrive exactly > > > > > > as they were transmitted. > > > > > > > > > > > > > > > > So this requirement is talking about transmission fidelity? I > > > > > sure would not have guessed that from reading it. I thought it > > > > > intended to talk about usability. > > > > > > > > > > I would suggest that the wording you have above is really a > > > > > lot more precise that what is currently in the spec. > > > > > > > > > > Any other comments? Could we substitute Gary's wording above > > > > > for "meaning" in the current requirement. > > > > > > > > > > jak > > > > > > > > > > > > > > > > > > > > > > > > > ------_=_NextPart_001_01C22EA0.64955AF0 Content-Type: text/html; charset="iso-8859-1" RE: [Seamoby] CT Requirements Comments from IESG
 
-----Original Message-----
From: Gary Kenward [mailto:gkenward@nortelnetworks.com]
Sent: Thursday, July 18, 2002 9:52 AM
To: 'Nakhjiri Madjid-MNAKHJI1'; 'Charles E. Perkins'
Cc: seamoby@ietf.org
Subject: RE: [Seamoby] CT Requirements Comments from IESG

Define "done"? 
 
Madjid>> Exactly my point, if you keep sending updates while you're
sending other context, you are never done.
 
Seriously, if CT is performed during or after a handover (reactively)
then, yes, there's not much more that can be done. If the context at
the destination is out of synch with changes in the source context,
there is an increased risk that the seamlessness of the handover will
be degraded.
 
Madjid>> Yes, assuming you mean L3 handover,
and this is the most critical use of CT: optimization
of handovers. I can't have CT add to feature disruption by getting
into an endless cycle of updates.
 
However, if CT is performed before a handover begins (proactively),
and changes occur at the source AR, then it would seem reasonable to
attempt updates. There is a presumption here that there is something
to be gained in handover performance by performing CT in advance of
an actual handover. It could turn out that CT (and the subsequent installion
of context at the destination AR) is so fast, that leaving the transfer
of context until a handover occurs (i.e. no proactive, only reactive) is
a sufficient, and simpler solution. We really won't know whether this
is the case until the wg starts looking at CT solutions. 
 
Madjid>>sure, but this is not a time-critical CT and CT needs to send updates because
it started too early on a dynamic context.
 
 
 
  
Cheers,
Gary
-----Original Message-----
From: Nakhjiri Madjid-MNAKHJI1 [mailto:Madjid.Nakhjiri@motorola.com]
Sent: July 17, 2002 19:25
To: Kenward, Gary [WDLN2:AN10:EXCH]; 'Charles E. Perkins'
Cc: seamoby@ietf.org
Subject: RE: [Seamoby] CT Requirements Comments from IESG

Well, not trying to regurgitate (as you said)
but we never agreed on timing and reliability requirements and maybe
that was ok, because they depend on the scenario and protocols.
So why talk about sending updates after CT is done?
 
 
Madjid
-----Original Message-----
From: Gary Kenward [mailto:gkenward@nortelnetworks.com]
Sent: Friday, July 12, 2002 2:35 PM
To: 'Charles E. Perkins'
Cc: seamoby@ietf.org
Subject: RE: [Seamoby] CT Requirements Comments from IESG

I agree Charlie. However, we have to fix the issue with
the requirements. Are you suggesting that we relax the
requirement? By how much - clearly, some updates are required
(e.g. CT really should try and update when flows come and go).

Gary

> -----Original Message-----
> From: Charles E. Perkins [mailto:charliep@iprg.nokia.com]
> Sent: July 12, 2002 12:15
> To: Kenward, Gary [WDLN2:AN10:EXCH]
> Cc: seamoby@ietf.org
> Subject: Re: [Seamoby] CT Requirements Comments from IESG
>
>
>
>
> Hello folks,
>
> I think we ought to try to get context transfers
> working correctly without initially worrying about
> this synchronization problem.
>
> In the instances I am familiar with, it is not
> required.  The most stringent case seems to be
> ROHC, and even for that it is not necessary.
>
> We can solve the most urgent problems without having
> to deal with any additional context synchronization.
> When the old AR sends it, and the new AR gets it,
> we should consider the transfer done.  In those
> cases where reliability is at issue, the old AR
> can retransmit when ACK is not received.  In many
> cases, retransmission of context even once won't
> be useful.
>
> Regards,
> Charlie P.
>
>
>
> > Gary Kenward wrote:
> >
> > James:
> >
> >   Yes, we need to fix it, and I think it is doable.
> > Thanks to Dirk for highlighting the real problem here
> > (I think historically, the integrity requirement came out
> > of the reliability section, and somehow, got lumped with
> > synchronization and updates).
> >
> >   I think the requirements need a bit of rewording, and
> > the paragraph should fall out from this. I do believe
> > however, that making the synchronization of context between
> > old and new AR a MUST requirement would be too extreme, and
> > result in a brittle solution. CT should certainly do it's best to
> > provide synchronization, but as was discussed in a recent
> > exchange, it would be impossible to guarantee synchronization
> > at any instant.
> >
> >   Any ideas/comments from the wg?
> >
> > Gary
> >
> > > -----Original Message-----
> > > From: James Kempf [mailto:kempf@docomolabs-usa.com]
> > > Sent: July 11, 2002 18:32
> > > To: Kenward, Gary [WDLN2:AN10:EXCH]; Dirk.Trossen@nokia.com;
> > > seamoby@ietf.org
> > > Subject: Re: [Seamoby] CT Requirements Comments from IESG
> > >
> > >
> > > Gary/Dirk,
> > >
> > > I think you may be on to something here. I think this might
> > > be what the IESG was talking about it the first point, namely the
> > > lack of discussion of dynamic changes in the context.
> > >
> > > Is there some way we could cook this idea down into a
> > > paragraph that we could insert for this requirement?
> > >
> > >             jak
> > >
> > > ----- Original Message -----
> > > From: "Gary Kenward" <gkenward@nortelnetworks.com>
> > > To: <Dirk.Trossen@nokia.com>; <kempf@docomolabs-usa.com>;
> > > <seamoby@ietf.org>
> > > Sent: Thursday, July 11, 2002 1:56 PM
> > > Subject: RE: [Seamoby] CT Requirements Comments from IESG
> > >
> > >
> > > > Dirk:
> > > >
> > > >   A valid point. There is a certain atomic level of
> > > granularity which has to
> > > > be
> > > > dealt with - that is, there's no protocol in the world that
> > > can synchronize
> > > > changes in
> > > > information that occur at the source while the information
> > > is "in-flight" or
> > > > being
> > > > received at the destination. If changes in context while
> > > the context is
> > > > being transferred
> > > > make a different to the successful performance of CT, then
> > > there is no hope.
> > > >
> > > >   The problem is most significant for state context
> > > transfer. E.g. counters
> > > > will continue
> > > > to count while CT is moving the context to the destination.
> > > Either these
> > > > changes have no
> > > > significant impact upon the forwarding service provided at
> > > the new AR (e.g.
> > > > it may not
> > > > matter that a policing meter misses a few packet counts),
> > > or a different
> > > > mechanism
> > > > has to be defined for re-establishing the state context.
> > > >
> > > >   The handover is real and unavoidable. Mitigating the
> > > disruption to the
> > > > service at the new
> > > > AR is the challenge. It would be nice if the disruption
> was nil, but
> > > > unlikely.
> > > >
> > > > Gary
> > > >
> > > > -----Original Message-----
> > > > From: Dirk.Trossen@nokia.com [mailto:Dirk.Trossen@nokia.com]
> > > > Sent: July 11, 2002 16:30
> > > > To: Kenward, Gary [WDLN2:AN10:EXCH]; kempf@docomolabs-usa.com;
> > > > seamoby@ietf.org
> > > > Subject: RE: [Seamoby] CT Requirements Comments from IESG
> > > >
> > > >
> > > > Hi all,
> > > >
> > > > jumping in as somebody who has been an observer so far,
> > > struggling with the
> > > > current discussion on
> > > > 'integrity'.
> > > >
> > > > When I look at the current wording, i.e.,
> > > > "5.5.2 A context update MUST preserve the integrity, and
> > > thus the meaning,
> > > > of the context
> > > > at each receiving AR. The context at the AR actually
> > > supporting an MN's
> > > > traffic will change with time.
> > > > For example, the MN may initiate new microflow(s), or
> > > discontinue existing
> > > > microflows. Any change of context
> > > > at the supporting AR must be replicated at those ARs that
> > > have already
> > > > received context for that MN.",
> > > >
> > > > and compare this to the plain integrity of the actually
> > > transmitted data
> > > > (i.e., its bits and therefore its semantics)
> > > > that has been brought to the table as a replacement now,
> > > I'm quite confident
> > > > that this is not what the requirement
> > > > is talking about.
> > > >
> > > > If we remove the word 'meaning' (which is very vague
> and free for
> > > > interpretation for me as well), it is still the word
> > > > 'integrity' left, which is more than plain integrity of the
> > > transmitted
> > > > data, in particular if we look at the following sentences
> > > > in the requirement, which state what kind of integrity is
> > > meant (which
> > > > probably also builds the bridge to the vague
> > > > term 'meaning'), namely that the integrity of a context
> > > must be preserved in
> > > > the sense that a received context at new
> > > > AR at some point t must be the same as the context at old
> > > AR at the same
> > > > time t. This is by far more than plain data
> > > > integrity of the transmitted data. Even if your data has
> > > been transmitted
> > > > correctly, the context might be stale (and therefore
> > > > its integrity is lost) because it had changed at old AR in
> > > the meanwhile.
> > > > The action to be taken is also given in the text,
> > > > namely the change of context has to be replicated to the
> > > new AR. As you can
> > > > (hopefully) see this is by far more than
> > > > preserving the 'meaning' of each bit. It mandates that
> > > changes in the bit
> > > > values at one end are reflected at the other
> > > > end, i.e., it talks about distributed data integrity in my
> > > interpretation of
> > > > the requirement text.
> > > >
> > > > Hence, the actual concern might have been (just guessing)
> > > whether or not it
> > > > is the task of the CT protocol to
> > > > preserve the abovementioned integrity. Maybe, the IESG
> > > wants to see this
> > > > functionality left to the replication logic that resides
> > > > within each AR. Or on the contrary, they do not see this
> > > important topic
> > > > covered appropriately.
> > > >
> > > > Regards,
> > > >
> > > >
> > > > Dirk
> > > >
> > > > -----Original Message-----
> > > > From: ext Gary Kenward [mailto:gkenward@nortelnetworks.com]
> > > > Sent: Thursday, July 11, 2002 3:48 PM
> > > > To: 'James Kempf'; seamoby@ietf.org
> > > > Subject: RE: [Seamoby] CT Requirements Comments from IESG
> > > >
> > > >
> > > >
> > > > You call it fidelity, I call it data integrity.
> > > > I've seen "data integrity" used in publications
> > > > (no, I cannot quote references).
> > > >
> > > > What we need is a term that everyone, including the
> > > > IESG, can agree upon.
> > > >
> > > > > -----Original Message-----
> > > > > From: James Kempf [ mailto:kempf@docomolabs-usa.com
> > > > <mailto:kempf@docomolabs-usa.com> ]
> > > > > Sent: July 11, 2002 12:22
> > > > > To: Kenward, Gary [WDLN2:AN10:EXCH]; seamoby@ietf.org
> > > > > Subject: Re: [Seamoby] CT Requirements Comments from IESG
> > > > >
> > > > >
> > > > > > Perhaps the actual answer is to state exactly what
> was intended
> > > > > > originally: that the bit order and bit values have to
> > > arrive exactly
> > > > > > as they were transmitted.
> > > > > >
> > > > >
> > > > > So this requirement is talking about transmission fidelity? I
> > > > > sure would not have guessed that from reading it. I thought it
> > > > > intended to talk about usability.
> > > > >
> > > > > I would suggest that the wording you have above is really a
> > > > > lot more precise that what is currently in the spec.
> > > > >
> > > > > Any other comments? Could we substitute Gary's wording above
> > > > > for "meaning" in the current requirement.
> > > > >
> > > > >             jak
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
>

------_=_NextPart_001_01C22EA0.64955AF0-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Thu Jul 18 17:19:55 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12935 for ; Thu, 18 Jul 2002 17:19:55 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA12307 for seamoby-archive@odin.ietf.org; Thu, 18 Jul 2002 17:20:55 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA12182; Thu, 18 Jul 2002 17:16:44 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA12109 for ; Thu, 18 Jul 2002 17:16:40 -0400 (EDT) Received: from ftpbox.mot.com (ftpbox.mot.com [129.188.136.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12839 for ; Thu, 18 Jul 2002 17:15:40 -0400 (EDT) Received: [from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id OAA03402 for ; Thu, 18 Jul 2002 14:16:37 -0700 (MST)] Received: [from il27exm07.cig.mot.com (IL27EXM07.cig.mot.com [136.182.15.116]) by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id OAA01961 for ; Thu, 18 Jul 2002 14:15:19 -0700 (MST)] Received: by IL27EXM07.cig.mot.com with Internet Mail Service (5.5.2654.52) id <3FLZY4YM>; Thu, 18 Jul 2002 16:16:35 -0500 Message-ID: <35DBB8B7AC89D4118E98009027B1009B08AD55C6@IL27EXM10.cig.mot.com> From: Nakhjiri Madjid-MNAKHJI1 To: "'Gary Kenward'" , Nakhjiri Madjid-MNAKHJI1 , "'Charles E. Perkins'" Cc: seamoby@ietf.org Subject: RE: [Seamoby] CT Requirements Comments from IESG Date: Thu, 18 Jul 2002 16:16:33 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.52) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C22EA0.64955AF0" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C22EA0.64955AF0 Content-Type: text/plain; charset="iso-8859-1" -----Original Message----- From: Gary Kenward [mailto:gkenward@nortelnetworks.com] Sent: Thursday, July 18, 2002 9:52 AM To: 'Nakhjiri Madjid-MNAKHJI1'; 'Charles E. Perkins' Cc: seamoby@ietf.org Subject: RE: [Seamoby] CT Requirements Comments from IESG Define "done"? Madjid>> Exactly my point, if you keep sending updates while you're sending other context, you are never done. Seriously, if CT is performed during or after a handover (reactively) then, yes, there's not much more that can be done. If the context at the destination is out of synch with changes in the source context, there is an increased risk that the seamlessness of the handover will be degraded. Madjid>> Yes, assuming you mean L3 handover, and this is the most critical use of CT: optimization of handovers. I can't have CT add to feature disruption by getting into an endless cycle of updates. However, if CT is performed before a handover begins (proactively), and changes occur at the source AR, then it would seem reasonable to attempt updates. There is a presumption here that there is something to be gained in handover performance by performing CT in advance of an actual handover. It could turn out that CT (and the subsequent installion of context at the destination AR) is so fast, that leaving the transfer of context until a handover occurs (i.e. no proactive, only reactive) is a sufficient, and simpler solution. We really won't know whether this is the case until the wg starts looking at CT solutions. Madjid>>sure, but this is not a time-critical CT and CT needs to send updates because it started too early on a dynamic context. Cheers, Gary -----Original Message----- From: Nakhjiri Madjid-MNAKHJI1 [mailto:Madjid.Nakhjiri@motorola.com] Sent: July 17, 2002 19:25 To: Kenward, Gary [WDLN2:AN10:EXCH]; 'Charles E. Perkins' Cc: seamoby@ietf.org Subject: RE: [Seamoby] CT Requirements Comments from IESG Well, not trying to regurgitate (as you said) but we never agreed on timing and reliability requirements and maybe that was ok, because they depend on the scenario and protocols. So why talk about sending updates after CT is done? Madjid -----Original Message----- From: Gary Kenward [mailto:gkenward@nortelnetworks.com] Sent: Friday, July 12, 2002 2:35 PM To: 'Charles E. Perkins' Cc: seamoby@ietf.org Subject: RE: [Seamoby] CT Requirements Comments from IESG I agree Charlie. However, we have to fix the issue with the requirements. Are you suggesting that we relax the requirement? By how much - clearly, some updates are required (e.g. CT really should try and update when flows come and go). Gary > -----Original Message----- > From: Charles E. Perkins [ mailto:charliep@iprg.nokia.com ] > Sent: July 12, 2002 12:15 > To: Kenward, Gary [WDLN2:AN10:EXCH] > Cc: seamoby@ietf.org > Subject: Re: [Seamoby] CT Requirements Comments from IESG > > > > > Hello folks, > > I think we ought to try to get context transfers > working correctly without initially worrying about > this synchronization problem. > > In the instances I am familiar with, it is not > required. The most stringent case seems to be > ROHC, and even for that it is not necessary. > > We can solve the most urgent problems without having > to deal with any additional context synchronization. > When the old AR sends it, and the new AR gets it, > we should consider the transfer done. In those > cases where reliability is at issue, the old AR > can retransmit when ACK is not received. In many > cases, retransmission of context even once won't > be useful. > > Regards, > Charlie P. > > > > > Gary Kenward wrote: > > > > James: > > > > Yes, we need to fix it, and I think it is doable. > > Thanks to Dirk for highlighting the real problem here > > (I think historically, the integrity requirement came out > > of the reliability section, and somehow, got lumped with > > synchronization and updates). > > > > I think the requirements need a bit of rewording, and > > the paragraph should fall out from this. I do believe > > however, that making the synchronization of context between > > old and new AR a MUST requirement would be too extreme, and > > result in a brittle solution. CT should certainly do it's best to > > provide synchronization, but as was discussed in a recent > > exchange, it would be impossible to guarantee synchronization > > at any instant. > > > > Any ideas/comments from the wg? > > > > Gary > > > > > -----Original Message----- > > > From: James Kempf [ mailto:kempf@docomolabs-usa.com ] > > > Sent: July 11, 2002 18:32 > > > To: Kenward, Gary [WDLN2:AN10:EXCH]; Dirk.Trossen@nokia.com; > > > seamoby@ietf.org > > > Subject: Re: [Seamoby] CT Requirements Comments from IESG > > > > > > > > > Gary/Dirk, > > > > > > I think you may be on to something here. I think this might > > > be what the IESG was talking about it the first point, namely the > > > lack of discussion of dynamic changes in the context. > > > > > > Is there some way we could cook this idea down into a > > > paragraph that we could insert for this requirement? > > > > > > jak > > > > > > ----- Original Message ----- > > > From: "Gary Kenward" > > > To: ; ; > > > > > > Sent: Thursday, July 11, 2002 1:56 PM > > > Subject: RE: [Seamoby] CT Requirements Comments from IESG > > > > > > > > > > Dirk: > > > > > > > > A valid point. There is a certain atomic level of > > > granularity which has to > > > > be > > > > dealt with - that is, there's no protocol in the world that > > > can synchronize > > > > changes in > > > > information that occur at the source while the information > > > is "in-flight" or > > > > being > > > > received at the destination. If changes in context while > > > the context is > > > > being transferred > > > > make a different to the successful performance of CT, then > > > there is no hope. > > > > > > > > The problem is most significant for state context > > > transfer. E.g. counters > > > > will continue > > > > to count while CT is moving the context to the destination. > > > Either these > > > > changes have no > > > > significant impact upon the forwarding service provided at > > > the new AR (e.g. > > > > it may not > > > > matter that a policing meter misses a few packet counts), > > > or a different > > > > mechanism > > > > has to be defined for re-establishing the state context. > > > > > > > > The handover is real and unavoidable. Mitigating the > > > disruption to the > > > > service at the new > > > > AR is the challenge. It would be nice if the disruption > was nil, but > > > > unlikely. > > > > > > > > Gary > > > > > > > > -----Original Message----- > > > > From: Dirk.Trossen@nokia.com [ mailto:Dirk.Trossen@nokia.com ] > > > > Sent: July 11, 2002 16:30 > > > > To: Kenward, Gary [WDLN2:AN10:EXCH]; kempf@docomolabs-usa.com; > > > > seamoby@ietf.org > > > > Subject: RE: [Seamoby] CT Requirements Comments from IESG > > > > > > > > > > > > Hi all, > > > > > > > > jumping in as somebody who has been an observer so far, > > > struggling with the > > > > current discussion on > > > > 'integrity'. > > > > > > > > When I look at the current wording, i.e., > > > > "5.5.2 A context update MUST preserve the integrity, and > > > thus the meaning, > > > > of the context > > > > at each receiving AR. The context at the AR actually > > > supporting an MN's > > > > traffic will change with time. > > > > For example, the MN may initiate new microflow(s), or > > > discontinue existing > > > > microflows. Any change of context > > > > at the supporting AR must be replicated at those ARs that > > > have already > > > > received context for that MN.", > > > > > > > > and compare this to the plain integrity of the actually > > > transmitted data > > > > (i.e., its bits and therefore its semantics) > > > > that has been brought to the table as a replacement now, > > > I'm quite confident > > > > that this is not what the requirement > > > > is talking about. > > > > > > > > If we remove the word 'meaning' (which is very vague > and free for > > > > interpretation for me as well), it is still the word > > > > 'integrity' left, which is more than plain integrity of the > > > transmitted > > > > data, in particular if we look at the following sentences > > > > in the requirement, which state what kind of integrity is > > > meant (which > > > > probably also builds the bridge to the vague > > > > term 'meaning'), namely that the integrity of a context > > > must be preserved in > > > > the sense that a received context at new > > > > AR at some point t must be the same as the context at old > > > AR at the same > > > > time t. This is by far more than plain data > > > > integrity of the transmitted data. Even if your data has > > > been transmitted > > > > correctly, the context might be stale (and therefore > > > > its integrity is lost) because it had changed at old AR in > > > the meanwhile. > > > > The action to be taken is also given in the text, > > > > namely the change of context has to be replicated to the > > > new AR. As you can > > > > (hopefully) see this is by far more than > > > > preserving the 'meaning' of each bit. It mandates that > > > changes in the bit > > > > values at one end are reflected at the other > > > > end, i.e., it talks about distributed data integrity in my > > > interpretation of > > > > the requirement text. > > > > > > > > Hence, the actual concern might have been (just guessing) > > > whether or not it > > > > is the task of the CT protocol to > > > > preserve the abovementioned integrity. Maybe, the IESG > > > wants to see this > > > > functionality left to the replication logic that resides > > > > within each AR. Or on the contrary, they do not see this > > > important topic > > > > covered appropriately. > > > > > > > > Regards, > > > > > > > > > > > > Dirk > > > > > > > > -----Original Message----- > > > > From: ext Gary Kenward [ mailto:gkenward@nortelnetworks.com ] > > > > Sent: Thursday, July 11, 2002 3:48 PM > > > > To: 'James Kempf'; seamoby@ietf.org > > > > Subject: RE: [Seamoby] CT Requirements Comments from IESG > > > > > > > > > > > > > > > > You call it fidelity, I call it data integrity. > > > > I've seen "data integrity" used in publications > > > > (no, I cannot quote references). > > > > > > > > What we need is a term that everyone, including the > > > > IESG, can agree upon. > > > > > > > > > -----Original Message----- > > > > > From: James Kempf [ mailto:kempf@docomolabs-usa.com > > > > < mailto:kempf@docomolabs-usa.com > ] > > > > > Sent: July 11, 2002 12:22 > > > > > To: Kenward, Gary [WDLN2:AN10:EXCH]; seamoby@ietf.org > > > > > Subject: Re: [Seamoby] CT Requirements Comments from IESG > > > > > > > > > > > > > > > > Perhaps the actual answer is to state exactly what > was intended > > > > > > originally: that the bit order and bit values have to > > > arrive exactly > > > > > > as they were transmitted. > > > > > > > > > > > > > > > > So this requirement is talking about transmission fidelity? I > > > > > sure would not have guessed that from reading it. I thought it > > > > > intended to talk about usability. > > > > > > > > > > I would suggest that the wording you have above is really a > > > > > lot more precise that what is currently in the spec. > > > > > > > > > > Any other comments? Could we substitute Gary's wording above > > > > > for "meaning" in the current requirement. > > > > > > > > > > jak > > > > > > > > > > > > > > > > > > > > > > > > > ------_=_NextPart_001_01C22EA0.64955AF0 Content-Type: text/html; charset="iso-8859-1" RE: [Seamoby] CT Requirements Comments from IESG
 
-----Original Message-----
From: Gary Kenward [mailto:gkenward@nortelnetworks.com]
Sent: Thursday, July 18, 2002 9:52 AM
To: 'Nakhjiri Madjid-MNAKHJI1'; 'Charles E. Perkins'
Cc: seamoby@ietf.org
Subject: RE: [Seamoby] CT Requirements Comments from IESG

Define "done"? 
 
Madjid>> Exactly my point, if you keep sending updates while you're
sending other context, you are never done.
 
Seriously, if CT is performed during or after a handover (reactively)
then, yes, there's not much more that can be done. If the context at
the destination is out of synch with changes in the source context,
there is an increased risk that the seamlessness of the handover will
be degraded.
 
Madjid>> Yes, assuming you mean L3 handover,
and this is the most critical use of CT: optimization
of handovers. I can't have CT add to feature disruption by getting
into an endless cycle of updates.
 
However, if CT is performed before a handover begins (proactively),
and changes occur at the source AR, then it would seem reasonable to
attempt updates. There is a presumption here that there is something
to be gained in handover performance by performing CT in advance of
an actual handover. It could turn out that CT (and the subsequent installion
of context at the destination AR) is so fast, that leaving the transfer
of context until a handover occurs (i.e. no proactive, only reactive) is
a sufficient, and simpler solution. We really won't know whether this
is the case until the wg starts looking at CT solutions. 
 
Madjid>>sure, but this is not a time-critical CT and CT needs to send updates because
it started too early on a dynamic context.
 
 
 
  
Cheers,
Gary
-----Original Message-----
From: Nakhjiri Madjid-MNAKHJI1 [mailto:Madjid.Nakhjiri@motorola.com]
Sent: July 17, 2002 19:25
To: Kenward, Gary [WDLN2:AN10:EXCH]; 'Charles E. Perkins'
Cc: seamoby@ietf.org
Subject: RE: [Seamoby] CT Requirements Comments from IESG

Well, not trying to regurgitate (as you said)
but we never agreed on timing and reliability requirements and maybe
that was ok, because they depend on the scenario and protocols.
So why talk about sending updates after CT is done?
 
 
Madjid
-----Original Message-----
From: Gary Kenward [mailto:gkenward@nortelnetworks.com]
Sent: Friday, July 12, 2002 2:35 PM
To: 'Charles E. Perkins'
Cc: seamoby@ietf.org
Subject: RE: [Seamoby] CT Requirements Comments from IESG

I agree Charlie. However, we have to fix the issue with
the requirements. Are you suggesting that we relax the
requirement? By how much - clearly, some updates are required
(e.g. CT really should try and update when flows come and go).

Gary

> -----Original Message-----
> From: Charles E. Perkins [mailto:charliep@iprg.nokia.com]
> Sent: July 12, 2002 12:15
> To: Kenward, Gary [WDLN2:AN10:EXCH]
> Cc: seamoby@ietf.org
> Subject: Re: [Seamoby] CT Requirements Comments from IESG
>
>
>
>
> Hello folks,
>
> I think we ought to try to get context transfers
> working correctly without initially worrying about
> this synchronization problem.
>
> In the instances I am familiar with, it is not
> required.  The most stringent case seems to be
> ROHC, and even for that it is not necessary.
>
> We can solve the most urgent problems without having
> to deal with any additional context synchronization.
> When the old AR sends it, and the new AR gets it,
> we should consider the transfer done.  In those
> cases where reliability is at issue, the old AR
> can retransmit when ACK is not received.  In many
> cases, retransmission of context even once won't
> be useful.
>
> Regards,
> Charlie P.
>
>
>
> > Gary Kenward wrote:
> >
> > James:
> >
> >   Yes, we need to fix it, and I think it is doable.
> > Thanks to Dirk for highlighting the real problem here
> > (I think historically, the integrity requirement came out
> > of the reliability section, and somehow, got lumped with
> > synchronization and updates).
> >
> >   I think the requirements need a bit of rewording, and
> > the paragraph should fall out from this. I do believe
> > however, that making the synchronization of context between
> > old and new AR a MUST requirement would be too extreme, and
> > result in a brittle solution. CT should certainly do it's best to
> > provide synchronization, but as was discussed in a recent
> > exchange, it would be impossible to guarantee synchronization
> > at any instant.
> >
> >   Any ideas/comments from the wg?
> >
> > Gary
> >
> > > -----Original Message-----
> > > From: James Kempf [mailto:kempf@docomolabs-usa.com]
> > > Sent: July 11, 2002 18:32
> > > To: Kenward, Gary [WDLN2:AN10:EXCH]; Dirk.Trossen@nokia.com;
> > > seamoby@ietf.org
> > > Subject: Re: [Seamoby] CT Requirements Comments from IESG
> > >
> > >
> > > Gary/Dirk,
> > >
> > > I think you may be on to something here. I think this might
> > > be what the IESG was talking about it the first point, namely the
> > > lack of discussion of dynamic changes in the context.
> > >
> > > Is there some way we could cook this idea down into a
> > > paragraph that we could insert for this requirement?
> > >
> > >             jak
> > >
> > > ----- Original Message -----
> > > From: "Gary Kenward" <gkenward@nortelnetworks.com>
> > > To: <Dirk.Trossen@nokia.com>; <kempf@docomolabs-usa.com>;
> > > <seamoby@ietf.org>
> > > Sent: Thursday, July 11, 2002 1:56 PM
> > > Subject: RE: [Seamoby] CT Requirements Comments from IESG
> > >
> > >
> > > > Dirk:
> > > >
> > > >   A valid point. There is a certain atomic level of
> > > granularity which has to
> > > > be
> > > > dealt with - that is, there's no protocol in the world that
> > > can synchronize
> > > > changes in
> > > > information that occur at the source while the information
> > > is "in-flight" or
> > > > being
> > > > received at the destination. If changes in context while
> > > the context is
> > > > being transferred
> > > > make a different to the successful performance of CT, then
> > > there is no hope.
> > > >
> > > >   The problem is most significant for state context
> > > transfer. E.g. counters
> > > > will continue
> > > > to count while CT is moving the context to the destination.
> > > Either these
> > > > changes have no
> > > > significant impact upon the forwarding service provided at
> > > the new AR (e.g.
> > > > it may not
> > > > matter that a policing meter misses a few packet counts),
> > > or a different
> > > > mechanism
> > > > has to be defined for re-establishing the state context.
> > > >
> > > >   The handover is real and unavoidable. Mitigating the
> > > disruption to the
> > > > service at the new
> > > > AR is the challenge. It would be nice if the disruption
> was nil, but
> > > > unlikely.
> > > >
> > > > Gary
> > > >
> > > > -----Original Message-----
> > > > From: Dirk.Trossen@nokia.com [mailto:Dirk.Trossen@nokia.com]
> > > > Sent: July 11, 2002 16:30
> > > > To: Kenward, Gary [WDLN2:AN10:EXCH]; kempf@docomolabs-usa.com;
> > > > seamoby@ietf.org
> > > > Subject: RE: [Seamoby] CT Requirements Comments from IESG
> > > >
> > > >
> > > > Hi all,
> > > >
> > > > jumping in as somebody who has been an observer so far,
> > > struggling with the
> > > > current discussion on
> > > > 'integrity'.
> > > >
> > > > When I look at the current wording, i.e.,
> > > > "5.5.2 A context update MUST preserve the integrity, and
> > > thus the meaning,
> > > > of the context
> > > > at each receiving AR. The context at the AR actually
> > > supporting an MN's
> > > > traffic will change with time.
> > > > For example, the MN may initiate new microflow(s), or
> > > discontinue existing
> > > > microflows. Any change of context
> > > > at the supporting AR must be replicated at those ARs that
> > > have already
> > > > received context for that MN.",
> > > >
> > > > and compare this to the plain integrity of the actually
> > > transmitted data
> > > > (i.e., its bits and therefore its semantics)
> > > > that has been brought to the table as a replacement now,
> > > I'm quite confident
> > > > that this is not what the requirement
> > > > is talking about.
> > > >
> > > > If we remove the word 'meaning' (which is very vague
> and free for
> > > > interpretation for me as well), it is still the word
> > > > 'integrity' left, which is more than plain integrity of the
> > > transmitted
> > > > data, in particular if we look at the following sentences
> > > > in the requirement, which state what kind of integrity is
> > > meant (which
> > > > probably also builds the bridge to the vague
> > > > term 'meaning'), namely that the integrity of a context
> > > must be preserved in
> > > > the sense that a received context at new
> > > > AR at some point t must be the same as the context at old
> > > AR at the same
> > > > time t. This is by far more than plain data
> > > > integrity of the transmitted data. Even if your data has
> > > been transmitted
> > > > correctly, the context might be stale (and therefore
> > > > its integrity is lost) because it had changed at old AR in
> > > the meanwhile.
> > > > The action to be taken is also given in the text,
> > > > namely the change of context has to be replicated to the
> > > new AR. As you can
> > > > (hopefully) see this is by far more than
> > > > preserving the 'meaning' of each bit. It mandates that
> > > changes in the bit
> > > > values at one end are reflected at the other
> > > > end, i.e., it talks about distributed data integrity in my
> > > interpretation of
> > > > the requirement text.
> > > >
> > > > Hence, the actual concern might have been (just guessing)
> > > whether or not it
> > > > is the task of the CT protocol to
> > > > preserve the abovementioned integrity. Maybe, the IESG
> > > wants to see this
> > > > functionality left to the replication logic that resides
> > > > within each AR. Or on the contrary, they do not see this
> > > important topic
> > > > covered appropriately.
> > > >
> > > > Regards,
> > > >
> > > >
> > > > Dirk
> > > >
> > > > -----Original Message-----
> > > > From: ext Gary Kenward [mailto:gkenward@nortelnetworks.com]
> > > > Sent: Thursday, July 11, 2002 3:48 PM
> > > > To: 'James Kempf'; seamoby@ietf.org
> > > > Subject: RE: [Seamoby] CT Requirements Comments from IESG
> > > >
> > > >
> > > >
> > > > You call it fidelity, I call it data integrity.
> > > > I've seen "data integrity" used in publications
> > > > (no, I cannot quote references).
> > > >
> > > > What we need is a term that everyone, including the
> > > > IESG, can agree upon.
> > > >
> > > > > -----Original Message-----
> > > > > From: James Kempf [ mailto:kempf@docomolabs-usa.com
> > > > <mailto:kempf@docomolabs-usa.com> ]
> > > > > Sent: July 11, 2002 12:22
> > > > > To: Kenward, Gary [WDLN2:AN10:EXCH]; seamoby@ietf.org
> > > > > Subject: Re: [Seamoby] CT Requirements Comments from IESG
> > > > >
> > > > >
> > > > > > Perhaps the actual answer is to state exactly what
> was intended
> > > > > > originally: that the bit order and bit values have to
> > > arrive exactly
> > > > > > as they were transmitted.
> > > > > >
> > > > >
> > > > > So this requirement is talking about transmission fidelity? I
> > > > > sure would not have guessed that from reading it. I thought it
> > > > > intended to talk about usability.
> > > > >
> > > > > I would suggest that the wording you have above is really a
> > > > > lot more precise that what is currently in the spec.
> > > > >
> > > > > Any other comments? Could we substitute Gary's wording above
> > > > > for "meaning" in the current requirement.
> > > > >
> > > > >             jak
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
>

------_=_NextPart_001_01C22EA0.64955AF0-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Thu Jul 18 17:56:15 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13412 for ; Thu, 18 Jul 2002 17:56:15 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA14092; Thu, 18 Jul 2002 17:53:43 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA14064 for ; Thu, 18 Jul 2002 17:53:42 -0400 (EDT) Received: from motgate3.mot.com (motgate3.mot.com [144.189.100.103]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13382 for ; Thu, 18 Jul 2002 17:52:41 -0400 (EDT) Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate3.mot.com (motgate3 2.1) with ESMTP id OAA08508 for ; Thu, 18 Jul 2002 14:52:37 -0700 (MST)] Received: [from il27exm07.cig.mot.com (IL27EXM07.cig.mot.com [136.182.15.116]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id OAA11389 for ; Thu, 18 Jul 2002 14:53:39 -0700 (MST)] Received: by IL27EXM07.cig.mot.com with Internet Mail Service (5.5.2654.52) id <3FLZYVXD>; Thu, 18 Jul 2002 16:53:38 -0500 Message-ID: <35DBB8B7AC89D4118E98009027B1009B08AD55C7@IL27EXM10.cig.mot.com> From: Nakhjiri Madjid-MNAKHJI1 To: "'Gary Kenward'" , Nakhjiri Madjid-MNAKHJI1 , "'James Kempf'" , john.loughney@nokia.com, seamoby@ietf.org Subject: RE: [Seamoby] Proposal on Sync/NoSync Requirement Date: Thu, 18 Jul 2002 16:53:35 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.52) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C22EA5.90B0E9B0" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C22EA5.90B0E9B0 Content-Type: text/plain; charset="iso-8859-1" Gary, Thanks for your reply. We are getting there. Please see comments below BR, Madjid > Proposed: > 5.5 Context Update and Synchronization > 5.5.1 The context transfer protocol MUST be capable of supporting the > updates to context information when it changes. > > Madjid>> Ok, this takes care of the dynamic context, however, we Actually, the real concern I have is not for dynamic context as it is for changes in the makeup of the traffic for the MN - i.e. the arrival and departure of microflows. This would change the configuration (aka static) context. Madjid>> Ok, as I recall the context transfer deals with a microflow as a unit. The discussion of arrival and departure of microflows is relevant if you are aggregating multiple microflows, so maybe this should be added to the section that talks about aggregation, otherwise I think it is hard to avoid the interpretation I made (dynamic feature context) > need to be clarify that we are not requiring the oldAR sends updates > to context features it has already transmitted while it is > transmitting > context for other features, otherwise CT might never end. I absolutely agree with you. Madjid>> glad to hear that. > Since, some folks have brought that up, I want to make sure that we > are not reading that in the requirement. Updates initiated by oldAR > should only be based on outside triggers such as new flow, > flow terminations > or messages from central entities... There seems to be a concern that CT will not be able to guarantee perfect synchronization of the configuration and state of both ARs. My response to this concern is, of course not, CT was never intended to do such a think. This is not distributed computing, it is handover optimization. Perhaps a new requirement would help clarify this, something like: 5.5.x Context transfer SHALL NOT attempt to guarantee perfect synchronization of context. The purpose of CT is to improve handover as best as it can. Given the complexity and overheads needed to synchronize distributed state machines, it is expected that occasionally, the context of the source and destination AR will not agree. The CT solution must minimize the likelihood of this happening "Addition: by careful consideration of the rate by which context will change over time . 5.5.x+1 Context transfer WILL NOT attempt to mitigate the effects of stale context at the receiving AR. Madjid>> Can't tell if you can put a NON-requirement to a requirement document :) but if you think it provides clarity, then fine. I added a little bit more guidance at the end, up to you whether you want to use it. To me, this all seems like responding to "what if" scenarios, which if we got to far into this mode, could cause the number of requirements to explode. However, perhaps this is one distinction we should emphasize. > > 5.5.2 Context updates SHOULD complete before the context is needed at > the receiving AR. > > Madjid>> How do we know when the context is needed at the > receiving AR? > I find this more like a design guidance than a requirement. Well, a requirement is a design guide. The wg has debated this extensively, Madjid, with, if I recall, no better resolution then the current wording. If you have a recommendation for wording of a requirement that would identify when CT should be complete, please submit it. Madjid>> "Context transfer must not add to the length of the disruption of the feature, for which it is transfering states for, otherwise the use of context transfer defeats its purpose" > The following > text > can with some exceptions added to the explanation of 5.5.2. > > The context at the AR actually supporting an MN's traffic will > change with time. For example, the MN may initiate new > microflow(s), > or discontinue existing microflows. > Madjid>> the above is good. > > Any change of context at the > supporting AR must be replicated at those ARs that have already > received context for that MN. > Madjid>> MUSt is too strong. 5.5.1 is SHOULD, so should this one be > (sorry for too many shoulds :)) There are ways to avoid having to do > this through CT. Hmmm. Could you expand on the "many ways"? I am curious. Madjid>> well I didn't say "many". If the change of context is resulted from an outside event by an outside trigger, the same information may be sent to the new AR to update the context there instead. As for MUST versus SHOULD: I think there is an issue here with interpretation. My interpretation is that CT MUST ATTEMPT to convey context changes at the ARs. That is, CT must provide the mechanisms to transfer context changes to all ARs that received the context originally. I agree that it is too extreme to state that the changes MUST make it to all ARs. Perhaps some rewording is needed. Yes, I think you covered it yourself in your new formulation. > However, context changes are often driven by events > external to the > sending AR, and will thus be asynchronous to any on-going context > updates. Given that context transfers will take a finite amount of > time to complete, it is possible that a change in context > cannot be > conveyed in time to the destination AR to avoid any impact > on a possible > handover. The objective of the context transfer design > must be to make > the likelihood of this delay, and its magnitude, as low as > possible. > > Madjid>> The above is good. > > This is not perfect: the desire to avoid a requirement for an > extreme degree > > of synchronization is only implied by the soft "SHOULD" in 5.5.2. > Regards, > Gary > > > > -----Original Message----- Thanks for the response; very useful input. Gary ------_=_NextPart_001_01C22EA5.90B0E9B0 Content-Type: text/html; charset="iso-8859-1" RE: [Seamoby] Proposal on Sync/NoSync Requirement
Gary,
Thanks for your reply. We are getting there. Please see comments below
 
BR,
 
Madjid
 
<snip> 
 > Proposed:
> 5.5 Context Update and Synchronization
> 5.5.1 The context transfer protocol MUST be capable of supporting the
>       updates to context information when it changes. 
>
>  Madjid>> Ok, this takes care of the dynamic context, however, we

Actually, the real concern I have is not for dynamic context as it is
for changes in the makeup of the traffic for the MN - i.e. the arrival
and departure of microflows. This would change the configuration (aka
static) context. 

Madjid>> Ok, as I recall the context transfer deals with a microflow

as a unit. The discussion of arrival and departure of    microflows is

relevant if you are aggregating multiple microflows, so maybe this

should be added to the section that talks about aggregation, otherwise

I think it is hard to avoid the interpretation I made (dynamic feature context) 

> need to be clarify that we are not requiring the oldAR sends updates
> to context features it has already transmitted while it is
> transmitting
> context for other features, otherwise CT might never end.

I absolutely agree with you.  

Madjid>> glad to hear that. 

> Since, some folks have brought that up, I want to make sure that we
>  are not reading that in the requirement. Updates initiated by oldAR
> should only be based on outside triggers such as new flow,
> flow terminations
> or messages from central entities...

There seems to be a concern that CT will not be able to guarantee perfect
synchronization of the configuration and state of both ARs. My response to
this concern is, of course not, CT was never intended to do such a think.
This is not distributed computing, it is handover optimization.

Perhaps a new requirement would help clarify this, something like:

5.5.x Context transfer SHALL NOT attempt to guarantee perfect synchronization
of context. The purpose of CT is to improve handover as best as it can. Given
the complexity and overheads needed to synchronize distributed state machines,
it is expected that occasionally, the context of the source and destination
AR will not agree. The CT solution must minimize the likelihood of this happening  "Addition:

by careful consideration of the rate by which context will change over time .

5.5.x+1 Context transfer WILL NOT attempt to mitigate the effects of stale context
        at the receiving AR.

 Madjid>> Can't tell if you can put a NON-requirement to a requirement document :)
but if you think it provides clarity, then fine. I added a little bit more guidance at the end,
up to you whether you want to use it.  

To me, this all seems like responding to "what if" scenarios, which if we got
to far into this mode, could cause the number of requirements to explode.
However, perhaps this is one distinction we should emphasize.

>
> 5.5.2 Context updates SHOULD complete before the context is needed at
>       the receiving AR.
>
> Madjid>> How do we know when the context is needed at the
> receiving AR?
> I find this more like a design guidance than a requirement.

Well, a requirement is a design guide. The wg has debated this extensively,
Madjid, with, if I recall, no better resolution then the current wording.
If you have a recommendation for wording of a requirement that would identify
when CT should be complete, please submit it.  

Madjid>> "Context transfer must not add to the length of the disruption of the feature, for

which it is transfering states for, otherwise the use of context transfer

defeats its purpose"

> The following
> text
> can with some exceptions added to the explanation of 5.5.2.
>
>    The context at the AR actually supporting an MN's traffic will
>    change with time. For example, the MN may initiate new
> microflow(s),
>    or discontinue existing microflows.
> Madjid>> the above is good.
>
> Any change of context at the
>    supporting AR must be replicated at those ARs that have already
>    received context for that MN.
> Madjid>> MUSt is too strong. 5.5.1 is SHOULD, so should this one be
> (sorry for too many shoulds :)) There are ways to avoid having to do
> this through CT.

Hmmm. Could you expand on the "many ways"? I am curious.  

Madjid>> well I didn't say "many". If the change of context is resulted

from an outside event by an outside trigger, the same information

may be sent to the new AR to update the context there instead. 

As for MUST versus SHOULD: I think there is an issue here with interpretation.
My interpretation is that CT MUST ATTEMPT to convey context changes at the ARs.
That is, CT must provide the mechanisms to transfer context changes to all ARs
that received the context originally. I agree that it is too extreme to state
that the changes MUST make it to all ARs. Perhaps some rewording is needed.

 Yes, I think you covered it yourself in your new formulation.

 
>    However, context changes are often driven by events
> external to the
>    sending AR, and will thus be asynchronous to any on-going context
>    updates. Given that context transfers will take a finite amount of
>    time to complete, it is possible that a change in context
> cannot be
>    conveyed in time to the destination AR to avoid any impact
> on a possible
>    handover. The objective of the context transfer design
> must be to make
>    the likelihood of this delay, and its magnitude, as low as
> possible.
>
> Madjid>> The above is good.
>
> This is not perfect: the desire to avoid a requirement for an
> extreme degree
>
> of synchronization is only implied by the soft "SHOULD" in 5.5.2.
> Regards,
> Gary
>
>
> > -----Original Message-----

Thanks for the response; very useful input.

Gary

------_=_NextPart_001_01C22EA5.90B0E9B0-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Thu Jul 18 17:56:15 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13421 for ; Thu, 18 Jul 2002 17:56:15 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA14172 for seamoby-archive@odin.ietf.org; Thu, 18 Jul 2002 17:57:15 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA14092; Thu, 18 Jul 2002 17:53:43 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA14064 for ; Thu, 18 Jul 2002 17:53:42 -0400 (EDT) Received: from motgate3.mot.com (motgate3.mot.com [144.189.100.103]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13382 for ; Thu, 18 Jul 2002 17:52:41 -0400 (EDT) Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate3.mot.com (motgate3 2.1) with ESMTP id OAA08508 for ; Thu, 18 Jul 2002 14:52:37 -0700 (MST)] Received: [from il27exm07.cig.mot.com (IL27EXM07.cig.mot.com [136.182.15.116]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id OAA11389 for ; Thu, 18 Jul 2002 14:53:39 -0700 (MST)] Received: by IL27EXM07.cig.mot.com with Internet Mail Service (5.5.2654.52) id <3FLZYVXD>; Thu, 18 Jul 2002 16:53:38 -0500 Message-ID: <35DBB8B7AC89D4118E98009027B1009B08AD55C7@IL27EXM10.cig.mot.com> From: Nakhjiri Madjid-MNAKHJI1 To: "'Gary Kenward'" , Nakhjiri Madjid-MNAKHJI1 , "'James Kempf'" , john.loughney@nokia.com, seamoby@ietf.org Subject: RE: [Seamoby] Proposal on Sync/NoSync Requirement Date: Thu, 18 Jul 2002 16:53:35 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.52) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C22EA5.90B0E9B0" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C22EA5.90B0E9B0 Content-Type: text/plain; charset="iso-8859-1" Gary, Thanks for your reply. We are getting there. Please see comments below BR, Madjid > Proposed: > 5.5 Context Update and Synchronization > 5.5.1 The context transfer protocol MUST be capable of supporting the > updates to context information when it changes. > > Madjid>> Ok, this takes care of the dynamic context, however, we Actually, the real concern I have is not for dynamic context as it is for changes in the makeup of the traffic for the MN - i.e. the arrival and departure of microflows. This would change the configuration (aka static) context. Madjid>> Ok, as I recall the context transfer deals with a microflow as a unit. The discussion of arrival and departure of microflows is relevant if you are aggregating multiple microflows, so maybe this should be added to the section that talks about aggregation, otherwise I think it is hard to avoid the interpretation I made (dynamic feature context) > need to be clarify that we are not requiring the oldAR sends updates > to context features it has already transmitted while it is > transmitting > context for other features, otherwise CT might never end. I absolutely agree with you. Madjid>> glad to hear that. > Since, some folks have brought that up, I want to make sure that we > are not reading that in the requirement. Updates initiated by oldAR > should only be based on outside triggers such as new flow, > flow terminations > or messages from central entities... There seems to be a concern that CT will not be able to guarantee perfect synchronization of the configuration and state of both ARs. My response to this concern is, of course not, CT was never intended to do such a think. This is not distributed computing, it is handover optimization. Perhaps a new requirement would help clarify this, something like: 5.5.x Context transfer SHALL NOT attempt to guarantee perfect synchronization of context. The purpose of CT is to improve handover as best as it can. Given the complexity and overheads needed to synchronize distributed state machines, it is expected that occasionally, the context of the source and destination AR will not agree. The CT solution must minimize the likelihood of this happening "Addition: by careful consideration of the rate by which context will change over time . 5.5.x+1 Context transfer WILL NOT attempt to mitigate the effects of stale context at the receiving AR. Madjid>> Can't tell if you can put a NON-requirement to a requirement document :) but if you think it provides clarity, then fine. I added a little bit more guidance at the end, up to you whether you want to use it. To me, this all seems like responding to "what if" scenarios, which if we got to far into this mode, could cause the number of requirements to explode. However, perhaps this is one distinction we should emphasize. > > 5.5.2 Context updates SHOULD complete before the context is needed at > the receiving AR. > > Madjid>> How do we know when the context is needed at the > receiving AR? > I find this more like a design guidance than a requirement. Well, a requirement is a design guide. The wg has debated this extensively, Madjid, with, if I recall, no better resolution then the current wording. If you have a recommendation for wording of a requirement that would identify when CT should be complete, please submit it. Madjid>> "Context transfer must not add to the length of the disruption of the feature, for which it is transfering states for, otherwise the use of context transfer defeats its purpose" > The following > text > can with some exceptions added to the explanation of 5.5.2. > > The context at the AR actually supporting an MN's traffic will > change with time. For example, the MN may initiate new > microflow(s), > or discontinue existing microflows. > Madjid>> the above is good. > > Any change of context at the > supporting AR must be replicated at those ARs that have already > received context for that MN. > Madjid>> MUSt is too strong. 5.5.1 is SHOULD, so should this one be > (sorry for too many shoulds :)) There are ways to avoid having to do > this through CT. Hmmm. Could you expand on the "many ways"? I am curious. Madjid>> well I didn't say "many". If the change of context is resulted from an outside event by an outside trigger, the same information may be sent to the new AR to update the context there instead. As for MUST versus SHOULD: I think there is an issue here with interpretation. My interpretation is that CT MUST ATTEMPT to convey context changes at the ARs. That is, CT must provide the mechanisms to transfer context changes to all ARs that received the context originally. I agree that it is too extreme to state that the changes MUST make it to all ARs. Perhaps some rewording is needed. Yes, I think you covered it yourself in your new formulation. > However, context changes are often driven by events > external to the > sending AR, and will thus be asynchronous to any on-going context > updates. Given that context transfers will take a finite amount of > time to complete, it is possible that a change in context > cannot be > conveyed in time to the destination AR to avoid any impact > on a possible > handover. The objective of the context transfer design > must be to make > the likelihood of this delay, and its magnitude, as low as > possible. > > Madjid>> The above is good. > > This is not perfect: the desire to avoid a requirement for an > extreme degree > > of synchronization is only implied by the soft "SHOULD" in 5.5.2. > Regards, > Gary > > > > -----Original Message----- Thanks for the response; very useful input. Gary ------_=_NextPart_001_01C22EA5.90B0E9B0 Content-Type: text/html; charset="iso-8859-1" RE: [Seamoby] Proposal on Sync/NoSync Requirement
Gary,
Thanks for your reply. We are getting there. Please see comments below
 
BR,
 
Madjid
 
<snip> 
 > Proposed:
> 5.5 Context Update and Synchronization
> 5.5.1 The context transfer protocol MUST be capable of supporting the
>       updates to context information when it changes. 
>
>  Madjid>> Ok, this takes care of the dynamic context, however, we

Actually, the real concern I have is not for dynamic context as it is
for changes in the makeup of the traffic for the MN - i.e. the arrival
and departure of microflows. This would change the configuration (aka
static) context. 

Madjid>> Ok, as I recall the context transfer deals with a microflow

as a unit. The discussion of arrival and departure of    microflows is

relevant if you are aggregating multiple microflows, so maybe this

should be added to the section that talks about aggregation, otherwise

I think it is hard to avoid the interpretation I made (dynamic feature context) 

> need to be clarify that we are not requiring the oldAR sends updates
> to context features it has already transmitted while it is
> transmitting
> context for other features, otherwise CT might never end.

I absolutely agree with you.  

Madjid>> glad to hear that. 

> Since, some folks have brought that up, I want to make sure that we
>  are not reading that in the requirement. Updates initiated by oldAR
> should only be based on outside triggers such as new flow,
> flow terminations
> or messages from central entities...

There seems to be a concern that CT will not be able to guarantee perfect
synchronization of the configuration and state of both ARs. My response to
this concern is, of course not, CT was never intended to do such a think.
This is not distributed computing, it is handover optimization.

Perhaps a new requirement would help clarify this, something like:

5.5.x Context transfer SHALL NOT attempt to guarantee perfect synchronization
of context. The purpose of CT is to improve handover as best as it can. Given
the complexity and overheads needed to synchronize distributed state machines,
it is expected that occasionally, the context of the source and destination
AR will not agree. The CT solution must minimize the likelihood of this happening  "Addition:

by careful consideration of the rate by which context will change over time .

5.5.x+1 Context transfer WILL NOT attempt to mitigate the effects of stale context
        at the receiving AR.

 Madjid>> Can't tell if you can put a NON-requirement to a requirement document :)
but if you think it provides clarity, then fine. I added a little bit more guidance at the end,
up to you whether you want to use it.  

To me, this all seems like responding to "what if" scenarios, which if we got
to far into this mode, could cause the number of requirements to explode.
However, perhaps this is one distinction we should emphasize.

>
> 5.5.2 Context updates SHOULD complete before the context is needed at
>       the receiving AR.
>
> Madjid>> How do we know when the context is needed at the
> receiving AR?
> I find this more like a design guidance than a requirement.

Well, a requirement is a design guide. The wg has debated this extensively,
Madjid, with, if I recall, no better resolution then the current wording.
If you have a recommendation for wording of a requirement that would identify
when CT should be complete, please submit it.  

Madjid>> "Context transfer must not add to the length of the disruption of the feature, for

which it is transfering states for, otherwise the use of context transfer

defeats its purpose"

> The following
> text
> can with some exceptions added to the explanation of 5.5.2.
>
>    The context at the AR actually supporting an MN's traffic will
>    change with time. For example, the MN may initiate new
> microflow(s),
>    or discontinue existing microflows.
> Madjid>> the above is good.
>
> Any change of context at the
>    supporting AR must be replicated at those ARs that have already
>    received context for that MN.
> Madjid>> MUSt is too strong. 5.5.1 is SHOULD, so should this one be
> (sorry for too many shoulds :)) There are ways to avoid having to do
> this through CT.

Hmmm. Could you expand on the "many ways"? I am curious.  

Madjid>> well I didn't say "many". If the change of context is resulted

from an outside event by an outside trigger, the same information

may be sent to the new AR to update the context there instead. 

As for MUST versus SHOULD: I think there is an issue here with interpretation.
My interpretation is that CT MUST ATTEMPT to convey context changes at the ARs.
That is, CT must provide the mechanisms to transfer context changes to all ARs
that received the context originally. I agree that it is too extreme to state
that the changes MUST make it to all ARs. Perhaps some rewording is needed.

 Yes, I think you covered it yourself in your new formulation.

 
>    However, context changes are often driven by events
> external to the
>    sending AR, and will thus be asynchronous to any on-going context
>    updates. Given that context transfers will take a finite amount of
>    time to complete, it is possible that a change in context
> cannot be
>    conveyed in time to the destination AR to avoid any impact
> on a possible
>    handover. The objective of the context transfer design
> must be to make
>    the likelihood of this delay, and its magnitude, as low as
> possible.
>
> Madjid>> The above is good.
>
> This is not perfect: the desire to avoid a requirement for an
> extreme degree
>
> of synchronization is only implied by the soft "SHOULD" in 5.5.2.
> Regards,
> Gary
>
>
> > -----Original Message-----

Thanks for the response; very useful input.

Gary

------_=_NextPart_001_01C22EA5.90B0E9B0-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Thu Jul 18 18:08:58 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12791 for ; Thu, 18 Jul 2002 17:12:01 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA12035 for seamoby-archive@odin.ietf.org; Thu, 18 Jul 2002 17:13:01 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA11326; Thu, 18 Jul 2002 17:00:40 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA11285 for ; Thu, 18 Jul 2002 17:00:37 -0400 (EDT) Received: from motgate4.mot.com (motgate4.mot.com [144.189.100.102]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12636 for ; Thu, 18 Jul 2002 16:59:37 -0400 (EDT) Received: [from pobox4.mot.com (pobox4.mot.com [10.64.251.243]) by motgate4.mot.com (motgate4 2.1) with ESMTP id OAA08464 for ; Thu, 18 Jul 2002 14:00:34 -0700 (MST)] Received: [from il75exm04.cig.mot.com ([136.182.110.113]) by pobox4.mot.com (MOT-pobox4 2.0) with ESMTP id OAA27611 for ; Thu, 18 Jul 2002 14:00:34 -0700 (MST)] Received: by IL75EXM04 with Internet Mail Service (5.5.2654.52) id ; Thu, 18 Jul 2002 16:00:33 -0500 Message-ID: <35DBB8B7AC89D4118E98009027B1009B08AD55C5@IL27EXM10.cig.mot.com> From: Nakhjiri Madjid-MNAKHJI1 To: "'James Kempf'" , seamoby@ietf.org Cc: mankin@psg.com Subject: RE: [Seamoby] Section 5.2 in CT Requirements Date: Thu, 18 Jul 2002 16:00:19 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.52) Content-Type: text/plain; charset="iso-8859-1" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org -----Original Message----- From: James Kempf [mailto:kempf@docomolabs-usa.com] Sent: Thursday, July 18, 2002 6:14 AM To: seamoby@ietf.org Cc: mankin@psg.com Subject: [Seamoby] Section 5.2 in CT Requirements Folks, So recently I had another look at the CT Requirements document and I was suprised to find Section 5.2. It says this: 5.2 Transport Reliability This section is intentionally left blank as the working group is waiting for a questionnaire from the transport directorate. The result of the questionnaire will create requirements that will be added in this section in a later revision of this specification. It is completely unacceptable that we sent this document to the IESG with this section in it. When a document passes through last call, it should be complete. As WG chairs, Pat and I naturally must accept responsibility for this, but this should really have been caught in WG Last Call. I would like suggest replacing Section 5.2 with the following: 5.2 Transport Requirements This section contains requirements on the context transfer transport. 5.1 Independence of Underlying Transport The context transfer solution MUST be independent of the underlying transport. It SHOULD be possible to transfer context directly on top of reliable transports, such as TCP or SCTP, unreliable transports, such as UDP, or as an option or extention on another protocol, such as handover signaling. Comments? Madjid>> I second Gary's comments. The wording was suggested to us. I also remember the very long debate of reliability and the fact that some folks wanted reliability and some didn't. Our TEXT proposal shows that you can add reliability to CT if you want it and is not offered to you. Good suggestion on 5.1. I am ok with your 5.1 formulation, I think it should make everybody happy by leaving enough flexibility there. However, I am not sure how I can prove independance of transport for our proposal even, i.e. the first MUST in 5.1. Don't know why the 5.2 (This section....) is still there. Madjid jak u _______________________________________________ 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 From seamoby-admin@ietf.org Thu Jul 18 19:01:52 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14748 for ; Thu, 18 Jul 2002 19:01:52 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA17544; Thu, 18 Jul 2002 19:00:57 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA17507 for ; Thu, 18 Jul 2002 19:00:55 -0400 (EDT) Received: from fridge.docomolabs-usa.com (fwuser@key1.docomolabs-usa.com [216.98.102.225]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14722 for ; Thu, 18 Jul 2002 18:59:58 -0400 (EDT) Message-ID: <005601c22eae$bb314230$056015ac@T23KEMPF> From: "James Kempf" To: "Gary Kenward" , Cc: References: <9FBD322B7824D511B36900508BF93C9C01AA4C3C@zcard031.ca.nortel.com> Subject: Re: [Seamoby] Section 5.2 in CT Requirements Date: Thu, 18 Jul 2002 15:59:10 -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-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit Gary, It isn't a question of debate. We've been talking about these requirements for a year and a half, it is time to complete them. We need to nail down this section. Do you have any specific technical comments on the requirement? jak ----- Original Message ----- From: "Gary Kenward" To: "'James Kempf'" ; Cc: Sent: Thursday, July 18, 2002 8:16 AM Subject: RE: [Seamoby] Section 5.2 in CT Requirements > James: > > There was a long and arduous debate over transport reliability. > The wording you are objecting to was, I believe, Allison's suggestion. > At the very lease, it was inserted with her approval in order to move > the requirements forward. > > Of course, you can open the debate again, but I don't expect it to > be resolved any better then it was the last time through. The problem > is that there seems to be some very different ideas in the wg as to > what the CT protocol looks like, with contradicting assumptions as > to what is needed from a transport layer. > > Gary > > > -----Original Message----- > > From: James Kempf [mailto:kempf@docomolabs-usa.com] > > Sent: July 18, 2002 07:14 > > To: seamoby@ietf.org > > Cc: mankin@psg.com > > Subject: [Seamoby] Section 5.2 in CT Requirements > > > > > > Folks, > > > > So recently I had another look at the CT Requirements > > document and I was > > suprised to find Section 5.2. It says this: > > > > 5.2 Transport Reliability > > > > This section is intentionally left blank as the > > working group is > > waiting for a questionnaire from the transport > > directorate. The result > > of the questionnaire will create requirements that > > will be added in this > > section in a later revision of this specification. > > > > It is completely unacceptable that we sent this document to > > the IESG with this > > section in it. When a document passes through last call, it > > should be complete. > > As WG chairs, Pat and I naturally must accept responsibility > > for this, but this > > should really have been caught in WG Last Call. > > > > I would like suggest replacing Section 5.2 with the following: > > > > 5.2 Transport Requirements > > > > This section contains requirements on the context > > transfer transport. > > > > 5.1 Independence of Underlying Transport > > > > The context transfer solution MUST be independent of > > the underlying > > transport. It SHOULD be possible to transfer > > context directly on top of reliable transports, such > > as TCP or SCTP, > > unreliable transports, such as UDP, or as an > > option or extention on another protocol, such as > > handover signaling. > > > > Comments? > > > > > > jak > > u > > > > > > > > _______________________________________________ > > 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 From daemon@optimus.ietf.org Thu Jul 18 19:01:52 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14753 for ; Thu, 18 Jul 2002 19:01:52 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id TAA17731 for seamoby-archive@odin.ietf.org; Thu, 18 Jul 2002 19:02:49 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA17544; Thu, 18 Jul 2002 19:00:57 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA17507 for ; Thu, 18 Jul 2002 19:00:55 -0400 (EDT) Received: from fridge.docomolabs-usa.com (fwuser@key1.docomolabs-usa.com [216.98.102.225]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14722 for ; Thu, 18 Jul 2002 18:59:58 -0400 (EDT) Message-ID: <005601c22eae$bb314230$056015ac@T23KEMPF> From: "James Kempf" To: "Gary Kenward" , Cc: References: <9FBD322B7824D511B36900508BF93C9C01AA4C3C@zcard031.ca.nortel.com> Subject: Re: [Seamoby] Section 5.2 in CT Requirements Date: Thu, 18 Jul 2002 15:59:10 -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-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit Gary, It isn't a question of debate. We've been talking about these requirements for a year and a half, it is time to complete them. We need to nail down this section. Do you have any specific technical comments on the requirement? jak ----- Original Message ----- From: "Gary Kenward" To: "'James Kempf'" ; Cc: Sent: Thursday, July 18, 2002 8:16 AM Subject: RE: [Seamoby] Section 5.2 in CT Requirements > James: > > There was a long and arduous debate over transport reliability. > The wording you are objecting to was, I believe, Allison's suggestion. > At the very lease, it was inserted with her approval in order to move > the requirements forward. > > Of course, you can open the debate again, but I don't expect it to > be resolved any better then it was the last time through. The problem > is that there seems to be some very different ideas in the wg as to > what the CT protocol looks like, with contradicting assumptions as > to what is needed from a transport layer. > > Gary > > > -----Original Message----- > > From: James Kempf [mailto:kempf@docomolabs-usa.com] > > Sent: July 18, 2002 07:14 > > To: seamoby@ietf.org > > Cc: mankin@psg.com > > Subject: [Seamoby] Section 5.2 in CT Requirements > > > > > > Folks, > > > > So recently I had another look at the CT Requirements > > document and I was > > suprised to find Section 5.2. It says this: > > > > 5.2 Transport Reliability > > > > This section is intentionally left blank as the > > working group is > > waiting for a questionnaire from the transport > > directorate. The result > > of the questionnaire will create requirements that > > will be added in this > > section in a later revision of this specification. > > > > It is completely unacceptable that we sent this document to > > the IESG with this > > section in it. When a document passes through last call, it > > should be complete. > > As WG chairs, Pat and I naturally must accept responsibility > > for this, but this > > should really have been caught in WG Last Call. > > > > I would like suggest replacing Section 5.2 with the following: > > > > 5.2 Transport Requirements > > > > This section contains requirements on the context > > transfer transport. > > > > 5.1 Independence of Underlying Transport > > > > The context transfer solution MUST be independent of > > the underlying > > transport. It SHOULD be possible to transfer > > context directly on top of reliable transports, such > > as TCP or SCTP, > > unreliable transports, such as UDP, or as an > > option or extention on another protocol, such as > > handover signaling. > > > > Comments? > > > > > > jak > > u > > > > > > > > _______________________________________________ > > 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 From seamoby-admin@ietf.org Thu Jul 18 19:26:06 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15240 for ; Thu, 18 Jul 2002 19:26:06 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA18243; Thu, 18 Jul 2002 19:24:13 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA18214 for ; Thu, 18 Jul 2002 19:24:08 -0400 (EDT) Received: from fridge.docomolabs-usa.com (fwuser@key1.docomolabs-usa.com [216.98.102.225]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15193 for ; Thu, 18 Jul 2002 19:23:10 -0400 (EDT) Message-ID: <00b901c22eb1$f8bf2240$056015ac@T23KEMPF> From: "James Kempf" To: , "Nakhjiri Madjid-MNAKHJI1" , Cc: References: <35DBB8B7AC89D4118E98009027B1009B08AD55C5@IL27EXM10.cig.mot.com> <200207181459.03702.pcalhoun@bstormnetworks.com> Subject: Re: [Seamoby] Section 5.2 in CT Requirements Date: Thu, 18 Jul 2002 16:18:29 -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-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit > I know that there was concern by the IESG on this very topic, and the idea of > the above text was a compromise with the area director, who was going to > initiate a discussion with the transport directorate. Unfortunately, this > never occured, and the text remained. Allison had suggested that we continue > with the non-transport discussions and that this topic will resurface again > in the future. > > The question is whether this can occur after the document can be published > (perhaps without the section). > Harald made a comment in the IESG Plenary on Wed. nite about working groups submitting documents with "to be defined" to the IESG. This document qualifies, IMHO. jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Thu Jul 18 19:26:06 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15247 for ; Thu, 18 Jul 2002 19:26:06 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id TAA18293 for seamoby-archive@odin.ietf.org; Thu, 18 Jul 2002 19:27:03 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA18243; Thu, 18 Jul 2002 19:24:13 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA18214 for ; Thu, 18 Jul 2002 19:24:08 -0400 (EDT) Received: from fridge.docomolabs-usa.com (fwuser@key1.docomolabs-usa.com [216.98.102.225]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15193 for ; Thu, 18 Jul 2002 19:23:10 -0400 (EDT) Message-ID: <00b901c22eb1$f8bf2240$056015ac@T23KEMPF> From: "James Kempf" To: , "Nakhjiri Madjid-MNAKHJI1" , Cc: References: <35DBB8B7AC89D4118E98009027B1009B08AD55C5@IL27EXM10.cig.mot.com> <200207181459.03702.pcalhoun@bstormnetworks.com> Subject: Re: [Seamoby] Section 5.2 in CT Requirements Date: Thu, 18 Jul 2002 16:18:29 -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-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit > I know that there was concern by the IESG on this very topic, and the idea of > the above text was a compromise with the area director, who was going to > initiate a discussion with the transport directorate. Unfortunately, this > never occured, and the text remained. Allison had suggested that we continue > with the non-transport discussions and that this topic will resurface again > in the future. > > The question is whether this can occur after the document can be published > (perhaps without the section). > Harald made a comment in the IESG Plenary on Wed. nite about working groups submitting documents with "to be defined" to the IESG. This document qualifies, IMHO. jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Thu Jul 18 19:37:09 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15669 for ; Thu, 18 Jul 2002 19:37:09 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA19008; Thu, 18 Jul 2002 19:36:16 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA18979 for ; Thu, 18 Jul 2002 19:36:14 -0400 (EDT) Received: from porsta.cs.Helsinki.FI (root@porsta.cs.Helsinki.FI [128.214.48.124]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15546 for ; Thu, 18 Jul 2002 19:35:16 -0400 (EDT) Received: from melkinpaasi.cs.Helsinki.FI (IDENT:jmanner@melkinpaasi.cs.Helsinki.FI [128.214.10.13]) by porsta.cs.Helsinki.FI (8.11.6/8.11.6) with ESMTP id g6INaAk18966; Fri, 19 Jul 2002 02:36:11 +0300 Date: Fri, 19 Jul 2002 02:36:02 +0300 (EEST) From: Jukka MJ Manner To: Govind Krishnamurthi cc: seamoby@ietf.org Subject: Re: [Seamoby] Terminology Draft In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT Content-Transfer-Encoding: 8BIT Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 8BIT Ack, consider that added to the list of future updates. jim On Thu, 18 Jul 2002, Govind Krishnamurthi wrote: > > > Hi Jim, > I would hope that Jukka incorporates some of the changes that were made > to the CAR Discovery Issues document. I think the definition of some terms > may have been changed. > > Thanks, > Govind. > > >Hi, > > > >In Salt Lake, we agreed to make draft-manner-seamoby-terms-04.txt a working > >group document. This contains mobility related turns in common use within > >the > >IETF at this time. > > > >Is there any objection to making this draft a working group draft? > > > > jak > > > > > >_______________________________________________ > >Seamoby mailing list > >Seamoby@ietf.org > >https://www1.ietf.org/mailman/listinfo/seamoby > > > > > _________________________________________________________________ > Join the world’s largest e-mail service with MSN Hotmail. > http://www.hotmail.com > > > _______________________________________________ > 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 From daemon@optimus.ietf.org Thu Jul 18 19:37:10 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15676 for ; Thu, 18 Jul 2002 19:37:09 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id TAA19095 for seamoby-archive@odin.ietf.org; Thu, 18 Jul 2002 19:38:06 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA19008; Thu, 18 Jul 2002 19:36:16 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA18979 for ; Thu, 18 Jul 2002 19:36:14 -0400 (EDT) Received: from porsta.cs.Helsinki.FI (root@porsta.cs.Helsinki.FI [128.214.48.124]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15546 for ; Thu, 18 Jul 2002 19:35:16 -0400 (EDT) Received: from melkinpaasi.cs.Helsinki.FI (IDENT:jmanner@melkinpaasi.cs.Helsinki.FI [128.214.10.13]) by porsta.cs.Helsinki.FI (8.11.6/8.11.6) with ESMTP id g6INaAk18966; Fri, 19 Jul 2002 02:36:11 +0300 Date: Fri, 19 Jul 2002 02:36:02 +0300 (EEST) From: Jukka MJ Manner To: Govind Krishnamurthi cc: seamoby@ietf.org Subject: Re: [Seamoby] Terminology Draft In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT Content-Transfer-Encoding: 8BIT Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 8BIT Ack, consider that added to the list of future updates. jim On Thu, 18 Jul 2002, Govind Krishnamurthi wrote: > > > Hi Jim, > I would hope that Jukka incorporates some of the changes that were made > to the CAR Discovery Issues document. I think the definition of some terms > may have been changed. > > Thanks, > Govind. > > >Hi, > > > >In Salt Lake, we agreed to make draft-manner-seamoby-terms-04.txt a working > >group document. This contains mobility related turns in common use within > >the > >IETF at this time. > > > >Is there any objection to making this draft a working group draft? > > > > jak > > > > > >_______________________________________________ > >Seamoby mailing list > >Seamoby@ietf.org > >https://www1.ietf.org/mailman/listinfo/seamoby > > > > > _________________________________________________________________ > Join the world’s largest e-mail service with MSN Hotmail. > http://www.hotmail.com > > > _______________________________________________ > 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 From seamoby-admin@ietf.org Fri Jul 19 04:42:25 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03426 for ; Fri, 19 Jul 2002 04:42:24 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA22447; Fri, 19 Jul 2002 04:37:38 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA22415 for ; Fri, 19 Jul 2002 04:37:36 -0400 (EDT) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03334 for ; Fri, 19 Jul 2002 04:36:36 -0400 (EDT) From: john.loughney@nokia.com Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g6J8c6i14446 for ; Fri, 19 Jul 2002 11:38:07 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 19 Jul 2002 11:37:35 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Fri, 19 Jul 2002 11:37:34 +0300 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Seamoby] Section 5.2 in CT Requirements X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Date: Fri, 19 Jul 2002 11:37:33 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC6579F@esebe004.NOE.Nokia.com> Thread-Topic: [Seamoby] Section 5.2 in CT Requirements Thread-Index: AcIub1vPwgX9yo0pTxeiQjRWnhxHBgAj5OsQ To: , Cc: X-OriginalArrivalTime: 19 Jul 2002 08:37:34.0732 (UTC) FILETIME=[87A8CCC0:01C22EFF] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id EAA22416 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 8bit Hi James, A suggestion. Could we ask from Allison to defer this discussion (i.e. - drop the requirement completely from the requirements). A much better way forward would be someone to produce a short document discussing different protocols that CT could use. The pros & cons of each. The list that has been discussed (if I remember correctly) are: 1) UDP 2) TCP 3) SCTP 4) PR-SCTP (formerly U-SCTP) 5) ICMP 6) DCCP (formerly DCP) - this one wasn't discussed, but is possible. Additionally, we have discussed a possible framework approach for CT solutions, so I am not sure if we need to specify a single transport protocol - if we go down a framework path. John _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Fri Jul 19 04:42:25 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03435 for ; Fri, 19 Jul 2002 04:42:25 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA22637 for seamoby-archive@odin.ietf.org; Fri, 19 Jul 2002 04:43:24 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA22447; Fri, 19 Jul 2002 04:37:38 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA22415 for ; Fri, 19 Jul 2002 04:37:36 -0400 (EDT) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03334 for ; Fri, 19 Jul 2002 04:36:36 -0400 (EDT) From: john.loughney@nokia.com Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g6J8c6i14446 for ; Fri, 19 Jul 2002 11:38:07 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 19 Jul 2002 11:37:35 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Fri, 19 Jul 2002 11:37:34 +0300 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Seamoby] Section 5.2 in CT Requirements X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Date: Fri, 19 Jul 2002 11:37:33 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC6579F@esebe004.NOE.Nokia.com> Thread-Topic: [Seamoby] Section 5.2 in CT Requirements Thread-Index: AcIub1vPwgX9yo0pTxeiQjRWnhxHBgAj5OsQ To: , Cc: X-OriginalArrivalTime: 19 Jul 2002 08:37:34.0732 (UTC) FILETIME=[87A8CCC0:01C22EFF] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id EAA22416 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 8bit Hi James, A suggestion. Could we ask from Allison to defer this discussion (i.e. - drop the requirement completely from the requirements). A much better way forward would be someone to produce a short document discussing different protocols that CT could use. The pros & cons of each. The list that has been discussed (if I remember correctly) are: 1) UDP 2) TCP 3) SCTP 4) PR-SCTP (formerly U-SCTP) 5) ICMP 6) DCCP (formerly DCP) - this one wasn't discussed, but is possible. Additionally, we have discussed a possible framework approach for CT solutions, so I am not sure if we need to specify a single transport protocol - if we go down a framework path. John _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Fri Jul 19 09:08:52 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07332 for ; Fri, 19 Jul 2002 09:08:52 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA04343; Fri, 19 Jul 2002 09:07:01 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA04314 for ; Fri, 19 Jul 2002 09:06:59 -0400 (EDT) Received: from fridge.docomolabs-usa.com (fwuser@key1.docomolabs-usa.com [216.98.102.225]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07287 for ; Fri, 19 Jul 2002 09:06:01 -0400 (EDT) Message-ID: <003501c22f24$eeac69c0$a86015ac@T23KEMPF> From: "James Kempf" To: "Pat R. Calhoun" , "Nakhjiri Madjid-MNAKHJI1" , Cc: References: <35DBB8B7AC89D4118E98009027B1009B08AD55C5@IL27EXM10.cig.mot.com> <200207181459.03702.pcalhoun@bstormnetworks.com> Subject: Re: [Seamoby] Section 5.2 in CT Requirements Date: Fri, 19 Jul 2002 06:03:52 -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-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit Pat, > I know that there was concern by the IESG on this very topic, and the idea of > the above text was a compromise with the area director, who was going to > initiate a discussion with the transport directorate. Unfortunately, this > never occured, and the text remained. Allison had suggested that we continue > with the non-transport discussions and that this topic will resurface again > in the future. > I don't think Allison intended that the document go to the IESG with this text in it, though I have not had an opportunity to speak with her about it. But ultimately she is not responsible for the working group documents, that is the working group's responsiblity. We should have pulled that text out before we sent it to the IESG, and, ideally, had something to replace it. If, at that point, the IESG had a technical disagreement with our proposed requirement, then we would have heard back. > The question is whether this can occur after the document can be published > (perhaps without the section). > I think we at least have to propose a requirement, which is what the text I sent was intended to do. jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Fri Jul 19 09:08:52 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07341 for ; Fri, 19 Jul 2002 09:08:52 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA04537 for seamoby-archive@odin.ietf.org; Fri, 19 Jul 2002 09:09:50 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA04343; Fri, 19 Jul 2002 09:07:01 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA04314 for ; Fri, 19 Jul 2002 09:06:59 -0400 (EDT) Received: from fridge.docomolabs-usa.com (fwuser@key1.docomolabs-usa.com [216.98.102.225]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07287 for ; Fri, 19 Jul 2002 09:06:01 -0400 (EDT) Message-ID: <003501c22f24$eeac69c0$a86015ac@T23KEMPF> From: "James Kempf" To: "Pat R. Calhoun" , "Nakhjiri Madjid-MNAKHJI1" , Cc: References: <35DBB8B7AC89D4118E98009027B1009B08AD55C5@IL27EXM10.cig.mot.com> <200207181459.03702.pcalhoun@bstormnetworks.com> Subject: Re: [Seamoby] Section 5.2 in CT Requirements Date: Fri, 19 Jul 2002 06:03:52 -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-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit Pat, > I know that there was concern by the IESG on this very topic, and the idea of > the above text was a compromise with the area director, who was going to > initiate a discussion with the transport directorate. Unfortunately, this > never occured, and the text remained. Allison had suggested that we continue > with the non-transport discussions and that this topic will resurface again > in the future. > I don't think Allison intended that the document go to the IESG with this text in it, though I have not had an opportunity to speak with her about it. But ultimately she is not responsible for the working group documents, that is the working group's responsiblity. We should have pulled that text out before we sent it to the IESG, and, ideally, had something to replace it. If, at that point, the IESG had a technical disagreement with our proposed requirement, then we would have heard back. > The question is whether this can occur after the document can be published > (perhaps without the section). > I think we at least have to propose a requirement, which is what the text I sent was intended to do. jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Fri Jul 19 09:08:54 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07358 for ; Fri, 19 Jul 2002 09:08:54 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA04477; Fri, 19 Jul 2002 09:07:24 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA04442 for ; Fri, 19 Jul 2002 09:07:21 -0400 (EDT) Received: from fridge.docomolabs-usa.com (fwuser@key1.docomolabs-usa.com [216.98.102.225]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07295 for ; Fri, 19 Jul 2002 09:06:22 -0400 (EDT) Message-ID: <003601c22f24$f0e7dad0$a86015ac@T23KEMPF> From: "James Kempf" To: "Gary Kenward" , "John Loughney" , References: <9FBD322B7824D511B36900508BF93C9C01AA4C1D@zcard031.ca.nortel.com> Subject: Re: [Seamoby] Proposal on Sync/NoSync Requirement Date: Fri, 19 Jul 2002 06:04:26 -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-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit Gary, > Proposed: > > 5.5 Context Update and Synchronization > > 5.5.1 The context transfer protocol MUST be capable of supporting the > updates to context information when it changes. > > 5.5.2 Context updates SHOULD complete before the context is needed at > the receiving AR. > > The context at the AR actually supporting an MN's traffic will > change with time. For example, the MN may initiate new microflow(s), > or discontinue existing microflows. Any change of context at the > supporting AR must be replicated at those ARs that have already > received context for that MN. > > However, context changes are often driven by events external to the > sending AR, and will thus be asynchronous to any on-going context > updates. Given that context transfers will take a finite amount of > time to complete, it is possible that a change in context cannot be > conveyed in time to the destination AR to avoid any impact on a possible > handover. The objective of the context transfer design must be to make > the likelihood of this delay, and its magnitude, as low as possible. > > > This is not perfect: the desire to avoid a requirement for an extreme degree > of synchronization is only implied by the soft "SHOULD" in 5.5.2. > I still don't think this is sufficiently crisp. In addition, after reviewing the email from the last couple weeks on this, I've seen good arguments why the CT protocol itself doesn't need to provide update after the context has left the router. We seem to be going through a bit of route flapping on this one. Let me slip into solution space for just a moment (we'll be out again quickly, never fear). The way I see the base CT protocol, it is the following things: 1) A container format in which feature context blobs get shipped. The container includes an identifier for the feature context, but not much more. 2) A procedure for standardizing blob formats. This will require IETF standards action, plus IANA specification of type identifier. So in order to use the CT protocol, a particular application would have to define the following in a standards track specification: 1) The detals of the blob layout and the IANA type code, 2) The transport for the CT container + blob, 3) The synchronization requirements (if any) with handover events. For some feature contexts, there may be no synchronization requirements. For others, there will be. Popping out of solution space (phew, that was a little tight!) , I see the following requirements supporting this situation: 5.5 Context Update and Synchronization 5.5.1 The base context transfer protocol SHOULD NOT provide direct support for synchronization with outside events, since synchronization is not a requirement for all or even most feature contexts. 5.5.2 The base context transfer protocol MUST allow individual feature context specifications to define their own synchronization with external events. 5.5.3 The base context transfer protocol SHOULD NOT provide support for updating context after it is transfered, since context transfer is an optimization, and updates would compromise the timeliness of the transfer. Changes in context at the source are discarded after transfer has been initiated. Most feature contexts will not require synchronization, however there are a few that may. Header compression, for example, may require that the header compressor on the old access router cease and the compressor on the new router start in synchrony with hand over of routing to the new router; otherwise, the compressor on the new router will not be properly synchronized. Since most contexts don't need synchronization support, the CT solution need not support it, but it should not provide a hinderance to those feature contexts that do. Any changes in the source router that would cause changes in the context are discarded after the context has been transferred. Comments? jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Fri Jul 19 09:08:55 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07363 for ; Fri, 19 Jul 2002 09:08:55 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA04548 for seamoby-archive@odin.ietf.org; Fri, 19 Jul 2002 09:09:52 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA04477; Fri, 19 Jul 2002 09:07:24 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA04442 for ; Fri, 19 Jul 2002 09:07:21 -0400 (EDT) Received: from fridge.docomolabs-usa.com (fwuser@key1.docomolabs-usa.com [216.98.102.225]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07295 for ; Fri, 19 Jul 2002 09:06:22 -0400 (EDT) Message-ID: <003601c22f24$f0e7dad0$a86015ac@T23KEMPF> From: "James Kempf" To: "Gary Kenward" , "John Loughney" , References: <9FBD322B7824D511B36900508BF93C9C01AA4C1D@zcard031.ca.nortel.com> Subject: Re: [Seamoby] Proposal on Sync/NoSync Requirement Date: Fri, 19 Jul 2002 06:04:26 -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-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit Gary, > Proposed: > > 5.5 Context Update and Synchronization > > 5.5.1 The context transfer protocol MUST be capable of supporting the > updates to context information when it changes. > > 5.5.2 Context updates SHOULD complete before the context is needed at > the receiving AR. > > The context at the AR actually supporting an MN's traffic will > change with time. For example, the MN may initiate new microflow(s), > or discontinue existing microflows. Any change of context at the > supporting AR must be replicated at those ARs that have already > received context for that MN. > > However, context changes are often driven by events external to the > sending AR, and will thus be asynchronous to any on-going context > updates. Given that context transfers will take a finite amount of > time to complete, it is possible that a change in context cannot be > conveyed in time to the destination AR to avoid any impact on a possible > handover. The objective of the context transfer design must be to make > the likelihood of this delay, and its magnitude, as low as possible. > > > This is not perfect: the desire to avoid a requirement for an extreme degree > of synchronization is only implied by the soft "SHOULD" in 5.5.2. > I still don't think this is sufficiently crisp. In addition, after reviewing the email from the last couple weeks on this, I've seen good arguments why the CT protocol itself doesn't need to provide update after the context has left the router. We seem to be going through a bit of route flapping on this one. Let me slip into solution space for just a moment (we'll be out again quickly, never fear). The way I see the base CT protocol, it is the following things: 1) A container format in which feature context blobs get shipped. The container includes an identifier for the feature context, but not much more. 2) A procedure for standardizing blob formats. This will require IETF standards action, plus IANA specification of type identifier. So in order to use the CT protocol, a particular application would have to define the following in a standards track specification: 1) The detals of the blob layout and the IANA type code, 2) The transport for the CT container + blob, 3) The synchronization requirements (if any) with handover events. For some feature contexts, there may be no synchronization requirements. For others, there will be. Popping out of solution space (phew, that was a little tight!) , I see the following requirements supporting this situation: 5.5 Context Update and Synchronization 5.5.1 The base context transfer protocol SHOULD NOT provide direct support for synchronization with outside events, since synchronization is not a requirement for all or even most feature contexts. 5.5.2 The base context transfer protocol MUST allow individual feature context specifications to define their own synchronization with external events. 5.5.3 The base context transfer protocol SHOULD NOT provide support for updating context after it is transfered, since context transfer is an optimization, and updates would compromise the timeliness of the transfer. Changes in context at the source are discarded after transfer has been initiated. Most feature contexts will not require synchronization, however there are a few that may. Header compression, for example, may require that the header compressor on the old access router cease and the compressor on the new router start in synchrony with hand over of routing to the new router; otherwise, the compressor on the new router will not be properly synchronized. Since most contexts don't need synchronization support, the CT solution need not support it, but it should not provide a hinderance to those feature contexts that do. Any changes in the source router that would cause changes in the context are discarded after the context has been transferred. Comments? jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Fri Jul 19 09:09:00 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07385 for ; Fri, 19 Jul 2002 09:09:00 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA04430; Fri, 19 Jul 2002 09:07:18 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA04360 for ; Fri, 19 Jul 2002 09:07:14 -0400 (EDT) Received: from fridge.docomolabs-usa.com (fwuser@key1.docomolabs-usa.com [216.98.102.225]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07291 for ; Fri, 19 Jul 2002 09:06:16 -0400 (EDT) Message-ID: <003901c22f24$f8132e90$a86015ac@T23KEMPF> From: "James Kempf" To: "Nakhjiri Madjid-MNAKHJI1" , References: <35DBB8B7AC89D4118E98009027B1009B08AD55B9@IL27EXM10.cig.mot.com> Subject: Re: [Seamoby] Proposal on Sync/NoSync Requirement Date: Fri, 19 Jul 2002 06:05:10 -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-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit Madjid, > Don't know if we can use NEED Not (certainly fits for the first SHOULD NOT, since > that one sounds like we are advising against it). We should (SHOULD? :-) use RFC language. > How would you allow particular features get synch service, if there is no inbuild > mechanisms in CT? Because the CT protocol would be just a container format that could be reused by many different feature specific protocols. For example, one could use the CT container to define an option for use along with handover signaling to transfer header compression context. Or, one could use SCTP to transfer security, QoS, and AAA context not requiring any synchronization with the handover signaling. The latter would require a separate protocol description for how the container format is used with the particular transport. For most protocols, the two are bundled, but they are conceptually separate and here I can see reasons for separating them. > > I think we can talk about synchronization when there are two copies at > two different places. I think the solutions should seriously avoid this, > as we did in our proposal. Care should be taken so that you don't have to > update a context at both oldAR and newAR. I think as you said for header compression > context, you should have the context updated only at one location and when > it is only at one location, how can we call it synchronization? > Because it is synchronized with an external event, namely handover. With context that is not sync sensitive there is no requirement for synchronization with handover because the change in routing doesn't invalidate the context on the old router. Conversely, if the non-sync sensitive context is sent a bit early, there will similarly not be a problem. This is not to state that the non-sync sensitive context isn't dynamic, just that the event of handover doesn't invalidate it per se. > > You would on the other hand get problem with dynamic context, if > some context that you sent over, gets lost or corrupted. Once this happen > then, you can see whether the context has changed (in which case you need a refresh) > or not (you only need a retx). > Dynamic context means that it is changing as the mobile's traffic goes through the router, right? So I view that as requiring synchronization with an external event, namely handover. Something like accounting information would qualify, as well as header compression state. On the other hand, a user's SLA would not, because handover wouldn't invalidate it. jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Fri Jul 19 09:09:01 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07390 for ; Fri, 19 Jul 2002 09:09:00 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA04562 for seamoby-archive@odin.ietf.org; Fri, 19 Jul 2002 09:09:58 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA04430; Fri, 19 Jul 2002 09:07:18 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA04360 for ; Fri, 19 Jul 2002 09:07:14 -0400 (EDT) Received: from fridge.docomolabs-usa.com (fwuser@key1.docomolabs-usa.com [216.98.102.225]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07291 for ; Fri, 19 Jul 2002 09:06:16 -0400 (EDT) Message-ID: <003901c22f24$f8132e90$a86015ac@T23KEMPF> From: "James Kempf" To: "Nakhjiri Madjid-MNAKHJI1" , References: <35DBB8B7AC89D4118E98009027B1009B08AD55B9@IL27EXM10.cig.mot.com> Subject: Re: [Seamoby] Proposal on Sync/NoSync Requirement Date: Fri, 19 Jul 2002 06:05:10 -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-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit Madjid, > Don't know if we can use NEED Not (certainly fits for the first SHOULD NOT, since > that one sounds like we are advising against it). We should (SHOULD? :-) use RFC language. > How would you allow particular features get synch service, if there is no inbuild > mechanisms in CT? Because the CT protocol would be just a container format that could be reused by many different feature specific protocols. For example, one could use the CT container to define an option for use along with handover signaling to transfer header compression context. Or, one could use SCTP to transfer security, QoS, and AAA context not requiring any synchronization with the handover signaling. The latter would require a separate protocol description for how the container format is used with the particular transport. For most protocols, the two are bundled, but they are conceptually separate and here I can see reasons for separating them. > > I think we can talk about synchronization when there are two copies at > two different places. I think the solutions should seriously avoid this, > as we did in our proposal. Care should be taken so that you don't have to > update a context at both oldAR and newAR. I think as you said for header compression > context, you should have the context updated only at one location and when > it is only at one location, how can we call it synchronization? > Because it is synchronized with an external event, namely handover. With context that is not sync sensitive there is no requirement for synchronization with handover because the change in routing doesn't invalidate the context on the old router. Conversely, if the non-sync sensitive context is sent a bit early, there will similarly not be a problem. This is not to state that the non-sync sensitive context isn't dynamic, just that the event of handover doesn't invalidate it per se. > > You would on the other hand get problem with dynamic context, if > some context that you sent over, gets lost or corrupted. Once this happen > then, you can see whether the context has changed (in which case you need a refresh) > or not (you only need a retx). > Dynamic context means that it is changing as the mobile's traffic goes through the router, right? So I view that as requiring synchronization with an external event, namely handover. Something like accounting information would qualify, as well as header compression state. On the other hand, a user's SLA would not, because handover wouldn't invalidate it. jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Fri Jul 19 10:04:30 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08795 for ; Fri, 19 Jul 2002 10:04:30 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA09556; Fri, 19 Jul 2002 10:01:55 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA09525 for ; Fri, 19 Jul 2002 10:01:53 -0400 (EDT) Received: from zcars04e.ca.nortel.com (zcars04e.nortelnetworks.com [47.129.242.56]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08604 for ; Fri, 19 Jul 2002 10:00:54 -0400 (EDT) Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g6JE0tg10044; Fri, 19 Jul 2002 10:00:55 -0400 (EDT) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 19 Jul 2002 10:00:54 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA4C3F@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'James Kempf'" , "'seamoby@ietf.org'" Cc: "'mankin@psg.com'" Subject: RE: [Seamoby] Section 5.2 in CT Requirements Date: Fri, 19 Jul 2002 10:00:46 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C22F2B.68499B4E" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C22F2B.68499B4E Content-Type: text/plain; charset="iso-8859-1" The question is whether there is wg consensus. Which was not reached at time of writing section 5. I'm not defending the situation, simply informing you. Perhaps this time it will not be an issue. The *technical* problem with your requirement - and I am only trying to recapture what others objected to - was that there was a significant number of people who wanted to define a transport solution for CT, based upon CTs unique needs. Some wanted transport capabilities built into CT. The melt down came when the wg started debating these needs, as the CT solution was not (and is not) defined, the transport needs are pure speculation, or based upon individual approaches. Thus, the decision to defer the CT transport evaluation until a CT solution - and the transport needs - where better known. BTW: the format you have used is not the standard format decided upon by the working group, which was to use section headers as the requirements (I believe this was Pat's suggestion). One requirement per section. We can, of course, change the style, but all of the requirements would have to be re-written. Gary > -----Original Message----- > From: James Kempf [mailto:kempf@docomolabs-usa.com] > Sent: July 18, 2002 18:59 > To: Kenward, Gary [WDLN2:AN10:EXCH]; seamoby@ietf.org > Cc: mankin@psg.com > Subject: Re: [Seamoby] Section 5.2 in CT Requirements > > > Gary, > > It isn't a question of debate. We've been talking about these > requirements for a > year and a half, it is time to complete them. > We need to nail down this section. > > Do you have any specific technical comments on the requirement? > > jak > > ----- Original Message ----- > From: "Gary Kenward" > To: "'James Kempf'" ; > Cc: > Sent: Thursday, July 18, 2002 8:16 AM > Subject: RE: [Seamoby] Section 5.2 in CT Requirements > > > > James: > > > > There was a long and arduous debate over transport reliability. > > The wording you are objecting to was, I believe, Allison's > suggestion. > > At the very lease, it was inserted with her approval in > order to move > > the requirements forward. > > > > Of course, you can open the debate again, but I don't expect it to > > be resolved any better then it was the last time through. > The problem > > is that there seems to be some very different ideas in the wg as to > > what the CT protocol looks like, with contradicting assumptions as > > to what is needed from a transport layer. > > > > Gary > > > > > -----Original Message----- > > > From: James Kempf [mailto:kempf@docomolabs-usa.com] > > > Sent: July 18, 2002 07:14 > > > To: seamoby@ietf.org > > > Cc: mankin@psg.com > > > Subject: [Seamoby] Section 5.2 in CT Requirements > > > > > > > > > Folks, > > > > > > So recently I had another look at the CT Requirements > > > document and I was > > > suprised to find Section 5.2. It says this: > > > > > > 5.2 Transport Reliability > > > > > > This section is intentionally left blank as the > > > working group is > > > waiting for a questionnaire from the transport > > > directorate. The result > > > of the questionnaire will create requirements that > > > will be added in this > > > section in a later revision of this specification. > > > > > > It is completely unacceptable that we sent this document to > > > the IESG with this > > > section in it. When a document passes through last call, it > > > should be complete. > > > As WG chairs, Pat and I naturally must accept responsibility > > > for this, but this > > > should really have been caught in WG Last Call. > > > > > > I would like suggest replacing Section 5.2 with the following: > > > > > > 5.2 Transport Requirements > > > > > > This section contains requirements on the context > > > transfer transport. > > > > > > 5.1 Independence of Underlying Transport > > > > > > The context transfer solution MUST be independent of > > > the underlying > > > transport. It SHOULD be possible to transfer > > > context directly on top of reliable transports, such > > > as TCP or SCTP, > > > unreliable transports, such as UDP, or as an > > > option or extention on another protocol, such as > > > handover signaling. > > > > > > Comments? > > > > > > > > > jak > > > u > > > > > > > > > > > > _______________________________________________ > > > Seamoby mailing list > > > Seamoby@ietf.org > > > https://www1.ietf.org/mailman/listinfo/seamoby > > > > > > > ------_=_NextPart_001_01C22F2B.68499B4E Content-Type: text/html; charset="iso-8859-1" RE: [Seamoby] Section 5.2 in CT Requirements

The question is whether there is wg consensus. Which was not
reached at time of writing section 5. I'm not defending
the situation, simply informing you. Perhaps this time it will
not be an issue.

The *technical* problem with your requirement - and I am only
trying to recapture what others objected to - was that there
was a significant number of people who wanted to define a
transport solution for CT, based upon CTs unique needs. Some
wanted transport capabilities built into CT. The melt down came
when the wg started debating these needs, as the CT solution was
not (and is not) defined, the transport needs are pure speculation,
or based upon individual approaches. Thus, the decision to defer the
CT transport evaluation until a CT solution - and the transport needs
- where better known.


BTW: the format you have used is not the standard format
     decided upon by the working group, which was to use
     section headers as the requirements (I believe this
     was Pat's suggestion). One requirement per section.

     We can, of course, change  the style, but all of
     the requirements would have to be re-written.

Gary

> -----Original Message-----
> From: James Kempf [mailto:kempf@docomolabs-usa.com]
> Sent: July 18, 2002 18:59
> To: Kenward, Gary [WDLN2:AN10:EXCH]; seamoby@ietf.org
> Cc: mankin@psg.com
> Subject: Re: [Seamoby] Section 5.2 in CT Requirements
>
>
> Gary,
>
> It isn't a question of debate. We've been talking about these
> requirements for a
> year and a half, it is time to complete them.
> We need to nail down this section.
>
> Do you have any specific technical comments on the requirement?
>
>             jak
>
> ----- Original Message -----
> From: "Gary Kenward" <gkenward@nortelnetworks.com>
> To: "'James Kempf'" <kempf@docomolabs-usa.com>; <seamoby@ietf.org>
> Cc: <mankin@psg.com>
> Sent: Thursday, July 18, 2002 8:16 AM
> Subject: RE: [Seamoby] Section 5.2 in CT Requirements
>
>
> > James:
> >
> >  There was a long and arduous debate over transport reliability.
> > The wording you are objecting to was, I believe, Allison's
> suggestion.
> > At the very lease, it was inserted with her approval in
> order to move
> > the requirements forward.
> >
> >  Of course, you can open the debate again, but I don't expect it to
> > be resolved any better then it was the last time through.
> The problem
> > is that there seems to be some very different ideas in the wg as to
> > what the CT protocol looks like, with contradicting assumptions as
> > to what is needed from a transport layer.
> >
> > Gary
> >
> > > -----Original Message-----
> > > From: James Kempf [mailto:kempf@docomolabs-usa.com]
> > > Sent: July 18, 2002 07:14
> > > To: seamoby@ietf.org
> > > Cc: mankin@psg.com
> > > Subject: [Seamoby] Section 5.2 in CT Requirements
> > >
> > >
> > > Folks,
> > >
> > > So recently I had another look at the CT Requirements
> > > document and I was
> > > suprised to find Section 5.2. It says this:
> > >
> > >     5.2 Transport Reliability
> > >
> > >        This section is intentionally left blank as the
> > > working group is
> > >        waiting for a questionnaire from the transport
> > > directorate. The result
> > >        of the questionnaire will create requirements that
> > > will be added in this
> > >        section in a later revision of this specification.
> > >
> > > It is completely unacceptable that we sent this document to
> > > the IESG with this
> > > section in it. When a document passes through last call, it
> > > should be complete.
> > > As WG chairs, Pat and I naturally must accept responsibility
> > > for this, but this
> > > should really have been caught in WG Last Call.
> > >
> > > I would like suggest replacing Section 5.2 with the following:
> > >
> > >     5.2 Transport Requirements
> > >
> > >         This section contains requirements on the context
> > > transfer transport.
> > >
> > >     5.1 Independence of Underlying Transport
> > >
> > >         The context transfer solution MUST be independent of
> > > the underlying
> > > transport. It SHOULD be possible to transfer
> > >         context directly on top of reliable transports, such
> > > as TCP or SCTP,
> > > unreliable transports, such as UDP, or as an
> > >         option or extention on another protocol, such as
> > > handover signaling.
> > >
> > > Comments?
> > >
> > >
> > >             jak
> > >    u
> > >
> > >
> > >
> > > _______________________________________________
> > > Seamoby mailing list
> > > Seamoby@ietf.org
> > > https://www1.ietf.org/mailman/listinfo/seamoby
> > >
> >
>
>

------_=_NextPart_001_01C22F2B.68499B4E-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Fri Jul 19 10:04:30 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08804 for ; Fri, 19 Jul 2002 10:04:30 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA10086 for seamoby-archive@odin.ietf.org; Fri, 19 Jul 2002 10:05:28 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA09556; Fri, 19 Jul 2002 10:01:55 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA09525 for ; Fri, 19 Jul 2002 10:01:53 -0400 (EDT) Received: from zcars04e.ca.nortel.com (zcars04e.nortelnetworks.com [47.129.242.56]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08604 for ; Fri, 19 Jul 2002 10:00:54 -0400 (EDT) Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g6JE0tg10044; Fri, 19 Jul 2002 10:00:55 -0400 (EDT) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 19 Jul 2002 10:00:54 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA4C3F@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'James Kempf'" , "'seamoby@ietf.org'" Cc: "'mankin@psg.com'" Subject: RE: [Seamoby] Section 5.2 in CT Requirements Date: Fri, 19 Jul 2002 10:00:46 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C22F2B.68499B4E" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C22F2B.68499B4E Content-Type: text/plain; charset="iso-8859-1" The question is whether there is wg consensus. Which was not reached at time of writing section 5. I'm not defending the situation, simply informing you. Perhaps this time it will not be an issue. The *technical* problem with your requirement - and I am only trying to recapture what others objected to - was that there was a significant number of people who wanted to define a transport solution for CT, based upon CTs unique needs. Some wanted transport capabilities built into CT. The melt down came when the wg started debating these needs, as the CT solution was not (and is not) defined, the transport needs are pure speculation, or based upon individual approaches. Thus, the decision to defer the CT transport evaluation until a CT solution - and the transport needs - where better known. BTW: the format you have used is not the standard format decided upon by the working group, which was to use section headers as the requirements (I believe this was Pat's suggestion). One requirement per section. We can, of course, change the style, but all of the requirements would have to be re-written. Gary > -----Original Message----- > From: James Kempf [mailto:kempf@docomolabs-usa.com] > Sent: July 18, 2002 18:59 > To: Kenward, Gary [WDLN2:AN10:EXCH]; seamoby@ietf.org > Cc: mankin@psg.com > Subject: Re: [Seamoby] Section 5.2 in CT Requirements > > > Gary, > > It isn't a question of debate. We've been talking about these > requirements for a > year and a half, it is time to complete them. > We need to nail down this section. > > Do you have any specific technical comments on the requirement? > > jak > > ----- Original Message ----- > From: "Gary Kenward" > To: "'James Kempf'" ; > Cc: > Sent: Thursday, July 18, 2002 8:16 AM > Subject: RE: [Seamoby] Section 5.2 in CT Requirements > > > > James: > > > > There was a long and arduous debate over transport reliability. > > The wording you are objecting to was, I believe, Allison's > suggestion. > > At the very lease, it was inserted with her approval in > order to move > > the requirements forward. > > > > Of course, you can open the debate again, but I don't expect it to > > be resolved any better then it was the last time through. > The problem > > is that there seems to be some very different ideas in the wg as to > > what the CT protocol looks like, with contradicting assumptions as > > to what is needed from a transport layer. > > > > Gary > > > > > -----Original Message----- > > > From: James Kempf [mailto:kempf@docomolabs-usa.com] > > > Sent: July 18, 2002 07:14 > > > To: seamoby@ietf.org > > > Cc: mankin@psg.com > > > Subject: [Seamoby] Section 5.2 in CT Requirements > > > > > > > > > Folks, > > > > > > So recently I had another look at the CT Requirements > > > document and I was > > > suprised to find Section 5.2. It says this: > > > > > > 5.2 Transport Reliability > > > > > > This section is intentionally left blank as the > > > working group is > > > waiting for a questionnaire from the transport > > > directorate. The result > > > of the questionnaire will create requirements that > > > will be added in this > > > section in a later revision of this specification. > > > > > > It is completely unacceptable that we sent this document to > > > the IESG with this > > > section in it. When a document passes through last call, it > > > should be complete. > > > As WG chairs, Pat and I naturally must accept responsibility > > > for this, but this > > > should really have been caught in WG Last Call. > > > > > > I would like suggest replacing Section 5.2 with the following: > > > > > > 5.2 Transport Requirements > > > > > > This section contains requirements on the context > > > transfer transport. > > > > > > 5.1 Independence of Underlying Transport > > > > > > The context transfer solution MUST be independent of > > > the underlying > > > transport. It SHOULD be possible to transfer > > > context directly on top of reliable transports, such > > > as TCP or SCTP, > > > unreliable transports, such as UDP, or as an > > > option or extention on another protocol, such as > > > handover signaling. > > > > > > Comments? > > > > > > > > > jak > > > u > > > > > > > > > > > > _______________________________________________ > > > Seamoby mailing list > > > Seamoby@ietf.org > > > https://www1.ietf.org/mailman/listinfo/seamoby > > > > > > > ------_=_NextPart_001_01C22F2B.68499B4E Content-Type: text/html; charset="iso-8859-1" RE: [Seamoby] Section 5.2 in CT Requirements

The question is whether there is wg consensus. Which was not
reached at time of writing section 5. I'm not defending
the situation, simply informing you. Perhaps this time it will
not be an issue.

The *technical* problem with your requirement - and I am only
trying to recapture what others objected to - was that there
was a significant number of people who wanted to define a
transport solution for CT, based upon CTs unique needs. Some
wanted transport capabilities built into CT. The melt down came
when the wg started debating these needs, as the CT solution was
not (and is not) defined, the transport needs are pure speculation,
or based upon individual approaches. Thus, the decision to defer the
CT transport evaluation until a CT solution - and the transport needs
- where better known.


BTW: the format you have used is not the standard format
     decided upon by the working group, which was to use
     section headers as the requirements (I believe this
     was Pat's suggestion). One requirement per section.

     We can, of course, change  the style, but all of
     the requirements would have to be re-written.

Gary

> -----Original Message-----
> From: James Kempf [mailto:kempf@docomolabs-usa.com]
> Sent: July 18, 2002 18:59
> To: Kenward, Gary [WDLN2:AN10:EXCH]; seamoby@ietf.org
> Cc: mankin@psg.com
> Subject: Re: [Seamoby] Section 5.2 in CT Requirements
>
>
> Gary,
>
> It isn't a question of debate. We've been talking about these
> requirements for a
> year and a half, it is time to complete them.
> We need to nail down this section.
>
> Do you have any specific technical comments on the requirement?
>
>             jak
>
> ----- Original Message -----
> From: "Gary Kenward" <gkenward@nortelnetworks.com>
> To: "'James Kempf'" <kempf@docomolabs-usa.com>; <seamoby@ietf.org>
> Cc: <mankin@psg.com>
> Sent: Thursday, July 18, 2002 8:16 AM
> Subject: RE: [Seamoby] Section 5.2 in CT Requirements
>
>
> > James:
> >
> >  There was a long and arduous debate over transport reliability.
> > The wording you are objecting to was, I believe, Allison's
> suggestion.
> > At the very lease, it was inserted with her approval in
> order to move
> > the requirements forward.
> >
> >  Of course, you can open the debate again, but I don't expect it to
> > be resolved any better then it was the last time through.
> The problem
> > is that there seems to be some very different ideas in the wg as to
> > what the CT protocol looks like, with contradicting assumptions as
> > to what is needed from a transport layer.
> >
> > Gary
> >
> > > -----Original Message-----
> > > From: James Kempf [mailto:kempf@docomolabs-usa.com]
> > > Sent: July 18, 2002 07:14
> > > To: seamoby@ietf.org
> > > Cc: mankin@psg.com
> > > Subject: [Seamoby] Section 5.2 in CT Requirements
> > >
> > >
> > > Folks,
> > >
> > > So recently I had another look at the CT Requirements
> > > document and I was
> > > suprised to find Section 5.2. It says this:
> > >
> > >     5.2 Transport Reliability
> > >
> > >        This section is intentionally left blank as the
> > > working group is
> > >        waiting for a questionnaire from the transport
> > > directorate. The result
> > >        of the questionnaire will create requirements that
> > > will be added in this
> > >        section in a later revision of this specification.
> > >
> > > It is completely unacceptable that we sent this document to
> > > the IESG with this
> > > section in it. When a document passes through last call, it
> > > should be complete.
> > > As WG chairs, Pat and I naturally must accept responsibility
> > > for this, but this
> > > should really have been caught in WG Last Call.
> > >
> > > I would like suggest replacing Section 5.2 with the following:
> > >
> > >     5.2 Transport Requirements
> > >
> > >         This section contains requirements on the context
> > > transfer transport.
> > >
> > >     5.1 Independence of Underlying Transport
> > >
> > >         The context transfer solution MUST be independent of
> > > the underlying
> > > transport. It SHOULD be possible to transfer
> > >         context directly on top of reliable transports, such
> > > as TCP or SCTP,
> > > unreliable transports, such as UDP, or as an
> > >         option or extention on another protocol, such as
> > > handover signaling.
> > >
> > > Comments?
> > >
> > >
> > >             jak
> > >    u
> > >
> > >
> > >
> > > _______________________________________________
> > > Seamoby mailing list
> > > Seamoby@ietf.org
> > > https://www1.ietf.org/mailman/listinfo/seamoby
> > >
> >
>
>

------_=_NextPart_001_01C22F2B.68499B4E-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Fri Jul 19 10:12:16 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09081 for ; Fri, 19 Jul 2002 10:12:15 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA10701; Fri, 19 Jul 2002 10:09:24 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA10632 for ; Fri, 19 Jul 2002 10:09:20 -0400 (EDT) Received: from zcars04f.ca.nortel.com (zcars04f.nortelnetworks.com [47.129.242.57]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08948 for ; Fri, 19 Jul 2002 10:08:21 -0400 (EDT) Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04f.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g6JE8dU03819; Fri, 19 Jul 2002 10:08:39 -0400 (EDT) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 19 Jul 2002 10:08:39 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA4C40@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'James Kempf'" , John Loughney , seamoby@ietf.org Subject: RE: [Seamoby] Proposal on Sync/NoSync Requirement Date: Fri, 19 Jul 2002 10:08:38 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C22F2C.C38A5BAA" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C22F2C.C38A5BAA Content-Type: text/plain; charset="iso-8859-1" James: You have completely ignored "proactive CT", which for me, and I believe others, is the primary value of CT. If you deliver the context to a receiving AR in the believe that it is a potential candidate for handover, and the context at the sending AR changes then an update seems like a necessary thing to do. At the very least, the context of newly created flows, or flows being destroyed, should be conveyed. This could be part of the flow set up semantics, but it seems wrong to insert CT into flow setup. The analogy for proactive CT here is soft handover: seamlessness at the IP layer is analogous to soft handover at the link layer. Finally, while I still would like to see CT progress, reducing the value of CT by simplifying the requirements simply to get IESG approval, does not seem to me to be an appropriate approach. Proactive CT (now referred to as "CT before handover", *sigh*), is 90% of CTs value, to me, and I hope others concur. Gary > -----Original Message----- > From: James Kempf [mailto:kempf@docomolabs-usa.com] > Sent: July 19, 2002 09:04 > To: Kenward, Gary [WDLN2:AN10:EXCH]; John Loughney; seamoby@ietf.org > Subject: Re: [Seamoby] Proposal on Sync/NoSync Requirement > > > Gary, > > > Proposed: > > > > 5.5 Context Update and Synchronization > > > > 5.5.1 The context transfer protocol MUST be capable of > supporting the > > updates to context information when it changes. > > > > 5.5.2 Context updates SHOULD complete before the context is > needed at > > the receiving AR. > > > > The context at the AR actually supporting an MN's traffic will > > change with time. For example, the MN may initiate new > microflow(s), > > or discontinue existing microflows. Any change of context at the > > supporting AR must be replicated at those ARs that have already > > received context for that MN. > > > > However, context changes are often driven by events > external to the > > sending AR, and will thus be asynchronous to any on-going context > > updates. Given that context transfers will take a finite > amount of > > time to complete, it is possible that a change in > context cannot be > > conveyed in time to the destination AR to avoid any > impact on a possible > > handover. The objective of the context transfer design > must be to make > > the likelihood of this delay, and its magnitude, as low > as possible. > > > > > > This is not perfect: the desire to avoid a requirement for > an extreme degree > > of synchronization is only implied by the soft "SHOULD" in 5.5.2. > > > > I still don't think this is sufficiently crisp. In addition, > after reviewing the > email from the last couple weeks on this, I've seen good > arguments why the CT protocol itself doesn't need to provide > update after > the context has left the router. > > We seem to be going through a bit of route flapping on this > one. Let me slip > into solution space for just a moment (we'll be out again > quickly, never fear). > The way I see the base CT protocol, it is the following things: > > 1) A container format in which feature context blobs > get shipped. The > container includes an identifier for the feature context, but > not much more. > > 2) A procedure for standardizing blob formats. This will > require IETF > standards action, plus IANA specification of type identifier. > > So in order to use the CT protocol, a particular application > would have to > define the following in a standards track specification: > > 1) The detals of the blob layout and the IANA type code, > > 2) The transport for the CT container + blob, > > 3) The synchronization requirements (if any) with > handover events. > > For some feature contexts, there may be no synchronization > requirements. For > others, there will be. > > Popping out of solution space (phew, that was a little > tight!) , I see the > following requirements supporting this situation: > > 5.5 Context Update and Synchronization > > 5.5.1 The base context transfer protocol SHOULD NOT provide > direct support for > synchronization with outside events, since synchronization is > not a requirement > for all > or even most feature contexts. > > 5.5.2 The base context transfer protocol MUST allow > individual feature context > specifications to define their own synchronization with > external events. > > 5.5.3 The base context transfer protocol SHOULD NOT provide > support for updating > context after it is transfered, since context transfer is an > optimization, and > updates would > compromise the timeliness of the transfer. Changes in context > at the source are > discarded > after transfer has been initiated. > > Most feature contexts will not require > synchronization, however there > are a few that may. Header compression, for example, > may require that > the header compressor on the old access router cease > and the compressor > on the new router start in synchrony with hand over > of routing to the > new router; otherwise, the compressor on the new > router will not be > properly synchronized. Since most contexts don't need > synchronization > support, > the CT solution need not support it, but it should > not provide a > hinderance to those feature contexts that do. Any > changes in the source > router > that would cause changes in the context are discarded > after the context > has > been transferred. > > Comments? > > jak > > > > > > > ------_=_NextPart_001_01C22F2C.C38A5BAA Content-Type: text/html; charset="iso-8859-1" RE: [Seamoby] Proposal on Sync/NoSync Requirement

James:

 You have completely ignored "proactive CT", which for me, and I
believe others, is the primary value of CT. If you deliver the context
to a receiving AR in the believe that it is a potential candidate for handover,
and the context at the sending AR changes then an update seems like a necessary
thing to do. At the very least, the context of newly created flows, or flows
being destroyed, should be conveyed. This could be part of the flow set up
semantics, but it seems wrong to insert CT into flow setup.

 The analogy for proactive CT here is soft handover: seamlessness at the IP
layer is analogous to soft handover at the link layer.

 Finally, while I still would like to see CT progress, reducing the value of
CT by simplifying the requirements simply to get IESG approval, does not seem
to me to be an appropriate approach. Proactive CT (now referred to as "CT before
handover", *sigh*), is 90% of CTs value, to me, and I hope others concur.

Gary

> -----Original Message-----
> From: James Kempf [mailto:kempf@docomolabs-usa.com]
> Sent: July 19, 2002 09:04
> To: Kenward, Gary [WDLN2:AN10:EXCH]; John Loughney; seamoby@ietf.org
> Subject: Re: [Seamoby] Proposal on Sync/NoSync Requirement
>
>
> Gary,
>
> > Proposed:
> >
> > 5.5 Context Update and Synchronization
> >
> > 5.5.1 The context transfer protocol MUST be capable of
> supporting the
> >       updates to context information when it changes.
> >
> > 5.5.2 Context updates SHOULD complete before the context is
> needed at
> >       the receiving AR.
> >
> >    The context at the AR actually supporting an MN's traffic will
> >    change with time. For example, the MN may initiate new
> microflow(s),
> >    or discontinue existing microflows. Any change of context at the
> >    supporting AR must be replicated at those ARs that have already
> >    received context for that MN.
> >
> >    However, context changes are often driven by events
> external to the
> >    sending AR, and will thus be asynchronous to any on-going context
> >    updates. Given that context transfers will take a finite
> amount of
> >    time to complete, it is possible that a change in
> context cannot be
> >    conveyed in time to the destination AR to avoid any
> impact on a possible
> >    handover. The objective of the context transfer design
> must be to make
> >    the likelihood of this delay, and its magnitude, as low
> as possible.
> >
> >
> > This is not perfect: the desire to avoid a requirement for
> an extreme degree
> > of synchronization is only implied by the soft "SHOULD" in 5.5.2.
> >
>
> I still don't think this is sufficiently crisp. In addition,
> after reviewing the
> email from the last couple weeks on this, I've seen good
> arguments why the CT protocol itself doesn't need to provide
> update after
> the context has left the router.
>
> We seem to be going through a bit of route flapping on this
> one. Let me slip
> into solution space for just a moment (we'll be out again
> quickly, never fear).
> The way I see the base CT protocol, it is the following things:
>
>         1) A container format in which feature context blobs
> get shipped. The
> container includes an identifier for the feature context, but
> not much more.
>
>     2) A procedure for standardizing blob formats. This will
> require IETF
> standards action, plus IANA specification of type identifier.
>
> So in order to use the CT protocol, a particular application
> would have to
> define the following in a standards track specification:
>
>     1) The detals of the blob layout and the IANA type code,
>
>      2)  The transport for the CT container + blob,
>
>      3) The synchronization requirements (if any) with
> handover events.
>
> For some feature contexts, there may be no synchronization
> requirements. For
> others, there will be.
>
> Popping out of solution space (phew, that was a little
> tight!) , I see the
> following requirements supporting this situation:
>
> 5.5 Context Update and Synchronization
>
> 5.5.1 The base context transfer protocol SHOULD NOT provide
> direct support for
> synchronization with outside events, since synchronization is
> not a requirement
> for all
> or even most feature contexts.
>
> 5.5.2 The base context transfer protocol MUST allow
> individual feature context
> specifications to define their own synchronization with
> external events.
>
> 5.5.3 The base context transfer protocol SHOULD NOT provide
> support for updating
> context after it is transfered, since context transfer is an
> optimization, and
> updates would
> compromise the timeliness of the transfer. Changes in context
> at the source are
> discarded
> after transfer has been initiated.
>
>         Most feature contexts will not require
> synchronization, however there
>         are a few that may. Header compression, for example,
> may require that
>         the header compressor on the old access router cease
> and the compressor
>         on the new router start in synchrony with hand over
> of routing to the
>         new router; otherwise, the compressor on the new
> router will not be
>        properly synchronized. Since most contexts don't need
> synchronization
> support,
>         the CT solution need not support it, but it should
> not provide a
>         hinderance to those feature contexts that do. Any
> changes in the source
> router
>         that would cause changes in the context are discarded
> after the context
> has
>         been transferred.
>
> Comments?
>
>                 jak
>
>
>
>
>
>
>

------_=_NextPart_001_01C22F2C.C38A5BAA-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Fri Jul 19 10:12:16 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09088 for ; Fri, 19 Jul 2002 10:12:16 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA11096 for seamoby-archive@odin.ietf.org; Fri, 19 Jul 2002 10:13:14 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA10701; Fri, 19 Jul 2002 10:09:24 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA10632 for ; Fri, 19 Jul 2002 10:09:20 -0400 (EDT) Received: from zcars04f.ca.nortel.com (zcars04f.nortelnetworks.com [47.129.242.57]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08948 for ; Fri, 19 Jul 2002 10:08:21 -0400 (EDT) Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04f.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g6JE8dU03819; Fri, 19 Jul 2002 10:08:39 -0400 (EDT) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 19 Jul 2002 10:08:39 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA4C40@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'James Kempf'" , John Loughney , seamoby@ietf.org Subject: RE: [Seamoby] Proposal on Sync/NoSync Requirement Date: Fri, 19 Jul 2002 10:08:38 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C22F2C.C38A5BAA" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C22F2C.C38A5BAA Content-Type: text/plain; charset="iso-8859-1" James: You have completely ignored "proactive CT", which for me, and I believe others, is the primary value of CT. If you deliver the context to a receiving AR in the believe that it is a potential candidate for handover, and the context at the sending AR changes then an update seems like a necessary thing to do. At the very least, the context of newly created flows, or flows being destroyed, should be conveyed. This could be part of the flow set up semantics, but it seems wrong to insert CT into flow setup. The analogy for proactive CT here is soft handover: seamlessness at the IP layer is analogous to soft handover at the link layer. Finally, while I still would like to see CT progress, reducing the value of CT by simplifying the requirements simply to get IESG approval, does not seem to me to be an appropriate approach. Proactive CT (now referred to as "CT before handover", *sigh*), is 90% of CTs value, to me, and I hope others concur. Gary > -----Original Message----- > From: James Kempf [mailto:kempf@docomolabs-usa.com] > Sent: July 19, 2002 09:04 > To: Kenward, Gary [WDLN2:AN10:EXCH]; John Loughney; seamoby@ietf.org > Subject: Re: [Seamoby] Proposal on Sync/NoSync Requirement > > > Gary, > > > Proposed: > > > > 5.5 Context Update and Synchronization > > > > 5.5.1 The context transfer protocol MUST be capable of > supporting the > > updates to context information when it changes. > > > > 5.5.2 Context updates SHOULD complete before the context is > needed at > > the receiving AR. > > > > The context at the AR actually supporting an MN's traffic will > > change with time. For example, the MN may initiate new > microflow(s), > > or discontinue existing microflows. Any change of context at the > > supporting AR must be replicated at those ARs that have already > > received context for that MN. > > > > However, context changes are often driven by events > external to the > > sending AR, and will thus be asynchronous to any on-going context > > updates. Given that context transfers will take a finite > amount of > > time to complete, it is possible that a change in > context cannot be > > conveyed in time to the destination AR to avoid any > impact on a possible > > handover. The objective of the context transfer design > must be to make > > the likelihood of this delay, and its magnitude, as low > as possible. > > > > > > This is not perfect: the desire to avoid a requirement for > an extreme degree > > of synchronization is only implied by the soft "SHOULD" in 5.5.2. > > > > I still don't think this is sufficiently crisp. In addition, > after reviewing the > email from the last couple weeks on this, I've seen good > arguments why the CT protocol itself doesn't need to provide > update after > the context has left the router. > > We seem to be going through a bit of route flapping on this > one. Let me slip > into solution space for just a moment (we'll be out again > quickly, never fear). > The way I see the base CT protocol, it is the following things: > > 1) A container format in which feature context blobs > get shipped. The > container includes an identifier for the feature context, but > not much more. > > 2) A procedure for standardizing blob formats. This will > require IETF > standards action, plus IANA specification of type identifier. > > So in order to use the CT protocol, a particular application > would have to > define the following in a standards track specification: > > 1) The detals of the blob layout and the IANA type code, > > 2) The transport for the CT container + blob, > > 3) The synchronization requirements (if any) with > handover events. > > For some feature contexts, there may be no synchronization > requirements. For > others, there will be. > > Popping out of solution space (phew, that was a little > tight!) , I see the > following requirements supporting this situation: > > 5.5 Context Update and Synchronization > > 5.5.1 The base context transfer protocol SHOULD NOT provide > direct support for > synchronization with outside events, since synchronization is > not a requirement > for all > or even most feature contexts. > > 5.5.2 The base context transfer protocol MUST allow > individual feature context > specifications to define their own synchronization with > external events. > > 5.5.3 The base context transfer protocol SHOULD NOT provide > support for updating > context after it is transfered, since context transfer is an > optimization, and > updates would > compromise the timeliness of the transfer. Changes in context > at the source are > discarded > after transfer has been initiated. > > Most feature contexts will not require > synchronization, however there > are a few that may. Header compression, for example, > may require that > the header compressor on the old access router cease > and the compressor > on the new router start in synchrony with hand over > of routing to the > new router; otherwise, the compressor on the new > router will not be > properly synchronized. Since most contexts don't need > synchronization > support, > the CT solution need not support it, but it should > not provide a > hinderance to those feature contexts that do. Any > changes in the source > router > that would cause changes in the context are discarded > after the context > has > been transferred. > > Comments? > > jak > > > > > > > ------_=_NextPart_001_01C22F2C.C38A5BAA Content-Type: text/html; charset="iso-8859-1" RE: [Seamoby] Proposal on Sync/NoSync Requirement

James:

 You have completely ignored "proactive CT", which for me, and I
believe others, is the primary value of CT. If you deliver the context
to a receiving AR in the believe that it is a potential candidate for handover,
and the context at the sending AR changes then an update seems like a necessary
thing to do. At the very least, the context of newly created flows, or flows
being destroyed, should be conveyed. This could be part of the flow set up
semantics, but it seems wrong to insert CT into flow setup.

 The analogy for proactive CT here is soft handover: seamlessness at the IP
layer is analogous to soft handover at the link layer.

 Finally, while I still would like to see CT progress, reducing the value of
CT by simplifying the requirements simply to get IESG approval, does not seem
to me to be an appropriate approach. Proactive CT (now referred to as "CT before
handover", *sigh*), is 90% of CTs value, to me, and I hope others concur.

Gary

> -----Original Message-----
> From: James Kempf [mailto:kempf@docomolabs-usa.com]
> Sent: July 19, 2002 09:04
> To: Kenward, Gary [WDLN2:AN10:EXCH]; John Loughney; seamoby@ietf.org
> Subject: Re: [Seamoby] Proposal on Sync/NoSync Requirement
>
>
> Gary,
>
> > Proposed:
> >
> > 5.5 Context Update and Synchronization
> >
> > 5.5.1 The context transfer protocol MUST be capable of
> supporting the
> >       updates to context information when it changes.
> >
> > 5.5.2 Context updates SHOULD complete before the context is
> needed at
> >       the receiving AR.
> >
> >    The context at the AR actually supporting an MN's traffic will
> >    change with time. For example, the MN may initiate new
> microflow(s),
> >    or discontinue existing microflows. Any change of context at the
> >    supporting AR must be replicated at those ARs that have already
> >    received context for that MN.
> >
> >    However, context changes are often driven by events
> external to the
> >    sending AR, and will thus be asynchronous to any on-going context
> >    updates. Given that context transfers will take a finite
> amount of
> >    time to complete, it is possible that a change in
> context cannot be
> >    conveyed in time to the destination AR to avoid any
> impact on a possible
> >    handover. The objective of the context transfer design
> must be to make
> >    the likelihood of this delay, and its magnitude, as low
> as possible.
> >
> >
> > This is not perfect: the desire to avoid a requirement for
> an extreme degree
> > of synchronization is only implied by the soft "SHOULD" in 5.5.2.
> >
>
> I still don't think this is sufficiently crisp. In addition,
> after reviewing the
> email from the last couple weeks on this, I've seen good
> arguments why the CT protocol itself doesn't need to provide
> update after
> the context has left the router.
>
> We seem to be going through a bit of route flapping on this
> one. Let me slip
> into solution space for just a moment (we'll be out again
> quickly, never fear).
> The way I see the base CT protocol, it is the following things:
>
>         1) A container format in which feature context blobs
> get shipped. The
> container includes an identifier for the feature context, but
> not much more.
>
>     2) A procedure for standardizing blob formats. This will
> require IETF
> standards action, plus IANA specification of type identifier.
>
> So in order to use the CT protocol, a particular application
> would have to
> define the following in a standards track specification:
>
>     1) The detals of the blob layout and the IANA type code,
>
>      2)  The transport for the CT container + blob,
>
>      3) The synchronization requirements (if any) with
> handover events.
>
> For some feature contexts, there may be no synchronization
> requirements. For
> others, there will be.
>
> Popping out of solution space (phew, that was a little
> tight!) , I see the
> following requirements supporting this situation:
>
> 5.5 Context Update and Synchronization
>
> 5.5.1 The base context transfer protocol SHOULD NOT provide
> direct support for
> synchronization with outside events, since synchronization is
> not a requirement
> for all
> or even most feature contexts.
>
> 5.5.2 The base context transfer protocol MUST allow
> individual feature context
> specifications to define their own synchronization with
> external events.
>
> 5.5.3 The base context transfer protocol SHOULD NOT provide
> support for updating
> context after it is transfered, since context transfer is an
> optimization, and
> updates would
> compromise the timeliness of the transfer. Changes in context
> at the source are
> discarded
> after transfer has been initiated.
>
>         Most feature contexts will not require
> synchronization, however there
>         are a few that may. Header compression, for example,
> may require that
>         the header compressor on the old access router cease
> and the compressor
>         on the new router start in synchrony with hand over
> of routing to the
>         new router; otherwise, the compressor on the new
> router will not be
>        properly synchronized. Since most contexts don't need
> synchronization
> support,
>         the CT solution need not support it, but it should
> not provide a
>         hinderance to those feature contexts that do. Any
> changes in the source
> router
>         that would cause changes in the context are discarded
> after the context
> has
>         been transferred.
>
> Comments?
>
>                 jak
>
>
>
>
>
>
>

------_=_NextPart_001_01C22F2C.C38A5BAA-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Fri Jul 19 10:17:14 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09387 for ; Fri, 19 Jul 2002 10:17:14 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA11483; Fri, 19 Jul 2002 10:15:48 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA11416 for ; Fri, 19 Jul 2002 10:15:44 -0400 (EDT) Received: from zcars04f.ca.nortel.com (zcars04f.nortelnetworks.com [47.129.242.57]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09248 for ; Fri, 19 Jul 2002 10:14:45 -0400 (EDT) Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04f.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g6JEFCU04515; Fri, 19 Jul 2002 10:15:12 -0400 (EDT) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 19 Jul 2002 10:15:12 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA4C41@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'Nakhjiri Madjid-MNAKHJI1'" , "'seamoby@ietf.org'" Subject: RE: [Seamoby] CT Requirements Comments from IESG Date: Fri, 19 Jul 2002 10:15:10 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C22F2D.EB4F5496" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C22F2D.EB4F5496 Content-Type: text/plain; charset="iso-8859-1" Madjid: Two comments: 1. As I responded to James, using CT in preparation of possible handovers *is* the main opportunity to ensure seamless. Trying to catch up to a handover, once it has begun, is very difficult, and likely to fail in many cases. 2. What does "too early mean"? Just as there is no deterministic way to predict the direction of a mobile, and thus which AR the MN handsover to, there is no deterministic way to predict when this will happen. So, while the network/MN may know that the MN has the potential to handover to, say, 3 or 4 ARs, and can prepare for it, there is no way to pin down the epoch. I get the impression that either everyone has forgotten about proactive CT, or does not care. Which is too bad, for the boy scouts are right on when they say "be prepared". Gary -----Original Message----- From: Nakhjiri Madjid-MNAKHJI1 [mailto:Madjid.Nakhjiri@motorola.com] Sent: July 18, 2002 17:17 To: Kenward, Gary [WDLN2:AN10:EXCH]; Nakhjiri Madjid-MNAKHJI1; 'Charles E. Perkins' Cc: seamoby@ietf.org Subject: RE: [Seamoby] CT Requirements Comments from IESG -----Original Message----- From: Gary Kenward [mailto:gkenward@nortelnetworks.com] Sent: Thursday, July 18, 2002 9:52 AM To: 'Nakhjiri Madjid-MNAKHJI1'; 'Charles E. Perkins' Cc: seamoby@ietf.org Subject: RE: [Seamoby] CT Requirements Comments from IESG Define "done"? Madjid>> Exactly my point, if you keep sending updates while you're sending other context, you are never done. Seriously, if CT is performed during or after a handover (reactively) then, yes, there's not much more that can be done. If the context at the destination is out of synch with changes in the source context, there is an increased risk that the seamlessness of the handover will be degraded. Madjid>> Yes, assuming you mean L3 handover, and this is the most critical use of CT: optimization of handovers. I can't have CT add to feature disruption by getting into an endless cycle of updates. However, if CT is performed before a handover begins (proactively), and changes occur at the source AR, then it would seem reasonable to attempt updates. There is a presumption here that there is something to be gained in handover performance by performing CT in advance of an actual handover. It could turn out that CT (and the subsequent installion of context at the destination AR) is so fast, that leaving the transfer of context until a handover occurs (i.e. no proactive, only reactive) is a sufficient, and simpler solution. We really won't know whether this is the case until the wg starts looking at CT solutions. Madjid>>sure, but this is not a time-critical CT and CT needs to send updates because it started too early on a dynamic context. Cheers, Gary -----Original Message----- From: Nakhjiri Madjid-MNAKHJI1 [mailto:Madjid.Nakhjiri@motorola.com] Sent: July 17, 2002 19:25 To: Kenward, Gary [WDLN2:AN10:EXCH]; 'Charles E. Perkins' Cc: seamoby@ietf.org Subject: RE: [Seamoby] CT Requirements Comments from IESG Well, not trying to regurgitate (as you said) but we never agreed on timing and reliability requirements and maybe that was ok, because they depend on the scenario and protocols. So why talk about sending updates after CT is done? Madjid -----Original Message----- From: Gary Kenward [mailto:gkenward@nortelnetworks.com] Sent: Friday, July 12, 2002 2:35 PM To: 'Charles E. Perkins' Cc: seamoby@ietf.org Subject: RE: [Seamoby] CT Requirements Comments from IESG I agree Charlie. However, we have to fix the issue with the requirements. Are you suggesting that we relax the requirement? By how much - clearly, some updates are required (e.g. CT really should try and update when flows come and go). Gary > -----Original Message----- > From: Charles E. Perkins [mailto:charliep@iprg.nokia.com] > Sent: July 12, 2002 12:15 > To: Kenward, Gary [WDLN2:AN10:EXCH] > Cc: seamoby@ietf.org > Subject: Re: [Seamoby] CT Requirements Comments from IESG > > > > > Hello folks, > > I think we ought to try to get context transfers > working correctly without initially worrying about > this synchronization problem. > > In the instances I am familiar with, it is not > required. The most stringent case seems to be > ROHC, and even for that it is not necessary. > > We can solve the most urgent problems without having > to deal with any additional context synchronization. > When the old AR sends it, and the new AR gets it, > we should consider the transfer done. In those > cases where reliability is at issue, the old AR > can retransmit when ACK is not received. In many > cases, retransmission of context even once won't > be useful. > > Regards, > Charlie P. > > > > > Gary Kenward wrote: > > > > James: > > > > Yes, we need to fix it, and I think it is doable. > > Thanks to Dirk for highlighting the real problem here > > (I think historically, the integrity requirement came out > > of the reliability section, and somehow, got lumped with > > synchronization and updates). > > > > I think the requirements need a bit of rewording, and > > the paragraph should fall out from this. I do believe > > however, that making the synchronization of context between > > old and new AR a MUST requirement would be too extreme, and > > result in a brittle solution. CT should certainly do it's best to > > provide synchronization, but as was discussed in a recent > > exchange, it would be impossible to guarantee synchronization > > at any instant. > > > > Any ideas/comments from the wg? > > > > Gary > > > > > -----Original Message----- > > > From: James Kempf [mailto:kempf@docomolabs-usa.com] > > > Sent: July 11, 2002 18:32 > > > To: Kenward, Gary [WDLN2:AN10:EXCH]; Dirk.Trossen@nokia.com; > > > seamoby@ietf.org > > > Subject: Re: [Seamoby] CT Requirements Comments from IESG > > > > > > > > > Gary/Dirk, > > > > > > I think you may be on to something here. I think this might > > > be what the IESG was talking about it the first point, namely the > > > lack of discussion of dynamic changes in the context. > > > > > > Is there some way we could cook this idea down into a > > > paragraph that we could insert for this requirement? > > > > > > jak > > > > > > ----- Original Message ----- > > > From: "Gary Kenward" > > > To: ; ; > > > > > > Sent: Thursday, July 11, 2002 1:56 PM > > > Subject: RE: [Seamoby] CT Requirements Comments from IESG > > > > > > > > > > Dirk: > > > > > > > > A valid point. There is a certain atomic level of > > > granularity which has to > > > > be > > > > dealt with - that is, there's no protocol in the world that > > > can synchronize > > > > changes in > > > > information that occur at the source while the information > > > is "in-flight" or > > > > being > > > > received at the destination. If changes in context while > > > the context is > > > > being transferred > > > > make a different to the successful performance of CT, then > > > there is no hope. > > > > > > > > The problem is most significant for state context > > > transfer. E.g. counters > > > > will continue > > > > to count while CT is moving the context to the destination. > > > Either these > > > > changes have no > > > > significant impact upon the forwarding service provided at > > > the new AR (e.g. > > > > it may not > > > > matter that a policing meter misses a few packet counts), > > > or a different > > > > mechanism > > > > has to be defined for re-establishing the state context. > > > > > > > > The handover is real and unavoidable. Mitigating the > > > disruption to the > > > > service at the new > > > > AR is the challenge. It would be nice if the disruption > was nil, but > > > > unlikely. > > > > > > > > Gary > > > > > > > > -----Original Message----- > > > > From: Dirk.Trossen@nokia.com [mailto:Dirk.Trossen@nokia.com] > > > > Sent: July 11, 2002 16:30 > > > > To: Kenward, Gary [WDLN2:AN10:EXCH]; kempf@docomolabs-usa.com; > > > > seamoby@ietf.org > > > > Subject: RE: [Seamoby] CT Requirements Comments from IESG > > > > > > > > > > > > Hi all, > > > > > > > > jumping in as somebody who has been an observer so far, > > > struggling with the > > > > current discussion on > > > > 'integrity'. > > > > > > > > When I look at the current wording, i.e., > > > > "5.5.2 A context update MUST preserve the integrity, and > > > thus the meaning, > > > > of the context > > > > at each receiving AR. The context at the AR actually > > > supporting an MN's > > > > traffic will change with time. > > > > For example, the MN may initiate new microflow(s), or > > > discontinue existing > > > > microflows. Any change of context > > > > at the supporting AR must be replicated at those ARs that > > > have already > > > > received context for that MN.", > > > > > > > > and compare this to the plain integrity of the actually > > > transmitted data > > > > (i.e., its bits and therefore its semantics) > > > > that has been brought to the table as a replacement now, > > > I'm quite confident > > > > that this is not what the requirement > > > > is talking about. > > > > > > > > If we remove the word 'meaning' (which is very vague > and free for > > > > interpretation for me as well), it is still the word > > > > 'integrity' left, which is more than plain integrity of the > > > transmitted > > > > data, in particular if we look at the following sentences > > > > in the requirement, which state what kind of integrity is > > > meant (which > > > > probably also builds the bridge to the vague > > > > term 'meaning'), namely that the integrity of a context > > > must be preserved in > > > > the sense that a received context at new > > > > AR at some point t must be the same as the context at old > > > AR at the same > > > > time t. This is by far more than plain data > > > > integrity of the transmitted data. Even if your data has > > > been transmitted > > > > correctly, the context might be stale (and therefore > > > > its integrity is lost) because it had changed at old AR in > > > the meanwhile. > > > > The action to be taken is also given in the text, > > > > namely the change of context has to be replicated to the > > > new AR. As you can > > > > (hopefully) see this is by far more than > > > > preserving the 'meaning' of each bit. It mandates that > > > changes in the bit > > > > values at one end are reflected at the other > > > > end, i.e., it talks about distributed data integrity in my > > > interpretation of > > > > the requirement text. > > > > > > > > Hence, the actual concern might have been (just guessing) > > > whether or not it > > > > is the task of the CT protocol to > > > > preserve the abovementioned integrity. Maybe, the IESG > > > wants to see this > > > > functionality left to the replication logic that resides > > > > within each AR. Or on the contrary, they do not see this > > > important topic > > > > covered appropriately. > > > > > > > > Regards, > > > > > > > > > > > > Dirk > > > > > > > > -----Original Message----- > > > > From: ext Gary Kenward [mailto:gkenward@nortelnetworks.com] > > > > Sent: Thursday, July 11, 2002 3:48 PM > > > > To: 'James Kempf'; seamoby@ietf.org > > > > Subject: RE: [Seamoby] CT Requirements Comments from IESG > > > > > > > > > > > > > > > > You call it fidelity, I call it data integrity. > > > > I've seen "data integrity" used in publications > > > > (no, I cannot quote references). > > > > > > > > What we need is a term that everyone, including the > > > > IESG, can agree upon. > > > > > > > > > -----Original Message----- > > > > > From: James Kempf [ mailto:kempf@docomolabs-usa.com > > > > ] > > > > > Sent: July 11, 2002 12:22 > > > > > To: Kenward, Gary [WDLN2:AN10:EXCH]; seamoby@ietf.org > > > > > Subject: Re: [Seamoby] CT Requirements Comments from IESG > > > > > > > > > > > > > > > > Perhaps the actual answer is to state exactly what > was intended > > > > > > originally: that the bit order and bit values have to > > > arrive exactly > > > > > > as they were transmitted. > > > > > > > > > > > > > > > > So this requirement is talking about transmission fidelity? I > > > > > sure would not have guessed that from reading it. I thought it > > > > > intended to talk about usability. > > > > > > > > > > I would suggest that the wording you have above is really a > > > > > lot more precise that what is currently in the spec. > > > > > > > > > > Any other comments? Could we substitute Gary's wording above > > > > > for "meaning" in the current requirement. > > > > > > > > > > jak > > > > > > > > > > > > > > > > > > > > > > > > > ------_=_NextPart_001_01C22F2D.EB4F5496 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Seamoby] CT Requirements Comments from IESG

Madjid:

  Two comments:

    1. As I responded to James, using = CT in preparation of possible handovers *is*
       the main = opportunity to ensure seamless. Trying to catch up to a = handover,
       once it has = begun, is very difficult, and likely to fail in many cases.

    2. What does "too early = mean"? Just as there is no deterministic way to predict the =
       direction of a = mobile, and thus which AR the MN handsover to, there is no = deterministic
       way to predict = when this will happen. So, while the network/MN may know that = the
       MN has the = potential to handover to, say, 3 or 4 ARs, and can prepare for = it,
       there is no way = to pin down the epoch.

  I get the impression that either everyone has = forgotten about proactive CT, or does
not care. Which is too bad, for the boy scouts are = right on when they say "be prepared".

Gary

-----Original Message-----
From: Nakhjiri Madjid-MNAKHJI1 [mailto:Madjid.Nakhjiri@moto= rola.com]
Sent: July 18, 2002 17:17
To: Kenward, Gary [WDLN2:AN10:EXCH]; Nakhjiri = Madjid-MNAKHJI1; 'Charles E. Perkins'
Cc: seamoby@ietf.org
Subject: RE: [Seamoby] CT Requirements Comments from = IESG


 
-----Original Message-----
From: Gary Kenward [mailto:gkenward@nortelnetwor= ks.com]
Sent: Thursday, July 18, 2002 9:52 AM
To: 'Nakhjiri Madjid-MNAKHJI1'; 'Charles E. = Perkins'
Cc: seamoby@ietf.org
Subject: RE: [Seamoby] CT Requirements Comments from = IESG


Define "done"?
 
Madjid>> Exactly my point, if you keep sending = updates while you're
sending other context, you are never done.
 
Seriously, if CT is performed during or after a = handover (reactively)
then, yes, there's not much more that can be done. = If the context at
the destination is out of synch with changes in the = source context,
there is an increased risk that the seamlessness of = the handover will
be degraded.
 
Madjid>> Yes, assuming you mean L3 = handover,
and this is the most critical use of CT: = optimization
of handovers. I can't have CT add to feature = disruption by getting
into an endless cycle of updates.
 
However, if CT is performed before a handover begins = (proactively),
and changes occur at the source AR, then it would = seem reasonable to
attempt updates. There is a presumption here that = there is something
to be gained in handover performance by performing = CT in advance of
an actual handover. It could turn out that CT (and = the subsequent installion
of context at the destination AR) is so fast, that = leaving the transfer
of context until a handover occurs (i.e. no = proactive, only reactive) is
a sufficient, and simpler solution. We really won't = know whether this
is the case until the wg starts looking at CT = solutions.
 
Madjid>>sure, but this is not a time-critical = CT and CT needs to send updates because
it started too early on a dynamic context.
 
 
 
 
Cheers,
Gary
-----Original Message-----
From: Nakhjiri Madjid-MNAKHJI1 [mailto:Madjid.Nakhjiri@moto= rola.com]
Sent: July 17, 2002 19:25
To: Kenward, Gary [WDLN2:AN10:EXCH]; 'Charles E. = Perkins'
Cc: seamoby@ietf.org
Subject: RE: [Seamoby] CT Requirements Comments from = IESG


Well, not trying to regurgitate (as you said)
but we never agreed on timing and reliability = requirements and maybe
that was ok, because they depend on the scenario and = protocols.
So why talk about sending updates after CT is = done?
 
 
Madjid
-----Original Message-----
From: Gary Kenward [mailto:gkenward@nortelnetwor= ks.com]
Sent: Friday, July 12, 2002 2:35 PM
To: 'Charles E. Perkins'
Cc: seamoby@ietf.org
Subject: RE: [Seamoby] CT Requirements Comments from = IESG


I agree Charlie. However, we have to fix the issue = with
the requirements. Are you suggesting that we relax = the
requirement? By how much - clearly, some updates are = required
(e.g. CT really should try and update when flows = come and go).
Gary
> -----Original Message-----
> From: Charles E. Perkins [mailto:charliep@iprg.nokia.com]
> Sent: July 12, 2002 12:15
> To: Kenward, Gary [WDLN2:AN10:EXCH]
> Cc: seamoby@ietf.org
> Subject: Re: [Seamoby] CT Requirements Comments = from IESG
>
>
>
>
> Hello folks,
>
> I think we ought to try to get context = transfers
> working correctly without initially worrying = about
> this synchronization problem.
>
> In the instances I am familiar with, it is not =
> required.  The most stringent case seems = to be
> ROHC, and even for that it is not necessary. =
>
> We can solve the most urgent problems without = having
> to deal with any additional context = synchronization.
> When the old AR sends it, and the new AR gets = it,
> we should consider the transfer done.  In = those
> cases where reliability is at issue, the old AR =
> can retransmit when ACK is not received.  = In many
> cases, retransmission of context even once = won't
> be useful.
>
> Regards,
> Charlie P.
>
>
>
> > Gary Kenward wrote:
> >
> > James:
> >
> >   Yes, we need to fix it, and I = think it is doable.
> > Thanks to Dirk for highlighting the real = problem here
> > (I think historically, the integrity = requirement came out
> > of the reliability section, and somehow, = got lumped with
> > synchronization and updates).
> >
> >   I think the requirements need = a bit of rewording, and
> > the paragraph should fall out from this. I = do believe
> > however, that making the synchronization = of context between
> > old and new AR a MUST requirement would be = too extreme, and
> > result in a brittle solution. CT should = certainly do it's best to
> > provide synchronization, but as was = discussed in a recent
> > exchange, it would be impossible to = guarantee synchronization
> > at any instant.
> >
> >   Any ideas/comments from the = wg?
> >
> > Gary
> >
> > > -----Original Message-----
> > > From: James Kempf [mailto:kempf@docomolabs-usa.com= ]
> > > Sent: July 11, 2002 18:32
> > > To: Kenward, Gary [WDLN2:AN10:EXCH]; = Dirk.Trossen@nokia.com;
> > > seamoby@ietf.org
> > > Subject: Re: [Seamoby] CT = Requirements Comments from IESG
> > >
> > >
> > > Gary/Dirk,
> > >
> > > I think you may be on to something = here. I think this might
> > > be what the IESG was talking about it = the first point, namely the
> > > lack of discussion of dynamic changes = in the context.
> > >
> > > Is there some way we could cook this = idea down into a
> > > paragraph that we could insert for = this requirement?
> > >
> > = >           &n= bsp; jak
> > >
> > > ----- Original Message -----
> > > From: "Gary Kenward" = <gkenward@nortelnetworks.com>
> > > To: <Dirk.Trossen@nokia.com>; = <kempf@docomolabs-usa.com>;
> > > <seamoby@ietf.org>
> > > Sent: Thursday, July 11, 2002 1:56 PM =
> > > Subject: RE: [Seamoby] CT = Requirements Comments from IESG
> > >
> > >
> > > > Dirk:
> > > >
> > > >   A valid point. There = is a certain atomic level of
> > > granularity which has to
> > > > be
> > > > dealt with - that is, there's no = protocol in the world that
> > > can synchronize
> > > > changes in
> > > > information that occur at the = source while the information
> > > is "in-flight" or
> > > > being
> > > > received at the destination. If = changes in context while
> > > the context is
> > > > being transferred
> > > > make a different to the = successful performance of CT, then
> > > there is no hope.
> > > >
> > > >   The problem is most = significant for state context
> > > transfer. E.g. counters
> > > > will continue
> > > > to count while CT is moving the = context to the destination.
> > > Either these
> > > > changes have no
> > > > significant impact upon the = forwarding service provided at
> > > the new AR (e.g.
> > > > it may not
> > > > matter that a policing meter = misses a few packet counts),
> > > or a different
> > > > mechanism
> > > > has to be defined for = re-establishing the state context.
> > > >
> > > >   The handover is real = and unavoidable. Mitigating the
> > > disruption to the
> > > > service at the new
> > > > AR is the challenge. It would be = nice if the disruption
> was nil, but
> > > > unlikely.
> > > >
> > > > Gary
> > > >
> > > > -----Original Message----- =
> > > > From: Dirk.Trossen@nokia.com [mailto:Dirk.Trossen@nokia.com= ]
> > > > Sent: July 11, 2002 16:30 =
> > > > To: Kenward, Gary = [WDLN2:AN10:EXCH]; kempf@docomolabs-usa.com;
> > > > seamoby@ietf.org
> > > > Subject: RE: [Seamoby] CT = Requirements Comments from IESG
> > > >
> > > >
> > > > Hi all,
> > > >
> > > > jumping in as somebody who has = been an observer so far,
> > > struggling with the
> > > > current discussion on
> > > > 'integrity'.
> > > >
> > > > When I look at the current = wording, i.e.,
> > > > "5.5.2 A context update = MUST preserve the integrity, and
> > > thus the meaning,
> > > > of the context
> > > > at each receiving AR. The = context at the AR actually
> > > supporting an MN's
> > > > traffic will change with time. =
> > > > For example, the MN may initiate = new microflow(s), or
> > > discontinue existing
> > > > microflows. Any change of = context
> > > > at the supporting AR must be = replicated at those ARs that
> > > have already
> > > > received context for that = MN.",
> > > >
> > > > and compare this to the plain = integrity of the actually
> > > transmitted data
> > > > (i.e., its bits and therefore = its semantics)
> > > > that has been brought to the = table as a replacement now,
> > > I'm quite confident
> > > > that this is not what the = requirement
> > > > is talking about.
> > > >
> > > > If we remove the word 'meaning' = (which is very vague
> and free for
> > > > interpretation for me as well), = it is still the word
> > > > 'integrity' left, which is more = than plain integrity of the
> > > transmitted
> > > > data, in particular if we look = at the following sentences
> > > > in the requirement, which state = what kind of integrity is
> > > meant (which
> > > > probably also builds the bridge = to the vague
> > > > term 'meaning'), namely that the = integrity of a context
> > > must be preserved in
> > > > the sense that a received = context at new
> > > > AR at some point t must be the = same as the context at old
> > > AR at the same
> > > > time t. This is by far more than = plain data
> > > > integrity of the transmitted = data. Even if your data has
> > > been transmitted
> > > > correctly, the context might be = stale (and therefore
> > > > its integrity is lost) because = it had changed at old AR in
> > > the meanwhile.
> > > > The action to be taken is also = given in the text,
> > > > namely the change of context has = to be replicated to the
> > > new AR. As you can
> > > > (hopefully) see this is by far = more than
> > > > preserving the 'meaning' of each = bit. It mandates that
> > > changes in the bit
> > > > values at one end are reflected = at the other
> > > > end, i.e., it talks about = distributed data integrity in my
> > > interpretation of
> > > > the requirement text.
> > > >
> > > > Hence, the actual concern might = have been (just guessing)
> > > whether or not it
> > > > is the task of the CT protocol = to
> > > > preserve the abovementioned = integrity. Maybe, the IESG
> > > wants to see this
> > > > functionality left to the = replication logic that resides
> > > > within each AR. Or on the = contrary, they do not see this
> > > important topic
> > > > covered appropriately.
> > > >
> > > > Regards,
> > > >
> > > >
> > > > Dirk
> > > >
> > > > -----Original Message----- =
> > > > From: ext Gary Kenward [mailto:gkenward@nortelnetwor= ks.com]
> > > > Sent: Thursday, July 11, 2002 = 3:48 PM
> > > > To: 'James Kempf'; = seamoby@ietf.org
> > > > Subject: RE: [Seamoby] CT = Requirements Comments from IESG
> > > >
> > > >
> > > >
> > > > You call it fidelity, I call it = data integrity.
> > > > I've seen "data = integrity" used in publications
> > > > (no, I cannot quote references). =
> > > >
> > > > What we need is a term that = everyone, including the
> > > > IESG, can agree upon.
> > > >
> > > > > -----Original Message----- =
> > > > > From: James Kempf [ mailto:kempf@docomolabs-usa.com=
> > > > <mailto:kempf@docomolabs-usa.com= > ]
> > > > > Sent: July 11, 2002 12:22 =
> > > > > To: Kenward, Gary = [WDLN2:AN10:EXCH]; seamoby@ietf.org
> > > > > Subject: Re: [Seamoby] CT = Requirements Comments from IESG
> > > > >
> > > > >
> > > > > > Perhaps the actual = answer is to state exactly what
> was intended
> > > > > > originally: that the = bit order and bit values have to
> > > arrive exactly
> > > > > > as they were = transmitted.
> > > > > >
> > > > >
> > > > > So this requirement is = talking about transmission fidelity? I
> > > > > sure would not have guessed = that from reading it. I thought it
> > > > > intended to talk about = usability.
> > > > >
> > > > > I would suggest that the = wording you have above is really a
> > > > > lot more precise that what = is currently in the spec.
> > > > >
> > > > > Any other comments? Could = we substitute Gary's wording above
> > > > > for "meaning" in = the current requirement.
> > > > >
> > > > = >           &n= bsp; jak
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
>

------_=_NextPart_001_01C22F2D.EB4F5496-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Fri Jul 19 10:17:15 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09394 for ; Fri, 19 Jul 2002 10:17:14 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA11693 for seamoby-archive@odin.ietf.org; Fri, 19 Jul 2002 10:18:13 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA11483; Fri, 19 Jul 2002 10:15:48 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA11416 for ; Fri, 19 Jul 2002 10:15:44 -0400 (EDT) Received: from zcars04f.ca.nortel.com (zcars04f.nortelnetworks.com [47.129.242.57]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09248 for ; Fri, 19 Jul 2002 10:14:45 -0400 (EDT) Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04f.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g6JEFCU04515; Fri, 19 Jul 2002 10:15:12 -0400 (EDT) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 19 Jul 2002 10:15:12 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA4C41@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'Nakhjiri Madjid-MNAKHJI1'" , "'seamoby@ietf.org'" Subject: RE: [Seamoby] CT Requirements Comments from IESG Date: Fri, 19 Jul 2002 10:15:10 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C22F2D.EB4F5496" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C22F2D.EB4F5496 Content-Type: text/plain; charset="iso-8859-1" Madjid: Two comments: 1. As I responded to James, using CT in preparation of possible handovers *is* the main opportunity to ensure seamless. Trying to catch up to a handover, once it has begun, is very difficult, and likely to fail in many cases. 2. What does "too early mean"? Just as there is no deterministic way to predict the direction of a mobile, and thus which AR the MN handsover to, there is no deterministic way to predict when this will happen. So, while the network/MN may know that the MN has the potential to handover to, say, 3 or 4 ARs, and can prepare for it, there is no way to pin down the epoch. I get the impression that either everyone has forgotten about proactive CT, or does not care. Which is too bad, for the boy scouts are right on when they say "be prepared". Gary -----Original Message----- From: Nakhjiri Madjid-MNAKHJI1 [mailto:Madjid.Nakhjiri@motorola.com] Sent: July 18, 2002 17:17 To: Kenward, Gary [WDLN2:AN10:EXCH]; Nakhjiri Madjid-MNAKHJI1; 'Charles E. Perkins' Cc: seamoby@ietf.org Subject: RE: [Seamoby] CT Requirements Comments from IESG -----Original Message----- From: Gary Kenward [mailto:gkenward@nortelnetworks.com] Sent: Thursday, July 18, 2002 9:52 AM To: 'Nakhjiri Madjid-MNAKHJI1'; 'Charles E. Perkins' Cc: seamoby@ietf.org Subject: RE: [Seamoby] CT Requirements Comments from IESG Define "done"? Madjid>> Exactly my point, if you keep sending updates while you're sending other context, you are never done. Seriously, if CT is performed during or after a handover (reactively) then, yes, there's not much more that can be done. If the context at the destination is out of synch with changes in the source context, there is an increased risk that the seamlessness of the handover will be degraded. Madjid>> Yes, assuming you mean L3 handover, and this is the most critical use of CT: optimization of handovers. I can't have CT add to feature disruption by getting into an endless cycle of updates. However, if CT is performed before a handover begins (proactively), and changes occur at the source AR, then it would seem reasonable to attempt updates. There is a presumption here that there is something to be gained in handover performance by performing CT in advance of an actual handover. It could turn out that CT (and the subsequent installion of context at the destination AR) is so fast, that leaving the transfer of context until a handover occurs (i.e. no proactive, only reactive) is a sufficient, and simpler solution. We really won't know whether this is the case until the wg starts looking at CT solutions. Madjid>>sure, but this is not a time-critical CT and CT needs to send updates because it started too early on a dynamic context. Cheers, Gary -----Original Message----- From: Nakhjiri Madjid-MNAKHJI1 [mailto:Madjid.Nakhjiri@motorola.com] Sent: July 17, 2002 19:25 To: Kenward, Gary [WDLN2:AN10:EXCH]; 'Charles E. Perkins' Cc: seamoby@ietf.org Subject: RE: [Seamoby] CT Requirements Comments from IESG Well, not trying to regurgitate (as you said) but we never agreed on timing and reliability requirements and maybe that was ok, because they depend on the scenario and protocols. So why talk about sending updates after CT is done? Madjid -----Original Message----- From: Gary Kenward [mailto:gkenward@nortelnetworks.com] Sent: Friday, July 12, 2002 2:35 PM To: 'Charles E. Perkins' Cc: seamoby@ietf.org Subject: RE: [Seamoby] CT Requirements Comments from IESG I agree Charlie. However, we have to fix the issue with the requirements. Are you suggesting that we relax the requirement? By how much - clearly, some updates are required (e.g. CT really should try and update when flows come and go). Gary > -----Original Message----- > From: Charles E. Perkins [mailto:charliep@iprg.nokia.com] > Sent: July 12, 2002 12:15 > To: Kenward, Gary [WDLN2:AN10:EXCH] > Cc: seamoby@ietf.org > Subject: Re: [Seamoby] CT Requirements Comments from IESG > > > > > Hello folks, > > I think we ought to try to get context transfers > working correctly without initially worrying about > this synchronization problem. > > In the instances I am familiar with, it is not > required. The most stringent case seems to be > ROHC, and even for that it is not necessary. > > We can solve the most urgent problems without having > to deal with any additional context synchronization. > When the old AR sends it, and the new AR gets it, > we should consider the transfer done. In those > cases where reliability is at issue, the old AR > can retransmit when ACK is not received. In many > cases, retransmission of context even once won't > be useful. > > Regards, > Charlie P. > > > > > Gary Kenward wrote: > > > > James: > > > > Yes, we need to fix it, and I think it is doable. > > Thanks to Dirk for highlighting the real problem here > > (I think historically, the integrity requirement came out > > of the reliability section, and somehow, got lumped with > > synchronization and updates). > > > > I think the requirements need a bit of rewording, and > > the paragraph should fall out from this. I do believe > > however, that making the synchronization of context between > > old and new AR a MUST requirement would be too extreme, and > > result in a brittle solution. CT should certainly do it's best to > > provide synchronization, but as was discussed in a recent > > exchange, it would be impossible to guarantee synchronization > > at any instant. > > > > Any ideas/comments from the wg? > > > > Gary > > > > > -----Original Message----- > > > From: James Kempf [mailto:kempf@docomolabs-usa.com] > > > Sent: July 11, 2002 18:32 > > > To: Kenward, Gary [WDLN2:AN10:EXCH]; Dirk.Trossen@nokia.com; > > > seamoby@ietf.org > > > Subject: Re: [Seamoby] CT Requirements Comments from IESG > > > > > > > > > Gary/Dirk, > > > > > > I think you may be on to something here. I think this might > > > be what the IESG was talking about it the first point, namely the > > > lack of discussion of dynamic changes in the context. > > > > > > Is there some way we could cook this idea down into a > > > paragraph that we could insert for this requirement? > > > > > > jak > > > > > > ----- Original Message ----- > > > From: "Gary Kenward" > > > To: ; ; > > > > > > Sent: Thursday, July 11, 2002 1:56 PM > > > Subject: RE: [Seamoby] CT Requirements Comments from IESG > > > > > > > > > > Dirk: > > > > > > > > A valid point. There is a certain atomic level of > > > granularity which has to > > > > be > > > > dealt with - that is, there's no protocol in the world that > > > can synchronize > > > > changes in > > > > information that occur at the source while the information > > > is "in-flight" or > > > > being > > > > received at the destination. If changes in context while > > > the context is > > > > being transferred > > > > make a different to the successful performance of CT, then > > > there is no hope. > > > > > > > > The problem is most significant for state context > > > transfer. E.g. counters > > > > will continue > > > > to count while CT is moving the context to the destination. > > > Either these > > > > changes have no > > > > significant impact upon the forwarding service provided at > > > the new AR (e.g. > > > > it may not > > > > matter that a policing meter misses a few packet counts), > > > or a different > > > > mechanism > > > > has to be defined for re-establishing the state context. > > > > > > > > The handover is real and unavoidable. Mitigating the > > > disruption to the > > > > service at the new > > > > AR is the challenge. It would be nice if the disruption > was nil, but > > > > unlikely. > > > > > > > > Gary > > > > > > > > -----Original Message----- > > > > From: Dirk.Trossen@nokia.com [mailto:Dirk.Trossen@nokia.com] > > > > Sent: July 11, 2002 16:30 > > > > To: Kenward, Gary [WDLN2:AN10:EXCH]; kempf@docomolabs-usa.com; > > > > seamoby@ietf.org > > > > Subject: RE: [Seamoby] CT Requirements Comments from IESG > > > > > > > > > > > > Hi all, > > > > > > > > jumping in as somebody who has been an observer so far, > > > struggling with the > > > > current discussion on > > > > 'integrity'. > > > > > > > > When I look at the current wording, i.e., > > > > "5.5.2 A context update MUST preserve the integrity, and > > > thus the meaning, > > > > of the context > > > > at each receiving AR. The context at the AR actually > > > supporting an MN's > > > > traffic will change with time. > > > > For example, the MN may initiate new microflow(s), or > > > discontinue existing > > > > microflows. Any change of context > > > > at the supporting AR must be replicated at those ARs that > > > have already > > > > received context for that MN.", > > > > > > > > and compare this to the plain integrity of the actually > > > transmitted data > > > > (i.e., its bits and therefore its semantics) > > > > that has been brought to the table as a replacement now, > > > I'm quite confident > > > > that this is not what the requirement > > > > is talking about. > > > > > > > > If we remove the word 'meaning' (which is very vague > and free for > > > > interpretation for me as well), it is still the word > > > > 'integrity' left, which is more than plain integrity of the > > > transmitted > > > > data, in particular if we look at the following sentences > > > > in the requirement, which state what kind of integrity is > > > meant (which > > > > probably also builds the bridge to the vague > > > > term 'meaning'), namely that the integrity of a context > > > must be preserved in > > > > the sense that a received context at new > > > > AR at some point t must be the same as the context at old > > > AR at the same > > > > time t. This is by far more than plain data > > > > integrity of the transmitted data. Even if your data has > > > been transmitted > > > > correctly, the context might be stale (and therefore > > > > its integrity is lost) because it had changed at old AR in > > > the meanwhile. > > > > The action to be taken is also given in the text, > > > > namely the change of context has to be replicated to the > > > new AR. As you can > > > > (hopefully) see this is by far more than > > > > preserving the 'meaning' of each bit. It mandates that > > > changes in the bit > > > > values at one end are reflected at the other > > > > end, i.e., it talks about distributed data integrity in my > > > interpretation of > > > > the requirement text. > > > > > > > > Hence, the actual concern might have been (just guessing) > > > whether or not it > > > > is the task of the CT protocol to > > > > preserve the abovementioned integrity. Maybe, the IESG > > > wants to see this > > > > functionality left to the replication logic that resides > > > > within each AR. Or on the contrary, they do not see this > > > important topic > > > > covered appropriately. > > > > > > > > Regards, > > > > > > > > > > > > Dirk > > > > > > > > -----Original Message----- > > > > From: ext Gary Kenward [mailto:gkenward@nortelnetworks.com] > > > > Sent: Thursday, July 11, 2002 3:48 PM > > > > To: 'James Kempf'; seamoby@ietf.org > > > > Subject: RE: [Seamoby] CT Requirements Comments from IESG > > > > > > > > > > > > > > > > You call it fidelity, I call it data integrity. > > > > I've seen "data integrity" used in publications > > > > (no, I cannot quote references). > > > > > > > > What we need is a term that everyone, including the > > > > IESG, can agree upon. > > > > > > > > > -----Original Message----- > > > > > From: James Kempf [ mailto:kempf@docomolabs-usa.com > > > > ] > > > > > Sent: July 11, 2002 12:22 > > > > > To: Kenward, Gary [WDLN2:AN10:EXCH]; seamoby@ietf.org > > > > > Subject: Re: [Seamoby] CT Requirements Comments from IESG > > > > > > > > > > > > > > > > Perhaps the actual answer is to state exactly what > was intended > > > > > > originally: that the bit order and bit values have to > > > arrive exactly > > > > > > as they were transmitted. > > > > > > > > > > > > > > > > So this requirement is talking about transmission fidelity? I > > > > > sure would not have guessed that from reading it. I thought it > > > > > intended to talk about usability. > > > > > > > > > > I would suggest that the wording you have above is really a > > > > > lot more precise that what is currently in the spec. > > > > > > > > > > Any other comments? Could we substitute Gary's wording above > > > > > for "meaning" in the current requirement. > > > > > > > > > > jak > > > > > > > > > > > > > > > > > > > > > > > > > ------_=_NextPart_001_01C22F2D.EB4F5496 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Seamoby] CT Requirements Comments from IESG

Madjid:

  Two comments:

    1. As I responded to James, using = CT in preparation of possible handovers *is*
       the main = opportunity to ensure seamless. Trying to catch up to a = handover,
       once it has = begun, is very difficult, and likely to fail in many cases.

    2. What does "too early = mean"? Just as there is no deterministic way to predict the =
       direction of a = mobile, and thus which AR the MN handsover to, there is no = deterministic
       way to predict = when this will happen. So, while the network/MN may know that = the
       MN has the = potential to handover to, say, 3 or 4 ARs, and can prepare for = it,
       there is no way = to pin down the epoch.

  I get the impression that either everyone has = forgotten about proactive CT, or does
not care. Which is too bad, for the boy scouts are = right on when they say "be prepared".

Gary

-----Original Message-----
From: Nakhjiri Madjid-MNAKHJI1 [mailto:Madjid.Nakhjiri@moto= rola.com]
Sent: July 18, 2002 17:17
To: Kenward, Gary [WDLN2:AN10:EXCH]; Nakhjiri = Madjid-MNAKHJI1; 'Charles E. Perkins'
Cc: seamoby@ietf.org
Subject: RE: [Seamoby] CT Requirements Comments from = IESG


 
-----Original Message-----
From: Gary Kenward [mailto:gkenward@nortelnetwor= ks.com]
Sent: Thursday, July 18, 2002 9:52 AM
To: 'Nakhjiri Madjid-MNAKHJI1'; 'Charles E. = Perkins'
Cc: seamoby@ietf.org
Subject: RE: [Seamoby] CT Requirements Comments from = IESG


Define "done"?
 
Madjid>> Exactly my point, if you keep sending = updates while you're
sending other context, you are never done.
 
Seriously, if CT is performed during or after a = handover (reactively)
then, yes, there's not much more that can be done. = If the context at
the destination is out of synch with changes in the = source context,
there is an increased risk that the seamlessness of = the handover will
be degraded.
 
Madjid>> Yes, assuming you mean L3 = handover,
and this is the most critical use of CT: = optimization
of handovers. I can't have CT add to feature = disruption by getting
into an endless cycle of updates.
 
However, if CT is performed before a handover begins = (proactively),
and changes occur at the source AR, then it would = seem reasonable to
attempt updates. There is a presumption here that = there is something
to be gained in handover performance by performing = CT in advance of
an actual handover. It could turn out that CT (and = the subsequent installion
of context at the destination AR) is so fast, that = leaving the transfer
of context until a handover occurs (i.e. no = proactive, only reactive) is
a sufficient, and simpler solution. We really won't = know whether this
is the case until the wg starts looking at CT = solutions.
 
Madjid>>sure, but this is not a time-critical = CT and CT needs to send updates because
it started too early on a dynamic context.
 
 
 
 
Cheers,
Gary
-----Original Message-----
From: Nakhjiri Madjid-MNAKHJI1 [mailto:Madjid.Nakhjiri@moto= rola.com]
Sent: July 17, 2002 19:25
To: Kenward, Gary [WDLN2:AN10:EXCH]; 'Charles E. = Perkins'
Cc: seamoby@ietf.org
Subject: RE: [Seamoby] CT Requirements Comments from = IESG


Well, not trying to regurgitate (as you said)
but we never agreed on timing and reliability = requirements and maybe
that was ok, because they depend on the scenario and = protocols.
So why talk about sending updates after CT is = done?
 
 
Madjid
-----Original Message-----
From: Gary Kenward [mailto:gkenward@nortelnetwor= ks.com]
Sent: Friday, July 12, 2002 2:35 PM
To: 'Charles E. Perkins'
Cc: seamoby@ietf.org
Subject: RE: [Seamoby] CT Requirements Comments from = IESG


I agree Charlie. However, we have to fix the issue = with
the requirements. Are you suggesting that we relax = the
requirement? By how much - clearly, some updates are = required
(e.g. CT really should try and update when flows = come and go).
Gary
> -----Original Message-----
> From: Charles E. Perkins [mailto:charliep@iprg.nokia.com]
> Sent: July 12, 2002 12:15
> To: Kenward, Gary [WDLN2:AN10:EXCH]
> Cc: seamoby@ietf.org
> Subject: Re: [Seamoby] CT Requirements Comments = from IESG
>
>
>
>
> Hello folks,
>
> I think we ought to try to get context = transfers
> working correctly without initially worrying = about
> this synchronization problem.
>
> In the instances I am familiar with, it is not =
> required.  The most stringent case seems = to be
> ROHC, and even for that it is not necessary. =
>
> We can solve the most urgent problems without = having
> to deal with any additional context = synchronization.
> When the old AR sends it, and the new AR gets = it,
> we should consider the transfer done.  In = those
> cases where reliability is at issue, the old AR =
> can retransmit when ACK is not received.  = In many
> cases, retransmission of context even once = won't
> be useful.
>
> Regards,
> Charlie P.
>
>
>
> > Gary Kenward wrote:
> >
> > James:
> >
> >   Yes, we need to fix it, and I = think it is doable.
> > Thanks to Dirk for highlighting the real = problem here
> > (I think historically, the integrity = requirement came out
> > of the reliability section, and somehow, = got lumped with
> > synchronization and updates).
> >
> >   I think the requirements need = a bit of rewording, and
> > the paragraph should fall out from this. I = do believe
> > however, that making the synchronization = of context between
> > old and new AR a MUST requirement would be = too extreme, and
> > result in a brittle solution. CT should = certainly do it's best to
> > provide synchronization, but as was = discussed in a recent
> > exchange, it would be impossible to = guarantee synchronization
> > at any instant.
> >
> >   Any ideas/comments from the = wg?
> >
> > Gary
> >
> > > -----Original Message-----
> > > From: James Kempf [mailto:kempf@docomolabs-usa.com= ]
> > > Sent: July 11, 2002 18:32
> > > To: Kenward, Gary [WDLN2:AN10:EXCH]; = Dirk.Trossen@nokia.com;
> > > seamoby@ietf.org
> > > Subject: Re: [Seamoby] CT = Requirements Comments from IESG
> > >
> > >
> > > Gary/Dirk,
> > >
> > > I think you may be on to something = here. I think this might
> > > be what the IESG was talking about it = the first point, namely the
> > > lack of discussion of dynamic changes = in the context.
> > >
> > > Is there some way we could cook this = idea down into a
> > > paragraph that we could insert for = this requirement?
> > >
> > = >           &n= bsp; jak
> > >
> > > ----- Original Message -----
> > > From: "Gary Kenward" = <gkenward@nortelnetworks.com>
> > > To: <Dirk.Trossen@nokia.com>; = <kempf@docomolabs-usa.com>;
> > > <seamoby@ietf.org>
> > > Sent: Thursday, July 11, 2002 1:56 PM =
> > > Subject: RE: [Seamoby] CT = Requirements Comments from IESG
> > >
> > >
> > > > Dirk:
> > > >
> > > >   A valid point. There = is a certain atomic level of
> > > granularity which has to
> > > > be
> > > > dealt with - that is, there's no = protocol in the world that
> > > can synchronize
> > > > changes in
> > > > information that occur at the = source while the information
> > > is "in-flight" or
> > > > being
> > > > received at the destination. If = changes in context while
> > > the context is
> > > > being transferred
> > > > make a different to the = successful performance of CT, then
> > > there is no hope.
> > > >
> > > >   The problem is most = significant for state context
> > > transfer. E.g. counters
> > > > will continue
> > > > to count while CT is moving the = context to the destination.
> > > Either these
> > > > changes have no
> > > > significant impact upon the = forwarding service provided at
> > > the new AR (e.g.
> > > > it may not
> > > > matter that a policing meter = misses a few packet counts),
> > > or a different
> > > > mechanism
> > > > has to be defined for = re-establishing the state context.
> > > >
> > > >   The handover is real = and unavoidable. Mitigating the
> > > disruption to the
> > > > service at the new
> > > > AR is the challenge. It would be = nice if the disruption
> was nil, but
> > > > unlikely.
> > > >
> > > > Gary
> > > >
> > > > -----Original Message----- =
> > > > From: Dirk.Trossen@nokia.com [mailto:Dirk.Trossen@nokia.com= ]
> > > > Sent: July 11, 2002 16:30 =
> > > > To: Kenward, Gary = [WDLN2:AN10:EXCH]; kempf@docomolabs-usa.com;
> > > > seamoby@ietf.org
> > > > Subject: RE: [Seamoby] CT = Requirements Comments from IESG
> > > >
> > > >
> > > > Hi all,
> > > >
> > > > jumping in as somebody who has = been an observer so far,
> > > struggling with the
> > > > current discussion on
> > > > 'integrity'.
> > > >
> > > > When I look at the current = wording, i.e.,
> > > > "5.5.2 A context update = MUST preserve the integrity, and
> > > thus the meaning,
> > > > of the context
> > > > at each receiving AR. The = context at the AR actually
> > > supporting an MN's
> > > > traffic will change with time. =
> > > > For example, the MN may initiate = new microflow(s), or
> > > discontinue existing
> > > > microflows. Any change of = context
> > > > at the supporting AR must be = replicated at those ARs that
> > > have already
> > > > received context for that = MN.",
> > > >
> > > > and compare this to the plain = integrity of the actually
> > > transmitted data
> > > > (i.e., its bits and therefore = its semantics)
> > > > that has been brought to the = table as a replacement now,
> > > I'm quite confident
> > > > that this is not what the = requirement
> > > > is talking about.
> > > >
> > > > If we remove the word 'meaning' = (which is very vague
> and free for
> > > > interpretation for me as well), = it is still the word
> > > > 'integrity' left, which is more = than plain integrity of the
> > > transmitted
> > > > data, in particular if we look = at the following sentences
> > > > in the requirement, which state = what kind of integrity is
> > > meant (which
> > > > probably also builds the bridge = to the vague
> > > > term 'meaning'), namely that the = integrity of a context
> > > must be preserved in
> > > > the sense that a received = context at new
> > > > AR at some point t must be the = same as the context at old
> > > AR at the same
> > > > time t. This is by far more than = plain data
> > > > integrity of the transmitted = data. Even if your data has
> > > been transmitted
> > > > correctly, the context might be = stale (and therefore
> > > > its integrity is lost) because = it had changed at old AR in
> > > the meanwhile.
> > > > The action to be taken is also = given in the text,
> > > > namely the change of context has = to be replicated to the
> > > new AR. As you can
> > > > (hopefully) see this is by far = more than
> > > > preserving the 'meaning' of each = bit. It mandates that
> > > changes in the bit
> > > > values at one end are reflected = at the other
> > > > end, i.e., it talks about = distributed data integrity in my
> > > interpretation of
> > > > the requirement text.
> > > >
> > > > Hence, the actual concern might = have been (just guessing)
> > > whether or not it
> > > > is the task of the CT protocol = to
> > > > preserve the abovementioned = integrity. Maybe, the IESG
> > > wants to see this
> > > > functionality left to the = replication logic that resides
> > > > within each AR. Or on the = contrary, they do not see this
> > > important topic
> > > > covered appropriately.
> > > >
> > > > Regards,
> > > >
> > > >
> > > > Dirk
> > > >
> > > > -----Original Message----- =
> > > > From: ext Gary Kenward [mailto:gkenward@nortelnetwor= ks.com]
> > > > Sent: Thursday, July 11, 2002 = 3:48 PM
> > > > To: 'James Kempf'; = seamoby@ietf.org
> > > > Subject: RE: [Seamoby] CT = Requirements Comments from IESG
> > > >
> > > >
> > > >
> > > > You call it fidelity, I call it = data integrity.
> > > > I've seen "data = integrity" used in publications
> > > > (no, I cannot quote references). =
> > > >
> > > > What we need is a term that = everyone, including the
> > > > IESG, can agree upon.
> > > >
> > > > > -----Original Message----- =
> > > > > From: James Kempf [ mailto:kempf@docomolabs-usa.com=
> > > > <mailto:kempf@docomolabs-usa.com= > ]
> > > > > Sent: July 11, 2002 12:22 =
> > > > > To: Kenward, Gary = [WDLN2:AN10:EXCH]; seamoby@ietf.org
> > > > > Subject: Re: [Seamoby] CT = Requirements Comments from IESG
> > > > >
> > > > >
> > > > > > Perhaps the actual = answer is to state exactly what
> was intended
> > > > > > originally: that the = bit order and bit values have to
> > > arrive exactly
> > > > > > as they were = transmitted.
> > > > > >
> > > > >
> > > > > So this requirement is = talking about transmission fidelity? I
> > > > > sure would not have guessed = that from reading it. I thought it
> > > > > intended to talk about = usability.
> > > > >
> > > > > I would suggest that the = wording you have above is really a
> > > > > lot more precise that what = is currently in the spec.
> > > > >
> > > > > Any other comments? Could = we substitute Gary's wording above
> > > > > for "meaning" in = the current requirement.
> > > > >
> > > > = >           &n= bsp; jak
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
>

------_=_NextPart_001_01C22F2D.EB4F5496-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Fri Jul 19 10:35:46 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09964 for ; Fri, 19 Jul 2002 10:35:46 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA13308; Fri, 19 Jul 2002 10:31:55 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA13281 for ; Fri, 19 Jul 2002 10:31:52 -0400 (EDT) Received: from zcars04e.ca.nortel.com (zcars04e.nortelnetworks.com [47.129.242.56]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09855 for ; Fri, 19 Jul 2002 10:30:48 -0400 (EDT) Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g6JEV6g12930; Fri, 19 Jul 2002 10:31:06 -0400 (EDT) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 19 Jul 2002 10:31:05 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA4C42@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'Nakhjiri Madjid-MNAKHJI1'" , "'James Kempf'" , john.loughney@nokia.com, seamoby@ietf.org Subject: RE: [Seamoby] Proposal on Sync/NoSync Requirement Date: Fri, 19 Jul 2002 10:31:02 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C22F30.E8701D34" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C22F30.E8701D34 Content-Type: text/plain; charset="iso-8859-1" Madjid: I would like to respond to your comments with a general comment, which hopefully covers much of the issue. Correct me if this is not the case. The fundamental concern here seems to be over the scenario where the context changes while a CT is already in progress. It does not seem to me to be a difficult task to formulate a requirement that states that CT will update, but at best, the granularity of the synchronization will be greater then the duration of a CT (lots of word smithing required, perhaps, but doable). As far as I can discern, the only detrimental effect of sending context updates to receiving ARs is the protocol overhead. A receiving AR may always decide that it does not need to use a context update. It would probably make this decision when, for example, it was receiving a handover, and had installed context in preparation for the arriving flows. In other words, the disruption of attempting to update the installed context would be greater then the disruption of not having the latest context. Now, dynamic, or state related context updates are a real problem. There is a big issue as to when to perform state updates, how often, etc. For example, if the dynamic context is a packet counter, you obviously do not want to be updating that context every time it changes. In our work, we came to the conclusion that while it was worthwile updated configuration context when it happened, updating dynamic context (e.g. state context) was not pratical, and indeed, transferring of state context only made sense to attempt just before the receiving AR needed the context. Again, the assumption here is that transferring configuration context ahead of time (e.g. ahead of an actual handover), improves seamlessness. There seems to be some evidence that it can. As I see it, this whole discussion is around, as you put it, the "NON-requirement" of ensuring that the CT solution is not driven to meet extreme synchronization goals. We could take this approach to many of the requirements - e.g. if I say CT has to be fast, does that mean pico-second transfer times? Clearly it doesn't, but we do not have a requirement that says "CT should be fast, but not too fast" (Note: the actual requirement doesn't use the word fast - this is simply a counter example). Cheers, Gary -----Original Message----- From: Nakhjiri Madjid-MNAKHJI1 [mailto:Madjid.Nakhjiri@motorola.com] Sent: July 18, 2002 17:54 To: Kenward, Gary [WDLN2:AN10:EXCH]; Nakhjiri Madjid-MNAKHJI1; 'James Kempf'; john.loughney@nokia.com; seamoby@ietf.org Subject: RE: [Seamoby] Proposal on Sync/NoSync Requirement Gary, Thanks for your reply. We are getting there. Please see comments below BR, Madjid > Proposed: > 5.5 Context Update and Synchronization > 5.5.1 The context transfer protocol MUST be capable of supporting the > updates to context information when it changes. > > Madjid>> Ok, this takes care of the dynamic context, however, we Actually, the real concern I have is not for dynamic context as it is for changes in the makeup of the traffic for the MN - i.e. the arrival and departure of microflows. This would change the configuration (aka static) context. Madjid>> Ok, as I recall the context transfer deals with a microflow as a unit. The discussion of arrival and departure of microflows is relevant if you are aggregating multiple microflows, so maybe this should be added to the section that talks about aggregation, otherwise I think it is hard to avoid the interpretation I made (dynamic feature context) > need to be clarify that we are not requiring the oldAR sends updates > to context features it has already transmitted while it is > transmitting > context for other features, otherwise CT might never end. I absolutely agree with you. Madjid>> glad to hear that. > Since, some folks have brought that up, I want to make sure that we > are not reading that in the requirement. Updates initiated by oldAR > should only be based on outside triggers such as new flow, > flow terminations > or messages from central entities... There seems to be a concern that CT will not be able to guarantee perfect synchronization of the configuration and state of both ARs. My response to this concern is, of course not, CT was never intended to do such a think. This is not distributed computing, it is handover optimization. Perhaps a new requirement would help clarify this, something like: 5.5.x Context transfer SHALL NOT attempt to guarantee perfect synchronization of context. The purpose of CT is to improve handover as best as it can. Given the complexity and overheads needed to synchronize distributed state machines, it is expected that occasionally, the context of the source and destination AR will not agree. The CT solution must minimize the likelihood of this happening "Addition: by careful consideration of the rate by which context will change over time . 5.5.x+1 Context transfer WILL NOT attempt to mitigate the effects of stale context at the receiving AR. Madjid>> Can't tell if you can put a NON-requirement to a requirement document :) but if you think it provides clarity, then fine. I added a little bit more guidance at the end, up to you whether you want to use it. To me, this all seems like responding to "what if" scenarios, which if we got to far into this mode, could cause the number of requirements to explode. However, perhaps this is one distinction we should emphasize. > > 5.5.2 Context updates SHOULD complete before the context is needed at > the receiving AR. > > Madjid>> How do we know when the context is needed at the > receiving AR? > I find this more like a design guidance than a requirement. Well, a requirement is a design guide. The wg has debated this extensively, Madjid, with, if I recall, no better resolution then the current wording. If you have a recommendation for wording of a requirement that would identify when CT should be complete, please submit it. Madjid>> "Context transfer must not add to the length of the disruption of the feature, for which it is transfering states for, otherwise the use of context transfer defeats its purpose" > The following > text > can with some exceptions added to the explanation of 5.5.2. > > The context at the AR actually supporting an MN's traffic will > change with time. For example, the MN may initiate new > microflow(s), > or discontinue existing microflows. > Madjid>> the above is good. > > Any change of context at the > supporting AR must be replicated at those ARs that have already > received context for that MN. > Madjid>> MUSt is too strong. 5.5.1 is SHOULD, so should this one be > (sorry for too many shoulds :)) There are ways to avoid having to do > this through CT. Hmmm. Could you expand on the "many ways"? I am curious. Madjid>> well I didn't say "many". If the change of context is resulted from an outside event by an outside trigger, the same information may be sent to the new AR to update the context there instead. As for MUST versus SHOULD: I think there is an issue here with interpretation. My interpretation is that CT MUST ATTEMPT to convey context changes at the ARs. That is, CT must provide the mechanisms to transfer context changes to all ARs that received the context originally. I agree that it is too extreme to state that the changes MUST make it to all ARs. Perhaps some rewording is needed. Yes, I think you covered it yourself in your new formulation. > However, context changes are often driven by events > external to the > sending AR, and will thus be asynchronous to any on-going context > updates. Given that context transfers will take a finite amount of > time to complete, it is possible that a change in context > cannot be > conveyed in time to the destination AR to avoid any impact > on a possible > handover. The objective of the context transfer design > must be to make > the likelihood of this delay, and its magnitude, as low as > possible. > > Madjid>> The above is good. > > This is not perfect: the desire to avoid a requirement for an > extreme degree > > of synchronization is only implied by the soft "SHOULD" in 5.5.2. > Regards, > Gary > > > > -----Original Message----- Thanks for the response; very useful input. Gary ------_=_NextPart_001_01C22F30.E8701D34 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Seamoby] Proposal on Sync/NoSync Requirement

Madjid:

  I would like to respond to your comments with = a general comment, which hopefully covers much
of the issue. Correct me if this is not the = case.

  The fundamental concern here seems to be over = the scenario where the context changes while a
CT is already in progress. It does not seem to me to = be a difficult task to formulate a requirement
that states that CT will update, but at best, the = granularity of the synchronization will be greater
then the duration of a CT (lots of word smithing = required, perhaps, but doable). As far as I can
discern, the only detrimental effect of sending = context updates to receiving ARs is the protocol overhead.

A receiving AR may always decide that it does not = need to use a context update. It would probably make
this decision when, for example, it was receiving a = handover, and had installed context in preparation for
the arriving flows. In other words, the disruption = of attempting to update the installed context would
be greater then the disruption of not having the = latest context.

Now, dynamic, or state related context updates are a = real problem. There is a big issue as to when to
perform state updates, how often, etc. For example, = if the dynamic context is a packet counter, you
obviously do not want to be updating that context = every time it changes. In our work, we came to
the conclusion that while it was worthwile updated = configuration context when it happened, updating
dynamic context (e.g. state context) was not = pratical, and indeed, transferring of state context only
made sense to attempt just before the receiving AR = needed the context. Again, the assumption here
is that transferring configuration context ahead of = time (e.g. ahead of an actual handover), improves
seamlessness. There seems to be some evidence that = it can.

As I see it, this whole discussion is around, as you = put it, the "NON-requirement" of ensuring that the
CT solution is not driven to meet extreme = synchronization goals. We could take this approach to many
of the requirements - e.g. if I say CT has to be = fast, does that mean pico-second transfer times? Clearly
it doesn't, but we do not have a requirement that = says "CT should be fast, but not too fast" (Note: the
actual requirement doesn't use the word fast - this = is simply a counter example).

Cheers,
Gary
-----Original Message-----
From: Nakhjiri Madjid-MNAKHJI1 [mailto:Madjid.Nakhjiri@moto= rola.com]
Sent: July 18, 2002 17:54
To: Kenward, Gary [WDLN2:AN10:EXCH]; Nakhjiri = Madjid-MNAKHJI1; 'James Kempf'; john.loughney@nokia.com; = seamoby@ietf.org
Subject: RE: [Seamoby] Proposal on Sync/NoSync = Requirement


Gary,
Thanks for your reply. We are getting there. Please = see comments below
 
BR,
 
Madjid
 
<snip>
 > Proposed:
> 5.5 Context Update and Synchronization
> 5.5.1 The context transfer protocol MUST be = capable of supporting the
>       updates to = context information when it changes. 
>
>  Madjid>> Ok, this takes care of the = dynamic context, however, we
Actually, the real concern I have is not for dynamic = context as it is
for changes in the makeup of the traffic for the MN = - i.e. the arrival
and departure of microflows. This would change the = configuration (aka
static) context.
Madjid>> Ok, as I recall the context transfer = deals with a microflow
as a unit. The discussion of arrival and departure = of    microflows is
relevant if you are aggregating multiple microflows, = so maybe this
should be added to the section that talks about = aggregation, otherwise
I think it is hard to avoid the interpretation I = made (dynamic feature context)
> need to be clarify that we are not requiring = the oldAR sends updates
> to context features it has already transmitted = while it is
> transmitting
> context for other features, otherwise CT might = never end.
I absolutely agree with you. 
Madjid>> glad to hear that.
> Since, some folks have brought that up, I want = to make sure that we
>  are not reading that in the requirement. = Updates initiated by oldAR
> should only be based on outside triggers such = as new flow,
> flow terminations
> or messages from central entities...
There seems to be a concern that CT will not be able = to guarantee perfect
synchronization of the configuration and state of = both ARs. My response to
this concern is, of course not, CT was never = intended to do such a think.
This is not distributed computing, it is handover = optimization.
Perhaps a new requirement would help clarify this, = something like:
5.5.x Context transfer SHALL NOT attempt to = guarantee perfect synchronization
of context. The purpose of CT is to improve handover = as best as it can. Given
the complexity and overheads needed to synchronize = distributed state machines,
it is expected that occasionally, the context of the = source and destination
AR will not agree. The CT solution must minimize the = likelihood of this happening  "Addition:
by careful consideration of the rate by which = context will change over time .
5.5.x+1 Context transfer WILL NOT attempt to = mitigate the effects of stale context
        at the = receiving AR.
 Madjid>> Can't tell if you can put a = NON-requirement to a requirement document :)
but if you think it provides clarity, then fine. I = added a little bit more guidance at the end,
up to you whether you want to use it. 

To me, this all seems like responding to "what = if" scenarios, which if we got
to far into this mode, could cause the number of = requirements to explode.
However, perhaps this is one distinction we should = emphasize.
>
> 5.5.2 Context updates SHOULD complete before = the context is needed at
>       the = receiving AR.
>
> Madjid>> How do we know when the context = is needed at the
> receiving AR?
> I find this more like a design guidance than a = requirement.
Well, a requirement is a design guide. The wg has = debated this extensively,
Madjid, with, if I recall, no better resolution then = the current wording.
If you have a recommendation for wording of a = requirement that would identify
when CT should be complete, please submit it.  =
Madjid>> "Context transfer must not add = to the length of the disruption of the feature, for
which it is transfering states for, otherwise the = use of context transfer
defeats its purpose"
> The following
> text
> can with some exceptions added to the = explanation of 5.5.2.
>
>    The context at the AR = actually supporting an MN's traffic will
>    change with time. For = example, the MN may initiate new
> microflow(s),
>    or discontinue existing = microflows.
> Madjid>> the above is good.
>
> Any change of context at the
>    supporting AR must be = replicated at those ARs that have already
>    received context for that MN. =
> Madjid>> MUSt is too strong. 5.5.1 is = SHOULD, so should this one be
> (sorry for too many shoulds :)) There are ways = to avoid having to do
> this through CT.
Hmmm. Could you expand on the "many ways"? = I am curious. 
Madjid>> well I didn't say "many". = If the change of context is resulted
from an outside event by an outside trigger, the = same information
may be sent to the new AR to update the context = there instead.
As for MUST versus SHOULD: I think there is an issue = here with interpretation.
My interpretation is that CT MUST ATTEMPT to convey = context changes at the ARs.
That is, CT must provide the mechanisms to transfer = context changes to all ARs
that received the context originally. I agree that = it is too extreme to state
that the changes MUST make it to all ARs. Perhaps = some rewording is needed.
 Yes, I think you covered it yourself in your = new formulation.
 
>    However, context changes are = often driven by events
> external to the
>    sending AR, and will thus be = asynchronous to any on-going context
>    updates. Given that context = transfers will take a finite amount of
>    time to complete, it is = possible that a change in context
> cannot be
>    conveyed in time to the = destination AR to avoid any impact
> on a possible
>    handover. The objective of = the context transfer design
> must be to make
>    the likelihood of this delay, = and its magnitude, as low as
> possible.
>
> Madjid>> The above is good.
>
> This is not perfect: the desire to avoid a = requirement for an
> extreme degree
>
> of synchronization is only implied by the soft = "SHOULD" in 5.5.2.
> Regards,
> Gary
>
>
> > -----Original Message-----
Thanks for the response; very useful input.
Gary

------_=_NextPart_001_01C22F30.E8701D34-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Fri Jul 19 10:35:50 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09972 for ; Fri, 19 Jul 2002 10:35:46 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA18931 for seamoby-archive@odin.ietf.org; Fri, 19 Jul 2002 10:36:44 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA13308; Fri, 19 Jul 2002 10:31:55 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA13281 for ; Fri, 19 Jul 2002 10:31:52 -0400 (EDT) Received: from zcars04e.ca.nortel.com (zcars04e.nortelnetworks.com [47.129.242.56]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09855 for ; Fri, 19 Jul 2002 10:30:48 -0400 (EDT) Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g6JEV6g12930; Fri, 19 Jul 2002 10:31:06 -0400 (EDT) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 19 Jul 2002 10:31:05 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA4C42@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'Nakhjiri Madjid-MNAKHJI1'" , "'James Kempf'" , john.loughney@nokia.com, seamoby@ietf.org Subject: RE: [Seamoby] Proposal on Sync/NoSync Requirement Date: Fri, 19 Jul 2002 10:31:02 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C22F30.E8701D34" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C22F30.E8701D34 Content-Type: text/plain; charset="iso-8859-1" Madjid: I would like to respond to your comments with a general comment, which hopefully covers much of the issue. Correct me if this is not the case. The fundamental concern here seems to be over the scenario where the context changes while a CT is already in progress. It does not seem to me to be a difficult task to formulate a requirement that states that CT will update, but at best, the granularity of the synchronization will be greater then the duration of a CT (lots of word smithing required, perhaps, but doable). As far as I can discern, the only detrimental effect of sending context updates to receiving ARs is the protocol overhead. A receiving AR may always decide that it does not need to use a context update. It would probably make this decision when, for example, it was receiving a handover, and had installed context in preparation for the arriving flows. In other words, the disruption of attempting to update the installed context would be greater then the disruption of not having the latest context. Now, dynamic, or state related context updates are a real problem. There is a big issue as to when to perform state updates, how often, etc. For example, if the dynamic context is a packet counter, you obviously do not want to be updating that context every time it changes. In our work, we came to the conclusion that while it was worthwile updated configuration context when it happened, updating dynamic context (e.g. state context) was not pratical, and indeed, transferring of state context only made sense to attempt just before the receiving AR needed the context. Again, the assumption here is that transferring configuration context ahead of time (e.g. ahead of an actual handover), improves seamlessness. There seems to be some evidence that it can. As I see it, this whole discussion is around, as you put it, the "NON-requirement" of ensuring that the CT solution is not driven to meet extreme synchronization goals. We could take this approach to many of the requirements - e.g. if I say CT has to be fast, does that mean pico-second transfer times? Clearly it doesn't, but we do not have a requirement that says "CT should be fast, but not too fast" (Note: the actual requirement doesn't use the word fast - this is simply a counter example). Cheers, Gary -----Original Message----- From: Nakhjiri Madjid-MNAKHJI1 [mailto:Madjid.Nakhjiri@motorola.com] Sent: July 18, 2002 17:54 To: Kenward, Gary [WDLN2:AN10:EXCH]; Nakhjiri Madjid-MNAKHJI1; 'James Kempf'; john.loughney@nokia.com; seamoby@ietf.org Subject: RE: [Seamoby] Proposal on Sync/NoSync Requirement Gary, Thanks for your reply. We are getting there. Please see comments below BR, Madjid > Proposed: > 5.5 Context Update and Synchronization > 5.5.1 The context transfer protocol MUST be capable of supporting the > updates to context information when it changes. > > Madjid>> Ok, this takes care of the dynamic context, however, we Actually, the real concern I have is not for dynamic context as it is for changes in the makeup of the traffic for the MN - i.e. the arrival and departure of microflows. This would change the configuration (aka static) context. Madjid>> Ok, as I recall the context transfer deals with a microflow as a unit. The discussion of arrival and departure of microflows is relevant if you are aggregating multiple microflows, so maybe this should be added to the section that talks about aggregation, otherwise I think it is hard to avoid the interpretation I made (dynamic feature context) > need to be clarify that we are not requiring the oldAR sends updates > to context features it has already transmitted while it is > transmitting > context for other features, otherwise CT might never end. I absolutely agree with you. Madjid>> glad to hear that. > Since, some folks have brought that up, I want to make sure that we > are not reading that in the requirement. Updates initiated by oldAR > should only be based on outside triggers such as new flow, > flow terminations > or messages from central entities... There seems to be a concern that CT will not be able to guarantee perfect synchronization of the configuration and state of both ARs. My response to this concern is, of course not, CT was never intended to do such a think. This is not distributed computing, it is handover optimization. Perhaps a new requirement would help clarify this, something like: 5.5.x Context transfer SHALL NOT attempt to guarantee perfect synchronization of context. The purpose of CT is to improve handover as best as it can. Given the complexity and overheads needed to synchronize distributed state machines, it is expected that occasionally, the context of the source and destination AR will not agree. The CT solution must minimize the likelihood of this happening "Addition: by careful consideration of the rate by which context will change over time . 5.5.x+1 Context transfer WILL NOT attempt to mitigate the effects of stale context at the receiving AR. Madjid>> Can't tell if you can put a NON-requirement to a requirement document :) but if you think it provides clarity, then fine. I added a little bit more guidance at the end, up to you whether you want to use it. To me, this all seems like responding to "what if" scenarios, which if we got to far into this mode, could cause the number of requirements to explode. However, perhaps this is one distinction we should emphasize. > > 5.5.2 Context updates SHOULD complete before the context is needed at > the receiving AR. > > Madjid>> How do we know when the context is needed at the > receiving AR? > I find this more like a design guidance than a requirement. Well, a requirement is a design guide. The wg has debated this extensively, Madjid, with, if I recall, no better resolution then the current wording. If you have a recommendation for wording of a requirement that would identify when CT should be complete, please submit it. Madjid>> "Context transfer must not add to the length of the disruption of the feature, for which it is transfering states for, otherwise the use of context transfer defeats its purpose" > The following > text > can with some exceptions added to the explanation of 5.5.2. > > The context at the AR actually supporting an MN's traffic will > change with time. For example, the MN may initiate new > microflow(s), > or discontinue existing microflows. > Madjid>> the above is good. > > Any change of context at the > supporting AR must be replicated at those ARs that have already > received context for that MN. > Madjid>> MUSt is too strong. 5.5.1 is SHOULD, so should this one be > (sorry for too many shoulds :)) There are ways to avoid having to do > this through CT. Hmmm. Could you expand on the "many ways"? I am curious. Madjid>> well I didn't say "many". If the change of context is resulted from an outside event by an outside trigger, the same information may be sent to the new AR to update the context there instead. As for MUST versus SHOULD: I think there is an issue here with interpretation. My interpretation is that CT MUST ATTEMPT to convey context changes at the ARs. That is, CT must provide the mechanisms to transfer context changes to all ARs that received the context originally. I agree that it is too extreme to state that the changes MUST make it to all ARs. Perhaps some rewording is needed. Yes, I think you covered it yourself in your new formulation. > However, context changes are often driven by events > external to the > sending AR, and will thus be asynchronous to any on-going context > updates. Given that context transfers will take a finite amount of > time to complete, it is possible that a change in context > cannot be > conveyed in time to the destination AR to avoid any impact > on a possible > handover. The objective of the context transfer design > must be to make > the likelihood of this delay, and its magnitude, as low as > possible. > > Madjid>> The above is good. > > This is not perfect: the desire to avoid a requirement for an > extreme degree > > of synchronization is only implied by the soft "SHOULD" in 5.5.2. > Regards, > Gary > > > > -----Original Message----- Thanks for the response; very useful input. Gary ------_=_NextPart_001_01C22F30.E8701D34 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Seamoby] Proposal on Sync/NoSync Requirement

Madjid:

  I would like to respond to your comments with = a general comment, which hopefully covers much
of the issue. Correct me if this is not the = case.

  The fundamental concern here seems to be over = the scenario where the context changes while a
CT is already in progress. It does not seem to me to = be a difficult task to formulate a requirement
that states that CT will update, but at best, the = granularity of the synchronization will be greater
then the duration of a CT (lots of word smithing = required, perhaps, but doable). As far as I can
discern, the only detrimental effect of sending = context updates to receiving ARs is the protocol overhead.

A receiving AR may always decide that it does not = need to use a context update. It would probably make
this decision when, for example, it was receiving a = handover, and had installed context in preparation for
the arriving flows. In other words, the disruption = of attempting to update the installed context would
be greater then the disruption of not having the = latest context.

Now, dynamic, or state related context updates are a = real problem. There is a big issue as to when to
perform state updates, how often, etc. For example, = if the dynamic context is a packet counter, you
obviously do not want to be updating that context = every time it changes. In our work, we came to
the conclusion that while it was worthwile updated = configuration context when it happened, updating
dynamic context (e.g. state context) was not = pratical, and indeed, transferring of state context only
made sense to attempt just before the receiving AR = needed the context. Again, the assumption here
is that transferring configuration context ahead of = time (e.g. ahead of an actual handover), improves
seamlessness. There seems to be some evidence that = it can.

As I see it, this whole discussion is around, as you = put it, the "NON-requirement" of ensuring that the
CT solution is not driven to meet extreme = synchronization goals. We could take this approach to many
of the requirements - e.g. if I say CT has to be = fast, does that mean pico-second transfer times? Clearly
it doesn't, but we do not have a requirement that = says "CT should be fast, but not too fast" (Note: the
actual requirement doesn't use the word fast - this = is simply a counter example).

Cheers,
Gary
-----Original Message-----
From: Nakhjiri Madjid-MNAKHJI1 [mailto:Madjid.Nakhjiri@moto= rola.com]
Sent: July 18, 2002 17:54
To: Kenward, Gary [WDLN2:AN10:EXCH]; Nakhjiri = Madjid-MNAKHJI1; 'James Kempf'; john.loughney@nokia.com; = seamoby@ietf.org
Subject: RE: [Seamoby] Proposal on Sync/NoSync = Requirement


Gary,
Thanks for your reply. We are getting there. Please = see comments below
 
BR,
 
Madjid
 
<snip>
 > Proposed:
> 5.5 Context Update and Synchronization
> 5.5.1 The context transfer protocol MUST be = capable of supporting the
>       updates to = context information when it changes. 
>
>  Madjid>> Ok, this takes care of the = dynamic context, however, we
Actually, the real concern I have is not for dynamic = context as it is
for changes in the makeup of the traffic for the MN = - i.e. the arrival
and departure of microflows. This would change the = configuration (aka
static) context.
Madjid>> Ok, as I recall the context transfer = deals with a microflow
as a unit. The discussion of arrival and departure = of    microflows is
relevant if you are aggregating multiple microflows, = so maybe this
should be added to the section that talks about = aggregation, otherwise
I think it is hard to avoid the interpretation I = made (dynamic feature context)
> need to be clarify that we are not requiring = the oldAR sends updates
> to context features it has already transmitted = while it is
> transmitting
> context for other features, otherwise CT might = never end.
I absolutely agree with you. 
Madjid>> glad to hear that.
> Since, some folks have brought that up, I want = to make sure that we
>  are not reading that in the requirement. = Updates initiated by oldAR
> should only be based on outside triggers such = as new flow,
> flow terminations
> or messages from central entities...
There seems to be a concern that CT will not be able = to guarantee perfect
synchronization of the configuration and state of = both ARs. My response to
this concern is, of course not, CT was never = intended to do such a think.
This is not distributed computing, it is handover = optimization.
Perhaps a new requirement would help clarify this, = something like:
5.5.x Context transfer SHALL NOT attempt to = guarantee perfect synchronization
of context. The purpose of CT is to improve handover = as best as it can. Given
the complexity and overheads needed to synchronize = distributed state machines,
it is expected that occasionally, the context of the = source and destination
AR will not agree. The CT solution must minimize the = likelihood of this happening  "Addition:
by careful consideration of the rate by which = context will change over time .
5.5.x+1 Context transfer WILL NOT attempt to = mitigate the effects of stale context
        at the = receiving AR.
 Madjid>> Can't tell if you can put a = NON-requirement to a requirement document :)
but if you think it provides clarity, then fine. I = added a little bit more guidance at the end,
up to you whether you want to use it. 

To me, this all seems like responding to "what = if" scenarios, which if we got
to far into this mode, could cause the number of = requirements to explode.
However, perhaps this is one distinction we should = emphasize.
>
> 5.5.2 Context updates SHOULD complete before = the context is needed at
>       the = receiving AR.
>
> Madjid>> How do we know when the context = is needed at the
> receiving AR?
> I find this more like a design guidance than a = requirement.
Well, a requirement is a design guide. The wg has = debated this extensively,
Madjid, with, if I recall, no better resolution then = the current wording.
If you have a recommendation for wording of a = requirement that would identify
when CT should be complete, please submit it.  =
Madjid>> "Context transfer must not add = to the length of the disruption of the feature, for
which it is transfering states for, otherwise the = use of context transfer
defeats its purpose"
> The following
> text
> can with some exceptions added to the = explanation of 5.5.2.
>
>    The context at the AR = actually supporting an MN's traffic will
>    change with time. For = example, the MN may initiate new
> microflow(s),
>    or discontinue existing = microflows.
> Madjid>> the above is good.
>
> Any change of context at the
>    supporting AR must be = replicated at those ARs that have already
>    received context for that MN. =
> Madjid>> MUSt is too strong. 5.5.1 is = SHOULD, so should this one be
> (sorry for too many shoulds :)) There are ways = to avoid having to do
> this through CT.
Hmmm. Could you expand on the "many ways"? = I am curious. 
Madjid>> well I didn't say "many". = If the change of context is resulted
from an outside event by an outside trigger, the = same information
may be sent to the new AR to update the context = there instead.
As for MUST versus SHOULD: I think there is an issue = here with interpretation.
My interpretation is that CT MUST ATTEMPT to convey = context changes at the ARs.
That is, CT must provide the mechanisms to transfer = context changes to all ARs
that received the context originally. I agree that = it is too extreme to state
that the changes MUST make it to all ARs. Perhaps = some rewording is needed.
 Yes, I think you covered it yourself in your = new formulation.
 
>    However, context changes are = often driven by events
> external to the
>    sending AR, and will thus be = asynchronous to any on-going context
>    updates. Given that context = transfers will take a finite amount of
>    time to complete, it is = possible that a change in context
> cannot be
>    conveyed in time to the = destination AR to avoid any impact
> on a possible
>    handover. The objective of = the context transfer design
> must be to make
>    the likelihood of this delay, = and its magnitude, as low as
> possible.
>
> Madjid>> The above is good.
>
> This is not perfect: the desire to avoid a = requirement for an
> extreme degree
>
> of synchronization is only implied by the soft = "SHOULD" in 5.5.2.
> Regards,
> Gary
>
>
> > -----Original Message-----
Thanks for the response; very useful input.
Gary

------_=_NextPart_001_01C22F30.E8701D34-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Fri Jul 19 10:40:09 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10186 for ; Fri, 19 Jul 2002 10:40:09 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA21160; Fri, 19 Jul 2002 10:38:04 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA21076 for ; Fri, 19 Jul 2002 10:38:00 -0400 (EDT) Received: from zcars04f.ca.nortel.com (zcars04f.nortelnetworks.com [47.129.242.57]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10037 for ; Fri, 19 Jul 2002 10:37:00 -0400 (EDT) Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04f.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g6JEbHU06500; Fri, 19 Jul 2002 10:37:17 -0400 (EDT) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 19 Jul 2002 10:37:16 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA4C44@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'James Kempf'" , pcalhoun@bstormnetworks.com, Nakhjiri Madjid-MNAKHJI1 , seamoby@ietf.org Cc: mankin@psg.com Subject: RE: [Seamoby] Section 5.2 in CT Requirements Date: Fri, 19 Jul 2002 10:37:16 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C22F31.BF120F50" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C22F31.BF120F50 Content-Type: text/plain; charset="iso-8859-1" So into the breach, once more we go.... > -----Original Message----- > From: James Kempf [mailto:kempf@docomolabs-usa.com] > Sent: July 18, 2002 19:18 > To: pcalhoun@bstormnetworks.com; Nakhjiri Madjid-MNAKHJI1; > seamoby@ietf.org > Cc: mankin@psg.com > Subject: Re: [Seamoby] Section 5.2 in CT Requirements > > > > I know that there was concern by the IESG on this very > topic, and the idea of > > the above text was a compromise with the area director, who > was going to > > initiate a discussion with the transport directorate. > Unfortunately, this > > never occured, and the text remained. Allison had suggested > that we continue > > with the non-transport discussions and that this topic will > resurface again > > in the future. > > > > The question is whether this can occur after the document > can be published > > (perhaps without the section). > > > > Harald made a comment in the IESG Plenary on Wed. nite about > working groups > submitting documents with "to be defined" to the IESG. This > document qualifies, > IMHO. > > jak > > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > ------_=_NextPart_001_01C22F31.BF120F50 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Seamoby] Section 5.2 in CT Requirements

So into the breach, once more we go....

> -----Original Message-----
> From: James Kempf [mailto:kempf@docomolabs-usa.com= ]
> Sent: July 18, 2002 19:18
> To: pcalhoun@bstormnetworks.com; Nakhjiri = Madjid-MNAKHJI1;
> seamoby@ietf.org
> Cc: mankin@psg.com
> Subject: Re: [Seamoby] Section 5.2 in CT = Requirements
>
>
> > I know that there was concern by the IESG = on this very
> topic, and the idea of
> > the above text was a compromise with the = area director, who
> was going to
> > initiate a discussion with the transport = directorate.
> Unfortunately, this
> > never occured, and the text remained. = Allison had suggested
> that we continue
> > with the non-transport discussions and = that this topic will
> resurface again
> > in the future.
> >
> > The question is whether this can occur = after the document
> can be published
> > (perhaps without the section).
> >
>
> Harald made a comment in the IESG Plenary on = Wed. nite about
> working groups
> submitting documents with "to be = defined" to the IESG. This
> document qualifies,
> IMHO.
>
>          = ;   jak
>
>
> = _______________________________________________
> Seamoby mailing list
> Seamoby@ietf.org
> https://www1.ietf.org/mailman/listinfo/seamoby
>

------_=_NextPart_001_01C22F31.BF120F50-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Fri Jul 19 10:40:11 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10200 for ; Fri, 19 Jul 2002 10:40:10 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA25992 for seamoby-archive@odin.ietf.org; Fri, 19 Jul 2002 10:41:09 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA21160; Fri, 19 Jul 2002 10:38:04 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA21076 for ; Fri, 19 Jul 2002 10:38:00 -0400 (EDT) Received: from zcars04f.ca.nortel.com (zcars04f.nortelnetworks.com [47.129.242.57]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10037 for ; Fri, 19 Jul 2002 10:37:00 -0400 (EDT) Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04f.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g6JEbHU06500; Fri, 19 Jul 2002 10:37:17 -0400 (EDT) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 19 Jul 2002 10:37:16 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA4C44@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'James Kempf'" , pcalhoun@bstormnetworks.com, Nakhjiri Madjid-MNAKHJI1 , seamoby@ietf.org Cc: mankin@psg.com Subject: RE: [Seamoby] Section 5.2 in CT Requirements Date: Fri, 19 Jul 2002 10:37:16 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C22F31.BF120F50" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C22F31.BF120F50 Content-Type: text/plain; charset="iso-8859-1" So into the breach, once more we go.... > -----Original Message----- > From: James Kempf [mailto:kempf@docomolabs-usa.com] > Sent: July 18, 2002 19:18 > To: pcalhoun@bstormnetworks.com; Nakhjiri Madjid-MNAKHJI1; > seamoby@ietf.org > Cc: mankin@psg.com > Subject: Re: [Seamoby] Section 5.2 in CT Requirements > > > > I know that there was concern by the IESG on this very > topic, and the idea of > > the above text was a compromise with the area director, who > was going to > > initiate a discussion with the transport directorate. > Unfortunately, this > > never occured, and the text remained. Allison had suggested > that we continue > > with the non-transport discussions and that this topic will > resurface again > > in the future. > > > > The question is whether this can occur after the document > can be published > > (perhaps without the section). > > > > Harald made a comment in the IESG Plenary on Wed. nite about > working groups > submitting documents with "to be defined" to the IESG. This > document qualifies, > IMHO. > > jak > > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > ------_=_NextPart_001_01C22F31.BF120F50 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Seamoby] Section 5.2 in CT Requirements

So into the breach, once more we go....

> -----Original Message-----
> From: James Kempf [mailto:kempf@docomolabs-usa.com= ]
> Sent: July 18, 2002 19:18
> To: pcalhoun@bstormnetworks.com; Nakhjiri = Madjid-MNAKHJI1;
> seamoby@ietf.org
> Cc: mankin@psg.com
> Subject: Re: [Seamoby] Section 5.2 in CT = Requirements
>
>
> > I know that there was concern by the IESG = on this very
> topic, and the idea of
> > the above text was a compromise with the = area director, who
> was going to
> > initiate a discussion with the transport = directorate.
> Unfortunately, this
> > never occured, and the text remained. = Allison had suggested
> that we continue
> > with the non-transport discussions and = that this topic will
> resurface again
> > in the future.
> >
> > The question is whether this can occur = after the document
> can be published
> > (perhaps without the section).
> >
>
> Harald made a comment in the IESG Plenary on = Wed. nite about
> working groups
> submitting documents with "to be = defined" to the IESG. This
> document qualifies,
> IMHO.
>
>          = ;   jak
>
>
> = _______________________________________________
> Seamoby mailing list
> Seamoby@ietf.org
> https://www1.ietf.org/mailman/listinfo/seamoby
>

------_=_NextPart_001_01C22F31.BF120F50-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Fri Jul 19 10:49:17 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10428 for ; Fri, 19 Jul 2002 10:49:17 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA10605; Fri, 19 Jul 2002 10:48:19 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA10508 for ; Fri, 19 Jul 2002 10:48:16 -0400 (EDT) Received: from zcars04f.ca.nortel.com (zcars04f.nortelnetworks.com [47.129.242.57]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10384 for ; Fri, 19 Jul 2002 10:47:16 -0400 (EDT) Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04f.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g6JElaU07449; Fri, 19 Jul 2002 10:47:36 -0400 (EDT) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 19 Jul 2002 10:47:36 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA4C45@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'James Kempf'" , "Pat R. Calhoun" , Nakhjiri Madjid-MNAKHJI1 , "'seamoby@ietf.org'" Cc: mankin@psg.com Subject: RE: [Seamoby] Section 5.2 in CT Requirements Date: Fri, 19 Jul 2002 10:47:35 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C22F33.38380C30" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C22F33.38380C30 Content-Type: text/plain; charset="iso-8859-1" James: Frankly this discussion is getting silly - he said, she said. You may speculate forever what did or did not transpire, but I recall clearly the discussion, which included Allison, and the decision was to defer the work on a transport requirements until we started working on a solution. Note well, that this decision was made in order to get the requirements completed, which is the same goal you strive for. So, let's move on. If the IESG has commented that this section is inappropriate, or if the wg believes that it is inappropriate, then let's change it. And so, we have three choices: 1. Leave the section as is and see if the IESG buys the logic or not. (I personally think the IESG is smart enough to realize the complexity of the problem and the cart and horse situation we are dealing with here). 2. Remove the section entirely (which I don't think will fool anyone) 3. Attempt to resolve the issue (The last debate went on for, oh, about six months) If this is truly up to the wg, then perhaps you should as the wg which option is preferred. Gary > -----Original Message----- > From: James Kempf [mailto:kempf@docomolabs-usa.com] > Sent: July 19, 2002 09:04 > To: Pat R. Calhoun; Nakhjiri Madjid-MNAKHJI1; seamoby@ietf.org > Cc: mankin@psg.com > Subject: Re: [Seamoby] Section 5.2 in CT Requirements > > > Pat, > > > I know that there was concern by the IESG on this very > topic, and the idea of > > the above text was a compromise with the area director, who > was going to > > initiate a discussion with the transport directorate. > Unfortunately, this > > never occured, and the text remained. Allison had suggested > that we continue > > with the non-transport discussions and that this topic will > resurface again > > in the future. > > > > I don't think Allison intended that the document go to the > IESG with this text > in it, though I have not had an opportunity to speak with her > about it. But > ultimately > she is not responsible for the working group documents, that is the > working group's responsiblity. We should have pulled that > text out before we > sent it to the IESG, and, ideally, had something to replace > it. If, at that > point, the IESG had a technical disagreement with our > proposed requirement, > then we would have heard back. > > > The question is whether this can occur after the document > can be published > > (perhaps without the section). > > > > I think we at least have to propose a requirement, which is > what the text I sent > was intended to do. > > jak > > > > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > ------_=_NextPart_001_01C22F33.38380C30 Content-Type: text/html; charset="iso-8859-1" RE: [Seamoby] Section 5.2 in CT Requirements

James:

 Frankly this discussion is getting silly - he said, she said.
You may speculate forever what did or did not transpire, but I recall
clearly the discussion, which included Allison, and the decision was
to defer the work on a transport requirements until we started working
on a solution. Note well, that this decision was made in order to get
the requirements completed, which is the same goal you strive for.

 So, let's move on. If the IESG has commented that this section is
inappropriate, or if the wg believes that it is inappropriate, then
let's change it.

 And so, we have three choices:

   1. Leave the section as is and see if the IESG buys the logic or not.
      (I personally think the IESG is smart enough to realize the complexity
       of the problem and the cart and horse situation we are dealing with
       here).

   2. Remove the section entirely
      (which I don't think will fool anyone)

   3. Attempt to resolve the issue
      (The last debate went on for, oh, about six months)

If this is truly up to the wg, then perhaps you should as the wg which option
is preferred.

Gary

> -----Original Message-----
> From: James Kempf [mailto:kempf@docomolabs-usa.com]
> Sent: July 19, 2002 09:04
> To: Pat R. Calhoun; Nakhjiri Madjid-MNAKHJI1; seamoby@ietf.org
> Cc: mankin@psg.com
> Subject: Re: [Seamoby] Section 5.2 in CT Requirements
>
>
> Pat,
>
> > I know that there was concern by the IESG on this very
> topic, and the idea of
> > the above text was a compromise with the area director, who
> was going to
> > initiate a discussion with the transport directorate.
> Unfortunately, this
> > never occured, and the text remained. Allison had suggested
> that we continue
> > with the non-transport discussions and that this topic will
> resurface again
> > in the future.
> >
>
> I don't think Allison intended that the document go to the
> IESG with this text
> in it, though I have not had an opportunity to speak with her
> about it. But
> ultimately
> she is not responsible for the working group documents, that is the
> working group's responsiblity. We should have pulled that
> text out before we
> sent it to the IESG, and, ideally, had something to replace
> it. If, at that
> point, the IESG had a technical disagreement with our
> proposed requirement,
> then we would have heard back.
>
> > The question is whether this can occur after the document
> can be published
> > (perhaps without the section).
> >
>
> I think we at least have to propose a requirement, which is
> what the text I sent
> was intended to do.
>
>             jak
>
>
>
>
> _______________________________________________
> Seamoby mailing list
> Seamoby@ietf.org
> https://www1.ietf.org/mailman/listinfo/seamoby
>

------_=_NextPart_001_01C22F33.38380C30-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Fri Jul 19 10:49:18 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10441 for ; Fri, 19 Jul 2002 10:49:18 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA15143 for seamoby-archive@odin.ietf.org; Fri, 19 Jul 2002 10:50:16 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA10605; Fri, 19 Jul 2002 10:48:19 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA10508 for ; Fri, 19 Jul 2002 10:48:16 -0400 (EDT) Received: from zcars04f.ca.nortel.com (zcars04f.nortelnetworks.com [47.129.242.57]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10384 for ; Fri, 19 Jul 2002 10:47:16 -0400 (EDT) Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04f.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g6JElaU07449; Fri, 19 Jul 2002 10:47:36 -0400 (EDT) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 19 Jul 2002 10:47:36 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA4C45@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'James Kempf'" , "Pat R. Calhoun" , Nakhjiri Madjid-MNAKHJI1 , "'seamoby@ietf.org'" Cc: mankin@psg.com Subject: RE: [Seamoby] Section 5.2 in CT Requirements Date: Fri, 19 Jul 2002 10:47:35 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C22F33.38380C30" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C22F33.38380C30 Content-Type: text/plain; charset="iso-8859-1" James: Frankly this discussion is getting silly - he said, she said. You may speculate forever what did or did not transpire, but I recall clearly the discussion, which included Allison, and the decision was to defer the work on a transport requirements until we started working on a solution. Note well, that this decision was made in order to get the requirements completed, which is the same goal you strive for. So, let's move on. If the IESG has commented that this section is inappropriate, or if the wg believes that it is inappropriate, then let's change it. And so, we have three choices: 1. Leave the section as is and see if the IESG buys the logic or not. (I personally think the IESG is smart enough to realize the complexity of the problem and the cart and horse situation we are dealing with here). 2. Remove the section entirely (which I don't think will fool anyone) 3. Attempt to resolve the issue (The last debate went on for, oh, about six months) If this is truly up to the wg, then perhaps you should as the wg which option is preferred. Gary > -----Original Message----- > From: James Kempf [mailto:kempf@docomolabs-usa.com] > Sent: July 19, 2002 09:04 > To: Pat R. Calhoun; Nakhjiri Madjid-MNAKHJI1; seamoby@ietf.org > Cc: mankin@psg.com > Subject: Re: [Seamoby] Section 5.2 in CT Requirements > > > Pat, > > > I know that there was concern by the IESG on this very > topic, and the idea of > > the above text was a compromise with the area director, who > was going to > > initiate a discussion with the transport directorate. > Unfortunately, this > > never occured, and the text remained. Allison had suggested > that we continue > > with the non-transport discussions and that this topic will > resurface again > > in the future. > > > > I don't think Allison intended that the document go to the > IESG with this text > in it, though I have not had an opportunity to speak with her > about it. But > ultimately > she is not responsible for the working group documents, that is the > working group's responsiblity. We should have pulled that > text out before we > sent it to the IESG, and, ideally, had something to replace > it. If, at that > point, the IESG had a technical disagreement with our > proposed requirement, > then we would have heard back. > > > The question is whether this can occur after the document > can be published > > (perhaps without the section). > > > > I think we at least have to propose a requirement, which is > what the text I sent > was intended to do. > > jak > > > > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > ------_=_NextPart_001_01C22F33.38380C30 Content-Type: text/html; charset="iso-8859-1" RE: [Seamoby] Section 5.2 in CT Requirements

James:

 Frankly this discussion is getting silly - he said, she said.
You may speculate forever what did or did not transpire, but I recall
clearly the discussion, which included Allison, and the decision was
to defer the work on a transport requirements until we started working
on a solution. Note well, that this decision was made in order to get
the requirements completed, which is the same goal you strive for.

 So, let's move on. If the IESG has commented that this section is
inappropriate, or if the wg believes that it is inappropriate, then
let's change it.

 And so, we have three choices:

   1. Leave the section as is and see if the IESG buys the logic or not.
      (I personally think the IESG is smart enough to realize the complexity
       of the problem and the cart and horse situation we are dealing with
       here).

   2. Remove the section entirely
      (which I don't think will fool anyone)

   3. Attempt to resolve the issue
      (The last debate went on for, oh, about six months)

If this is truly up to the wg, then perhaps you should as the wg which option
is preferred.

Gary

> -----Original Message-----
> From: James Kempf [mailto:kempf@docomolabs-usa.com]
> Sent: July 19, 2002 09:04
> To: Pat R. Calhoun; Nakhjiri Madjid-MNAKHJI1; seamoby@ietf.org
> Cc: mankin@psg.com
> Subject: Re: [Seamoby] Section 5.2 in CT Requirements
>
>
> Pat,
>
> > I know that there was concern by the IESG on this very
> topic, and the idea of
> > the above text was a compromise with the area director, who
> was going to
> > initiate a discussion with the transport directorate.
> Unfortunately, this
> > never occured, and the text remained. Allison had suggested
> that we continue
> > with the non-transport discussions and that this topic will
> resurface again
> > in the future.
> >
>
> I don't think Allison intended that the document go to the
> IESG with this text
> in it, though I have not had an opportunity to speak with her
> about it. But
> ultimately
> she is not responsible for the working group documents, that is the
> working group's responsiblity. We should have pulled that
> text out before we
> sent it to the IESG, and, ideally, had something to replace
> it. If, at that
> point, the IESG had a technical disagreement with our
> proposed requirement,
> then we would have heard back.
>
> > The question is whether this can occur after the document
> can be published
> > (perhaps without the section).
> >
>
> I think we at least have to propose a requirement, which is
> what the text I sent
> was intended to do.
>
>             jak
>
>
>
>
> _______________________________________________
> Seamoby mailing list
> Seamoby@ietf.org
> https://www1.ietf.org/mailman/listinfo/seamoby
>

------_=_NextPart_001_01C22F33.38380C30-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Fri Jul 19 10:53:45 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10531 for ; Fri, 19 Jul 2002 10:53:45 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA19617; Fri, 19 Jul 2002 10:52:05 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA19328 for ; Fri, 19 Jul 2002 10:51:58 -0400 (EDT) Received: from zcars04f.ca.nortel.com (zcars04f.nortelnetworks.com [47.129.242.57]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10502 for ; Fri, 19 Jul 2002 10:50:59 -0400 (EDT) Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04f.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g6JEpJU07842; Fri, 19 Jul 2002 10:51:19 -0400 (EDT) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 19 Jul 2002 10:51:19 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA4C46@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'James Kempf'" , Nakhjiri Madjid-MNAKHJI1 , seamoby@ietf.org Subject: RE: [Seamoby] Proposal on Sync/NoSync Requirement Date: Fri, 19 Jul 2002 10:51:18 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C22F33.47107094" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C22F33.47107094 Content-Type: text/plain; charset="iso-8859-1" James: So you are proposing now that there are also feature specific CT protocols? If this is true, and we follow your argument, the we need to revisit all the attributes stated for CT: reliability, timeliness, etc., etc. to determine what capabilities should be common, and what capabilities should be feature specific. As far as updates go, I think it is a common capability. Gary > -----Original Message----- > From: James Kempf [mailto:kempf@docomolabs-usa.com] > Sent: July 19, 2002 09:05 > To: Nakhjiri Madjid-MNAKHJI1; seamoby@ietf.org > Subject: Re: [Seamoby] Proposal on Sync/NoSync Requirement > > > Madjid, > > > > Don't know if we can use NEED Not (certainly fits for the > first SHOULD NOT, > since > > that one sounds like we are advising against it). > > We should (SHOULD? :-) use RFC language. > > > How would you allow particular features get synch service, > if there is no > inbuild > > mechanisms in CT? > > Because the CT protocol would be just a container format that > could be reused by > many different feature specific protocols. For example, one > could use the CT > container to define an option for use along with handover > signaling to transfer > header compression context. Or, one could use SCTP to > transfer security, QoS, > and AAA context not requiring any synchronization with the > handover signaling. > The latter would require a separate protocol description for > how the container > format is used with the particular transport. For most > protocols, the two are > bundled, but they are conceptually separate and here I can > see reasons for > separating them. > > > > > I think we can talk about synchronization when there are > two copies at > > two different places. I think the solutions should > seriously avoid this, > > as we did in our proposal. Care should be taken so that you > don't have to > > update a context at both oldAR and newAR. I think as you > said for header > compression > > context, you should have the context updated only at one > location and when > > it is only at one location, how can we call it synchronization? > > > > Because it is synchronized with an external event, namely > handover. With context > that is not sync sensitive there is no requirement for > synchronization with > handover because the change in routing doesn't invalidate the > context on the old > router. Conversely, if the non-sync sensitive context is sent > a bit early, there > will similarly not be a problem. > > This is not to state that the non-sync sensitive context > isn't dynamic, just > that the event of handover doesn't invalidate it per se. > > > > > > You would on the other hand get problem with dynamic context, if > > some context that you sent over, gets lost or corrupted. > Once this happen > > then, you can see whether the context has changed (in which > case you need a > refresh) > > or not (you only need a retx). > > > > Dynamic context means that it is changing as the mobile's > traffic goes through > the router, right? So I view that as requiring > synchronization with an external > event, namely handover. Something like accounting information > would qualify, as > well as header compression state. On the other hand, a user's > SLA would not, > because handover wouldn't invalidate it. > > jak > > > > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > ------_=_NextPart_001_01C22F33.47107094 Content-Type: text/html; charset="iso-8859-1" RE: [Seamoby] Proposal on Sync/NoSync Requirement

James:

 So you are proposing now that there are also feature specific
CT protocols? If this is true, and we follow your argument,
the we need to revisit all the attributes stated for CT: reliability,
timeliness, etc., etc. to determine what capabilities should be
common, and what capabilities should be feature specific.

 As far as updates go, I think it is a common capability.

Gary

> -----Original Message-----
> From: James Kempf [mailto:kempf@docomolabs-usa.com]
> Sent: July 19, 2002 09:05
> To: Nakhjiri Madjid-MNAKHJI1; seamoby@ietf.org
> Subject: Re: [Seamoby] Proposal on Sync/NoSync Requirement
>
>
> Madjid,
>
>
> > Don't know if we can use NEED Not (certainly fits for the
> first SHOULD NOT,
> since
> > that one sounds like we are advising against it).
>
> We should (SHOULD? :-) use RFC language.
>
> > How would you allow particular features get synch service,
> if there is no
> inbuild
> > mechanisms in CT?
>
> Because the CT protocol would be just a container format that
> could be reused by
> many different feature specific protocols. For example, one
> could use the CT
> container to define an option for use along with handover
> signaling to transfer
> header compression context. Or, one could use SCTP to
> transfer security, QoS,
> and AAA context not requiring any synchronization with the
> handover signaling.
> The latter would require a separate protocol description for
> how the container
> format is used with the particular transport. For most
> protocols, the two are
> bundled, but they are conceptually separate and here I can
> see reasons for
> separating them.
>
> >
> > I think we can talk about synchronization when there are
> two copies at
> > two different places. I think the solutions should
> seriously avoid this,
> > as we did in our proposal. Care should be taken so that you
> don't have to
> > update a context at both oldAR and newAR. I think as you
> said for header
> compression
> > context, you should have the context updated only at one
> location and when
> > it is only at one location, how can we call it synchronization?
> >
>
> Because it is synchronized with an external event, namely
> handover. With context
> that is not sync sensitive  there is no requirement for
> synchronization with
> handover because the change in routing doesn't invalidate the
> context on the old
> router. Conversely, if the non-sync sensitive context is sent
> a bit early, there
> will similarly not be a problem.
>
> This is not to state that the non-sync sensitive context
> isn't dynamic, just
> that the event of handover doesn't invalidate it per se.
>
>
> >
> > You would on the other hand get problem with dynamic context, if
> > some context that you sent over, gets lost or corrupted.
> Once this happen
> > then, you can see whether the context has changed (in which
> case you need a
> refresh)
> > or not (you only need a retx).
> >
>
> Dynamic context means that it is changing as the mobile's
> traffic goes through
> the router, right? So I view that as requiring
> synchronization with an external
> event, namely handover. Something like accounting information
> would qualify, as
> well as header compression state. On the other hand, a user's
> SLA would not,
> because handover wouldn't invalidate it.
>
>                 jak
>
>
>
>
> _______________________________________________
> Seamoby mailing list
> Seamoby@ietf.org
> https://www1.ietf.org/mailman/listinfo/seamoby
>

------_=_NextPart_001_01C22F33.47107094-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Fri Jul 19 10:53:46 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10544 for ; Fri, 19 Jul 2002 10:53:46 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA26762 for seamoby-archive@odin.ietf.org; Fri, 19 Jul 2002 10:54:45 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA19617; Fri, 19 Jul 2002 10:52:05 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA19328 for ; Fri, 19 Jul 2002 10:51:58 -0400 (EDT) Received: from zcars04f.ca.nortel.com (zcars04f.nortelnetworks.com [47.129.242.57]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10502 for ; Fri, 19 Jul 2002 10:50:59 -0400 (EDT) Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04f.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g6JEpJU07842; Fri, 19 Jul 2002 10:51:19 -0400 (EDT) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 19 Jul 2002 10:51:19 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA4C46@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'James Kempf'" , Nakhjiri Madjid-MNAKHJI1 , seamoby@ietf.org Subject: RE: [Seamoby] Proposal on Sync/NoSync Requirement Date: Fri, 19 Jul 2002 10:51:18 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C22F33.47107094" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C22F33.47107094 Content-Type: text/plain; charset="iso-8859-1" James: So you are proposing now that there are also feature specific CT protocols? If this is true, and we follow your argument, the we need to revisit all the attributes stated for CT: reliability, timeliness, etc., etc. to determine what capabilities should be common, and what capabilities should be feature specific. As far as updates go, I think it is a common capability. Gary > -----Original Message----- > From: James Kempf [mailto:kempf@docomolabs-usa.com] > Sent: July 19, 2002 09:05 > To: Nakhjiri Madjid-MNAKHJI1; seamoby@ietf.org > Subject: Re: [Seamoby] Proposal on Sync/NoSync Requirement > > > Madjid, > > > > Don't know if we can use NEED Not (certainly fits for the > first SHOULD NOT, > since > > that one sounds like we are advising against it). > > We should (SHOULD? :-) use RFC language. > > > How would you allow particular features get synch service, > if there is no > inbuild > > mechanisms in CT? > > Because the CT protocol would be just a container format that > could be reused by > many different feature specific protocols. For example, one > could use the CT > container to define an option for use along with handover > signaling to transfer > header compression context. Or, one could use SCTP to > transfer security, QoS, > and AAA context not requiring any synchronization with the > handover signaling. > The latter would require a separate protocol description for > how the container > format is used with the particular transport. For most > protocols, the two are > bundled, but they are conceptually separate and here I can > see reasons for > separating them. > > > > > I think we can talk about synchronization when there are > two copies at > > two different places. I think the solutions should > seriously avoid this, > > as we did in our proposal. Care should be taken so that you > don't have to > > update a context at both oldAR and newAR. I think as you > said for header > compression > > context, you should have the context updated only at one > location and when > > it is only at one location, how can we call it synchronization? > > > > Because it is synchronized with an external event, namely > handover. With context > that is not sync sensitive there is no requirement for > synchronization with > handover because the change in routing doesn't invalidate the > context on the old > router. Conversely, if the non-sync sensitive context is sent > a bit early, there > will similarly not be a problem. > > This is not to state that the non-sync sensitive context > isn't dynamic, just > that the event of handover doesn't invalidate it per se. > > > > > > You would on the other hand get problem with dynamic context, if > > some context that you sent over, gets lost or corrupted. > Once this happen > > then, you can see whether the context has changed (in which > case you need a > refresh) > > or not (you only need a retx). > > > > Dynamic context means that it is changing as the mobile's > traffic goes through > the router, right? So I view that as requiring > synchronization with an external > event, namely handover. Something like accounting information > would qualify, as > well as header compression state. On the other hand, a user's > SLA would not, > because handover wouldn't invalidate it. > > jak > > > > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > ------_=_NextPart_001_01C22F33.47107094 Content-Type: text/html; charset="iso-8859-1" RE: [Seamoby] Proposal on Sync/NoSync Requirement

James:

 So you are proposing now that there are also feature specific
CT protocols? If this is true, and we follow your argument,
the we need to revisit all the attributes stated for CT: reliability,
timeliness, etc., etc. to determine what capabilities should be
common, and what capabilities should be feature specific.

 As far as updates go, I think it is a common capability.

Gary

> -----Original Message-----
> From: James Kempf [mailto:kempf@docomolabs-usa.com]
> Sent: July 19, 2002 09:05
> To: Nakhjiri Madjid-MNAKHJI1; seamoby@ietf.org
> Subject: Re: [Seamoby] Proposal on Sync/NoSync Requirement
>
>
> Madjid,
>
>
> > Don't know if we can use NEED Not (certainly fits for the
> first SHOULD NOT,
> since
> > that one sounds like we are advising against it).
>
> We should (SHOULD? :-) use RFC language.
>
> > How would you allow particular features get synch service,
> if there is no
> inbuild
> > mechanisms in CT?
>
> Because the CT protocol would be just a container format that
> could be reused by
> many different feature specific protocols. For example, one
> could use the CT
> container to define an option for use along with handover
> signaling to transfer
> header compression context. Or, one could use SCTP to
> transfer security, QoS,
> and AAA context not requiring any synchronization with the
> handover signaling.
> The latter would require a separate protocol description for
> how the container
> format is used with the particular transport. For most
> protocols, the two are
> bundled, but they are conceptually separate and here I can
> see reasons for
> separating them.
>
> >
> > I think we can talk about synchronization when there are
> two copies at
> > two different places. I think the solutions should
> seriously avoid this,
> > as we did in our proposal. Care should be taken so that you
> don't have to
> > update a context at both oldAR and newAR. I think as you
> said for header
> compression
> > context, you should have the context updated only at one
> location and when
> > it is only at one location, how can we call it synchronization?
> >
>
> Because it is synchronized with an external event, namely
> handover. With context
> that is not sync sensitive  there is no requirement for
> synchronization with
> handover because the change in routing doesn't invalidate the
> context on the old
> router. Conversely, if the non-sync sensitive context is sent
> a bit early, there
> will similarly not be a problem.
>
> This is not to state that the non-sync sensitive context
> isn't dynamic, just
> that the event of handover doesn't invalidate it per se.
>
>
> >
> > You would on the other hand get problem with dynamic context, if
> > some context that you sent over, gets lost or corrupted.
> Once this happen
> > then, you can see whether the context has changed (in which
> case you need a
> refresh)
> > or not (you only need a retx).
> >
>
> Dynamic context means that it is changing as the mobile's
> traffic goes through
> the router, right? So I view that as requiring
> synchronization with an external
> event, namely handover. Something like accounting information
> would qualify, as
> well as header compression state. On the other hand, a user's
> SLA would not,
> because handover wouldn't invalidate it.
>
>                 jak
>
>
>
>
> _______________________________________________
> Seamoby mailing list
> Seamoby@ietf.org
> https://www1.ietf.org/mailman/listinfo/seamoby
>

------_=_NextPart_001_01C22F33.47107094-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Fri Jul 19 11:53:24 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12518 for ; Fri, 19 Jul 2002 11:53:24 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA11066; Fri, 19 Jul 2002 11:51:42 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA10999 for ; Fri, 19 Jul 2002 11:51:38 -0400 (EDT) Received: from motgate4.mot.com (motgate4.mot.com [144.189.100.102]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12462 for ; Fri, 19 Jul 2002 11:50:38 -0400 (EDT) Received: [from pobox4.mot.com (pobox4.mot.com [10.64.251.243]) by motgate4.mot.com (motgate4 2.1) with ESMTP id IAA08659 for ; Fri, 19 Jul 2002 08:51:37 -0700 (MST)] Received: [from il27exm07.cig.mot.com (IL27EXM07.cig.mot.com [136.182.15.116]) by pobox4.mot.com (MOT-pobox4 2.0) with ESMTP id IAA21266 for ; Fri, 19 Jul 2002 08:51:37 -0700 (MST)] Received: by IL27EXM07.cig.mot.com with Internet Mail Service (5.5.2654.52) id <3FLZZDPV>; Fri, 19 Jul 2002 10:51:37 -0500 Message-ID: <35DBB8B7AC89D4118E98009027B1009B08AD55D3@IL27EXM10.cig.mot.com> From: Nakhjiri Madjid-MNAKHJI1 To: "'Gary Kenward'" , Nakhjiri Madjid-MNAKHJI1 , "'James Kempf'" , john.loughney@nokia.com, seamoby@ietf.org Subject: RE: [Seamoby] Proposal on Sync/NoSync Requirement Date: Fri, 19 Jul 2002 10:51:36 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.52) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C22F3C.29D826D0" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C22F3C.29D826D0 Content-Type: text/plain; charset="iso-8859-1" Gary, Agree with most of the things you said, in the interest of getting things done as quick as possible, if you like to serve the "fundamental concern" as you put it " The fundamental concern here seems to be over the scenario where the context changes while a CT is already in progress. It does not seem to me to be a difficult task to formulate a requirement that states that CT will update, but at best, the granularity of the synchronization will be greater then the duration of a CT (lots of word smithing required, perhaps, but doable). As far as I can discern, the only detrimental effect of sending context updates to receiving ARs is the protocol overhead. " I will say, the following is enough (extracted from your own words with an insertion: "feature"): "states that CT will update, but at best, the granularity of the synchronization will be greater then the duration of a feature CT I leave the word smithing to you :) but the word "feature" ensures that as I said you wouldn't have to update a feature while you are sending others, also it covers people who like to support context retransmissions, while the context is highly dynamic and changes between retransmissions. Regards, Madjid -----Original Message----- From: Gary Kenward [mailto:gkenward@nortelnetworks.com] Sent: Friday, July 19, 2002 9:31 AM To: 'Nakhjiri Madjid-MNAKHJI1'; 'James Kempf'; john.loughney@nokia.com; seamoby@ietf.org Subject: RE: [Seamoby] Proposal on Sync/NoSync Requirement Madjid: I would like to respond to your comments with a general comment, which hopefully covers much of the issue. Correct me if this is not the case. The fundamental concern here seems to be over the scenario where the context changes while a CT is already in progress. It does not seem to me to be a difficult task to formulate a requirement that states that CT will update, but at best, the granularity of the synchronization will be greater then the duration of a CT (lots of word smithing required, perhaps, but doable). As far as I can discern, the only detrimental effect of sending context updates to receiving ARs is the protocol overhead. A receiving AR may always decide that it does not need to use a context update. It would probably make this decision when, for example, it was receiving a handover, and had installed context in preparation for the arriving flows. In other words, the disruption of attempting to update the installed context would be greater then the disruption of not having the latest context. Now, dynamic, or state related context updates are a real problem. There is a big issue as to when to perform state updates, how often, etc. For example, if the dynamic context is a packet counter, you obviously do not want to be updating that context every time it changes. In our work, we came to the conclusion that while it was worthwile updated configuration context when it happened, updating dynamic context (e.g. state context) was not pratical, and indeed, transferring of state context only made sense to attempt just before the receiving AR needed the context. Again, the assumption here is that transferring configuration context ahead of time (e.g. ahead of an actual handover), improves seamlessness. There seems to be some evidence that it can. As I see it, this whole discussion is around, as you put it, the "NON-requirement" of ensuring that the CT solution is not driven to meet extreme synchronization goals. We could take this approach to many of the requirements - e.g. if I say CT has to be fast, does that mean pico-second transfer times? Clearly it doesn't, but we do not have a requirement that says "CT should be fast, but not too fast" (Note: the actual requirement doesn't use the word fast - this is simply a counter example). Cheers, Gary -----Original Message----- From: Nakhjiri Madjid-MNAKHJI1 [ mailto:Madjid.Nakhjiri@motorola.com ] Sent: July 18, 2002 17:54 To: Kenward, Gary [WDLN2:AN10:EXCH]; Nakhjiri Madjid-MNAKHJI1; 'James Kempf'; john.loughney@nokia.com; seamoby@ietf.org Subject: RE: [Seamoby] Proposal on Sync/NoSync Requirement Gary, Thanks for your reply. We are getting there. Please see comments below BR, Madjid > Proposed: > 5.5 Context Update and Synchronization > 5.5.1 The context transfer protocol MUST be capable of supporting the > updates to context information when it changes. > > Madjid>> Ok, this takes care of the dynamic context, however, we Actually, the real concern I have is not for dynamic context as it is for changes in the makeup of the traffic for the MN - i.e. the arrival and departure of microflows. This would change the configuration (aka static) context. Madjid>> Ok, as I recall the context transfer deals with a microflow as a unit. The discussion of arrival and departure of microflows is relevant if you are aggregating multiple microflows, so maybe this should be added to the section that talks about aggregation, otherwise I think it is hard to avoid the interpretation I made (dynamic feature context) > need to be clarify that we are not requiring the oldAR sends updates > to context features it has already transmitted while it is > transmitting > context for other features, otherwise CT might never end. I absolutely agree with you. Madjid>> glad to hear that. > Since, some folks have brought that up, I want to make sure that we > are not reading that in the requirement. Updates initiated by oldAR > should only be based on outside triggers such as new flow, > flow terminations > or messages from central entities... There seems to be a concern that CT will not be able to guarantee perfect synchronization of the configuration and state of both ARs. My response to this concern is, of course not, CT was never intended to do such a think. This is not distributed computing, it is handover optimization. Perhaps a new requirement would help clarify this, something like: 5.5.x Context transfer SHALL NOT attempt to guarantee perfect synchronization of context. The purpose of CT is to improve handover as best as it can. Given the complexity and overheads needed to synchronize distributed state machines, it is expected that occasionally, the context of the source and destination AR will not agree. The CT solution must minimize the likelihood of this happening "Addition: by careful consideration of the rate by which context will change over time . 5.5.x+1 Context transfer WILL NOT attempt to mitigate the effects of stale context at the receiving AR. Madjid>> Can't tell if you can put a NON-requirement to a requirement document :) but if you think it provides clarity, then fine. I added a little bit more guidance at the end, up to you whether you want to use it. To me, this all seems like responding to "what if" scenarios, which if we got to far into this mode, could cause the number of requirements to explode. However, perhaps this is one distinction we should emphasize. > > 5.5.2 Context updates SHOULD complete before the context is needed at > the receiving AR. > > Madjid>> How do we know when the context is needed at the > receiving AR? > I find this more like a design guidance than a requirement. Well, a requirement is a design guide. The wg has debated this extensively, Madjid, with, if I recall, no better resolution then the current wording. If you have a recommendation for wording of a requirement that would identify when CT should be complete, please submit it. Madjid>> "Context transfer must not add to the length of the disruption of the feature, for which it is transfering states for, otherwise the use of context transfer defeats its purpose" > The following > text > can with some exceptions added to the explanation of 5.5.2. > > The context at the AR actually supporting an MN's traffic will > change with time. For example, the MN may initiate new > microflow(s), > or discontinue existing microflows. > Madjid>> the above is good. > > Any change of context at the > supporting AR must be replicated at those ARs that have already > received context for that MN. > Madjid>> MUSt is too strong. 5.5.1 is SHOULD, so should this one be > (sorry for too many shoulds :)) There are ways to avoid having to do > this through CT. Hmmm. Could you expand on the "many ways"? I am curious. Madjid>> well I didn't say "many". If the change of context is resulted from an outside event by an outside trigger, the same information may be sent to the new AR to update the context there instead. As for MUST versus SHOULD: I think there is an issue here with interpretation. My interpretation is that CT MUST ATTEMPT to convey context changes at the ARs. That is, CT must provide the mechanisms to transfer context changes to all ARs that received the context originally. I agree that it is too extreme to state that the changes MUST make it to all ARs. Perhaps some rewording is needed. Yes, I think you covered it yourself in your new formulation. > However, context changes are often driven by events > external to the > sending AR, and will thus be asynchronous to any on-going context > updates. Given that context transfers will take a finite amount of > time to complete, it is possible that a change in context > cannot be > conveyed in time to the destination AR to avoid any impact > on a possible > handover. The objective of the context transfer design > must be to make > the likelihood of this delay, and its magnitude, as low as > possible. > > Madjid>> The above is good. > > This is not perfect: the desire to avoid a requirement for an > extreme degree > > of synchronization is only implied by the soft "SHOULD" in 5.5.2. > Regards, > Gary > > > > -----Original Message----- Thanks for the response; very useful input. Gary ------_=_NextPart_001_01C22F3C.29D826D0 Content-Type: text/html; charset="iso-8859-1" RE: [Seamoby] Proposal on Sync/NoSync Requirement
Gary,
 
Agree with most of the things you said, in the interest of getting things
done as quick as possible, if you like to serve the "fundamental concern" as
you put it

"  The fundamental concern here seems to be over the scenario where the context changes while a
CT is already in progress. It does not seem to me to be a difficult task to formulate a requirement
that states that CT will update, but at best, the granularity of the synchronization will be greater
then the duration of a CT (lots of word smithing required, perhaps, but doable). As far as I can
discern, the only detrimental effect of sending context updates to receiving ARs is the protocol overhead. "

I will say, the following is enough (extracted from your own words with an insertion: "feature"):

"states that CT will update, but at best, the granularity of the synchronization will be greater
then the duration of a feature CT

I leave the word smithing to you :) but the word "feature" ensures that as I said you wouldn't 
have to update a feature while you are sending others, also it covers people who like to support
context retransmissions, while the context is highly dynamic and changes between retransmissions.
 
Regards,
 
Madjid
-----Original Message-----
From: Gary Kenward [mailto:gkenward@nortelnetworks.com]
Sent: Friday, July 19, 2002 9:31 AM
To: 'Nakhjiri Madjid-MNAKHJI1'; 'James Kempf'; john.loughney@nokia.com; seamoby@ietf.org
Subject: RE: [Seamoby] Proposal on Sync/NoSync Requirement

Madjid:

  I would like to respond to your comments with a general comment, which hopefully covers much
of the issue. Correct me if this is not the case.

  The fundamental concern here seems to be over the scenario where the context changes while a
CT is already in progress. It does not seem to me to be a difficult task to formulate a requirement
that states that CT will update, but at best, the granularity of the synchronization will be greater
then the duration of a CT (lots of word smithing required, perhaps, but doable). As far as I can
discern, the only detrimental effect of sending context updates to receiving ARs is the protocol overhead.

A receiving AR may always decide that it does not need to use a context update. It would probably make
this decision when, for example, it was receiving a handover, and had installed context in preparation for
the arriving flows. In other words, the disruption of attempting to update the installed context would
be greater then the disruption of not having the latest context.

Now, dynamic, or state related context updates are a real problem. There is a big issue as to when to
perform state updates, how often, etc. For example, if the dynamic context is a packet counter, you
obviously do not want to be updating that context every time it changes. In our work, we came to
the conclusion that while it was worthwile updated configuration context when it happened, updating
dynamic context (e.g. state context) was not pratical, and indeed, transferring of state context only
made sense to attempt just before the receiving AR needed the context. Again, the assumption here
is that transferring configuration context ahead of time (e.g. ahead of an actual handover), improves
seamlessness. There seems to be some evidence that it can.

As I see it, this whole discussion is around, as you put it, the "NON-requirement" of ensuring that the
CT solution is not driven to meet extreme synchronization goals. We could take this approach to many
of the requirements - e.g. if I say CT has to be fast, does that mean pico-second transfer times? Clearly
it doesn't, but we do not have a requirement that says "CT should be fast, but not too fast" (Note: the
actual requirement doesn't use the word fast - this is simply a counter example).

Cheers,
Gary
-----Original Message-----
From: Nakhjiri Madjid-MNAKHJI1 [mailto:Madjid.Nakhjiri@motorola.com]
Sent: July 18, 2002 17:54
To: Kenward, Gary [WDLN2:AN10:EXCH]; Nakhjiri Madjid-MNAKHJI1; 'James Kempf'; john.loughney@nokia.com; seamoby@ietf.org
Subject: RE: [Seamoby] Proposal on Sync/NoSync Requirement


Gary,
Thanks for your reply. We are getting there. Please see comments below
 
BR,
 
Madjid
 
<snip>
 > Proposed:
> 5.5 Context Update and Synchronization
> 5.5.1 The context transfer protocol MUST be capable of supporting the
>       updates to context information when it changes. 
>
>  Madjid>> Ok, this takes care of the dynamic context, however, we
Actually, the real concern I have is not for dynamic context as it is
for changes in the makeup of the traffic for the MN - i.e. the arrival
and departure of microflows. This would change the configuration (aka
static) context.
Madjid>> Ok, as I recall the context transfer deals with a microflow
as a unit. The discussion of arrival and departure of    microflows is
relevant if you are aggregating multiple microflows, so maybe this
should be added to the section that talks about aggregation, otherwise
I think it is hard to avoid the interpretation I made (dynamic feature context)
> need to be clarify that we are not requiring the oldAR sends updates
> to context features it has already transmitted while it is
> transmitting
> context for other features, otherwise CT might never end.
I absolutely agree with you. 
Madjid>> glad to hear that.
> Since, some folks have brought that up, I want to make sure that we
>  are not reading that in the requirement. Updates initiated by oldAR
> should only be based on outside triggers such as new flow,
> flow terminations
> or messages from central entities...
There seems to be a concern that CT will not be able to guarantee perfect
synchronization of the configuration and state of both ARs. My response to
this concern is, of course not, CT was never intended to do such a think.
This is not distributed computing, it is handover optimization.
Perhaps a new requirement would help clarify this, something like:
5.5.x Context transfer SHALL NOT attempt to guarantee perfect synchronization
of context. The purpose of CT is to improve handover as best as it can. Given
the complexity and overheads needed to synchronize distributed state machines,
it is expected that occasionally, the context of the source and destination
AR will not agree. The CT solution must minimize the likelihood of this happening  "Addition:
by careful consideration of the rate by which context will change over time .
5.5.x+1 Context transfer WILL NOT attempt to mitigate the effects of stale context
        at the receiving AR.
 Madjid>> Can't tell if you can put a NON-requirement to a requirement document :)
but if you think it provides clarity, then fine. I added a little bit more guidance at the end,
up to you whether you want to use it. 

To me, this all seems like responding to "what if" scenarios, which if we got
to far into this mode, could cause the number of requirements to explode.
However, perhaps this is one distinction we should emphasize.
>
> 5.5.2 Context updates SHOULD complete before the context is needed at
>       the receiving AR.
>
> Madjid>> How do we know when the context is needed at the
> receiving AR?
> I find this more like a design guidance than a requirement.
Well, a requirement is a design guide. The wg has debated this extensively,
Madjid, with, if I recall, no better resolution then the current wording.
If you have a recommendation for wording of a requirement that would identify
when CT should be complete, please submit it. 
Madjid>> "Context transfer must not add to the length of the disruption of the feature, for
which it is transfering states for, otherwise the use of context transfer
defeats its purpose"
> The following
> text
> can with some exceptions added to the explanation of 5.5.2.
>
>    The context at the AR actually supporting an MN's traffic will
>    change with time. For example, the MN may initiate new
> microflow(s),
>    or discontinue existing microflows.
> Madjid>> the above is good.
>
> Any change of context at the
>    supporting AR must be replicated at those ARs that have already
>    received context for that MN.
> Madjid>> MUSt is too strong. 5.5.1 is SHOULD, so should this one be
> (sorry for too many shoulds :)) There are ways to avoid having to do
> this through CT.
Hmmm. Could you expand on the "many ways"? I am curious. 
Madjid>> well I didn't say "many". If the change of context is resulted
from an outside event by an outside trigger, the same information
may be sent to the new AR to update the context there instead.
As for MUST versus SHOULD: I think there is an issue here with interpretation.
My interpretation is that CT MUST ATTEMPT to convey context changes at the ARs.
That is, CT must provide the mechanisms to transfer context changes to all ARs
that received the context originally. I agree that it is too extreme to state
that the changes MUST make it to all ARs. Perhaps some rewording is needed.
 Yes, I think you covered it yourself in your new formulation.
 
>    However, context changes are often driven by events
> external to the
>    sending AR, and will thus be asynchronous to any on-going context
>    updates. Given that context transfers will take a finite amount of
>    time to complete, it is possible that a change in context
> cannot be
>    conveyed in time to the destination AR to avoid any impact
> on a possible
>    handover. The objective of the context transfer design
> must be to make
>    the likelihood of this delay, and its magnitude, as low as
> possible.
>
> Madjid>> The above is good.
>
> This is not perfect: the desire to avoid a requirement for an
> extreme degree
>
> of synchronization is only implied by the soft "SHOULD" in 5.5.2.
> Regards,
> Gary
>
>
> > -----Original Message-----
Thanks for the response; very useful input.
Gary

------_=_NextPart_001_01C22F3C.29D826D0-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Fri Jul 19 11:53:25 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12527 for ; Fri, 19 Jul 2002 11:53:24 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA11172 for seamoby-archive@odin.ietf.org; Fri, 19 Jul 2002 11:54:23 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA11066; Fri, 19 Jul 2002 11:51:42 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA10999 for ; Fri, 19 Jul 2002 11:51:38 -0400 (EDT) Received: from motgate4.mot.com (motgate4.mot.com [144.189.100.102]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12462 for ; Fri, 19 Jul 2002 11:50:38 -0400 (EDT) Received: [from pobox4.mot.com (pobox4.mot.com [10.64.251.243]) by motgate4.mot.com (motgate4 2.1) with ESMTP id IAA08659 for ; Fri, 19 Jul 2002 08:51:37 -0700 (MST)] Received: [from il27exm07.cig.mot.com (IL27EXM07.cig.mot.com [136.182.15.116]) by pobox4.mot.com (MOT-pobox4 2.0) with ESMTP id IAA21266 for ; Fri, 19 Jul 2002 08:51:37 -0700 (MST)] Received: by IL27EXM07.cig.mot.com with Internet Mail Service (5.5.2654.52) id <3FLZZDPV>; Fri, 19 Jul 2002 10:51:37 -0500 Message-ID: <35DBB8B7AC89D4118E98009027B1009B08AD55D3@IL27EXM10.cig.mot.com> From: Nakhjiri Madjid-MNAKHJI1 To: "'Gary Kenward'" , Nakhjiri Madjid-MNAKHJI1 , "'James Kempf'" , john.loughney@nokia.com, seamoby@ietf.org Subject: RE: [Seamoby] Proposal on Sync/NoSync Requirement Date: Fri, 19 Jul 2002 10:51:36 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.52) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C22F3C.29D826D0" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C22F3C.29D826D0 Content-Type: text/plain; charset="iso-8859-1" Gary, Agree with most of the things you said, in the interest of getting things done as quick as possible, if you like to serve the "fundamental concern" as you put it " The fundamental concern here seems to be over the scenario where the context changes while a CT is already in progress. It does not seem to me to be a difficult task to formulate a requirement that states that CT will update, but at best, the granularity of the synchronization will be greater then the duration of a CT (lots of word smithing required, perhaps, but doable). As far as I can discern, the only detrimental effect of sending context updates to receiving ARs is the protocol overhead. " I will say, the following is enough (extracted from your own words with an insertion: "feature"): "states that CT will update, but at best, the granularity of the synchronization will be greater then the duration of a feature CT I leave the word smithing to you :) but the word "feature" ensures that as I said you wouldn't have to update a feature while you are sending others, also it covers people who like to support context retransmissions, while the context is highly dynamic and changes between retransmissions. Regards, Madjid -----Original Message----- From: Gary Kenward [mailto:gkenward@nortelnetworks.com] Sent: Friday, July 19, 2002 9:31 AM To: 'Nakhjiri Madjid-MNAKHJI1'; 'James Kempf'; john.loughney@nokia.com; seamoby@ietf.org Subject: RE: [Seamoby] Proposal on Sync/NoSync Requirement Madjid: I would like to respond to your comments with a general comment, which hopefully covers much of the issue. Correct me if this is not the case. The fundamental concern here seems to be over the scenario where the context changes while a CT is already in progress. It does not seem to me to be a difficult task to formulate a requirement that states that CT will update, but at best, the granularity of the synchronization will be greater then the duration of a CT (lots of word smithing required, perhaps, but doable). As far as I can discern, the only detrimental effect of sending context updates to receiving ARs is the protocol overhead. A receiving AR may always decide that it does not need to use a context update. It would probably make this decision when, for example, it was receiving a handover, and had installed context in preparation for the arriving flows. In other words, the disruption of attempting to update the installed context would be greater then the disruption of not having the latest context. Now, dynamic, or state related context updates are a real problem. There is a big issue as to when to perform state updates, how often, etc. For example, if the dynamic context is a packet counter, you obviously do not want to be updating that context every time it changes. In our work, we came to the conclusion that while it was worthwile updated configuration context when it happened, updating dynamic context (e.g. state context) was not pratical, and indeed, transferring of state context only made sense to attempt just before the receiving AR needed the context. Again, the assumption here is that transferring configuration context ahead of time (e.g. ahead of an actual handover), improves seamlessness. There seems to be some evidence that it can. As I see it, this whole discussion is around, as you put it, the "NON-requirement" of ensuring that the CT solution is not driven to meet extreme synchronization goals. We could take this approach to many of the requirements - e.g. if I say CT has to be fast, does that mean pico-second transfer times? Clearly it doesn't, but we do not have a requirement that says "CT should be fast, but not too fast" (Note: the actual requirement doesn't use the word fast - this is simply a counter example). Cheers, Gary -----Original Message----- From: Nakhjiri Madjid-MNAKHJI1 [ mailto:Madjid.Nakhjiri@motorola.com ] Sent: July 18, 2002 17:54 To: Kenward, Gary [WDLN2:AN10:EXCH]; Nakhjiri Madjid-MNAKHJI1; 'James Kempf'; john.loughney@nokia.com; seamoby@ietf.org Subject: RE: [Seamoby] Proposal on Sync/NoSync Requirement Gary, Thanks for your reply. We are getting there. Please see comments below BR, Madjid > Proposed: > 5.5 Context Update and Synchronization > 5.5.1 The context transfer protocol MUST be capable of supporting the > updates to context information when it changes. > > Madjid>> Ok, this takes care of the dynamic context, however, we Actually, the real concern I have is not for dynamic context as it is for changes in the makeup of the traffic for the MN - i.e. the arrival and departure of microflows. This would change the configuration (aka static) context. Madjid>> Ok, as I recall the context transfer deals with a microflow as a unit. The discussion of arrival and departure of microflows is relevant if you are aggregating multiple microflows, so maybe this should be added to the section that talks about aggregation, otherwise I think it is hard to avoid the interpretation I made (dynamic feature context) > need to be clarify that we are not requiring the oldAR sends updates > to context features it has already transmitted while it is > transmitting > context for other features, otherwise CT might never end. I absolutely agree with you. Madjid>> glad to hear that. > Since, some folks have brought that up, I want to make sure that we > are not reading that in the requirement. Updates initiated by oldAR > should only be based on outside triggers such as new flow, > flow terminations > or messages from central entities... There seems to be a concern that CT will not be able to guarantee perfect synchronization of the configuration and state of both ARs. My response to this concern is, of course not, CT was never intended to do such a think. This is not distributed computing, it is handover optimization. Perhaps a new requirement would help clarify this, something like: 5.5.x Context transfer SHALL NOT attempt to guarantee perfect synchronization of context. The purpose of CT is to improve handover as best as it can. Given the complexity and overheads needed to synchronize distributed state machines, it is expected that occasionally, the context of the source and destination AR will not agree. The CT solution must minimize the likelihood of this happening "Addition: by careful consideration of the rate by which context will change over time . 5.5.x+1 Context transfer WILL NOT attempt to mitigate the effects of stale context at the receiving AR. Madjid>> Can't tell if you can put a NON-requirement to a requirement document :) but if you think it provides clarity, then fine. I added a little bit more guidance at the end, up to you whether you want to use it. To me, this all seems like responding to "what if" scenarios, which if we got to far into this mode, could cause the number of requirements to explode. However, perhaps this is one distinction we should emphasize. > > 5.5.2 Context updates SHOULD complete before the context is needed at > the receiving AR. > > Madjid>> How do we know when the context is needed at the > receiving AR? > I find this more like a design guidance than a requirement. Well, a requirement is a design guide. The wg has debated this extensively, Madjid, with, if I recall, no better resolution then the current wording. If you have a recommendation for wording of a requirement that would identify when CT should be complete, please submit it. Madjid>> "Context transfer must not add to the length of the disruption of the feature, for which it is transfering states for, otherwise the use of context transfer defeats its purpose" > The following > text > can with some exceptions added to the explanation of 5.5.2. > > The context at the AR actually supporting an MN's traffic will > change with time. For example, the MN may initiate new > microflow(s), > or discontinue existing microflows. > Madjid>> the above is good. > > Any change of context at the > supporting AR must be replicated at those ARs that have already > received context for that MN. > Madjid>> MUSt is too strong. 5.5.1 is SHOULD, so should this one be > (sorry for too many shoulds :)) There are ways to avoid having to do > this through CT. Hmmm. Could you expand on the "many ways"? I am curious. Madjid>> well I didn't say "many". If the change of context is resulted from an outside event by an outside trigger, the same information may be sent to the new AR to update the context there instead. As for MUST versus SHOULD: I think there is an issue here with interpretation. My interpretation is that CT MUST ATTEMPT to convey context changes at the ARs. That is, CT must provide the mechanisms to transfer context changes to all ARs that received the context originally. I agree that it is too extreme to state that the changes MUST make it to all ARs. Perhaps some rewording is needed. Yes, I think you covered it yourself in your new formulation. > However, context changes are often driven by events > external to the > sending AR, and will thus be asynchronous to any on-going context > updates. Given that context transfers will take a finite amount of > time to complete, it is possible that a change in context > cannot be > conveyed in time to the destination AR to avoid any impact > on a possible > handover. The objective of the context transfer design > must be to make > the likelihood of this delay, and its magnitude, as low as > possible. > > Madjid>> The above is good. > > This is not perfect: the desire to avoid a requirement for an > extreme degree > > of synchronization is only implied by the soft "SHOULD" in 5.5.2. > Regards, > Gary > > > > -----Original Message----- Thanks for the response; very useful input. Gary ------_=_NextPart_001_01C22F3C.29D826D0 Content-Type: text/html; charset="iso-8859-1" RE: [Seamoby] Proposal on Sync/NoSync Requirement
Gary,
 
Agree with most of the things you said, in the interest of getting things
done as quick as possible, if you like to serve the "fundamental concern" as
you put it

"  The fundamental concern here seems to be over the scenario where the context changes while a
CT is already in progress. It does not seem to me to be a difficult task to formulate a requirement
that states that CT will update, but at best, the granularity of the synchronization will be greater
then the duration of a CT (lots of word smithing required, perhaps, but doable). As far as I can
discern, the only detrimental effect of sending context updates to receiving ARs is the protocol overhead. "

I will say, the following is enough (extracted from your own words with an insertion: "feature"):

"states that CT will update, but at best, the granularity of the synchronization will be greater
then the duration of a feature CT

I leave the word smithing to you :) but the word "feature" ensures that as I said you wouldn't 
have to update a feature while you are sending others, also it covers people who like to support
context retransmissions, while the context is highly dynamic and changes between retransmissions.
 
Regards,
 
Madjid
-----Original Message-----
From: Gary Kenward [mailto:gkenward@nortelnetworks.com]
Sent: Friday, July 19, 2002 9:31 AM
To: 'Nakhjiri Madjid-MNAKHJI1'; 'James Kempf'; john.loughney@nokia.com; seamoby@ietf.org
Subject: RE: [Seamoby] Proposal on Sync/NoSync Requirement

Madjid:

  I would like to respond to your comments with a general comment, which hopefully covers much
of the issue. Correct me if this is not the case.

  The fundamental concern here seems to be over the scenario where the context changes while a
CT is already in progress. It does not seem to me to be a difficult task to formulate a requirement
that states that CT will update, but at best, the granularity of the synchronization will be greater
then the duration of a CT (lots of word smithing required, perhaps, but doable). As far as I can
discern, the only detrimental effect of sending context updates to receiving ARs is the protocol overhead.

A receiving AR may always decide that it does not need to use a context update. It would probably make
this decision when, for example, it was receiving a handover, and had installed context in preparation for
the arriving flows. In other words, the disruption of attempting to update the installed context would
be greater then the disruption of not having the latest context.

Now, dynamic, or state related context updates are a real problem. There is a big issue as to when to
perform state updates, how often, etc. For example, if the dynamic context is a packet counter, you
obviously do not want to be updating that context every time it changes. In our work, we came to
the conclusion that while it was worthwile updated configuration context when it happened, updating
dynamic context (e.g. state context) was not pratical, and indeed, transferring of state context only
made sense to attempt just before the receiving AR needed the context. Again, the assumption here
is that transferring configuration context ahead of time (e.g. ahead of an actual handover), improves
seamlessness. There seems to be some evidence that it can.

As I see it, this whole discussion is around, as you put it, the "NON-requirement" of ensuring that the
CT solution is not driven to meet extreme synchronization goals. We could take this approach to many
of the requirements - e.g. if I say CT has to be fast, does that mean pico-second transfer times? Clearly
it doesn't, but we do not have a requirement that says "CT should be fast, but not too fast" (Note: the
actual requirement doesn't use the word fast - this is simply a counter example).

Cheers,
Gary
-----Original Message-----
From: Nakhjiri Madjid-MNAKHJI1 [mailto:Madjid.Nakhjiri@motorola.com]
Sent: July 18, 2002 17:54
To: Kenward, Gary [WDLN2:AN10:EXCH]; Nakhjiri Madjid-MNAKHJI1; 'James Kempf'; john.loughney@nokia.com; seamoby@ietf.org
Subject: RE: [Seamoby] Proposal on Sync/NoSync Requirement


Gary,
Thanks for your reply. We are getting there. Please see comments below
 
BR,
 
Madjid
 
<snip>
 > Proposed:
> 5.5 Context Update and Synchronization
> 5.5.1 The context transfer protocol MUST be capable of supporting the
>       updates to context information when it changes. 
>
>  Madjid>> Ok, this takes care of the dynamic context, however, we
Actually, the real concern I have is not for dynamic context as it is
for changes in the makeup of the traffic for the MN - i.e. the arrival
and departure of microflows. This would change the configuration (aka
static) context.
Madjid>> Ok, as I recall the context transfer deals with a microflow
as a unit. The discussion of arrival and departure of    microflows is
relevant if you are aggregating multiple microflows, so maybe this
should be added to the section that talks about aggregation, otherwise
I think it is hard to avoid the interpretation I made (dynamic feature context)
> need to be clarify that we are not requiring the oldAR sends updates
> to context features it has already transmitted while it is
> transmitting
> context for other features, otherwise CT might never end.
I absolutely agree with you. 
Madjid>> glad to hear that.
> Since, some folks have brought that up, I want to make sure that we
>  are not reading that in the requirement. Updates initiated by oldAR
> should only be based on outside triggers such as new flow,
> flow terminations
> or messages from central entities...
There seems to be a concern that CT will not be able to guarantee perfect
synchronization of the configuration and state of both ARs. My response to
this concern is, of course not, CT was never intended to do such a think.
This is not distributed computing, it is handover optimization.
Perhaps a new requirement would help clarify this, something like:
5.5.x Context transfer SHALL NOT attempt to guarantee perfect synchronization
of context. The purpose of CT is to improve handover as best as it can. Given
the complexity and overheads needed to synchronize distributed state machines,
it is expected that occasionally, the context of the source and destination
AR will not agree. The CT solution must minimize the likelihood of this happening  "Addition:
by careful consideration of the rate by which context will change over time .
5.5.x+1 Context transfer WILL NOT attempt to mitigate the effects of stale context
        at the receiving AR.
 Madjid>> Can't tell if you can put a NON-requirement to a requirement document :)
but if you think it provides clarity, then fine. I added a little bit more guidance at the end,
up to you whether you want to use it. 

To me, this all seems like responding to "what if" scenarios, which if we got
to far into this mode, could cause the number of requirements to explode.
However, perhaps this is one distinction we should emphasize.
>
> 5.5.2 Context updates SHOULD complete before the context is needed at
>       the receiving AR.
>
> Madjid>> How do we know when the context is needed at the
> receiving AR?
> I find this more like a design guidance than a requirement.
Well, a requirement is a design guide. The wg has debated this extensively,
Madjid, with, if I recall, no better resolution then the current wording.
If you have a recommendation for wording of a requirement that would identify
when CT should be complete, please submit it. 
Madjid>> "Context transfer must not add to the length of the disruption of the feature, for
which it is transfering states for, otherwise the use of context transfer
defeats its purpose"
> The following
> text
> can with some exceptions added to the explanation of 5.5.2.
>
>    The context at the AR actually supporting an MN's traffic will
>    change with time. For example, the MN may initiate new
> microflow(s),
>    or discontinue existing microflows.
> Madjid>> the above is good.
>
> Any change of context at the
>    supporting AR must be replicated at those ARs that have already
>    received context for that MN.
> Madjid>> MUSt is too strong. 5.5.1 is SHOULD, so should this one be
> (sorry for too many shoulds :)) There are ways to avoid having to do
> this through CT.
Hmmm. Could you expand on the "many ways"? I am curious. 
Madjid>> well I didn't say "many". If the change of context is resulted
from an outside event by an outside trigger, the same information
may be sent to the new AR to update the context there instead.
As for MUST versus SHOULD: I think there is an issue here with interpretation.
My interpretation is that CT MUST ATTEMPT to convey context changes at the ARs.
That is, CT must provide the mechanisms to transfer context changes to all ARs
that received the context originally. I agree that it is too extreme to state
that the changes MUST make it to all ARs. Perhaps some rewording is needed.
 Yes, I think you covered it yourself in your new formulation.
 
>    However, context changes are often driven by events
> external to the
>    sending AR, and will thus be asynchronous to any on-going context
>    updates. Given that context transfers will take a finite amount of
>    time to complete, it is possible that a change in context
> cannot be
>    conveyed in time to the destination AR to avoid any impact
> on a possible
>    handover. The objective of the context transfer design
> must be to make
>    the likelihood of this delay, and its magnitude, as low as
> possible.
>
> Madjid>> The above is good.
>
> This is not perfect: the desire to avoid a requirement for an
> extreme degree
>
> of synchronization is only implied by the soft "SHOULD" in 5.5.2.
> Regards,
> Gary
>
>
> > -----Original Message-----
Thanks for the response; very useful input.
Gary

------_=_NextPart_001_01C22F3C.29D826D0-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Fri Jul 19 12:01:29 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12692 for ; Fri, 19 Jul 2002 12:01:29 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA11367; Fri, 19 Jul 2002 11:59:13 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA11337 for ; Fri, 19 Jul 2002 11:59:11 -0400 (EDT) Received: from motgate4.mot.com (motgate4.mot.com [144.189.100.102]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12607 for ; Fri, 19 Jul 2002 11:58:11 -0400 (EDT) Received: [from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by motgate4.mot.com (motgate4 2.1) with ESMTP id IAA13796 for ; Fri, 19 Jul 2002 08:59:11 -0700 (MST)] Received: [from il27exb01.cig.mot.com (il27exb01.cig.mot.com [136.182.15.100]) by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id IAA26575 for ; Fri, 19 Jul 2002 08:57:52 -0700 (MST)] Received: by il27exb01.cig.mot.com with Internet Mail Service (5.5.2654.52) id ; Fri, 19 Jul 2002 10:59:10 -0500 Message-ID: <35DBB8B7AC89D4118E98009027B1009B08AD55D4@IL27EXM10.cig.mot.com> From: Nakhjiri Madjid-MNAKHJI1 To: "'john.loughney@nokia.com'" , kempf@docomolabs-usa.com, seamoby@ietf.org Cc: mankin@psg.com Subject: RE: [Seamoby] Section 5.2 in CT Requirements Date: Fri, 19 Jul 2002 10:59:09 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.52) Content-Type: text/plain; charset="iso-8859-1" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Hi John, I think this will just delay things, the reason: you need to look at each protocol individually and determine its reliability needs, not to mention design scenarios for every person's network. Not to mention that you have found somebody who wants to do this study :) I think we have waited long enough for requirement. James' formulation is avoiding this whole discussion in a very neat way. Regards, madjid -----Original Message----- From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] Sent: Friday, July 19, 2002 3:38 AM To: kempf@docomolabs-usa.com; seamoby@ietf.org Cc: mankin@psg.com Subject: RE: [Seamoby] Section 5.2 in CT Requirements Hi James, A suggestion. Could we ask from Allison to defer this discussion (i.e. - drop the requirement completely from the requirements). A much better way forward would be someone to produce a short document discussing different protocols that CT could use. The pros & cons of each. The list that has been discussed (if I remember correctly) are: 1) UDP 2) TCP 3) SCTP 4) PR-SCTP (formerly U-SCTP) 5) ICMP 6) DCCP (formerly DCP) - this one wasn't discussed, but is possible. Additionally, we have discussed a possible framework approach for CT solutions, so I am not sure if we need to specify a single transport protocol - if we go down a framework path. John _______________________________________________ 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 From daemon@optimus.ietf.org Fri Jul 19 12:01:29 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12700 for ; Fri, 19 Jul 2002 12:01:29 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA12994 for seamoby-archive@odin.ietf.org; Fri, 19 Jul 2002 12:02:28 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA11367; Fri, 19 Jul 2002 11:59:13 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA11337 for ; Fri, 19 Jul 2002 11:59:11 -0400 (EDT) Received: from motgate4.mot.com (motgate4.mot.com [144.189.100.102]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12607 for ; Fri, 19 Jul 2002 11:58:11 -0400 (EDT) Received: [from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by motgate4.mot.com (motgate4 2.1) with ESMTP id IAA13796 for ; Fri, 19 Jul 2002 08:59:11 -0700 (MST)] Received: [from il27exb01.cig.mot.com (il27exb01.cig.mot.com [136.182.15.100]) by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id IAA26575 for ; Fri, 19 Jul 2002 08:57:52 -0700 (MST)] Received: by il27exb01.cig.mot.com with Internet Mail Service (5.5.2654.52) id ; Fri, 19 Jul 2002 10:59:10 -0500 Message-ID: <35DBB8B7AC89D4118E98009027B1009B08AD55D4@IL27EXM10.cig.mot.com> From: Nakhjiri Madjid-MNAKHJI1 To: "'john.loughney@nokia.com'" , kempf@docomolabs-usa.com, seamoby@ietf.org Cc: mankin@psg.com Subject: RE: [Seamoby] Section 5.2 in CT Requirements Date: Fri, 19 Jul 2002 10:59:09 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.52) Content-Type: text/plain; charset="iso-8859-1" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Hi John, I think this will just delay things, the reason: you need to look at each protocol individually and determine its reliability needs, not to mention design scenarios for every person's network. Not to mention that you have found somebody who wants to do this study :) I think we have waited long enough for requirement. James' formulation is avoiding this whole discussion in a very neat way. Regards, madjid -----Original Message----- From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] Sent: Friday, July 19, 2002 3:38 AM To: kempf@docomolabs-usa.com; seamoby@ietf.org Cc: mankin@psg.com Subject: RE: [Seamoby] Section 5.2 in CT Requirements Hi James, A suggestion. Could we ask from Allison to defer this discussion (i.e. - drop the requirement completely from the requirements). A much better way forward would be someone to produce a short document discussing different protocols that CT could use. The pros & cons of each. The list that has been discussed (if I remember correctly) are: 1) UDP 2) TCP 3) SCTP 4) PR-SCTP (formerly U-SCTP) 5) ICMP 6) DCCP (formerly DCP) - this one wasn't discussed, but is possible. Additionally, we have discussed a possible framework approach for CT solutions, so I am not sure if we need to specify a single transport protocol - if we go down a framework path. John _______________________________________________ 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 From seamoby-admin@ietf.org Fri Jul 19 12:22:18 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13056 for ; Fri, 19 Jul 2002 12:22:18 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA13624; Fri, 19 Jul 2002 12:18:44 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA13588 for ; Fri, 19 Jul 2002 12:18:41 -0400 (EDT) Received: from motgate.mot.com (motgate.mot.com [129.188.136.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12960 for ; Fri, 19 Jul 2002 12:17:41 -0400 (EDT) Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate.mot.com (motgate 2.1) with ESMTP id JAA28306 for ; Fri, 19 Jul 2002 09:18:41 -0700 (MST)] Received: [from il75exm04.cig.mot.com ([136.182.110.113]) by mothost.mot.com (MOT-pobox 2.0) with ESMTP id JAA08135 for ; Fri, 19 Jul 2002 09:18:54 -0700 (MST)] Received: by IL75EXM04 with Internet Mail Service (5.5.2654.52) id ; Fri, 19 Jul 2002 11:18:40 -0500 Message-ID: <35DBB8B7AC89D4118E98009027B1009B08AD55D5@IL27EXM10.cig.mot.com> From: Nakhjiri Madjid-MNAKHJI1 To: "'Gary Kenward'" , "'James Kempf'" , "Pat R. Calhoun" , Nakhjiri Madjid-MNAKHJI1 , seamoby@ietf.org Cc: mankin@psg.com Subject: RE: [Seamoby] Section 5.2 in CT Requirements Date: Fri, 19 Jul 2002 11:18:32 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.52) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C22F3F.ED0247F0" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C22F3F.ED0247F0 Content-Type: text/plain; charset="iso-8859-1" I think, in the interest of getting things forward, we should focus on what IESG wants now, not 1 year ago (BTW I didn't like the previous course of action we took). I think James is being constructive by suggesting reliability requirements and I added my modification on it. Lets go from there and get this going :) Madjid -----Original Message----- From: Gary Kenward [mailto:gkenward@nortelnetworks.com] Sent: Friday, July 19, 2002 9:48 AM To: 'James Kempf'; Pat R. Calhoun; Nakhjiri Madjid-MNAKHJI1; seamoby@ietf.org Cc: mankin@psg.com Subject: RE: [Seamoby] Section 5.2 in CT Requirements James: Frankly this discussion is getting silly - he said, she said. You may speculate forever what did or did not transpire, but I recall clearly the discussion, which included Allison, and the decision was to defer the work on a transport requirements until we started working on a solution. Note well, that this decision was made in order to get the requirements completed, which is the same goal you strive for. So, let's move on. If the IESG has commented that this section is inappropriate, or if the wg believes that it is inappropriate, then let's change it. And so, we have three choices: 1. Leave the section as is and see if the IESG buys the logic or not. (I personally think the IESG is smart enough to realize the complexity of the problem and the cart and horse situation we are dealing with here). 2. Remove the section entirely (which I don't think will fool anyone) 3. Attempt to resolve the issue (The last debate went on for, oh, about six months) If this is truly up to the wg, then perhaps you should as the wg which option is preferred. Gary > -----Original Message----- > From: James Kempf [ mailto:kempf@docomolabs-usa.com ] > Sent: July 19, 2002 09:04 > To: Pat R. Calhoun; Nakhjiri Madjid-MNAKHJI1; seamoby@ietf.org > Cc: mankin@psg.com > Subject: Re: [Seamoby] Section 5.2 in CT Requirements > > > Pat, > > > I know that there was concern by the IESG on this very > topic, and the idea of > > the above text was a compromise with the area director, who > was going to > > initiate a discussion with the transport directorate. > Unfortunately, this > > never occured, and the text remained. Allison had suggested > that we continue > > with the non-transport discussions and that this topic will > resurface again > > in the future. > > > > I don't think Allison intended that the document go to the > IESG with this text > in it, though I have not had an opportunity to speak with her > about it. But > ultimately > she is not responsible for the working group documents, that is the > working group's responsiblity. We should have pulled that > text out before we > sent it to the IESG, and, ideally, had something to replace > it. If, at that > point, the IESG had a technical disagreement with our > proposed requirement, > then we would have heard back. > > > The question is whether this can occur after the document > can be published > > (perhaps without the section). > > > > I think we at least have to propose a requirement, which is > what the text I sent > was intended to do. > > jak > > > > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > ------_=_NextPart_001_01C22F3F.ED0247F0 Content-Type: text/html; charset="iso-8859-1" RE: [Seamoby] Section 5.2 in CT Requirements
I think, in the interest of getting things forward, we should focus
on what IESG wants now, not 1 year ago (BTW I didn't like the
previous course of action we took). I think James is being constructive
by suggesting reliability requirements and I added my modification on it.
 
Lets go from there  and get this going :)
 
Madjid
-----Original Message-----
From: Gary Kenward [mailto:gkenward@nortelnetworks.com]
Sent: Friday, July 19, 2002 9:48 AM
To: 'James Kempf'; Pat R. Calhoun; Nakhjiri Madjid-MNAKHJI1; seamoby@ietf.org
Cc: mankin@psg.com
Subject: RE: [Seamoby] Section 5.2 in CT Requirements

James:

 Frankly this discussion is getting silly - he said, she said.
You may speculate forever what did or did not transpire, but I recall
clearly the discussion, which included Allison, and the decision was
to defer the work on a transport requirements until we started working
on a solution. Note well, that this decision was made in order to get
the requirements completed, which is the same goal you strive for.

 So, let's move on. If the IESG has commented that this section is
inappropriate, or if the wg believes that it is inappropriate, then
let's change it.

 And so, we have three choices:

   1. Leave the section as is and see if the IESG buys the logic or not.
      (I personally think the IESG is smart enough to realize the complexity
       of the problem and the cart and horse situation we are dealing with
       here).

   2. Remove the section entirely
      (which I don't think will fool anyone)

   3. Attempt to resolve the issue
      (The last debate went on for, oh, about six months)

If this is truly up to the wg, then perhaps you should as the wg which option
is preferred.

Gary

> -----Original Message-----
> From: James Kempf [mailto:kempf@docomolabs-usa.com]
> Sent: July 19, 2002 09:04
> To: Pat R. Calhoun; Nakhjiri Madjid-MNAKHJI1; seamoby@ietf.org
> Cc: mankin@psg.com
> Subject: Re: [Seamoby] Section 5.2 in CT Requirements
>
>
> Pat,
>
> > I know that there was concern by the IESG on this very
> topic, and the idea of
> > the above text was a compromise with the area director, who
> was going to
> > initiate a discussion with the transport directorate.
> Unfortunately, this
> > never occured, and the text remained. Allison had suggested
> that we continue
> > with the non-transport discussions and that this topic will
> resurface again
> > in the future.
> >
>
> I don't think Allison intended that the document go to the
> IESG with this text
> in it, though I have not had an opportunity to speak with her
> about it. But
> ultimately
> she is not responsible for the working group documents, that is the
> working group's responsiblity. We should have pulled that
> text out before we
> sent it to the IESG, and, ideally, had something to replace
> it. If, at that
> point, the IESG had a technical disagreement with our
> proposed requirement,
> then we would have heard back.
>
> > The question is whether this can occur after the document
> can be published
> > (perhaps without the section).
> >
>
> I think we at least have to propose a requirement, which is
> what the text I sent
> was intended to do.
>
>             jak
>
>
>
>
> _______________________________________________
> Seamoby mailing list
> Seamoby@ietf.org
> https://www1.ietf.org/mailman/listinfo/seamoby
>

------_=_NextPart_001_01C22F3F.ED0247F0-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Fri Jul 19 12:22:19 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13067 for ; Fri, 19 Jul 2002 12:22:18 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA13906 for seamoby-archive@odin.ietf.org; Fri, 19 Jul 2002 12:23:18 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA13624; Fri, 19 Jul 2002 12:18:44 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA13588 for ; Fri, 19 Jul 2002 12:18:41 -0400 (EDT) Received: from motgate.mot.com (motgate.mot.com [129.188.136.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12960 for ; Fri, 19 Jul 2002 12:17:41 -0400 (EDT) Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate.mot.com (motgate 2.1) with ESMTP id JAA28306 for ; Fri, 19 Jul 2002 09:18:41 -0700 (MST)] Received: [from il75exm04.cig.mot.com ([136.182.110.113]) by mothost.mot.com (MOT-pobox 2.0) with ESMTP id JAA08135 for ; Fri, 19 Jul 2002 09:18:54 -0700 (MST)] Received: by IL75EXM04 with Internet Mail Service (5.5.2654.52) id ; Fri, 19 Jul 2002 11:18:40 -0500 Message-ID: <35DBB8B7AC89D4118E98009027B1009B08AD55D5@IL27EXM10.cig.mot.com> From: Nakhjiri Madjid-MNAKHJI1 To: "'Gary Kenward'" , "'James Kempf'" , "Pat R. Calhoun" , Nakhjiri Madjid-MNAKHJI1 , seamoby@ietf.org Cc: mankin@psg.com Subject: RE: [Seamoby] Section 5.2 in CT Requirements Date: Fri, 19 Jul 2002 11:18:32 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.52) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C22F3F.ED0247F0" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C22F3F.ED0247F0 Content-Type: text/plain; charset="iso-8859-1" I think, in the interest of getting things forward, we should focus on what IESG wants now, not 1 year ago (BTW I didn't like the previous course of action we took). I think James is being constructive by suggesting reliability requirements and I added my modification on it. Lets go from there and get this going :) Madjid -----Original Message----- From: Gary Kenward [mailto:gkenward@nortelnetworks.com] Sent: Friday, July 19, 2002 9:48 AM To: 'James Kempf'; Pat R. Calhoun; Nakhjiri Madjid-MNAKHJI1; seamoby@ietf.org Cc: mankin@psg.com Subject: RE: [Seamoby] Section 5.2 in CT Requirements James: Frankly this discussion is getting silly - he said, she said. You may speculate forever what did or did not transpire, but I recall clearly the discussion, which included Allison, and the decision was to defer the work on a transport requirements until we started working on a solution. Note well, that this decision was made in order to get the requirements completed, which is the same goal you strive for. So, let's move on. If the IESG has commented that this section is inappropriate, or if the wg believes that it is inappropriate, then let's change it. And so, we have three choices: 1. Leave the section as is and see if the IESG buys the logic or not. (I personally think the IESG is smart enough to realize the complexity of the problem and the cart and horse situation we are dealing with here). 2. Remove the section entirely (which I don't think will fool anyone) 3. Attempt to resolve the issue (The last debate went on for, oh, about six months) If this is truly up to the wg, then perhaps you should as the wg which option is preferred. Gary > -----Original Message----- > From: James Kempf [ mailto:kempf@docomolabs-usa.com ] > Sent: July 19, 2002 09:04 > To: Pat R. Calhoun; Nakhjiri Madjid-MNAKHJI1; seamoby@ietf.org > Cc: mankin@psg.com > Subject: Re: [Seamoby] Section 5.2 in CT Requirements > > > Pat, > > > I know that there was concern by the IESG on this very > topic, and the idea of > > the above text was a compromise with the area director, who > was going to > > initiate a discussion with the transport directorate. > Unfortunately, this > > never occured, and the text remained. Allison had suggested > that we continue > > with the non-transport discussions and that this topic will > resurface again > > in the future. > > > > I don't think Allison intended that the document go to the > IESG with this text > in it, though I have not had an opportunity to speak with her > about it. But > ultimately > she is not responsible for the working group documents, that is the > working group's responsiblity. We should have pulled that > text out before we > sent it to the IESG, and, ideally, had something to replace > it. If, at that > point, the IESG had a technical disagreement with our > proposed requirement, > then we would have heard back. > > > The question is whether this can occur after the document > can be published > > (perhaps without the section). > > > > I think we at least have to propose a requirement, which is > what the text I sent > was intended to do. > > jak > > > > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > ------_=_NextPart_001_01C22F3F.ED0247F0 Content-Type: text/html; charset="iso-8859-1" RE: [Seamoby] Section 5.2 in CT Requirements
I think, in the interest of getting things forward, we should focus
on what IESG wants now, not 1 year ago (BTW I didn't like the
previous course of action we took). I think James is being constructive
by suggesting reliability requirements and I added my modification on it.
 
Lets go from there  and get this going :)
 
Madjid
-----Original Message-----
From: Gary Kenward [mailto:gkenward@nortelnetworks.com]
Sent: Friday, July 19, 2002 9:48 AM
To: 'James Kempf'; Pat R. Calhoun; Nakhjiri Madjid-MNAKHJI1; seamoby@ietf.org
Cc: mankin@psg.com
Subject: RE: [Seamoby] Section 5.2 in CT Requirements

James:

 Frankly this discussion is getting silly - he said, she said.
You may speculate forever what did or did not transpire, but I recall
clearly the discussion, which included Allison, and the decision was
to defer the work on a transport requirements until we started working
on a solution. Note well, that this decision was made in order to get
the requirements completed, which is the same goal you strive for.

 So, let's move on. If the IESG has commented that this section is
inappropriate, or if the wg believes that it is inappropriate, then
let's change it.

 And so, we have three choices:

   1. Leave the section as is and see if the IESG buys the logic or not.
      (I personally think the IESG is smart enough to realize the complexity
       of the problem and the cart and horse situation we are dealing with
       here).

   2. Remove the section entirely
      (which I don't think will fool anyone)

   3. Attempt to resolve the issue
      (The last debate went on for, oh, about six months)

If this is truly up to the wg, then perhaps you should as the wg which option
is preferred.

Gary

> -----Original Message-----
> From: James Kempf [mailto:kempf@docomolabs-usa.com]
> Sent: July 19, 2002 09:04
> To: Pat R. Calhoun; Nakhjiri Madjid-MNAKHJI1; seamoby@ietf.org
> Cc: mankin@psg.com
> Subject: Re: [Seamoby] Section 5.2 in CT Requirements
>
>
> Pat,
>
> > I know that there was concern by the IESG on this very
> topic, and the idea of
> > the above text was a compromise with the area director, who
> was going to
> > initiate a discussion with the transport directorate.
> Unfortunately, this
> > never occured, and the text remained. Allison had suggested
> that we continue
> > with the non-transport discussions and that this topic will
> resurface again
> > in the future.
> >
>
> I don't think Allison intended that the document go to the
> IESG with this text
> in it, though I have not had an opportunity to speak with her
> about it. But
> ultimately
> she is not responsible for the working group documents, that is the
> working group's responsiblity. We should have pulled that
> text out before we
> sent it to the IESG, and, ideally, had something to replace
> it. If, at that
> point, the IESG had a technical disagreement with our
> proposed requirement,
> then we would have heard back.
>
> > The question is whether this can occur after the document
> can be published
> > (perhaps without the section).
> >
>
> I think we at least have to propose a requirement, which is
> what the text I sent
> was intended to do.
>
>             jak
>
>
>
>
> _______________________________________________
> Seamoby mailing list
> Seamoby@ietf.org
> https://www1.ietf.org/mailman/listinfo/seamoby
>

------_=_NextPart_001_01C22F3F.ED0247F0-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Fri Jul 19 12:24:50 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13141 for ; Fri, 19 Jul 2002 12:24:50 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA13818; Fri, 19 Jul 2002 12:22:29 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA13788 for ; Fri, 19 Jul 2002 12:22:27 -0400 (EDT) Received: from ftpbox.mot.com (ftpbox.mot.com [129.188.136.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13019 for ; Fri, 19 Jul 2002 12:21:27 -0400 (EDT) Received: [from pobox4.mot.com (pobox4.mot.com [10.64.251.243]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id JAA26352 for ; Fri, 19 Jul 2002 09:22:26 -0700 (MST)] Received: [from il75exm04.cig.mot.com ([136.182.110.113]) by pobox4.mot.com (MOT-pobox4 2.0) with ESMTP id JAA02644 for ; Fri, 19 Jul 2002 09:22:26 -0700 (MST)] Received: by IL75EXM04 with Internet Mail Service (5.5.2654.52) id ; Fri, 19 Jul 2002 11:22:25 -0500 Message-ID: <35DBB8B7AC89D4118E98009027B1009B08AD55D6@IL27EXM10.cig.mot.com> From: Nakhjiri Madjid-MNAKHJI1 To: "'James Kempf'" , Nakhjiri Madjid-MNAKHJI1 , seamoby@ietf.org Subject: RE: [Seamoby] Proposal on Sync/NoSync Requirement Date: Fri, 19 Jul 2002 11:21:49 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.52) Content-Type: text/plain; charset="iso-8859-1" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org James, Thank you for your respond. Ok, if you say SHOULD NOT in RFC means NEED NOT, I am fine. I don't remember where it is all was defined. I think there are two issues I like to point out to: 1-In the CT requirement synchronization, referred to content synchronization, i.e. matching copies of states at oldAR and newAR each have and not and not time synchronization (as you mentioned CT-handover synch). I don't have any disagreements on CT-HO synch issue, that was reflected in the multi-phase CT requirements (already in there), i.e. critical context and non-critical context go in different phases. 2- I agree with you on what you said on CT being a container, blob type and all that stuff, we did all that in TEXT, however, There are things that no transport protocol can provide. Consider the following case as we described in TEXT: You are sending data and context at the same time. Say you are sending HC context and it get lost. The second time, oldAR must update HC context and send the updated version, it can't retransmit what it had sent first time. No transport protocol can do this for you. This is an update by application layer. If this can't be supported in CT, then CT is useless for such protocols. I don't know how a separate option, that is sent once, would solve this problem. Unless you somehow build this in CT-transport hook. If we reflect this in the requirement, then we are fine. Madjid -----Original Message----- From: James Kempf [mailto:kempf@docomolabs-usa.com] Sent: Friday, July 19, 2002 8:05 AM To: Nakhjiri Madjid-MNAKHJI1; seamoby@ietf.org Subject: Re: [Seamoby] Proposal on Sync/NoSync Requirement Madjid, > Don't know if we can use NEED Not (certainly fits for the first SHOULD NOT, since > that one sounds like we are advising against it). We should (SHOULD? :-) use RFC language. > How would you allow particular features get synch service, if there is no inbuild > mechanisms in CT? Because the CT protocol would be just a container format that could be reused by many different feature specific protocols. For example, one could use the CT container to define an option for use along with handover signaling to transfer header compression context. Or, one could use SCTP to transfer security, QoS, and AAA context not requiring any synchronization with the handover signaling. The latter would require a separate protocol description for how the container format is used with the particular transport. For most protocols, the two are bundled, but they are conceptually separate and here I can see reasons for separating them. > > I think we can talk about synchronization when there are two copies at > two different places. I think the solutions should seriously avoid this, > as we did in our proposal. Care should be taken so that you don't have to > update a context at both oldAR and newAR. I think as you said for header compression > context, you should have the context updated only at one location and when > it is only at one location, how can we call it synchronization? > Because it is synchronized with an external event, namely handover. With context that is not sync sensitive there is no requirement for synchronization with handover because the change in routing doesn't invalidate the context on the old router. Conversely, if the non-sync sensitive context is sent a bit early, there will similarly not be a problem. This is not to state that the non-sync sensitive context isn't dynamic, just that the event of handover doesn't invalidate it per se. > > You would on the other hand get problem with dynamic context, if > some context that you sent over, gets lost or corrupted. Once this happen > then, you can see whether the context has changed (in which case you need a refresh) > or not (you only need a retx). > Dynamic context means that it is changing as the mobile's traffic goes through the router, right? So I view that as requiring synchronization with an external event, namely handover. Something like accounting information would qualify, as well as header compression state. On the other hand, a user's SLA would not, because handover wouldn't invalidate it. jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Fri Jul 19 12:24:50 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13147 for ; Fri, 19 Jul 2002 12:24:50 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA14068 for seamoby-archive@odin.ietf.org; Fri, 19 Jul 2002 12:25:48 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA13818; Fri, 19 Jul 2002 12:22:29 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA13788 for ; Fri, 19 Jul 2002 12:22:27 -0400 (EDT) Received: from ftpbox.mot.com (ftpbox.mot.com [129.188.136.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13019 for ; Fri, 19 Jul 2002 12:21:27 -0400 (EDT) Received: [from pobox4.mot.com (pobox4.mot.com [10.64.251.243]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id JAA26352 for ; Fri, 19 Jul 2002 09:22:26 -0700 (MST)] Received: [from il75exm04.cig.mot.com ([136.182.110.113]) by pobox4.mot.com (MOT-pobox4 2.0) with ESMTP id JAA02644 for ; Fri, 19 Jul 2002 09:22:26 -0700 (MST)] Received: by IL75EXM04 with Internet Mail Service (5.5.2654.52) id ; Fri, 19 Jul 2002 11:22:25 -0500 Message-ID: <35DBB8B7AC89D4118E98009027B1009B08AD55D6@IL27EXM10.cig.mot.com> From: Nakhjiri Madjid-MNAKHJI1 To: "'James Kempf'" , Nakhjiri Madjid-MNAKHJI1 , seamoby@ietf.org Subject: RE: [Seamoby] Proposal on Sync/NoSync Requirement Date: Fri, 19 Jul 2002 11:21:49 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.52) Content-Type: text/plain; charset="iso-8859-1" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org James, Thank you for your respond. Ok, if you say SHOULD NOT in RFC means NEED NOT, I am fine. I don't remember where it is all was defined. I think there are two issues I like to point out to: 1-In the CT requirement synchronization, referred to content synchronization, i.e. matching copies of states at oldAR and newAR each have and not and not time synchronization (as you mentioned CT-handover synch). I don't have any disagreements on CT-HO synch issue, that was reflected in the multi-phase CT requirements (already in there), i.e. critical context and non-critical context go in different phases. 2- I agree with you on what you said on CT being a container, blob type and all that stuff, we did all that in TEXT, however, There are things that no transport protocol can provide. Consider the following case as we described in TEXT: You are sending data and context at the same time. Say you are sending HC context and it get lost. The second time, oldAR must update HC context and send the updated version, it can't retransmit what it had sent first time. No transport protocol can do this for you. This is an update by application layer. If this can't be supported in CT, then CT is useless for such protocols. I don't know how a separate option, that is sent once, would solve this problem. Unless you somehow build this in CT-transport hook. If we reflect this in the requirement, then we are fine. Madjid -----Original Message----- From: James Kempf [mailto:kempf@docomolabs-usa.com] Sent: Friday, July 19, 2002 8:05 AM To: Nakhjiri Madjid-MNAKHJI1; seamoby@ietf.org Subject: Re: [Seamoby] Proposal on Sync/NoSync Requirement Madjid, > Don't know if we can use NEED Not (certainly fits for the first SHOULD NOT, since > that one sounds like we are advising against it). We should (SHOULD? :-) use RFC language. > How would you allow particular features get synch service, if there is no inbuild > mechanisms in CT? Because the CT protocol would be just a container format that could be reused by many different feature specific protocols. For example, one could use the CT container to define an option for use along with handover signaling to transfer header compression context. Or, one could use SCTP to transfer security, QoS, and AAA context not requiring any synchronization with the handover signaling. The latter would require a separate protocol description for how the container format is used with the particular transport. For most protocols, the two are bundled, but they are conceptually separate and here I can see reasons for separating them. > > I think we can talk about synchronization when there are two copies at > two different places. I think the solutions should seriously avoid this, > as we did in our proposal. Care should be taken so that you don't have to > update a context at both oldAR and newAR. I think as you said for header compression > context, you should have the context updated only at one location and when > it is only at one location, how can we call it synchronization? > Because it is synchronized with an external event, namely handover. With context that is not sync sensitive there is no requirement for synchronization with handover because the change in routing doesn't invalidate the context on the old router. Conversely, if the non-sync sensitive context is sent a bit early, there will similarly not be a problem. This is not to state that the non-sync sensitive context isn't dynamic, just that the event of handover doesn't invalidate it per se. > > You would on the other hand get problem with dynamic context, if > some context that you sent over, gets lost or corrupted. Once this happen > then, you can see whether the context has changed (in which case you need a refresh) > or not (you only need a retx). > Dynamic context means that it is changing as the mobile's traffic goes through the router, right? So I view that as requiring synchronization with an external event, namely handover. Something like accounting information would qualify, as well as header compression state. On the other hand, a user's SLA would not, because handover wouldn't invalidate it. jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Fri Jul 19 18:29:32 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18353 for ; Fri, 19 Jul 2002 18:29:32 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA00329; Fri, 19 Jul 2002 18:28:32 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA00295 for ; Fri, 19 Jul 2002 18:28:30 -0400 (EDT) Received: from fridge.docomolabs-usa.com (fwuser@key1.docomolabs-usa.com [216.98.102.225]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18338 for ; Fri, 19 Jul 2002 18:27:30 -0400 (EDT) Message-ID: <002b01c22f73$5d22ee30$0f6015ac@T23KEMPF> From: "James Kempf" To: "Gary Kenward" , Cc: References: <9FBD322B7824D511B36900508BF93C9C01AA4C3F@zcard031.ca.nortel.com> Subject: Re: [Seamoby] Section 5.2 in CT Requirements Date: Fri, 19 Jul 2002 15:26:40 -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-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit Gary, Thanx for the history. I wasn't in the original discussion. I think we can might have an opportunity for concensus this time if we can agree that the generic CT protocol consists of a container format and a description of the rules for standardizing container contents. It would be up to the individual feature context standards to describe the transport. jak ----- Original Message ----- From: "Gary Kenward" To: "'James Kempf'" ; Cc: Sent: Friday, July 19, 2002 7:00 AM Subject: RE: [Seamoby] Section 5.2 in CT Requirements > The question is whether there is wg consensus. Which was not > reached at time of writing section 5. I'm not defending > the situation, simply informing you. Perhaps this time it will > not be an issue. > > The *technical* problem with your requirement - and I am only > trying to recapture what others objected to - was that there > was a significant number of people who wanted to define a > transport solution for CT, based upon CTs unique needs. Some > wanted transport capabilities built into CT. The melt down came > when the wg started debating these needs, as the CT solution was > not (and is not) defined, the transport needs are pure speculation, > or based upon individual approaches. Thus, the decision to defer the > CT transport evaluation until a CT solution - and the transport needs > - where better known. > > > BTW: the format you have used is not the standard format > decided upon by the working group, which was to use > section headers as the requirements (I believe this > was Pat's suggestion). One requirement per section. > > We can, of course, change the style, but all of > the requirements would have to be re-written. > > Gary > > > -----Original Message----- > > From: James Kempf [mailto:kempf@docomolabs-usa.com] > > Sent: July 18, 2002 18:59 > > To: Kenward, Gary [WDLN2:AN10:EXCH]; seamoby@ietf.org > > Cc: mankin@psg.com > > Subject: Re: [Seamoby] Section 5.2 in CT Requirements > > > > > > Gary, > > > > It isn't a question of debate. We've been talking about these > > requirements for a > > year and a half, it is time to complete them. > > We need to nail down this section. > > > > Do you have any specific technical comments on the requirement? > > > > jak > > > > ----- Original Message ----- > > From: "Gary Kenward" > > To: "'James Kempf'" ; > > Cc: > > Sent: Thursday, July 18, 2002 8:16 AM > > Subject: RE: [Seamoby] Section 5.2 in CT Requirements > > > > > > > James: > > > > > > There was a long and arduous debate over transport reliability. > > > The wording you are objecting to was, I believe, Allison's > > suggestion. > > > At the very lease, it was inserted with her approval in > > order to move > > > the requirements forward. > > > > > > Of course, you can open the debate again, but I don't expect it to > > > be resolved any better then it was the last time through. > > The problem > > > is that there seems to be some very different ideas in the wg as to > > > what the CT protocol looks like, with contradicting assumptions as > > > to what is needed from a transport layer. > > > > > > Gary > > > > > > > -----Original Message----- > > > > From: James Kempf [mailto:kempf@docomolabs-usa.com] > > > > Sent: July 18, 2002 07:14 > > > > To: seamoby@ietf.org > > > > Cc: mankin@psg.com > > > > Subject: [Seamoby] Section 5.2 in CT Requirements > > > > > > > > > > > > Folks, > > > > > > > > So recently I had another look at the CT Requirements > > > > document and I was > > > > suprised to find Section 5.2. It says this: > > > > > > > > 5.2 Transport Reliability > > > > > > > > This section is intentionally left blank as the > > > > working group is > > > > waiting for a questionnaire from the transport > > > > directorate. The result > > > > of the questionnaire will create requirements that > > > > will be added in this > > > > section in a later revision of this specification. > > > > > > > > It is completely unacceptable that we sent this document to > > > > the IESG with this > > > > section in it. When a document passes through last call, it > > > > should be complete. > > > > As WG chairs, Pat and I naturally must accept responsibility > > > > for this, but this > > > > should really have been caught in WG Last Call. > > > > > > > > I would like suggest replacing Section 5.2 with the following: > > > > > > > > 5.2 Transport Requirements > > > > > > > > This section contains requirements on the context > > > > transfer transport. > > > > > > > > 5.1 Independence of Underlying Transport > > > > > > > > The context transfer solution MUST be independent of > > > > the underlying > > > > transport. It SHOULD be possible to transfer > > > > context directly on top of reliable transports, such > > > > as TCP or SCTP, > > > > unreliable transports, such as UDP, or as an > > > > option or extention on another protocol, such as > > > > handover signaling. > > > > > > > > Comments? > > > > > > > > > > > > jak > > > > u > > > > > > > > > > > > > > > > _______________________________________________ > > > > 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 From daemon@ns.ietf.org Fri Jul 19 18:29:33 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18362 for ; Fri, 19 Jul 2002 18:29:33 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA00618 for seamoby-archive@odin.ietf.org; Fri, 19 Jul 2002 18:30:32 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA00329; Fri, 19 Jul 2002 18:28:32 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA00295 for ; Fri, 19 Jul 2002 18:28:30 -0400 (EDT) Received: from fridge.docomolabs-usa.com (fwuser@key1.docomolabs-usa.com [216.98.102.225]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18338 for ; Fri, 19 Jul 2002 18:27:30 -0400 (EDT) Message-ID: <002b01c22f73$5d22ee30$0f6015ac@T23KEMPF> From: "James Kempf" To: "Gary Kenward" , Cc: References: <9FBD322B7824D511B36900508BF93C9C01AA4C3F@zcard031.ca.nortel.com> Subject: Re: [Seamoby] Section 5.2 in CT Requirements Date: Fri, 19 Jul 2002 15:26:40 -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-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit Gary, Thanx for the history. I wasn't in the original discussion. I think we can might have an opportunity for concensus this time if we can agree that the generic CT protocol consists of a container format and a description of the rules for standardizing container contents. It would be up to the individual feature context standards to describe the transport. jak ----- Original Message ----- From: "Gary Kenward" To: "'James Kempf'" ; Cc: Sent: Friday, July 19, 2002 7:00 AM Subject: RE: [Seamoby] Section 5.2 in CT Requirements > The question is whether there is wg consensus. Which was not > reached at time of writing section 5. I'm not defending > the situation, simply informing you. Perhaps this time it will > not be an issue. > > The *technical* problem with your requirement - and I am only > trying to recapture what others objected to - was that there > was a significant number of people who wanted to define a > transport solution for CT, based upon CTs unique needs. Some > wanted transport capabilities built into CT. The melt down came > when the wg started debating these needs, as the CT solution was > not (and is not) defined, the transport needs are pure speculation, > or based upon individual approaches. Thus, the decision to defer the > CT transport evaluation until a CT solution - and the transport needs > - where better known. > > > BTW: the format you have used is not the standard format > decided upon by the working group, which was to use > section headers as the requirements (I believe this > was Pat's suggestion). One requirement per section. > > We can, of course, change the style, but all of > the requirements would have to be re-written. > > Gary > > > -----Original Message----- > > From: James Kempf [mailto:kempf@docomolabs-usa.com] > > Sent: July 18, 2002 18:59 > > To: Kenward, Gary [WDLN2:AN10:EXCH]; seamoby@ietf.org > > Cc: mankin@psg.com > > Subject: Re: [Seamoby] Section 5.2 in CT Requirements > > > > > > Gary, > > > > It isn't a question of debate. We've been talking about these > > requirements for a > > year and a half, it is time to complete them. > > We need to nail down this section. > > > > Do you have any specific technical comments on the requirement? > > > > jak > > > > ----- Original Message ----- > > From: "Gary Kenward" > > To: "'James Kempf'" ; > > Cc: > > Sent: Thursday, July 18, 2002 8:16 AM > > Subject: RE: [Seamoby] Section 5.2 in CT Requirements > > > > > > > James: > > > > > > There was a long and arduous debate over transport reliability. > > > The wording you are objecting to was, I believe, Allison's > > suggestion. > > > At the very lease, it was inserted with her approval in > > order to move > > > the requirements forward. > > > > > > Of course, you can open the debate again, but I don't expect it to > > > be resolved any better then it was the last time through. > > The problem > > > is that there seems to be some very different ideas in the wg as to > > > what the CT protocol looks like, with contradicting assumptions as > > > to what is needed from a transport layer. > > > > > > Gary > > > > > > > -----Original Message----- > > > > From: James Kempf [mailto:kempf@docomolabs-usa.com] > > > > Sent: July 18, 2002 07:14 > > > > To: seamoby@ietf.org > > > > Cc: mankin@psg.com > > > > Subject: [Seamoby] Section 5.2 in CT Requirements > > > > > > > > > > > > Folks, > > > > > > > > So recently I had another look at the CT Requirements > > > > document and I was > > > > suprised to find Section 5.2. It says this: > > > > > > > > 5.2 Transport Reliability > > > > > > > > This section is intentionally left blank as the > > > > working group is > > > > waiting for a questionnaire from the transport > > > > directorate. The result > > > > of the questionnaire will create requirements that > > > > will be added in this > > > > section in a later revision of this specification. > > > > > > > > It is completely unacceptable that we sent this document to > > > > the IESG with this > > > > section in it. When a document passes through last call, it > > > > should be complete. > > > > As WG chairs, Pat and I naturally must accept responsibility > > > > for this, but this > > > > should really have been caught in WG Last Call. > > > > > > > > I would like suggest replacing Section 5.2 with the following: > > > > > > > > 5.2 Transport Requirements > > > > > > > > This section contains requirements on the context > > > > transfer transport. > > > > > > > > 5.1 Independence of Underlying Transport > > > > > > > > The context transfer solution MUST be independent of > > > > the underlying > > > > transport. It SHOULD be possible to transfer > > > > context directly on top of reliable transports, such > > > > as TCP or SCTP, > > > > unreliable transports, such as UDP, or as an > > > > option or extention on another protocol, such as > > > > handover signaling. > > > > > > > > Comments? > > > > > > > > > > > > jak > > > > u > > > > > > > > > > > > > > > > _______________________________________________ > > > > 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 From seamoby-admin@ietf.org Fri Jul 19 18:32:05 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18407 for ; Fri, 19 Jul 2002 18:32:05 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA00249; Fri, 19 Jul 2002 18:26:09 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA00223 for ; Fri, 19 Jul 2002 18:26:07 -0400 (EDT) Received: from fridge.docomolabs-usa.com (fwuser@key1.docomolabs-usa.com [216.98.102.225]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18319 for ; Fri, 19 Jul 2002 18:25:07 -0400 (EDT) Message-ID: <002801c22f73$09a136e0$0f6015ac@T23KEMPF> From: "James Kempf" To: "John Loughney" , Cc: References: <0C1353ABB1DEB74DB067ADFF749C4EEFC6579F@esebe004.NOE.Nokia.com> Subject: Re: [Seamoby] Section 5.2 in CT Requirements Date: Fri, 19 Jul 2002 15:11:23 -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-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit John, > A suggestion. Could we ask from Allison to defer this discussion (i.e. - > drop the requirement completely from the requirements). A much better > way forward would be someone to produce a short document discussing > different protocols that CT could use. The pros & cons of each. > > I am OK with doing this, but I think I would like to get some comment first on the requirement I proposed. Perhaps we could run the comment period for a week, then have last call on that requirement. jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@ns.ietf.org Fri Jul 19 18:32:06 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18412 for ; Fri, 19 Jul 2002 18:32:05 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA00959 for seamoby-archive@odin.ietf.org; Fri, 19 Jul 2002 18:33:04 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA00249; Fri, 19 Jul 2002 18:26:09 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA00223 for ; Fri, 19 Jul 2002 18:26:07 -0400 (EDT) Received: from fridge.docomolabs-usa.com (fwuser@key1.docomolabs-usa.com [216.98.102.225]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18319 for ; Fri, 19 Jul 2002 18:25:07 -0400 (EDT) Message-ID: <002801c22f73$09a136e0$0f6015ac@T23KEMPF> From: "James Kempf" To: "John Loughney" , Cc: References: <0C1353ABB1DEB74DB067ADFF749C4EEFC6579F@esebe004.NOE.Nokia.com> Subject: Re: [Seamoby] Section 5.2 in CT Requirements Date: Fri, 19 Jul 2002 15:11:23 -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-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit John, > A suggestion. Could we ask from Allison to defer this discussion (i.e. - > drop the requirement completely from the requirements). A much better > way forward would be someone to produce a short document discussing > different protocols that CT could use. The pros & cons of each. > > I am OK with doing this, but I think I would like to get some comment first on the requirement I proposed. Perhaps we could run the comment period for a week, then have last call on that requirement. jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Fri Jul 19 20:52:31 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA20949 for ; Fri, 19 Jul 2002 20:52:31 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA12143; Fri, 19 Jul 2002 20:48:29 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA12112 for ; Fri, 19 Jul 2002 20:48:27 -0400 (EDT) Received: from fridge.docomolabs-usa.com (fwuser@key1.docomolabs-usa.com [216.98.102.225]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA20844 for ; Fri, 19 Jul 2002 20:47:27 -0400 (EDT) Message-ID: <00d201c22f86$e9144ca0$0f6015ac@T23KEMPF> From: "James Kempf" To: "Gary Kenward" , "'Nakhjiri Madjid-MNAKHJI1'" , References: <9FBD322B7824D511B36900508BF93C9C01AA4C41@zcard031.ca.nortel.com> Date: Fri, 19 Jul 2002 17:46:36 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Seamoby] Section 5.5 Modifications Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit Hi Gary, > I get the impression that either everyone has forgotten about proactive > CT, or does > not care. Which is too bad, for the boy scouts are right on when they say > "be prepared". > Thanx for reminding me, being an old Boy Scout myself I should have remembered. :-) How about if we modify the text I sent out as below? In addition, I think we need an additional section, which I will post on a separate thread, that describes the steps needed to standardize a feature context. This text will include a requirement for update on feature contexts that are not tightly synchronized with external events. jak ------------------------------------------------------------ 5.5 Context Update and Synchronization 5.5.1 The base context transfer protocol SHOULD NOT provide direct support for synchronization with outside events, since synchronization is not a requirement for all or even most feature contexts. 5.5.2 The base context transfer protocol MUST allow individual feature context specifications to define their own synchronization with external events. 5.5.3 The base context transfer protocol SHOULD NOT provide support for updating context after it is transfered, since individual feature contexts will differ in their need for update. 5.5.4 The base context transfer protocol MUST allow individual feature context specifications to define their own update procedures if required. Most feature contexts will not require synchronization, however there are a few that may. Header compression, for example, may require that the header compressor on the old access router cease and the compressor on the new router start in synchrony with hand over of routing to the new router; otherwise, the compressor on the new router will not be properly synchronized. Since most contexts don't need synchronization support, the general CT solution need not support it, but it should not provide a hinderance to those feature contexts that do. Feature contexts will differ in whether or not they require update. A feature context such as QoS parameters for the service level agreement with a user may not involve dynamically changing information, but it may change during or after context transfer. Such feature contexts may benefit from allowing the context to change after the transfer is completed. Other feature contexts, such as header compression, may be tightly synchronized with external events and changes on the old router need to be discarded since the new router's state may already have been modified. _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@ns.ietf.org Fri Jul 19 20:52:32 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA20956 for ; Fri, 19 Jul 2002 20:52:32 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id UAA12218 for seamoby-archive@odin.ietf.org; Fri, 19 Jul 2002 20:53:30 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA12143; Fri, 19 Jul 2002 20:48:29 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA12112 for ; Fri, 19 Jul 2002 20:48:27 -0400 (EDT) Received: from fridge.docomolabs-usa.com (fwuser@key1.docomolabs-usa.com [216.98.102.225]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA20844 for ; Fri, 19 Jul 2002 20:47:27 -0400 (EDT) Message-ID: <00d201c22f86$e9144ca0$0f6015ac@T23KEMPF> From: "James Kempf" To: "Gary Kenward" , "'Nakhjiri Madjid-MNAKHJI1'" , References: <9FBD322B7824D511B36900508BF93C9C01AA4C41@zcard031.ca.nortel.com> Date: Fri, 19 Jul 2002 17:46:36 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Seamoby] Section 5.5 Modifications Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit Hi Gary, > I get the impression that either everyone has forgotten about proactive > CT, or does > not care. Which is too bad, for the boy scouts are right on when they say > "be prepared". > Thanx for reminding me, being an old Boy Scout myself I should have remembered. :-) How about if we modify the text I sent out as below? In addition, I think we need an additional section, which I will post on a separate thread, that describes the steps needed to standardize a feature context. This text will include a requirement for update on feature contexts that are not tightly synchronized with external events. jak ------------------------------------------------------------ 5.5 Context Update and Synchronization 5.5.1 The base context transfer protocol SHOULD NOT provide direct support for synchronization with outside events, since synchronization is not a requirement for all or even most feature contexts. 5.5.2 The base context transfer protocol MUST allow individual feature context specifications to define their own synchronization with external events. 5.5.3 The base context transfer protocol SHOULD NOT provide support for updating context after it is transfered, since individual feature contexts will differ in their need for update. 5.5.4 The base context transfer protocol MUST allow individual feature context specifications to define their own update procedures if required. Most feature contexts will not require synchronization, however there are a few that may. Header compression, for example, may require that the header compressor on the old access router cease and the compressor on the new router start in synchrony with hand over of routing to the new router; otherwise, the compressor on the new router will not be properly synchronized. Since most contexts don't need synchronization support, the general CT solution need not support it, but it should not provide a hinderance to those feature contexts that do. Feature contexts will differ in whether or not they require update. A feature context such as QoS parameters for the service level agreement with a user may not involve dynamically changing information, but it may change during or after context transfer. Such feature contexts may benefit from allowing the context to change after the transfer is completed. Other feature contexts, such as header compression, may be tightly synchronized with external events and changes on the old router need to be discarded since the new router's state may already have been modified. _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Fri Jul 19 21:07:56 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA21199 for ; Fri, 19 Jul 2002 21:07:56 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA13104; Fri, 19 Jul 2002 21:05:52 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA13073 for ; Fri, 19 Jul 2002 21:05:50 -0400 (EDT) Received: from fridge.docomolabs-usa.com (fwuser@key1.docomolabs-usa.com [216.98.102.225]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA21166 for ; Fri, 19 Jul 2002 21:04:51 -0400 (EDT) Message-ID: <00db01c22f89$4a972680$0f6015ac@T23KEMPF> From: "James Kempf" To: "Gary Kenward" , "Nakhjiri Madjid-MNAKHJI1" , References: <9FBD322B7824D511B36900508BF93C9C01AA4C46@zcard031.ca.nortel.com> Date: Fri, 19 Jul 2002 18:03:39 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Seamoby] Difficulty of Achieving Precision on Certain Requiremnts Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit Gary, > So you are proposing now that there are also feature specific > CT protocols? If this is true, and we follow your argument, > the we need to revisit all the attributes stated for CT: reliability, > timeliness, etc., etc. to determine what capabilities should be > common, and what capabilities should be feature specific. > Do you really think this is necessary? I just looked through the requirements and they all looked pretty general to me. If you think there are some specific requirements that would need updating, please post suggested modifications to the list. Best would be a separate thread per requirement, so that people can follow. > As far as updates go, I think it is a common capability. > Others don't agree, and they have examples which are convincing, such as header compression transfer (this one came up in coversations with the IESG this week). I was not involved in the initial discusssions on CT so I do not have the history on it. But I also don't have a lot invested in a particular outcome. I would like the WG to achieve concensus on a set of requirements that are specific enough to pass IESG muster, so that we can procced on to actually designing the protocol. My observation, over the last couple weeks of mailing list traffic and talking to some people involved, is that the requirements are not sufficiently crisp in places where people have very different ideas about what types of feature contexts they want to transfer. These include: 1) Update allowed v.s. prohibited. 2) Tight synchronization with external events v.s. no synchronization. 3) What transport to use. Trying to specify requirements in these areas for a general context transfer protocol when people have legitimate but very different notions of what they want to use the protocol for that would result in very different feature specific requirements can't succeed. In a separate thread, I will propose a new section that specifies requirements on specifications for individual feature contexts. Note that this proposal will not contain requirements on the feature contexts themselves, but only on their specifications. These will address the issues above. jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@ns.ietf.org Fri Jul 19 21:07:56 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA21205 for ; Fri, 19 Jul 2002 21:07:56 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id VAA13228 for seamoby-archive@odin.ietf.org; Fri, 19 Jul 2002 21:08:55 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA13104; Fri, 19 Jul 2002 21:05:52 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA13073 for ; Fri, 19 Jul 2002 21:05:50 -0400 (EDT) Received: from fridge.docomolabs-usa.com (fwuser@key1.docomolabs-usa.com [216.98.102.225]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA21166 for ; Fri, 19 Jul 2002 21:04:51 -0400 (EDT) Message-ID: <00db01c22f89$4a972680$0f6015ac@T23KEMPF> From: "James Kempf" To: "Gary Kenward" , "Nakhjiri Madjid-MNAKHJI1" , References: <9FBD322B7824D511B36900508BF93C9C01AA4C46@zcard031.ca.nortel.com> Date: Fri, 19 Jul 2002 18:03:39 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Seamoby] Difficulty of Achieving Precision on Certain Requiremnts Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit Gary, > So you are proposing now that there are also feature specific > CT protocols? If this is true, and we follow your argument, > the we need to revisit all the attributes stated for CT: reliability, > timeliness, etc., etc. to determine what capabilities should be > common, and what capabilities should be feature specific. > Do you really think this is necessary? I just looked through the requirements and they all looked pretty general to me. If you think there are some specific requirements that would need updating, please post suggested modifications to the list. Best would be a separate thread per requirement, so that people can follow. > As far as updates go, I think it is a common capability. > Others don't agree, and they have examples which are convincing, such as header compression transfer (this one came up in coversations with the IESG this week). I was not involved in the initial discusssions on CT so I do not have the history on it. But I also don't have a lot invested in a particular outcome. I would like the WG to achieve concensus on a set of requirements that are specific enough to pass IESG muster, so that we can procced on to actually designing the protocol. My observation, over the last couple weeks of mailing list traffic and talking to some people involved, is that the requirements are not sufficiently crisp in places where people have very different ideas about what types of feature contexts they want to transfer. These include: 1) Update allowed v.s. prohibited. 2) Tight synchronization with external events v.s. no synchronization. 3) What transport to use. Trying to specify requirements in these areas for a general context transfer protocol when people have legitimate but very different notions of what they want to use the protocol for that would result in very different feature specific requirements can't succeed. In a separate thread, I will propose a new section that specifies requirements on specifications for individual feature contexts. Note that this proposal will not contain requirements on the feature contexts themselves, but only on their specifications. These will address the issues above. jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Fri Jul 19 21:32:04 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA21463 for ; Fri, 19 Jul 2002 21:32:04 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA13495; Fri, 19 Jul 2002 21:27:43 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA13429 for ; Fri, 19 Jul 2002 21:27:39 -0400 (EDT) Received: from fridge.docomolabs-usa.com (fwuser@key1.docomolabs-usa.com [216.98.102.225]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA21382 for ; Fri, 19 Jul 2002 21:26:40 -0400 (EDT) Message-ID: <00e101c22f8c$68717c70$0f6015ac@T23KEMPF> From: "James Kempf" To: Date: Fri, 19 Jul 2002 18:25:58 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Seamoby] New Section 5.8 - Requirements on Feature Context Specifications Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit I'd like to propose the following new section for the CT requirments listing requirements on feature context specifications. Note that this section does not place requirements on the feature context protocols themselves, but only on their specifications. jak ------------------------------------------ 5.8 Feature Context Specifications The context transfer protocol provides a basic framework in which feature contexts of varying types can be transfered. Recognizing that the particular feature contexts may have very different needs with regard to update, synchronization, and transport, this section contains requirements on the feature context specifications. Note that these requirements do not constrain the actual feature context protocols themselves, but only their specification. 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. 5.8.2 A feature context specification MUST define the byte layout of the individual elements of the feature context, and how those map into the context transfer protocol's container. The byte layout SHOULD obey standard IETF conventions with regard to mapping of data into on the wire format. 5.8.3 A feature context specification MUST define the transport to be used. If the feature context is transferred using an IETF transport layer protocol , then the feature context specification MUST include the full details of how the transport layer protocol is used. 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 through a non-IETF protocol (such as IAPP [4]), then the feature context protocol specification MUST define how the standard context transfer container is mapped into the non-IETF transport. 5.8.4 A feature context specification MUST indicate whether update to context information is allowed if changes in the source occur after the context is transferred. If such changes are allowed, the feature context specification MUST define the change protocol message format using the standard context transfer container, and MUST include details of how the update is accomplished. 5.8.5 A feature context specification MUST indicate whether the context transfer is tightly synchronized with external events, such as handover. The freature context specification MUST indicate what event or events trigger transfer. 6.0 References [4] "Recommended Practice for Multi-vendor Interaccess Point Interoperability via an Inter-access Point Protocol Across Distribution Systems Supporting IEEE 802.11 Operation," IEEE Std. 802.11f/D3, January, 2002. _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@ns.ietf.org Fri Jul 19 21:32:05 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA21469 for ; Fri, 19 Jul 2002 21:32:04 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id VAA14107 for seamoby-archive@odin.ietf.org; Fri, 19 Jul 2002 21:33:03 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA13495; Fri, 19 Jul 2002 21:27:43 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA13429 for ; Fri, 19 Jul 2002 21:27:39 -0400 (EDT) Received: from fridge.docomolabs-usa.com (fwuser@key1.docomolabs-usa.com [216.98.102.225]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA21382 for ; Fri, 19 Jul 2002 21:26:40 -0400 (EDT) Message-ID: <00e101c22f8c$68717c70$0f6015ac@T23KEMPF> From: "James Kempf" To: Date: Fri, 19 Jul 2002 18:25:58 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Seamoby] New Section 5.8 - Requirements on Feature Context Specifications Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit I'd like to propose the following new section for the CT requirments listing requirements on feature context specifications. Note that this section does not place requirements on the feature context protocols themselves, but only on their specifications. jak ------------------------------------------ 5.8 Feature Context Specifications The context transfer protocol provides a basic framework in which feature contexts of varying types can be transfered. Recognizing that the particular feature contexts may have very different needs with regard to update, synchronization, and transport, this section contains requirements on the feature context specifications. Note that these requirements do not constrain the actual feature context protocols themselves, but only their specification. 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. 5.8.2 A feature context specification MUST define the byte layout of the individual elements of the feature context, and how those map into the context transfer protocol's container. The byte layout SHOULD obey standard IETF conventions with regard to mapping of data into on the wire format. 5.8.3 A feature context specification MUST define the transport to be used. If the feature context is transferred using an IETF transport layer protocol , then the feature context specification MUST include the full details of how the transport layer protocol is used. 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 through a non-IETF protocol (such as IAPP [4]), then the feature context protocol specification MUST define how the standard context transfer container is mapped into the non-IETF transport. 5.8.4 A feature context specification MUST indicate whether update to context information is allowed if changes in the source occur after the context is transferred. If such changes are allowed, the feature context specification MUST define the change protocol message format using the standard context transfer container, and MUST include details of how the update is accomplished. 5.8.5 A feature context specification MUST indicate whether the context transfer is tightly synchronized with external events, such as handover. The freature context specification MUST indicate what event or events trigger transfer. 6.0 References [4] "Recommended Practice for Multi-vendor Interaccess Point Interoperability via an Inter-access Point Protocol Across Distribution Systems Supporting IEEE 802.11 Operation," IEEE Std. 802.11f/D3, January, 2002. _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Sun Jul 21 23:45:12 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA15834 for ; Sun, 21 Jul 2002 23:45:12 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA08417; Sun, 21 Jul 2002 23:42:44 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA08379 for ; Sun, 21 Jul 2002 23:42:41 -0400 (EDT) Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA15689 for ; Sun, 21 Jul 2002 23:41:40 -0400 (EDT) From: john.loughney@nokia.com Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x3.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g6M3ijW12816 for ; Mon, 22 Jul 2002 06:44:45 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 22 Jul 2002 06:42:39 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Mon, 22 Jul 2002 06:42:39 +0300 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Seamoby] Section 5.2 in CT Requirements X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Date: Mon, 22 Jul 2002 06:42:39 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEF0113083E@esebe004.NOE.Nokia.com> Thread-Topic: [Seamoby] Section 5.2 in CT Requirements Thread-Index: AcIvPTp7aGbHxfHlRbSIA7t0G3KovAA3gz4A To: , Cc: X-OriginalArrivalTime: 22 Jul 2002 03:42:39.0765 (UTC) FILETIME=[D3E05C50:01C23131] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id XAA08380 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 8bit Hi Madjid, > I think this will just delay things, the reason: > you need to look at each protocol individually and determine > its reliability needs, not to mention design scenarios for every > person's network. > > Not to mention that you have found somebody who wants to do this > study :) I think we have waited long enough for requirement. What I think we want to do is progress the requirements, without a detailed discussion on reliability, as that has been a rathole. I think we need a short document, listing some transport options, and with some pro's & con's. This could be a living document. I'd be happy to edit folks suggestions into a document. I see the following options: 1) ICMP 2) UDP 3) TCP a) reuse existing TCP connections b) dynamic TCP connections 4) SCTP a) reuse existing TCP connections b) dynamic TCP connections c) PR-SCTP 5) DCCP 6) other a) routing protocol extensions b) ? John _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Sun Jul 21 23:45:12 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA15839 for ; Sun, 21 Jul 2002 23:45:12 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id XAA08530 for seamoby-archive@odin.ietf.org; Sun, 21 Jul 2002 23:46:13 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA08417; Sun, 21 Jul 2002 23:42:44 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA08379 for ; Sun, 21 Jul 2002 23:42:41 -0400 (EDT) Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA15689 for ; Sun, 21 Jul 2002 23:41:40 -0400 (EDT) From: john.loughney@nokia.com Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x3.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g6M3ijW12816 for ; Mon, 22 Jul 2002 06:44:45 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 22 Jul 2002 06:42:39 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Mon, 22 Jul 2002 06:42:39 +0300 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Seamoby] Section 5.2 in CT Requirements X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Date: Mon, 22 Jul 2002 06:42:39 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEF0113083E@esebe004.NOE.Nokia.com> Thread-Topic: [Seamoby] Section 5.2 in CT Requirements Thread-Index: AcIvPTp7aGbHxfHlRbSIA7t0G3KovAA3gz4A To: , Cc: X-OriginalArrivalTime: 22 Jul 2002 03:42:39.0765 (UTC) FILETIME=[D3E05C50:01C23131] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id XAA08380 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 8bit Hi Madjid, > I think this will just delay things, the reason: > you need to look at each protocol individually and determine > its reliability needs, not to mention design scenarios for every > person's network. > > Not to mention that you have found somebody who wants to do this > study :) I think we have waited long enough for requirement. What I think we want to do is progress the requirements, without a detailed discussion on reliability, as that has been a rathole. I think we need a short document, listing some transport options, and with some pro's & con's. This could be a living document. I'd be happy to edit folks suggestions into a document. I see the following options: 1) ICMP 2) UDP 3) TCP a) reuse existing TCP connections b) dynamic TCP connections 4) SCTP a) reuse existing TCP connections b) dynamic TCP connections c) PR-SCTP 5) DCCP 6) other a) routing protocol extensions b) ? John _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Sun Jul 21 23:45:22 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA15866 for ; Sun, 21 Jul 2002 23:45:22 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA08442; Sun, 21 Jul 2002 23:42:45 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA08377 for ; Sun, 21 Jul 2002 23:42:41 -0400 (EDT) Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA15688 for ; Sun, 21 Jul 2002 23:41:39 -0400 (EDT) From: john.loughney@nokia.com Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g6M3f2d20806 for ; Mon, 22 Jul 2002 06:41:02 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 22 Jul 2002 06:42:38 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Mon, 22 Jul 2002 06:42:38 +0300 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Seamoby] Section 5.2 in CT Requirements X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Date: Mon, 22 Jul 2002 06:42:37 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEF0113083D@esebe004.NOE.Nokia.com> Thread-Topic: [Seamoby] Section 5.2 in CT Requirements Thread-Index: AcIvLOKEKWvA0gTpQkGQQ7BqBCi9awAUjw3w To: , Cc: X-OriginalArrivalTime: 22 Jul 2002 03:42:38.0452 (UTC) FILETIME=[D3180340:01C23131] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id XAA08386 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 8bit Hi James I disagree with your requirement, because I don't see a lot of meaning and/or use in it. I think that different context may have different need. Timelyness & reliability are 2 different and opposing needs. This is directly relatable to the earlier discussion on dynamicisity of context. A situation could occur where a context goes stale during re-transmission when running over a reliable protocol. Some other context, such as security may not time out, unless the end-user completely times out of the user-session. Besides going stale, it is entirely possible that some context may be superceded. As this issue is fairly complex and intertwined with the context being transfered, I suggest we don't have a reliability requirement, but rather we try to do an analysis of the reliability needs and then take this into the solution. Additionally, I don't think that we want to get into defining new transport protocols or behaviors. John === 5.2 Transport Requirements This section contains requirements on the context transfer transport. 5.1 Independence of Underlying Transport The context transfer solution MUST be independent of the underlying transport. It SHOULD be possible to transfer context directly on top of reliable transports, such as TCP or SCTP, unreliable transports, such as UDP, or as an option or extention on another protocol, such as handover signaling. _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Sun Jul 21 23:45:22 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA15879 for ; Sun, 21 Jul 2002 23:45:22 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id XAA08541 for seamoby-archive@odin.ietf.org; Sun, 21 Jul 2002 23:46:23 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA08442; Sun, 21 Jul 2002 23:42:45 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA08377 for ; Sun, 21 Jul 2002 23:42:41 -0400 (EDT) Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA15688 for ; Sun, 21 Jul 2002 23:41:39 -0400 (EDT) From: john.loughney@nokia.com Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g6M3f2d20806 for ; Mon, 22 Jul 2002 06:41:02 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 22 Jul 2002 06:42:38 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Mon, 22 Jul 2002 06:42:38 +0300 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Seamoby] Section 5.2 in CT Requirements X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Date: Mon, 22 Jul 2002 06:42:37 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEF0113083D@esebe004.NOE.Nokia.com> Thread-Topic: [Seamoby] Section 5.2 in CT Requirements Thread-Index: AcIvLOKEKWvA0gTpQkGQQ7BqBCi9awAUjw3w To: , Cc: X-OriginalArrivalTime: 22 Jul 2002 03:42:38.0452 (UTC) FILETIME=[D3180340:01C23131] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id XAA08386 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 8bit Hi James I disagree with your requirement, because I don't see a lot of meaning and/or use in it. I think that different context may have different need. Timelyness & reliability are 2 different and opposing needs. This is directly relatable to the earlier discussion on dynamicisity of context. A situation could occur where a context goes stale during re-transmission when running over a reliable protocol. Some other context, such as security may not time out, unless the end-user completely times out of the user-session. Besides going stale, it is entirely possible that some context may be superceded. As this issue is fairly complex and intertwined with the context being transfered, I suggest we don't have a reliability requirement, but rather we try to do an analysis of the reliability needs and then take this into the solution. Additionally, I don't think that we want to get into defining new transport protocols or behaviors. John === 5.2 Transport Requirements This section contains requirements on the context transfer transport. 5.1 Independence of Underlying Transport The context transfer solution MUST be independent of the underlying transport. It SHOULD be possible to transfer context directly on top of reliable transports, such as TCP or SCTP, unreliable transports, such as UDP, or as an option or extention on another protocol, such as handover signaling. _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Mon Jul 22 11:39:50 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07843 for ; Mon, 22 Jul 2002 11:39:50 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA26364; Mon, 22 Jul 2002 11:37:28 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA26338 for ; Mon, 22 Jul 2002 11:37:26 -0400 (EDT) Received: from motgate.mot.com (motgate.mot.com [129.188.136.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07740 for ; Mon, 22 Jul 2002 11:36:24 -0400 (EDT) Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate.mot.com (motgate 2.1) with ESMTP id IAA24758 for ; Mon, 22 Jul 2002 08:37:25 -0700 (MST)] Received: [from il27exm07.cig.mot.com (IL27EXM07.cig.mot.com [136.182.15.116]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id IAA14206 for ; Mon, 22 Jul 2002 08:37:25 -0700 (MST)] Received: by IL27EXM07.cig.mot.com with Internet Mail Service (5.5.2654.52) id <3FLZ5GPM>; Mon, 22 Jul 2002 10:37:24 -0500 Message-ID: <35DBB8B7AC89D4118E98009027B1009B08AD55DC@IL27EXM10.cig.mot.com> From: Nakhjiri Madjid-MNAKHJI1 To: "'James Kempf'" , Gary Kenward , Nakhjiri Madjid-MNAKHJI1 , seamoby@ietf.org Date: Mon, 22 Jul 2002 10:37:24 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.52) Content-Type: text/plain; charset="iso-8859-1" Subject: [Seamoby] RE: Section 5.5 Modifications Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Well, I am maybe not as good of a boy scout as some others but, I remember 3 weeks of debate, followed by a period of 2 months of silence and then a 90 minute discussion in London (not to mention the 3$K trip expense :) ) that lead to us not making reactive or proactive CT as a basis for the CT usefulness debate. Lets not open that barrel of snakes (certainly bigger than worms) again. If you want to mention proactive a byproduct, or use case, that is fine. But I think we should be careful about making a byproduct a primary goal. Regards, Madjid -----Original Message----- From: James Kempf [mailto:kempf@docomolabs-usa.com] Sent: Friday, July 19, 2002 7:47 PM To: Gary Kenward; 'Nakhjiri Madjid-MNAKHJI1'; seamoby@ietf.org Subject: Section 5.5 Modifications Hi Gary, > I get the impression that either everyone has forgotten about proactive > CT, or does > not care. Which is too bad, for the boy scouts are right on when they say > "be prepared". > Thanx for reminding me, being an old Boy Scout myself I should have remembered. :-) How about if we modify the text I sent out as below? In addition, I think we need an additional section, which I will post on a separate thread, that describes the steps needed to standardize a feature context. This text will include a requirement for update on feature contexts that are not tightly synchronized with external events. jak ------------------------------------------------------------ 5.5 Context Update and Synchronization 5.5.1 The base context transfer protocol SHOULD NOT provide direct support for synchronization with outside events, since synchronization is not a requirement for all or even most feature contexts. 5.5.2 The base context transfer protocol MUST allow individual feature context specifications to define their own synchronization with external events. 5.5.3 The base context transfer protocol SHOULD NOT provide support for updating context after it is transfered, since individual feature contexts will differ in their need for update. 5.5.4 The base context transfer protocol MUST allow individual feature context specifications to define their own update procedures if required. Most feature contexts will not require synchronization, however there are a few that may. Header compression, for example, may require that the header compressor on the old access router cease and the compressor on the new router start in synchrony with hand over of routing to the new router; otherwise, the compressor on the new router will not be properly synchronized. Since most contexts don't need synchronization support, the general CT solution need not support it, but it should not provide a hinderance to those feature contexts that do. Feature contexts will differ in whether or not they require update. A feature context such as QoS parameters for the service level agreement with a user may not involve dynamically changing information, but it may change during or after context transfer. Such feature contexts may benefit from allowing the context to change after the transfer is completed. Other feature contexts, such as header compression, may be tightly synchronized with external events and changes on the old router need to be discarded since the new router's state may already have been modified. _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Mon Jul 22 12:34:59 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12969 for ; Mon, 22 Jul 2002 12:34:59 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA21285; Mon, 22 Jul 2002 12:33:16 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA21218 for ; Mon, 22 Jul 2002 12:33:12 -0400 (EDT) Received: from fridge.docomolabs-usa.com (fwuser@key1.docomolabs-usa.com [216.98.102.225]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12612 for ; Mon, 22 Jul 2002 12:32:09 -0400 (EDT) Message-ID: <004701c2319d$3b978f10$296015ac@T23KEMPF> From: "James Kempf" To: , References: <0C1353ABB1DEB74DB067ADFF749C4EEF0113083D@esebe004.NOE.Nokia.com> Subject: Re: [Seamoby] Section 5.2 in CT Requirements Date: Mon, 22 Jul 2002 09:31:29 -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-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit John, > I disagree with your requirement, because I don't see a lot of meaning > and/or use in it. > > I think that different context may have different need. Timelyness & > reliability are 2 different and opposing needs. This is directly > relatable to the earlier discussion on dynamicisity of context. > A situation could occur where a context goes stale during re-transmission > when running over a reliable protocol. Some other context, such as security > may not time out, unless the end-user completely times out of the user-session. > > Besides going stale, it is entirely possible that some context may > be superceded. As this issue is fairly complex and intertwined with the > context being transfered, I suggest we don't have a reliability requirement, > but rather we try to do an analysis of the reliability needs and then > take this into the solution. > > Additionally, I don't think that we want to get into defining new > transport protocols or behaviors. > That is exactly why I proposed this requirement. The intent of this requirement, together with the newly proposed Section 5.8, is that it would be up to the particular feature context profile to specify the transport. Here's an example of why I think the requirement is needed. 802.11 specifies its own context transfer protocol, namely IAPP. If we specify that, for example, SCTP is required for transport, vendors on 802.11 would have to implement two context transfer protocols, IAPP and the Seamoby SCTP-based protocol. IMHO, it makes sense to only have one context transfer protocol and leverage a particular transport for the feature contexts that need it. Does this make sense? jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Mon Jul 22 12:35:00 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12978 for ; Mon, 22 Jul 2002 12:34:59 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA23451 for seamoby-archive@odin.ietf.org; Mon, 22 Jul 2002 12:36:01 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA21285; Mon, 22 Jul 2002 12:33:16 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA21218 for ; Mon, 22 Jul 2002 12:33:12 -0400 (EDT) Received: from fridge.docomolabs-usa.com (fwuser@key1.docomolabs-usa.com [216.98.102.225]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12612 for ; Mon, 22 Jul 2002 12:32:09 -0400 (EDT) Message-ID: <004701c2319d$3b978f10$296015ac@T23KEMPF> From: "James Kempf" To: , References: <0C1353ABB1DEB74DB067ADFF749C4EEF0113083D@esebe004.NOE.Nokia.com> Subject: Re: [Seamoby] Section 5.2 in CT Requirements Date: Mon, 22 Jul 2002 09:31:29 -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-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit John, > I disagree with your requirement, because I don't see a lot of meaning > and/or use in it. > > I think that different context may have different need. Timelyness & > reliability are 2 different and opposing needs. This is directly > relatable to the earlier discussion on dynamicisity of context. > A situation could occur where a context goes stale during re-transmission > when running over a reliable protocol. Some other context, such as security > may not time out, unless the end-user completely times out of the user-session. > > Besides going stale, it is entirely possible that some context may > be superceded. As this issue is fairly complex and intertwined with the > context being transfered, I suggest we don't have a reliability requirement, > but rather we try to do an analysis of the reliability needs and then > take this into the solution. > > Additionally, I don't think that we want to get into defining new > transport protocols or behaviors. > That is exactly why I proposed this requirement. The intent of this requirement, together with the newly proposed Section 5.8, is that it would be up to the particular feature context profile to specify the transport. Here's an example of why I think the requirement is needed. 802.11 specifies its own context transfer protocol, namely IAPP. If we specify that, for example, SCTP is required for transport, vendors on 802.11 would have to implement two context transfer protocols, IAPP and the Seamoby SCTP-based protocol. IMHO, it makes sense to only have one context transfer protocol and leverage a particular transport for the feature contexts that need it. Does this make sense? jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Mon Jul 22 12:39:27 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07851 for ; Mon, 22 Jul 2002 11:39:50 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA26612 for seamoby-archive@odin.ietf.org; Mon, 22 Jul 2002 11:40:51 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA26364; Mon, 22 Jul 2002 11:37:28 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA26338 for ; Mon, 22 Jul 2002 11:37:26 -0400 (EDT) Received: from motgate.mot.com (motgate.mot.com [129.188.136.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07740 for ; Mon, 22 Jul 2002 11:36:24 -0400 (EDT) Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate.mot.com (motgate 2.1) with ESMTP id IAA24758 for ; Mon, 22 Jul 2002 08:37:25 -0700 (MST)] Received: [from il27exm07.cig.mot.com (IL27EXM07.cig.mot.com [136.182.15.116]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id IAA14206 for ; Mon, 22 Jul 2002 08:37:25 -0700 (MST)] Received: by IL27EXM07.cig.mot.com with Internet Mail Service (5.5.2654.52) id <3FLZ5GPM>; Mon, 22 Jul 2002 10:37:24 -0500 Message-ID: <35DBB8B7AC89D4118E98009027B1009B08AD55DC@IL27EXM10.cig.mot.com> From: Nakhjiri Madjid-MNAKHJI1 To: "'James Kempf'" , Gary Kenward , Nakhjiri Madjid-MNAKHJI1 , seamoby@ietf.org Date: Mon, 22 Jul 2002 10:37:24 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.52) Content-Type: text/plain; charset="iso-8859-1" Subject: [Seamoby] RE: Section 5.5 Modifications Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Well, I am maybe not as good of a boy scout as some others but, I remember 3 weeks of debate, followed by a period of 2 months of silence and then a 90 minute discussion in London (not to mention the 3$K trip expense :) ) that lead to us not making reactive or proactive CT as a basis for the CT usefulness debate. Lets not open that barrel of snakes (certainly bigger than worms) again. If you want to mention proactive a byproduct, or use case, that is fine. But I think we should be careful about making a byproduct a primary goal. Regards, Madjid -----Original Message----- From: James Kempf [mailto:kempf@docomolabs-usa.com] Sent: Friday, July 19, 2002 7:47 PM To: Gary Kenward; 'Nakhjiri Madjid-MNAKHJI1'; seamoby@ietf.org Subject: Section 5.5 Modifications Hi Gary, > I get the impression that either everyone has forgotten about proactive > CT, or does > not care. Which is too bad, for the boy scouts are right on when they say > "be prepared". > Thanx for reminding me, being an old Boy Scout myself I should have remembered. :-) How about if we modify the text I sent out as below? In addition, I think we need an additional section, which I will post on a separate thread, that describes the steps needed to standardize a feature context. This text will include a requirement for update on feature contexts that are not tightly synchronized with external events. jak ------------------------------------------------------------ 5.5 Context Update and Synchronization 5.5.1 The base context transfer protocol SHOULD NOT provide direct support for synchronization with outside events, since synchronization is not a requirement for all or even most feature contexts. 5.5.2 The base context transfer protocol MUST allow individual feature context specifications to define their own synchronization with external events. 5.5.3 The base context transfer protocol SHOULD NOT provide support for updating context after it is transfered, since individual feature contexts will differ in their need for update. 5.5.4 The base context transfer protocol MUST allow individual feature context specifications to define their own update procedures if required. Most feature contexts will not require synchronization, however there are a few that may. Header compression, for example, may require that the header compressor on the old access router cease and the compressor on the new router start in synchrony with hand over of routing to the new router; otherwise, the compressor on the new router will not be properly synchronized. Since most contexts don't need synchronization support, the general CT solution need not support it, but it should not provide a hinderance to those feature contexts that do. Feature contexts will differ in whether or not they require update. A feature context such as QoS parameters for the service level agreement with a user may not involve dynamically changing information, but it may change during or after context transfer. Such feature contexts may benefit from allowing the context to change after the transfer is completed. Other feature contexts, such as header compression, may be tightly synchronized with external events and changes on the old router need to be discarded since the new router's state may already have been modified. _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Mon Jul 22 13:15:07 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17956 for ; Mon, 22 Jul 2002 13:15:07 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA19474; Mon, 22 Jul 2002 13:09:26 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA19420 for ; Mon, 22 Jul 2002 13:09:22 -0400 (EDT) Received: from fridge.docomolabs-usa.com (fwuser@key1.docomolabs-usa.com [216.98.102.225]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17241 for ; Mon, 22 Jul 2002 13:08:19 -0400 (EDT) Message-ID: <008501c231a2$47144950$296015ac@T23KEMPF> From: "James Kempf" To: "Nakhjiri Madjid-MNAKHJI1" , "Gary Kenward" , References: <35DBB8B7AC89D4118E98009027B1009B08AD55DC@IL27EXM10.cig.mot.com> Date: Mon, 22 Jul 2002 10:07:36 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Seamoby] Re: Section 5.5 Modifications Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit Madjid, > Well, I am maybe not as good of a boy scout as some others > but, I remember 3 weeks of debate, followed by a period > of 2 months of silence and then a 90 minute discussion in London > (not to mention the 3$K trip expense :) ) > that lead to us not making reactive > or proactive CT as a basis for the CT usefulness debate. > Lets not open that barrel of snakes (certainly bigger than worms) again. > > If you want to mention proactive a byproduct, or use case, that is fine. > But I think we should be careful about making a byproduct a primary goal. > I guess I am not clear what your opinion is on the proposed change. The intent of the changes I proposed, including both the modification to Section 5.5 and the new Section 5.8, was to leave it up to the individual feature context specifications whether the transfer was done proactively or reactively. The general context transfer protocol would continue to be neutral in this regard, as it was agreed to in London. Is this acceptable to you? Also, if you feel the wording I've proposed doesn't capture this intent, please feel free to propose an alternative. jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Mon Jul 22 13:15:07 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17966 for ; Mon, 22 Jul 2002 13:15:07 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA24190 for seamoby-archive@odin.ietf.org; Mon, 22 Jul 2002 13:16:09 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA19474; Mon, 22 Jul 2002 13:09:26 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA19420 for ; Mon, 22 Jul 2002 13:09:22 -0400 (EDT) Received: from fridge.docomolabs-usa.com (fwuser@key1.docomolabs-usa.com [216.98.102.225]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17241 for ; Mon, 22 Jul 2002 13:08:19 -0400 (EDT) Message-ID: <008501c231a2$47144950$296015ac@T23KEMPF> From: "James Kempf" To: "Nakhjiri Madjid-MNAKHJI1" , "Gary Kenward" , References: <35DBB8B7AC89D4118E98009027B1009B08AD55DC@IL27EXM10.cig.mot.com> Date: Mon, 22 Jul 2002 10:07:36 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Seamoby] Re: Section 5.5 Modifications Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit Madjid, > Well, I am maybe not as good of a boy scout as some others > but, I remember 3 weeks of debate, followed by a period > of 2 months of silence and then a 90 minute discussion in London > (not to mention the 3$K trip expense :) ) > that lead to us not making reactive > or proactive CT as a basis for the CT usefulness debate. > Lets not open that barrel of snakes (certainly bigger than worms) again. > > If you want to mention proactive a byproduct, or use case, that is fine. > But I think we should be careful about making a byproduct a primary goal. > I guess I am not clear what your opinion is on the proposed change. The intent of the changes I proposed, including both the modification to Section 5.5 and the new Section 5.8, was to leave it up to the individual feature context specifications whether the transfer was done proactively or reactively. The general context transfer protocol would continue to be neutral in this regard, as it was agreed to in London. Is this acceptable to you? Also, if you feel the wording I've proposed doesn't capture this intent, please feel free to propose an alternative. jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Mon Jul 22 17:47:15 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12953 for ; Mon, 22 Jul 2002 17:47:15 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA14317; Mon, 22 Jul 2002 17:43:05 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA10358 for ; Fri, 19 Jul 2002 11:42:30 -0400 (EDT) Received: from ftpbox.mot.com (ftpbox.mot.com [129.188.136.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12246 for ; Fri, 19 Jul 2002 11:41:30 -0400 (EDT) Received: [from pobox4.mot.com (pobox4.mot.com [10.64.251.243]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id IAA21481 for ; Fri, 19 Jul 2002 08:42:29 -0700 (MST)] Received: [from il27exm07.cig.mot.com (IL27EXM07.cig.mot.com [136.182.15.116]) by pobox4.mot.com (MOT-pobox4 2.0) with ESMTP id IAA17783 for ; Fri, 19 Jul 2002 08:42:29 -0700 (MST)] Received: by IL27EXM07.cig.mot.com with Internet Mail Service (5.5.2654.52) id <3FLZZDGD>; Fri, 19 Jul 2002 10:42:27 -0500 Message-ID: <35DBB8B7AC89D4118E98009027B1009B08AD55D2@IL27EXM10.cig.mot.com> From: Nakhjiri Madjid-MNAKHJI1 To: "'Gary Kenward'" , Nakhjiri Madjid-MNAKHJI1 , seamoby@ietf.org Subject: RE: [Seamoby] CT Requirements Comments from IESG Date: Fri, 19 Jul 2002 10:42:26 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.52) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C22F3A.E21300A0" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C22F3A.E21300A0 Content-Type: text/plain; charset="iso-8859-1" Gary, I see your usage scenario of CT (proactive) as a case for CT, but not the primary case. This comes handy if you are building "capability discovery" assisted handovers. Since we agreed on the text in another email, I won't dwell on this any further. Regards, Madjid -----Original Message----- From: Gary Kenward [mailto:gkenward@nortelnetworks.com] Sent: Friday, July 19, 2002 9:15 AM To: 'Nakhjiri Madjid-MNAKHJI1'; seamoby@ietf.org Subject: RE: [Seamoby] CT Requirements Comments from IESG Madjid: Two comments: 1. As I responded to James, using CT in preparation of possible handovers *is* the main opportunity to ensure seamless. Trying to catch up to a handover, once it has begun, is very difficult, and likely to fail in many cases. 2. What does "too early mean"? Just as there is no deterministic way to predict the direction of a mobile, and thus which AR the MN handsover to, there is no deterministic way to predict when this will happen. So, while the network/MN may know that the MN has the potential to handover to, say, 3 or 4 ARs, and can prepare for it, there is no way to pin down the epoch. I get the impression that either everyone has forgotten about proactive CT, or does not care. Which is too bad, for the boy scouts are right on when they say "be prepared". Gary -----Original Message----- From: Nakhjiri Madjid-MNAKHJI1 [ mailto:Madjid.Nakhjiri@motorola.com ] Sent: July 18, 2002 17:17 To: Kenward, Gary [WDLN2:AN10:EXCH]; Nakhjiri Madjid-MNAKHJI1; 'Charles E. Perkins' Cc: seamoby@ietf.org Subject: RE: [Seamoby] CT Requirements Comments from IESG -----Original Message----- From: Gary Kenward [ mailto:gkenward@nortelnetworks.com ] Sent: Thursday, July 18, 2002 9:52 AM To: 'Nakhjiri Madjid-MNAKHJI1'; 'Charles E. Perkins' Cc: seamoby@ietf.org Subject: RE: [Seamoby] CT Requirements Comments from IESG Define "done"? Madjid>> Exactly my point, if you keep sending updates while you're sending other context, you are never done. Seriously, if CT is performed during or after a handover (reactively) then, yes, there's not much more that can be done. If the context at the destination is out of synch with changes in the source context, there is an increased risk that the seamlessness of the handover will be degraded. Madjid>> Yes, assuming you mean L3 handover, and this is the most critical use of CT: optimization of handovers. I can't have CT add to feature disruption by getting into an endless cycle of updates. However, if CT is performed before a handover begins (proactively), and changes occur at the source AR, then it would seem reasonable to attempt updates. There is a presumption here that there is something to be gained in handover performance by performing CT in advance of an actual handover. It could turn out that CT (and the subsequent installion of context at the destination AR) is so fast, that leaving the transfer of context until a handover occurs (i.e. no proactive, only reactive) is a sufficient, and simpler solution. We really won't know whether this is the case until the wg starts looking at CT solutions. Madjid>>sure, but this is not a time-critical CT and CT needs to send updates because it started too early on a dynamic context. Cheers, Gary -----Original Message----- From: Nakhjiri Madjid-MNAKHJI1 [ mailto:Madjid.Nakhjiri@motorola.com ] Sent: July 17, 2002 19:25 To: Kenward, Gary [WDLN2:AN10:EXCH]; 'Charles E. Perkins' Cc: seamoby@ietf.org Subject: RE: [Seamoby] CT Requirements Comments from IESG Well, not trying to regurgitate (as you said) but we never agreed on timing and reliability requirements and maybe that was ok, because they depend on the scenario and protocols. So why talk about sending updates after CT is done? Madjid -----Original Message----- From: Gary Kenward [ mailto:gkenward@nortelnetworks.com ] Sent: Friday, July 12, 2002 2:35 PM To: 'Charles E. Perkins' Cc: seamoby@ietf.org Subject: RE: [Seamoby] CT Requirements Comments from IESG I agree Charlie. However, we have to fix the issue with the requirements. Are you suggesting that we relax the requirement? By how much - clearly, some updates are required (e.g. CT really should try and update when flows come and go). Gary > -----Original Message----- > From: Charles E. Perkins [ mailto:charliep@iprg.nokia.com ] > Sent: July 12, 2002 12:15 > To: Kenward, Gary [WDLN2:AN10:EXCH] > Cc: seamoby@ietf.org > Subject: Re: [Seamoby] CT Requirements Comments from IESG > > > > > Hello folks, > > I think we ought to try to get context transfers > working correctly without initially worrying about > this synchronization problem. > > In the instances I am familiar with, it is not > required. The most stringent case seems to be > ROHC, and even for that it is not necessary. > > We can solve the most urgent problems without having > to deal with any additional context synchronization. > When the old AR sends it, and the new AR gets it, > we should consider the transfer done. In those > cases where reliability is at issue, the old AR > can retransmit when ACK is not received. In many > cases, retransmission of context even once won't > be useful. > > Regards, > Charlie P. > > > > > Gary Kenward wrote: > > > > James: > > > > Yes, we need to fix it, and I think it is doable. > > Thanks to Dirk for highlighting the real problem here > > (I think historically, the integrity requirement came out > > of the reliability section, and somehow, got lumped with > > synchronization and updates). > > > > I think the requirements need a bit of rewording, and > > the paragraph should fall out from this. I do believe > > however, that making the synchronization of context between > > old and new AR a MUST requirement would be too extreme, and > > result in a brittle solution. CT should certainly do it's best to > > provide synchronization, but as was discussed in a recent > > exchange, it would be impossible to guarantee synchronization > > at any instant. > > > > Any ideas/comments from the wg? > > > > Gary > > > > > -----Original Message----- > > > From: James Kempf [ mailto:kempf@docomolabs-usa.com ] > > > Sent: July 11, 2002 18:32 > > > To: Kenward, Gary [WDLN2:AN10:EXCH]; Dirk.Trossen@nokia.com; > > > seamoby@ietf.org > > > Subject: Re: [Seamoby] CT Requirements Comments from IESG > > > > > > > > > Gary/Dirk, > > > > > > I think you may be on to something here. I think this might > > > be what the IESG was talking about it the first point, namely the > > > lack of discussion of dynamic changes in the context. > > > > > > Is there some way we could cook this idea down into a > > > paragraph that we could insert for this requirement? > > > > > > jak > > > > > > ----- Original Message ----- > > > From: "Gary Kenward" > > > To: ; ; > > > > > > Sent: Thursday, July 11, 2002 1:56 PM > > > Subject: RE: [Seamoby] CT Requirements Comments from IESG > > > > > > > > > > Dirk: > > > > > > > > A valid point. There is a certain atomic level of > > > granularity which has to > > > > be > > > > dealt with - that is, there's no protocol in the world that > > > can synchronize > > > > changes in > > > > information that occur at the source while the information > > > is "in-flight" or > > > > being > > > > received at the destination. If changes in context while > > > the context is > > > > being transferred > > > > make a different to the successful performance of CT, then > > > there is no hope. > > > > > > > > The problem is most significant for state context > > > transfer. E.g. counters > > > > will continue > > > > to count while CT is moving the context to the destination. > > > Either these > > > > changes have no > > > > significant impact upon the forwarding service provided at > > > the new AR (e.g. > > > > it may not > > > > matter that a policing meter misses a few packet counts), > > > or a different > > > > mechanism > > > > has to be defined for re-establishing the state context. > > > > > > > > The handover is real and unavoidable. Mitigating the > > > disruption to the > > > > service at the new > > > > AR is the challenge. It would be nice if the disruption > was nil, but > > > > unlikely. > > > > > > > > Gary > > > > > > > > -----Original Message----- > > > > From: Dirk.Trossen@nokia.com [ mailto:Dirk.Trossen@nokia.com ] > > > > Sent: July 11, 2002 16:30 > > > > To: Kenward, Gary [WDLN2:AN10:EXCH]; kempf@docomolabs-usa.com; > > > > seamoby@ietf.org > > > > Subject: RE: [Seamoby] CT Requirements Comments from IESG > > > > > > > > > > > > Hi all, > > > > > > > > jumping in as somebody who has been an observer so far, > > > struggling with the > > > > current discussion on > > > > 'integrity'. > > > > > > > > When I look at the current wording, i.e., > > > > "5.5.2 A context update MUST preserve the integrity, and > > > thus the meaning, > > > > of the context > > > > at each receiving AR. The context at the AR actually > > > supporting an MN's > > > > traffic will change with time. > > > > For example, the MN may initiate new microflow(s), or > > > discontinue existing > > > > microflows. Any change of context > > > > at the supporting AR must be replicated at those ARs that > > > have already > > > > received context for that MN.", > > > > > > > > and compare this to the plain integrity of the actually > > > transmitted data > > > > (i.e., its bits and therefore its semantics) > > > > that has been brought to the table as a replacement now, > > > I'm quite confident > > > > that this is not what the requirement > > > > is talking about. > > > > > > > > If we remove the word 'meaning' (which is very vague > and free for > > > > interpretation for me as well), it is still the word > > > > 'integrity' left, which is more than plain integrity of the > > > transmitted > > > > data, in particular if we look at the following sentences > > > > in the requirement, which state what kind of integrity is > > > meant (which > > > > probably also builds the bridge to the vague > > > > term 'meaning'), namely that the integrity of a context > > > must be preserved in > > > > the sense that a received context at new > > > > AR at some point t must be the same as the context at old > > > AR at the same > > > > time t. This is by far more than plain data > > > > integrity of the transmitted data. Even if your data has > > > been transmitted > > > > correctly, the context might be stale (and therefore > > > > its integrity is lost) because it had changed at old AR in > > > the meanwhile. > > > > The action to be taken is also given in the text, > > > > namely the change of context has to be replicated to the > > > new AR. As you can > > > > (hopefully) see this is by far more than > > > > preserving the 'meaning' of each bit. It mandates that > > > changes in the bit > > > > values at one end are reflected at the other > > > > end, i.e., it talks about distributed data integrity in my > > > interpretation of > > > > the requirement text. > > > > > > > > Hence, the actual concern might have been (just guessing) > > > whether or not it > > > > is the task of the CT protocol to > > > > preserve the abovementioned integrity. Maybe, the IESG > > > wants to see this > > > > functionality left to the replication logic that resides > > > > within each AR. Or on the contrary, they do not see this > > > important topic > > > > covered appropriately. > > > > > > > > Regards, > > > > > > > > > > > > Dirk > > > > > > > > -----Original Message----- > > > > From: ext Gary Kenward [ mailto:gkenward@nortelnetworks.com ] > > > > Sent: Thursday, July 11, 2002 3:48 PM > > > > To: 'James Kempf'; seamoby@ietf.org > > > > Subject: RE: [Seamoby] CT Requirements Comments from IESG > > > > > > > > > > > > > > > > You call it fidelity, I call it data integrity. > > > > I've seen "data integrity" used in publications > > > > (no, I cannot quote references). > > > > > > > > What we need is a term that everyone, including the > > > > IESG, can agree upon. > > > > > > > > > -----Original Message----- > > > > > From: James Kempf [ mailto:kempf@docomolabs-usa.com > > > > < mailto:kempf@docomolabs-usa.com > ] > > > > > Sent: July 11, 2002 12:22 > > > > > To: Kenward, Gary [WDLN2:AN10:EXCH]; seamoby@ietf.org > > > > > Subject: Re: [Seamoby] CT Requirements Comments from IESG > > > > > > > > > > > > > > > > Perhaps the actual answer is to state exactly what > was intended > > > > > > originally: that the bit order and bit values have to > > > arrive exactly > > > > > > as they were transmitted. > > > > > > > > > > > > > > > > So this requirement is talking about transmission fidelity? I > > > > > sure would not have guessed that from reading it. I thought it > > > > > intended to talk about usability. > > > > > > > > > > I would suggest that the wording you have above is really a > > > > > lot more precise that what is currently in the spec. > > > > > > > > > > Any other comments? Could we substitute Gary's wording above > > > > > for "meaning" in the current requirement. > > > > > > > > > > jak > > > > > > > > > > > > > > > > > > > > > > > > > ------_=_NextPart_001_01C22F3A.E21300A0 Content-Type: text/html; charset="iso-8859-1" RE: [Seamoby] CT Requirements Comments from IESG
Gary,
 
I see your usage scenario of CT (proactive) as a case for CT, but
not the primary case. This comes handy if you are building "capability
discovery" assisted handovers. 
 
Since we agreed on the text in another email, I won't dwell on this
any further.
 
Regards,
 
Madjid 
-----Original Message-----
From: Gary Kenward [mailto:gkenward@nortelnetworks.com]
Sent: Friday, July 19, 2002 9:15 AM
To: 'Nakhjiri Madjid-MNAKHJI1'; seamoby@ietf.org
Subject: RE: [Seamoby] CT Requirements Comments from IESG

Madjid:

  Two comments:

    1. As I responded to James, using CT in preparation of possible handovers *is*
       the main opportunity to ensure seamless. Trying to catch up to a handover,
       once it has begun, is very difficult, and likely to fail in many cases.

    2. What does "too early mean"? Just as there is no deterministic way to predict the
       direction of a mobile, and thus which AR the MN handsover to, there is no deterministic
       way to predict when this will happen. So, while the network/MN may know that the
       MN has the potential to handover to, say, 3 or 4 ARs, and can prepare for it,
       there is no way to pin down the epoch.

  I get the impression that either everyone has forgotten about proactive CT, or does
not care. Which is too bad, for the boy scouts are right on when they say "be prepared".

Gary

-----Original Message-----
From: Nakhjiri Madjid-MNAKHJI1 [mailto:Madjid.Nakhjiri@motorola.com]
Sent: July 18, 2002 17:17
To: Kenward, Gary [WDLN2:AN10:EXCH]; Nakhjiri Madjid-MNAKHJI1; 'Charles E. Perkins'
Cc: seamoby@ietf.org
Subject: RE: [Seamoby] CT Requirements Comments from IESG



-----Original Message-----
From: Gary Kenward [mailto:gkenward@nortelnetworks.com]
Sent: Thursday, July 18, 2002 9:52 AM
To: 'Nakhjiri Madjid-MNAKHJI1'; 'Charles E. Perkins'
Cc: seamoby@ietf.org
Subject: RE: [Seamoby] CT Requirements Comments from IESG


Define "done"?
 
Madjid>> Exactly my point, if you keep sending updates while you're
sending other context, you are never done.
 
Seriously, if CT is performed during or after a handover (reactively)
then, yes, there's not much more that can be done. If the context at
the destination is out of synch with changes in the source context,
there is an increased risk that the seamlessness of the handover will
be degraded.
 
Madjid>> Yes, assuming you mean L3 handover,
and this is the most critical use of CT: optimization
of handovers. I can't have CT add to feature disruption by getting
into an endless cycle of updates.
 
However, if CT is performed before a handover begins (proactively),
and changes occur at the source AR, then it would seem reasonable to
attempt updates. There is a presumption here that there is something
to be gained in handover performance by performing CT in advance of
an actual handover. It could turn out that CT (and the subsequent installion
of context at the destination AR) is so fast, that leaving the transfer
of context until a handover occurs (i.e. no proactive, only reactive) is
a sufficient, and simpler solution. We really won't know whether this
is the case until the wg starts looking at CT solutions.
 
Madjid>>sure, but this is not a time-critical CT and CT needs to send updates because
it started too early on a dynamic context.
 
 
 
 
Cheers,
Gary
-----Original Message-----
From: Nakhjiri Madjid-MNAKHJI1 [mailto:Madjid.Nakhjiri@motorola.com]
Sent: July 17, 2002 19:25
To: Kenward, Gary [WDLN2:AN10:EXCH]; 'Charles E. Perkins'
Cc: seamoby@ietf.org
Subject: RE: [Seamoby] CT Requirements Comments from IESG


Well, not trying to regurgitate (as you said)
but we never agreed on timing and reliability requirements and maybe
that was ok, because they depend on the scenario and protocols.
So why talk about sending updates after CT is done?
 
 
Madjid
-----Original Message-----
From: Gary Kenward [mailto:gkenward@nortelnetworks.com]
Sent: Friday, July 12, 2002 2:35 PM
To: 'Charles E. Perkins'
Cc: seamoby@ietf.org
Subject: RE: [Seamoby] CT Requirements Comments from IESG


I agree Charlie. However, we have to fix the issue with
the requirements. Are you suggesting that we relax the
requirement? By how much - clearly, some updates are required
(e.g. CT really should try and update when flows come and go).
Gary
> -----Original Message-----
> From: Charles E. Perkins [mailto:charliep@iprg.nokia.com]
> Sent: July 12, 2002 12:15
> To: Kenward, Gary [WDLN2:AN10:EXCH]
> Cc: seamoby@ietf.org
> Subject: Re: [Seamoby] CT Requirements Comments from IESG
>
>
>
>
> Hello folks,
>
> I think we ought to try to get context transfers
> working correctly without initially worrying about
> this synchronization problem.
>
> In the instances I am familiar with, it is not
> required.  The most stringent case seems to be
> ROHC, and even for that it is not necessary.
>
> We can solve the most urgent problems without having
> to deal with any additional context synchronization.
> When the old AR sends it, and the new AR gets it,
> we should consider the transfer done.  In those
> cases where reliability is at issue, the old AR
> can retransmit when ACK is not received.  In many
> cases, retransmission of context even once won't
> be useful.
>
> Regards,
> Charlie P.
>
>
>
> > Gary Kenward wrote:
> >
> > James:
> >
> >   Yes, we need to fix it, and I think it is doable.
> > Thanks to Dirk for highlighting the real problem here
> > (I think historically, the integrity requirement came out
> > of the reliability section, and somehow, got lumped with
> > synchronization and updates).
> >
> >   I think the requirements need a bit of rewording, and
> > the paragraph should fall out from this. I do believe
> > however, that making the synchronization of context between
> > old and new AR a MUST requirement would be too extreme, and
> > result in a brittle solution. CT should certainly do it's best to
> > provide synchronization, but as was discussed in a recent
> > exchange, it would be impossible to guarantee synchronization
> > at any instant.
> >
> >   Any ideas/comments from the wg?
> >
> > Gary
> >
> > > -----Original Message-----
> > > From: James Kempf [mailto:kempf@docomolabs-usa.com]
> > > Sent: July 11, 2002 18:32
> > > To: Kenward, Gary [WDLN2:AN10:EXCH]; Dirk.Trossen@nokia.com;
> > > seamoby@ietf.org
> > > Subject: Re: [Seamoby] CT Requirements Comments from IESG
> > >
> > >
> > > Gary/Dirk,
> > >
> > > I think you may be on to something here. I think this might
> > > be what the IESG was talking about it the first point, namely the
> > > lack of discussion of dynamic changes in the context.
> > >
> > > Is there some way we could cook this idea down into a
> > > paragraph that we could insert for this requirement?
> > >
> > >             jak
> > >
> > > ----- Original Message -----
> > > From: "Gary Kenward" <gkenward@nortelnetworks.com>
> > > To: <Dirk.Trossen@nokia.com>; <kempf@docomolabs-usa.com>;
> > > <seamoby@ietf.org>
> > > Sent: Thursday, July 11, 2002 1:56 PM
> > > Subject: RE: [Seamoby] CT Requirements Comments from IESG
> > >
> > >
> > > > Dirk:
> > > >
> > > >   A valid point. There is a certain atomic level of
> > > granularity which has to
> > > > be
> > > > dealt with - that is, there's no protocol in the world that
> > > can synchronize
> > > > changes in
> > > > information that occur at the source while the information
> > > is "in-flight" or
> > > > being
> > > > received at the destination. If changes in context while
> > > the context is
> > > > being transferred
> > > > make a different to the successful performance of CT, then
> > > there is no hope.
> > > >
> > > >   The problem is most significant for state context
> > > transfer. E.g. counters
> > > > will continue
> > > > to count while CT is moving the context to the destination.
> > > Either these
> > > > changes have no
> > > > significant impact upon the forwarding service provided at
> > > the new AR (e.g.
> > > > it may not
> > > > matter that a policing meter misses a few packet counts),
> > > or a different
> > > > mechanism
> > > > has to be defined for re-establishing the state context.
> > > >
> > > >   The handover is real and unavoidable. Mitigating the
> > > disruption to the
> > > > service at the new
> > > > AR is the challenge. It would be nice if the disruption
> was nil, but
> > > > unlikely.
> > > >
> > > > Gary
> > > >
> > > > -----Original Message-----
> > > > From: Dirk.Trossen@nokia.com [mailto:Dirk.Trossen@nokia.com]
> > > > Sent: July 11, 2002 16:30
> > > > To: Kenward, Gary [WDLN2:AN10:EXCH]; kempf@docomolabs-usa.com;
> > > > seamoby@ietf.org
> > > > Subject: RE: [Seamoby] CT Requirements Comments from IESG
> > > >
> > > >
> > > > Hi all,
> > > >
> > > > jumping in as somebody who has been an observer so far,
> > > struggling with the
> > > > current discussion on
> > > > 'integrity'.
> > > >
> > > > When I look at the current wording, i.e.,
> > > > "5.5.2 A context update MUST preserve the integrity, and
> > > thus the meaning,
> > > > of the context
> > > > at each receiving AR. The context at the AR actually
> > > supporting an MN's
> > > > traffic will change with time.
> > > > For example, the MN may initiate new microflow(s), or
> > > discontinue existing
> > > > microflows. Any change of context
> > > > at the supporting AR must be replicated at those ARs that
> > > have already
> > > > received context for that MN.",
> > > >
> > > > and compare this to the plain integrity of the actually
> > > transmitted data
> > > > (i.e., its bits and therefore its semantics)
> > > > that has been brought to the table as a replacement now,
> > > I'm quite confident
> > > > that this is not what the requirement
> > > > is talking about.
> > > >
> > > > If we remove the word 'meaning' (which is very vague
> and free for
> > > > interpretation for me as well), it is still the word
> > > > 'integrity' left, which is more than plain integrity of the
> > > transmitted
> > > > data, in particular if we look at the following sentences
> > > > in the requirement, which state what kind of integrity is
> > > meant (which
> > > > probably also builds the bridge to the vague
> > > > term 'meaning'), namely that the integrity of a context
> > > must be preserved in
> > > > the sense that a received context at new
> > > > AR at some point t must be the same as the context at old
> > > AR at the same
> > > > time t. This is by far more than plain data
> > > > integrity of the transmitted data. Even if your data has
> > > been transmitted
> > > > correctly, the context might be stale (and therefore
> > > > its integrity is lost) because it had changed at old AR in
> > > the meanwhile.
> > > > The action to be taken is also given in the text,
> > > > namely the change of context has to be replicated to the
> > > new AR. As you can
> > > > (hopefully) see this is by far more than
> > > > preserving the 'meaning' of each bit. It mandates that
> > > changes in the bit
> > > > values at one end are reflected at the other
> > > > end, i.e., it talks about distributed data integrity in my
> > > interpretation of
> > > > the requirement text.
> > > >
> > > > Hence, the actual concern might have been (just guessing)
> > > whether or not it
> > > > is the task of the CT protocol to
> > > > preserve the abovementioned integrity. Maybe, the IESG
> > > wants to see this
> > > > functionality left to the replication logic that resides
> > > > within each AR. Or on the contrary, they do not see this
> > > important topic
> > > > covered appropriately.
> > > >
> > > > Regards,
> > > >
> > > >
> > > > Dirk
> > > >
> > > > -----Original Message-----
> > > > From: ext Gary Kenward [mailto:gkenward@nortelnetworks.com]
> > > > Sent: Thursday, July 11, 2002 3:48 PM
> > > > To: 'James Kempf'; seamoby@ietf.org
> > > > Subject: RE: [Seamoby] CT Requirements Comments from IESG
> > > >
> > > >
> > > >
> > > > You call it fidelity, I call it data integrity.
> > > > I've seen "data integrity" used in publications
> > > > (no, I cannot quote references).
> > > >
> > > > What we need is a term that everyone, including the
> > > > IESG, can agree upon.
> > > >
> > > > > -----Original Message-----
> > > > > From: James Kempf [ mailto:kempf@docomolabs-usa.com
> > > > <mailto:kempf@docomolabs-usa.com> ]
> > > > > Sent: July 11, 2002 12:22
> > > > > To: Kenward, Gary [WDLN2:AN10:EXCH]; seamoby@ietf.org
> > > > > Subject: Re: [Seamoby] CT Requirements Comments from IESG
> > > > >
> > > > >
> > > > > > Perhaps the actual answer is to state exactly what
> was intended
> > > > > > originally: that the bit order and bit values have to
> > > arrive exactly
> > > > > > as they were transmitted.
> > > > > >
> > > > >
> > > > > So this requirement is talking about transmission fidelity? I
> > > > > sure would not have guessed that from reading it. I thought it
> > > > > intended to talk about usability.
> > > > >
> > > > > I would suggest that the wording you have above is really a
> > > > > lot more precise that what is currently in the spec.
> > > > >
> > > > > Any other comments? Could we substitute Gary's wording above
> > > > > for "meaning" in the current requirement.
> > > > >
> > > > >             jak
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
>

------_=_NextPart_001_01C22F3A.E21300A0-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@ns.ietf.org Mon Jul 22 17:47:16 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12962 for ; Mon, 22 Jul 2002 17:47:16 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA17018 for seamoby-archive@odin.ietf.org; Mon, 22 Jul 2002 17:48:16 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA14317; Mon, 22 Jul 2002 17:43:05 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA10358 for ; Fri, 19 Jul 2002 11:42:30 -0400 (EDT) Received: from ftpbox.mot.com (ftpbox.mot.com [129.188.136.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12246 for ; Fri, 19 Jul 2002 11:41:30 -0400 (EDT) Received: [from pobox4.mot.com (pobox4.mot.com [10.64.251.243]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id IAA21481 for ; Fri, 19 Jul 2002 08:42:29 -0700 (MST)] Received: [from il27exm07.cig.mot.com (IL27EXM07.cig.mot.com [136.182.15.116]) by pobox4.mot.com (MOT-pobox4 2.0) with ESMTP id IAA17783 for ; Fri, 19 Jul 2002 08:42:29 -0700 (MST)] Received: by IL27EXM07.cig.mot.com with Internet Mail Service (5.5.2654.52) id <3FLZZDGD>; Fri, 19 Jul 2002 10:42:27 -0500 Message-ID: <35DBB8B7AC89D4118E98009027B1009B08AD55D2@IL27EXM10.cig.mot.com> From: Nakhjiri Madjid-MNAKHJI1 To: "'Gary Kenward'" , Nakhjiri Madjid-MNAKHJI1 , seamoby@ietf.org Subject: RE: [Seamoby] CT Requirements Comments from IESG Date: Fri, 19 Jul 2002 10:42:26 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.52) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C22F3A.E21300A0" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C22F3A.E21300A0 Content-Type: text/plain; charset="iso-8859-1" Gary, I see your usage scenario of CT (proactive) as a case for CT, but not the primary case. This comes handy if you are building "capability discovery" assisted handovers. Since we agreed on the text in another email, I won't dwell on this any further. Regards, Madjid -----Original Message----- From: Gary Kenward [mailto:gkenward@nortelnetworks.com] Sent: Friday, July 19, 2002 9:15 AM To: 'Nakhjiri Madjid-MNAKHJI1'; seamoby@ietf.org Subject: RE: [Seamoby] CT Requirements Comments from IESG Madjid: Two comments: 1. As I responded to James, using CT in preparation of possible handovers *is* the main opportunity to ensure seamless. Trying to catch up to a handover, once it has begun, is very difficult, and likely to fail in many cases. 2. What does "too early mean"? Just as there is no deterministic way to predict the direction of a mobile, and thus which AR the MN handsover to, there is no deterministic way to predict when this will happen. So, while the network/MN may know that the MN has the potential to handover to, say, 3 or 4 ARs, and can prepare for it, there is no way to pin down the epoch. I get the impression that either everyone has forgotten about proactive CT, or does not care. Which is too bad, for the boy scouts are right on when they say "be prepared". Gary -----Original Message----- From: Nakhjiri Madjid-MNAKHJI1 [ mailto:Madjid.Nakhjiri@motorola.com ] Sent: July 18, 2002 17:17 To: Kenward, Gary [WDLN2:AN10:EXCH]; Nakhjiri Madjid-MNAKHJI1; 'Charles E. Perkins' Cc: seamoby@ietf.org Subject: RE: [Seamoby] CT Requirements Comments from IESG -----Original Message----- From: Gary Kenward [ mailto:gkenward@nortelnetworks.com ] Sent: Thursday, July 18, 2002 9:52 AM To: 'Nakhjiri Madjid-MNAKHJI1'; 'Charles E. Perkins' Cc: seamoby@ietf.org Subject: RE: [Seamoby] CT Requirements Comments from IESG Define "done"? Madjid>> Exactly my point, if you keep sending updates while you're sending other context, you are never done. Seriously, if CT is performed during or after a handover (reactively) then, yes, there's not much more that can be done. If the context at the destination is out of synch with changes in the source context, there is an increased risk that the seamlessness of the handover will be degraded. Madjid>> Yes, assuming you mean L3 handover, and this is the most critical use of CT: optimization of handovers. I can't have CT add to feature disruption by getting into an endless cycle of updates. However, if CT is performed before a handover begins (proactively), and changes occur at the source AR, then it would seem reasonable to attempt updates. There is a presumption here that there is something to be gained in handover performance by performing CT in advance of an actual handover. It could turn out that CT (and the subsequent installion of context at the destination AR) is so fast, that leaving the transfer of context until a handover occurs (i.e. no proactive, only reactive) is a sufficient, and simpler solution. We really won't know whether this is the case until the wg starts looking at CT solutions. Madjid>>sure, but this is not a time-critical CT and CT needs to send updates because it started too early on a dynamic context. Cheers, Gary -----Original Message----- From: Nakhjiri Madjid-MNAKHJI1 [ mailto:Madjid.Nakhjiri@motorola.com ] Sent: July 17, 2002 19:25 To: Kenward, Gary [WDLN2:AN10:EXCH]; 'Charles E. Perkins' Cc: seamoby@ietf.org Subject: RE: [Seamoby] CT Requirements Comments from IESG Well, not trying to regurgitate (as you said) but we never agreed on timing and reliability requirements and maybe that was ok, because they depend on the scenario and protocols. So why talk about sending updates after CT is done? Madjid -----Original Message----- From: Gary Kenward [ mailto:gkenward@nortelnetworks.com ] Sent: Friday, July 12, 2002 2:35 PM To: 'Charles E. Perkins' Cc: seamoby@ietf.org Subject: RE: [Seamoby] CT Requirements Comments from IESG I agree Charlie. However, we have to fix the issue with the requirements. Are you suggesting that we relax the requirement? By how much - clearly, some updates are required (e.g. CT really should try and update when flows come and go). Gary > -----Original Message----- > From: Charles E. Perkins [ mailto:charliep@iprg.nokia.com ] > Sent: July 12, 2002 12:15 > To: Kenward, Gary [WDLN2:AN10:EXCH] > Cc: seamoby@ietf.org > Subject: Re: [Seamoby] CT Requirements Comments from IESG > > > > > Hello folks, > > I think we ought to try to get context transfers > working correctly without initially worrying about > this synchronization problem. > > In the instances I am familiar with, it is not > required. The most stringent case seems to be > ROHC, and even for that it is not necessary. > > We can solve the most urgent problems without having > to deal with any additional context synchronization. > When the old AR sends it, and the new AR gets it, > we should consider the transfer done. In those > cases where reliability is at issue, the old AR > can retransmit when ACK is not received. In many > cases, retransmission of context even once won't > be useful. > > Regards, > Charlie P. > > > > > Gary Kenward wrote: > > > > James: > > > > Yes, we need to fix it, and I think it is doable. > > Thanks to Dirk for highlighting the real problem here > > (I think historically, the integrity requirement came out > > of the reliability section, and somehow, got lumped with > > synchronization and updates). > > > > I think the requirements need a bit of rewording, and > > the paragraph should fall out from this. I do believe > > however, that making the synchronization of context between > > old and new AR a MUST requirement would be too extreme, and > > result in a brittle solution. CT should certainly do it's best to > > provide synchronization, but as was discussed in a recent > > exchange, it would be impossible to guarantee synchronization > > at any instant. > > > > Any ideas/comments from the wg? > > > > Gary > > > > > -----Original Message----- > > > From: James Kempf [ mailto:kempf@docomolabs-usa.com ] > > > Sent: July 11, 2002 18:32 > > > To: Kenward, Gary [WDLN2:AN10:EXCH]; Dirk.Trossen@nokia.com; > > > seamoby@ietf.org > > > Subject: Re: [Seamoby] CT Requirements Comments from IESG > > > > > > > > > Gary/Dirk, > > > > > > I think you may be on to something here. I think this might > > > be what the IESG was talking about it the first point, namely the > > > lack of discussion of dynamic changes in the context. > > > > > > Is there some way we could cook this idea down into a > > > paragraph that we could insert for this requirement? > > > > > > jak > > > > > > ----- Original Message ----- > > > From: "Gary Kenward" > > > To: ; ; > > > > > > Sent: Thursday, July 11, 2002 1:56 PM > > > Subject: RE: [Seamoby] CT Requirements Comments from IESG > > > > > > > > > > Dirk: > > > > > > > > A valid point. There is a certain atomic level of > > > granularity which has to > > > > be > > > > dealt with - that is, there's no protocol in the world that > > > can synchronize > > > > changes in > > > > information that occur at the source while the information > > > is "in-flight" or > > > > being > > > > received at the destination. If changes in context while > > > the context is > > > > being transferred > > > > make a different to the successful performance of CT, then > > > there is no hope. > > > > > > > > The problem is most significant for state context > > > transfer. E.g. counters > > > > will continue > > > > to count while CT is moving the context to the destination. > > > Either these > > > > changes have no > > > > significant impact upon the forwarding service provided at > > > the new AR (e.g. > > > > it may not > > > > matter that a policing meter misses a few packet counts), > > > or a different > > > > mechanism > > > > has to be defined for re-establishing the state context. > > > > > > > > The handover is real and unavoidable. Mitigating the > > > disruption to the > > > > service at the new > > > > AR is the challenge. It would be nice if the disruption > was nil, but > > > > unlikely. > > > > > > > > Gary > > > > > > > > -----Original Message----- > > > > From: Dirk.Trossen@nokia.com [ mailto:Dirk.Trossen@nokia.com ] > > > > Sent: July 11, 2002 16:30 > > > > To: Kenward, Gary [WDLN2:AN10:EXCH]; kempf@docomolabs-usa.com; > > > > seamoby@ietf.org > > > > Subject: RE: [Seamoby] CT Requirements Comments from IESG > > > > > > > > > > > > Hi all, > > > > > > > > jumping in as somebody who has been an observer so far, > > > struggling with the > > > > current discussion on > > > > 'integrity'. > > > > > > > > When I look at the current wording, i.e., > > > > "5.5.2 A context update MUST preserve the integrity, and > > > thus the meaning, > > > > of the context > > > > at each receiving AR. The context at the AR actually > > > supporting an MN's > > > > traffic will change with time. > > > > For example, the MN may initiate new microflow(s), or > > > discontinue existing > > > > microflows. Any change of context > > > > at the supporting AR must be replicated at those ARs that > > > have already > > > > received context for that MN.", > > > > > > > > and compare this to the plain integrity of the actually > > > transmitted data > > > > (i.e., its bits and therefore its semantics) > > > > that has been brought to the table as a replacement now, > > > I'm quite confident > > > > that this is not what the requirement > > > > is talking about. > > > > > > > > If we remove the word 'meaning' (which is very vague > and free for > > > > interpretation for me as well), it is still the word > > > > 'integrity' left, which is more than plain integrity of the > > > transmitted > > > > data, in particular if we look at the following sentences > > > > in the requirement, which state what kind of integrity is > > > meant (which > > > > probably also builds the bridge to the vague > > > > term 'meaning'), namely that the integrity of a context > > > must be preserved in > > > > the sense that a received context at new > > > > AR at some point t must be the same as the context at old > > > AR at the same > > > > time t. This is by far more than plain data > > > > integrity of the transmitted data. Even if your data has > > > been transmitted > > > > correctly, the context might be stale (and therefore > > > > its integrity is lost) because it had changed at old AR in > > > the meanwhile. > > > > The action to be taken is also given in the text, > > > > namely the change of context has to be replicated to the > > > new AR. As you can > > > > (hopefully) see this is by far more than > > > > preserving the 'meaning' of each bit. It mandates that > > > changes in the bit > > > > values at one end are reflected at the other > > > > end, i.e., it talks about distributed data integrity in my > > > interpretation of > > > > the requirement text. > > > > > > > > Hence, the actual concern might have been (just guessing) > > > whether or not it > > > > is the task of the CT protocol to > > > > preserve the abovementioned integrity. Maybe, the IESG > > > wants to see this > > > > functionality left to the replication logic that resides > > > > within each AR. Or on the contrary, they do not see this > > > important topic > > > > covered appropriately. > > > > > > > > Regards, > > > > > > > > > > > > Dirk > > > > > > > > -----Original Message----- > > > > From: ext Gary Kenward [ mailto:gkenward@nortelnetworks.com ] > > > > Sent: Thursday, July 11, 2002 3:48 PM > > > > To: 'James Kempf'; seamoby@ietf.org > > > > Subject: RE: [Seamoby] CT Requirements Comments from IESG > > > > > > > > > > > > > > > > You call it fidelity, I call it data integrity. > > > > I've seen "data integrity" used in publications > > > > (no, I cannot quote references). > > > > > > > > What we need is a term that everyone, including the > > > > IESG, can agree upon. > > > > > > > > > -----Original Message----- > > > > > From: James Kempf [ mailto:kempf@docomolabs-usa.com > > > > < mailto:kempf@docomolabs-usa.com > ] > > > > > Sent: July 11, 2002 12:22 > > > > > To: Kenward, Gary [WDLN2:AN10:EXCH]; seamoby@ietf.org > > > > > Subject: Re: [Seamoby] CT Requirements Comments from IESG > > > > > > > > > > > > > > > > Perhaps the actual answer is to state exactly what > was intended > > > > > > originally: that the bit order and bit values have to > > > arrive exactly > > > > > > as they were transmitted. > > > > > > > > > > > > > > > > So this requirement is talking about transmission fidelity? I > > > > > sure would not have guessed that from reading it. I thought it > > > > > intended to talk about usability. > > > > > > > > > > I would suggest that the wording you have above is really a > > > > > lot more precise that what is currently in the spec. > > > > > > > > > > Any other comments? Could we substitute Gary's wording above > > > > > for "meaning" in the current requirement. > > > > > > > > > > jak > > > > > > > > > > > > > > > > > > > > > > > > > ------_=_NextPart_001_01C22F3A.E21300A0 Content-Type: text/html; charset="iso-8859-1" RE: [Seamoby] CT Requirements Comments from IESG
Gary,
 
I see your usage scenario of CT (proactive) as a case for CT, but
not the primary case. This comes handy if you are building "capability
discovery" assisted handovers. 
 
Since we agreed on the text in another email, I won't dwell on this
any further.
 
Regards,
 
Madjid 
-----Original Message-----
From: Gary Kenward [mailto:gkenward@nortelnetworks.com]
Sent: Friday, July 19, 2002 9:15 AM
To: 'Nakhjiri Madjid-MNAKHJI1'; seamoby@ietf.org
Subject: RE: [Seamoby] CT Requirements Comments from IESG

Madjid:

  Two comments:

    1. As I responded to James, using CT in preparation of possible handovers *is*
       the main opportunity to ensure seamless. Trying to catch up to a handover,
       once it has begun, is very difficult, and likely to fail in many cases.

    2. What does "too early mean"? Just as there is no deterministic way to predict the
       direction of a mobile, and thus which AR the MN handsover to, there is no deterministic
       way to predict when this will happen. So, while the network/MN may know that the
       MN has the potential to handover to, say, 3 or 4 ARs, and can prepare for it,
       there is no way to pin down the epoch.

  I get the impression that either everyone has forgotten about proactive CT, or does
not care. Which is too bad, for the boy scouts are right on when they say "be prepared".

Gary

-----Original Message-----
From: Nakhjiri Madjid-MNAKHJI1 [mailto:Madjid.Nakhjiri@motorola.com]
Sent: July 18, 2002 17:17
To: Kenward, Gary [WDLN2:AN10:EXCH]; Nakhjiri Madjid-MNAKHJI1; 'Charles E. Perkins'
Cc: seamoby@ietf.org
Subject: RE: [Seamoby] CT Requirements Comments from IESG



-----Original Message-----
From: Gary Kenward [mailto:gkenward@nortelnetworks.com]
Sent: Thursday, July 18, 2002 9:52 AM
To: 'Nakhjiri Madjid-MNAKHJI1'; 'Charles E. Perkins'
Cc: seamoby@ietf.org
Subject: RE: [Seamoby] CT Requirements Comments from IESG


Define "done"?
 
Madjid>> Exactly my point, if you keep sending updates while you're
sending other context, you are never done.
 
Seriously, if CT is performed during or after a handover (reactively)
then, yes, there's not much more that can be done. If the context at
the destination is out of synch with changes in the source context,
there is an increased risk that the seamlessness of the handover will
be degraded.
 
Madjid>> Yes, assuming you mean L3 handover,
and this is the most critical use of CT: optimization
of handovers. I can't have CT add to feature disruption by getting
into an endless cycle of updates.
 
However, if CT is performed before a handover begins (proactively),
and changes occur at the source AR, then it would seem reasonable to
attempt updates. There is a presumption here that there is something
to be gained in handover performance by performing CT in advance of
an actual handover. It could turn out that CT (and the subsequent installion
of context at the destination AR) is so fast, that leaving the transfer
of context until a handover occurs (i.e. no proactive, only reactive) is
a sufficient, and simpler solution. We really won't know whether this
is the case until the wg starts looking at CT solutions.
 
Madjid>>sure, but this is not a time-critical CT and CT needs to send updates because
it started too early on a dynamic context.
 
 
 
 
Cheers,
Gary
-----Original Message-----
From: Nakhjiri Madjid-MNAKHJI1 [mailto:Madjid.Nakhjiri@motorola.com]
Sent: July 17, 2002 19:25
To: Kenward, Gary [WDLN2:AN10:EXCH]; 'Charles E. Perkins'
Cc: seamoby@ietf.org
Subject: RE: [Seamoby] CT Requirements Comments from IESG


Well, not trying to regurgitate (as you said)
but we never agreed on timing and reliability requirements and maybe
that was ok, because they depend on the scenario and protocols.
So why talk about sending updates after CT is done?
 
 
Madjid
-----Original Message-----
From: Gary Kenward [mailto:gkenward@nortelnetworks.com]
Sent: Friday, July 12, 2002 2:35 PM
To: 'Charles E. Perkins'
Cc: seamoby@ietf.org
Subject: RE: [Seamoby] CT Requirements Comments from IESG


I agree Charlie. However, we have to fix the issue with
the requirements. Are you suggesting that we relax the
requirement? By how much - clearly, some updates are required
(e.g. CT really should try and update when flows come and go).
Gary
> -----Original Message-----
> From: Charles E. Perkins [mailto:charliep@iprg.nokia.com]
> Sent: July 12, 2002 12:15
> To: Kenward, Gary [WDLN2:AN10:EXCH]
> Cc: seamoby@ietf.org
> Subject: Re: [Seamoby] CT Requirements Comments from IESG
>
>
>
>
> Hello folks,
>
> I think we ought to try to get context transfers
> working correctly without initially worrying about
> this synchronization problem.
>
> In the instances I am familiar with, it is not
> required.  The most stringent case seems to be
> ROHC, and even for that it is not necessary.
>
> We can solve the most urgent problems without having
> to deal with any additional context synchronization.
> When the old AR sends it, and the new AR gets it,
> we should consider the transfer done.  In those
> cases where reliability is at issue, the old AR
> can retransmit when ACK is not received.  In many
> cases, retransmission of context even once won't
> be useful.
>
> Regards,
> Charlie P.
>
>
>
> > Gary Kenward wrote:
> >
> > James:
> >
> >   Yes, we need to fix it, and I think it is doable.
> > Thanks to Dirk for highlighting the real problem here
> > (I think historically, the integrity requirement came out
> > of the reliability section, and somehow, got lumped with
> > synchronization and updates).
> >
> >   I think the requirements need a bit of rewording, and
> > the paragraph should fall out from this. I do believe
> > however, that making the synchronization of context between
> > old and new AR a MUST requirement would be too extreme, and
> > result in a brittle solution. CT should certainly do it's best to
> > provide synchronization, but as was discussed in a recent
> > exchange, it would be impossible to guarantee synchronization
> > at any instant.
> >
> >   Any ideas/comments from the wg?
> >
> > Gary
> >
> > > -----Original Message-----
> > > From: James Kempf [mailto:kempf@docomolabs-usa.com]
> > > Sent: July 11, 2002 18:32
> > > To: Kenward, Gary [WDLN2:AN10:EXCH]; Dirk.Trossen@nokia.com;
> > > seamoby@ietf.org
> > > Subject: Re: [Seamoby] CT Requirements Comments from IESG
> > >
> > >
> > > Gary/Dirk,
> > >
> > > I think you may be on to something here. I think this might
> > > be what the IESG was talking about it the first point, namely the
> > > lack of discussion of dynamic changes in the context.
> > >
> > > Is there some way we could cook this idea down into a
> > > paragraph that we could insert for this requirement?
> > >
> > >             jak
> > >
> > > ----- Original Message -----
> > > From: "Gary Kenward" <gkenward@nortelnetworks.com>
> > > To: <Dirk.Trossen@nokia.com>; <kempf@docomolabs-usa.com>;
> > > <seamoby@ietf.org>
> > > Sent: Thursday, July 11, 2002 1:56 PM
> > > Subject: RE: [Seamoby] CT Requirements Comments from IESG
> > >
> > >
> > > > Dirk:
> > > >
> > > >   A valid point. There is a certain atomic level of
> > > granularity which has to
> > > > be
> > > > dealt with - that is, there's no protocol in the world that
> > > can synchronize
> > > > changes in
> > > > information that occur at the source while the information
> > > is "in-flight" or
> > > > being
> > > > received at the destination. If changes in context while
> > > the context is
> > > > being transferred
> > > > make a different to the successful performance of CT, then
> > > there is no hope.
> > > >
> > > >   The problem is most significant for state context
> > > transfer. E.g. counters
> > > > will continue
> > > > to count while CT is moving the context to the destination.
> > > Either these
> > > > changes have no
> > > > significant impact upon the forwarding service provided at
> > > the new AR (e.g.
> > > > it may not
> > > > matter that a policing meter misses a few packet counts),
> > > or a different
> > > > mechanism
> > > > has to be defined for re-establishing the state context.
> > > >
> > > >   The handover is real and unavoidable. Mitigating the
> > > disruption to the
> > > > service at the new
> > > > AR is the challenge. It would be nice if the disruption
> was nil, but
> > > > unlikely.
> > > >
> > > > Gary
> > > >
> > > > -----Original Message-----
> > > > From: Dirk.Trossen@nokia.com [mailto:Dirk.Trossen@nokia.com]
> > > > Sent: July 11, 2002 16:30
> > > > To: Kenward, Gary [WDLN2:AN10:EXCH]; kempf@docomolabs-usa.com;
> > > > seamoby@ietf.org
> > > > Subject: RE: [Seamoby] CT Requirements Comments from IESG
> > > >
> > > >
> > > > Hi all,
> > > >
> > > > jumping in as somebody who has been an observer so far,
> > > struggling with the
> > > > current discussion on
> > > > 'integrity'.
> > > >
> > > > When I look at the current wording, i.e.,
> > > > "5.5.2 A context update MUST preserve the integrity, and
> > > thus the meaning,
> > > > of the context
> > > > at each receiving AR. The context at the AR actually
> > > supporting an MN's
> > > > traffic will change with time.
> > > > For example, the MN may initiate new microflow(s), or
> > > discontinue existing
> > > > microflows. Any change of context
> > > > at the supporting AR must be replicated at those ARs that
> > > have already
> > > > received context for that MN.",
> > > >
> > > > and compare this to the plain integrity of the actually
> > > transmitted data
> > > > (i.e., its bits and therefore its semantics)
> > > > that has been brought to the table as a replacement now,
> > > I'm quite confident
> > > > that this is not what the requirement
> > > > is talking about.
> > > >
> > > > If we remove the word 'meaning' (which is very vague
> and free for
> > > > interpretation for me as well), it is still the word
> > > > 'integrity' left, which is more than plain integrity of the
> > > transmitted
> > > > data, in particular if we look at the following sentences
> > > > in the requirement, which state what kind of integrity is
> > > meant (which
> > > > probably also builds the bridge to the vague
> > > > term 'meaning'), namely that the integrity of a context
> > > must be preserved in
> > > > the sense that a received context at new
> > > > AR at some point t must be the same as the context at old
> > > AR at the same
> > > > time t. This is by far more than plain data
> > > > integrity of the transmitted data. Even if your data has
> > > been transmitted
> > > > correctly, the context might be stale (and therefore
> > > > its integrity is lost) because it had changed at old AR in
> > > the meanwhile.
> > > > The action to be taken is also given in the text,
> > > > namely the change of context has to be replicated to the
> > > new AR. As you can
> > > > (hopefully) see this is by far more than
> > > > preserving the 'meaning' of each bit. It mandates that
> > > changes in the bit
> > > > values at one end are reflected at the other
> > > > end, i.e., it talks about distributed data integrity in my
> > > interpretation of
> > > > the requirement text.
> > > >
> > > > Hence, the actual concern might have been (just guessing)
> > > whether or not it
> > > > is the task of the CT protocol to
> > > > preserve the abovementioned integrity. Maybe, the IESG
> > > wants to see this
> > > > functionality left to the replication logic that resides
> > > > within each AR. Or on the contrary, they do not see this
> > > important topic
> > > > covered appropriately.
> > > >
> > > > Regards,
> > > >
> > > >
> > > > Dirk
> > > >
> > > > -----Original Message-----
> > > > From: ext Gary Kenward [mailto:gkenward@nortelnetworks.com]
> > > > Sent: Thursday, July 11, 2002 3:48 PM
> > > > To: 'James Kempf'; seamoby@ietf.org
> > > > Subject: RE: [Seamoby] CT Requirements Comments from IESG
> > > >
> > > >
> > > >
> > > > You call it fidelity, I call it data integrity.
> > > > I've seen "data integrity" used in publications
> > > > (no, I cannot quote references).
> > > >
> > > > What we need is a term that everyone, including the
> > > > IESG, can agree upon.
> > > >
> > > > > -----Original Message-----
> > > > > From: James Kempf [ mailto:kempf@docomolabs-usa.com
> > > > <mailto:kempf@docomolabs-usa.com> ]
> > > > > Sent: July 11, 2002 12:22
> > > > > To: Kenward, Gary [WDLN2:AN10:EXCH]; seamoby@ietf.org
> > > > > Subject: Re: [Seamoby] CT Requirements Comments from IESG
> > > > >
> > > > >
> > > > > > Perhaps the actual answer is to state exactly what
> was intended
> > > > > > originally: that the bit order and bit values have to
> > > arrive exactly
> > > > > > as they were transmitted.
> > > > > >
> > > > >
> > > > > So this requirement is talking about transmission fidelity? I
> > > > > sure would not have guessed that from reading it. I thought it
> > > > > intended to talk about usability.
> > > > >
> > > > > I would suggest that the wording you have above is really a
> > > > > lot more precise that what is currently in the spec.
> > > > >
> > > > > Any other comments? Could we substitute Gary's wording above
> > > > > for "meaning" in the current requirement.
> > > > >
> > > > >             jak
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
>

------_=_NextPart_001_01C22F3A.E21300A0-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Mon Jul 22 18:34:07 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16696 for ; Mon, 22 Jul 2002 18:34:07 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA07039; Mon, 22 Jul 2002 18:28:32 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA06993 for ; Mon, 22 Jul 2002 18:28:29 -0400 (EDT) Received: from motgate4.mot.com (motgate4.mot.com [144.189.100.102]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16185 for ; Mon, 22 Jul 2002 18:27:27 -0400 (EDT) Received: [from pobox4.mot.com (pobox4.mot.com [10.64.251.243]) by motgate4.mot.com (motgate4 2.1) with ESMTP id PAA15025 for ; Mon, 22 Jul 2002 15:28:27 -0700 (MST)] Received: [from il75exm04.cig.mot.com ([136.182.110.113]) by pobox4.mot.com (MOT-pobox4 2.0) with ESMTP id PAA15795 for ; Mon, 22 Jul 2002 15:28:27 -0700 (MST)] Received: by IL75EXM04 with Internet Mail Service (5.5.2654.52) id ; Mon, 22 Jul 2002 17:28:26 -0500 Message-ID: <35DBB8B7AC89D4118E98009027B1009B08AD55E7@IL27EXM10.cig.mot.com> From: Nakhjiri Madjid-MNAKHJI1 To: "'James Kempf'" , Nakhjiri Madjid-MNAKHJI1 , Gary Kenward , seamoby@ietf.org Date: Mon, 22 Jul 2002 17:28:01 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.52) Content-Type: text/plain; charset="iso-8859-1" Subject: [Seamoby] RE: Section 5.5 Modifications Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org James, Ok, I guess I am reactive to proactive or reactive CT, because the baggage that the words have and their relation to handover and L2 triggers. If I understand your point clearly, you are refering to the need for transfering different feature contexts at different points in relation to handover. I think this is covered by the following (what lead to this discussion, was actually the difference in urgency of header compression versus accounting data) And the MAY and MUSTs were debated heavily too :) Regards, Madjid 4.11 Context information MAY be transferred in phases. Providing for phased transfers allows the context acquisition and transfer to be prioritized. 4.12 The context information to be transferred MUST be available at the AR performing the transfer, prior to the initiation of a given phase of the context transfer. To effect a rapid transfer, the context information has to be readily available when the AR begins a phase of the transfer. If the context transfer is comprised of a single phase, then all of the context must be available prior to the transfer initiation. -----Original Message----- From: James Kempf [mailto:kempf@docomolabs-usa.com] Sent: Monday, July 22, 2002 12:08 PM To: Nakhjiri Madjid-MNAKHJI1; Gary Kenward; seamoby@ietf.org Subject: Re: Section 5.5 Modifications Madjid, > Well, I am maybe not as good of a boy scout as some others > but, I remember 3 weeks of debate, followed by a period > of 2 months of silence and then a 90 minute discussion in London > (not to mention the 3$K trip expense :) ) > that lead to us not making reactive > or proactive CT as a basis for the CT usefulness debate. > Lets not open that barrel of snakes (certainly bigger than worms) again. > > If you want to mention proactive a byproduct, or use case, that is fine. > But I think we should be careful about making a byproduct a primary goal. > I guess I am not clear what your opinion is on the proposed change. The intent of the changes I proposed, including both the modification to Section 5.5 and the new Section 5.8, was to leave it up to the individual feature context specifications whether the transfer was done proactively or reactively. The general context transfer protocol would continue to be neutral in this regard, as it was agreed to in London. Is this acceptable to you? Also, if you feel the wording I've proposed doesn't capture this intent, please feel free to propose an alternative. jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@ns.ietf.org Mon Jul 22 18:34:08 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16705 for ; Mon, 22 Jul 2002 18:34:08 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA10659 for seamoby-archive@odin.ietf.org; Mon, 22 Jul 2002 18:35:08 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA07039; Mon, 22 Jul 2002 18:28:32 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA06993 for ; Mon, 22 Jul 2002 18:28:29 -0400 (EDT) Received: from motgate4.mot.com (motgate4.mot.com [144.189.100.102]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16185 for ; Mon, 22 Jul 2002 18:27:27 -0400 (EDT) Received: [from pobox4.mot.com (pobox4.mot.com [10.64.251.243]) by motgate4.mot.com (motgate4 2.1) with ESMTP id PAA15025 for ; Mon, 22 Jul 2002 15:28:27 -0700 (MST)] Received: [from il75exm04.cig.mot.com ([136.182.110.113]) by pobox4.mot.com (MOT-pobox4 2.0) with ESMTP id PAA15795 for ; Mon, 22 Jul 2002 15:28:27 -0700 (MST)] Received: by IL75EXM04 with Internet Mail Service (5.5.2654.52) id ; Mon, 22 Jul 2002 17:28:26 -0500 Message-ID: <35DBB8B7AC89D4118E98009027B1009B08AD55E7@IL27EXM10.cig.mot.com> From: Nakhjiri Madjid-MNAKHJI1 To: "'James Kempf'" , Nakhjiri Madjid-MNAKHJI1 , Gary Kenward , seamoby@ietf.org Date: Mon, 22 Jul 2002 17:28:01 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.52) Content-Type: text/plain; charset="iso-8859-1" Subject: [Seamoby] RE: Section 5.5 Modifications Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org James, Ok, I guess I am reactive to proactive or reactive CT, because the baggage that the words have and their relation to handover and L2 triggers. If I understand your point clearly, you are refering to the need for transfering different feature contexts at different points in relation to handover. I think this is covered by the following (what lead to this discussion, was actually the difference in urgency of header compression versus accounting data) And the MAY and MUSTs were debated heavily too :) Regards, Madjid 4.11 Context information MAY be transferred in phases. Providing for phased transfers allows the context acquisition and transfer to be prioritized. 4.12 The context information to be transferred MUST be available at the AR performing the transfer, prior to the initiation of a given phase of the context transfer. To effect a rapid transfer, the context information has to be readily available when the AR begins a phase of the transfer. If the context transfer is comprised of a single phase, then all of the context must be available prior to the transfer initiation. -----Original Message----- From: James Kempf [mailto:kempf@docomolabs-usa.com] Sent: Monday, July 22, 2002 12:08 PM To: Nakhjiri Madjid-MNAKHJI1; Gary Kenward; seamoby@ietf.org Subject: Re: Section 5.5 Modifications Madjid, > Well, I am maybe not as good of a boy scout as some others > but, I remember 3 weeks of debate, followed by a period > of 2 months of silence and then a 90 minute discussion in London > (not to mention the 3$K trip expense :) ) > that lead to us not making reactive > or proactive CT as a basis for the CT usefulness debate. > Lets not open that barrel of snakes (certainly bigger than worms) again. > > If you want to mention proactive a byproduct, or use case, that is fine. > But I think we should be careful about making a byproduct a primary goal. > I guess I am not clear what your opinion is on the proposed change. The intent of the changes I proposed, including both the modification to Section 5.5 and the new Section 5.8, was to leave it up to the individual feature context specifications whether the transfer was done proactively or reactively. The general context transfer protocol would continue to be neutral in this regard, as it was agreed to in London. Is this acceptable to you? Also, if you feel the wording I've proposed doesn't capture this intent, please feel free to propose an alternative. jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Mon Jul 22 18:58:33 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18754 for ; Mon, 22 Jul 2002 18:58:33 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA21049; Mon, 22 Jul 2002 18:55:45 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA21004 for ; Mon, 22 Jul 2002 18:55:42 -0400 (EDT) Received: from motgate3.mot.com (motgate3.mot.com [144.189.100.103]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18410 for ; Mon, 22 Jul 2002 18:54:39 -0400 (EDT) Received: [from pobox4.mot.com (pobox4.mot.com [10.64.251.243]) by motgate3.mot.com (motgate3 2.1) with ESMTP id PAA00679 for ; Mon, 22 Jul 2002 15:54:33 -0700 (MST)] Received: [from il27exb01.cig.mot.com (il27exb01.cig.mot.com [136.182.15.100]) by pobox4.mot.com (MOT-pobox4 2.0) with ESMTP id PAA24064 for ; Mon, 22 Jul 2002 15:55:40 -0700 (MST)] Received: by il27exb01.cig.mot.com with Internet Mail Service (5.5.2654.52) id ; Mon, 22 Jul 2002 17:55:39 -0500 Message-ID: <35DBB8B7AC89D4118E98009027B1009B08AD55E9@IL27EXM10.cig.mot.com> From: Nakhjiri Madjid-MNAKHJI1 To: "'James Kempf'" , seamoby@ietf.org Subject: RE: [Seamoby] New Section 5.8 - Requirements on Feature Context S pecifications Date: Mon, 22 Jul 2002 17:55:36 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.52) Content-Type: text/plain; charset="iso-8859-1" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org James, thanks for making the effort you made on this section. and thanks for trying to expedite this process. I like most of it except a few minor comments based on the history of discussions. Please see below. BR, Madjid -----Original Message----- From: James Kempf [mailto:kempf@docomolabs-usa.com] Sent: Friday, July 19, 2002 8:26 PM To: seamoby@ietf.org Subject: [Seamoby] New Section 5.8 - Requirements on Feature Context Specifications I'd like to propose the following new section for the CT requirments listing requirements on feature context specifications. Note that this section does not place requirements on the feature context protocols themselves, but only on their specifications. jak ------------------------------------------ 5.8 Feature Context Specifications The context transfer protocol provides a basic framework in which feature contexts of varying types can be transfered. Recognizing that the particular feature contexts may have very different needs with regard to update, synchronization, and transport, this section contains requirements on the feature context specifications. Note that these requirements do not constrain the actual feature context protocols themselves, but only their specification. 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. 5.8.2 A feature context specification MUST define the byte layout of the individual elements of the feature context, and how those map into the context transfer protocol's container. The byte layout SHOULD obey standard IETF conventions with regard to mapping of data into on the wire format. 5.8.3 A feature context specification MUST define the transport to be used. If the feature context is transferred using an IETF transport layer protocol , then the feature context specification MUST include the full details of how the transport layer protocol is used. Madjid>> This would impose a little bit of vertical design and might again lead to heated debates on whether to use UDP/SCTP.... Don't know if the following addition within <> helps: Madjid>> "If the feature context is transferred using an IETF transport layer protocol , , then the feature context specification MUST include the full details of how the transport layer protocol is used. " 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 through a non-IETF protocol (such as IAPP [4]), then the feature context protocol specification MUST define how the standard context transfer container is mapped into the non-IETF transport. 5.8.4 A feature context specification MUST indicate whether update to context information is allowed if changes in the source occur after the context is transferred. If such changes are allowed, the feature context specification MUST define the change protocol message format using the standard context transfer container, and MUST include details of how the update is accomplished . Madjid>> See the addition above. The external trigger might be needed. 5.8.5 A feature context specification MUST indicate whether the context transfer is tightly synchronized with external events, such as handover. The freature context specification MUST indicate what event or events trigger transfer. 6.0 References [4] "Recommended Practice for Multi-vendor Interaccess Point Interoperability via an Inter-access Point Protocol Across Distribution Systems Supporting IEEE 802.11 Operation," IEEE Std. 802.11f/D3, January, 2002. _______________________________________________ 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 From daemon@ns.ietf.org Mon Jul 22 18:58:34 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18762 for ; Mon, 22 Jul 2002 18:58:34 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA22944 for seamoby-archive@odin.ietf.org; Mon, 22 Jul 2002 18:59:35 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA21049; Mon, 22 Jul 2002 18:55:45 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA21004 for ; Mon, 22 Jul 2002 18:55:42 -0400 (EDT) Received: from motgate3.mot.com (motgate3.mot.com [144.189.100.103]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18410 for ; Mon, 22 Jul 2002 18:54:39 -0400 (EDT) Received: [from pobox4.mot.com (pobox4.mot.com [10.64.251.243]) by motgate3.mot.com (motgate3 2.1) with ESMTP id PAA00679 for ; Mon, 22 Jul 2002 15:54:33 -0700 (MST)] Received: [from il27exb01.cig.mot.com (il27exb01.cig.mot.com [136.182.15.100]) by pobox4.mot.com (MOT-pobox4 2.0) with ESMTP id PAA24064 for ; Mon, 22 Jul 2002 15:55:40 -0700 (MST)] Received: by il27exb01.cig.mot.com with Internet Mail Service (5.5.2654.52) id ; Mon, 22 Jul 2002 17:55:39 -0500 Message-ID: <35DBB8B7AC89D4118E98009027B1009B08AD55E9@IL27EXM10.cig.mot.com> From: Nakhjiri Madjid-MNAKHJI1 To: "'James Kempf'" , seamoby@ietf.org Subject: RE: [Seamoby] New Section 5.8 - Requirements on Feature Context S pecifications Date: Mon, 22 Jul 2002 17:55:36 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.52) Content-Type: text/plain; charset="iso-8859-1" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org James, thanks for making the effort you made on this section. and thanks for trying to expedite this process. I like most of it except a few minor comments based on the history of discussions. Please see below. BR, Madjid -----Original Message----- From: James Kempf [mailto:kempf@docomolabs-usa.com] Sent: Friday, July 19, 2002 8:26 PM To: seamoby@ietf.org Subject: [Seamoby] New Section 5.8 - Requirements on Feature Context Specifications I'd like to propose the following new section for the CT requirments listing requirements on feature context specifications. Note that this section does not place requirements on the feature context protocols themselves, but only on their specifications. jak ------------------------------------------ 5.8 Feature Context Specifications The context transfer protocol provides a basic framework in which feature contexts of varying types can be transfered. Recognizing that the particular feature contexts may have very different needs with regard to update, synchronization, and transport, this section contains requirements on the feature context specifications. Note that these requirements do not constrain the actual feature context protocols themselves, but only their specification. 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. 5.8.2 A feature context specification MUST define the byte layout of the individual elements of the feature context, and how those map into the context transfer protocol's container. The byte layout SHOULD obey standard IETF conventions with regard to mapping of data into on the wire format. 5.8.3 A feature context specification MUST define the transport to be used. If the feature context is transferred using an IETF transport layer protocol , then the feature context specification MUST include the full details of how the transport layer protocol is used. Madjid>> This would impose a little bit of vertical design and might again lead to heated debates on whether to use UDP/SCTP.... Don't know if the following addition within <> helps: Madjid>> "If the feature context is transferred using an IETF transport layer protocol , , then the feature context specification MUST include the full details of how the transport layer protocol is used. " 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 through a non-IETF protocol (such as IAPP [4]), then the feature context protocol specification MUST define how the standard context transfer container is mapped into the non-IETF transport. 5.8.4 A feature context specification MUST indicate whether update to context information is allowed if changes in the source occur after the context is transferred. If such changes are allowed, the feature context specification MUST define the change protocol message format using the standard context transfer container, and MUST include details of how the update is accomplished . Madjid>> See the addition above. The external trigger might be needed. 5.8.5 A feature context specification MUST indicate whether the context transfer is tightly synchronized with external events, such as handover. The freature context specification MUST indicate what event or events trigger transfer. 6.0 References [4] "Recommended Practice for Multi-vendor Interaccess Point Interoperability via an Inter-access Point Protocol Across Distribution Systems Supporting IEEE 802.11 Operation," IEEE Std. 802.11f/D3, January, 2002. _______________________________________________ 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 From seamoby-admin@ietf.org Mon Jul 22 19:08:44 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19659 for ; Mon, 22 Jul 2002 19:08:43 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA27129; Mon, 22 Jul 2002 19:07:01 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA27080 for ; Mon, 22 Jul 2002 19:06:58 -0400 (EDT) Received: from motgate.mot.com (motgate.mot.com [129.188.136.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19430 for ; Mon, 22 Jul 2002 19:05:56 -0400 (EDT) Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate.mot.com (motgate 2.1) with ESMTP id QAA18198 for ; Mon, 22 Jul 2002 16:06:58 -0700 (MST)] Received: [from il27exm07.cig.mot.com (IL27EXM07.cig.mot.com [136.182.15.116]) by mothost.mot.com (MOT-pobox 2.0) with ESMTP id QAA10271 for ; Mon, 22 Jul 2002 16:07:13 -0700 (MST)] Received: by IL27EXM07.cig.mot.com with Internet Mail Service (5.5.2654.52) id <3FLZ5SS4>; Mon, 22 Jul 2002 18:06:58 -0500 Message-ID: <35DBB8B7AC89D4118E98009027B1009B08AD55EA@IL27EXM10.cig.mot.com> From: Nakhjiri Madjid-MNAKHJI1 To: "'john.loughney@nokia.com'" , Nakhjiri Madjid-MNAKHJI1 , seamoby@ietf.org Cc: mankin@psg.com Subject: RE: [Seamoby] Section 5.2 in CT Requirements Date: Mon, 22 Jul 2002 18:06:57 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.52) Content-Type: text/plain; charset="iso-8859-1" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Hi John, Well I won't say no to a giving hand :) If you like to take on this effort, that is fine, as long as the reliability requirements of CT and CT requirement RFC process does not have a dependancy on completion of this draft. I am glad James brought the IAPP example, already we are seeing people moving away from IETF CT because it has been delayed so much. I think James' effort in reviving the CT work is very valid and constructive (given that some of us now have some hindsight with CT, we have dealt with reliability issues in our draft making zero assumptions about transport layer. Please let me know if I can send our draft to you). I think James is leading in the right direction, given that CT needs some CPR right now, and then once we get into solutions and specific features, things will become more clear. Regards, Madjid -----Original Message----- From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] Sent: Sunday, July 21, 2002 10:43 PM To: Madjid Nakhjiri; seamoby@ietf.org Cc: mankin@psg.com Subject: RE: [Seamoby] Section 5.2 in CT Requirements Hi Madjid, > I think this will just delay things, the reason: > you need to look at each protocol individually and determine > its reliability needs, not to mention design scenarios for every > person's network. > > Not to mention that you have found somebody who wants to do this > study :) I think we have waited long enough for requirement. What I think we want to do is progress the requirements, without a detailed discussion on reliability, as that has been a rathole. I think we need a short document, listing some transport options, and with some pro's & con's. This could be a living document. I'd be happy to edit folks suggestions into a document. I see the following options: 1) ICMP 2) UDP 3) TCP a) reuse existing TCP connections b) dynamic TCP connections 4) SCTP a) reuse existing TCP connections b) dynamic TCP connections c) PR-SCTP 5) DCCP 6) other a) routing protocol extensions b) ? John _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@ns.ietf.org Mon Jul 22 19:08:44 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19670 for ; Mon, 22 Jul 2002 19:08:44 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id TAA28467 for seamoby-archive@odin.ietf.org; Mon, 22 Jul 2002 19:09:45 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA27129; Mon, 22 Jul 2002 19:07:01 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA27080 for ; Mon, 22 Jul 2002 19:06:58 -0400 (EDT) Received: from motgate.mot.com (motgate.mot.com [129.188.136.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19430 for ; Mon, 22 Jul 2002 19:05:56 -0400 (EDT) Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate.mot.com (motgate 2.1) with ESMTP id QAA18198 for ; Mon, 22 Jul 2002 16:06:58 -0700 (MST)] Received: [from il27exm07.cig.mot.com (IL27EXM07.cig.mot.com [136.182.15.116]) by mothost.mot.com (MOT-pobox 2.0) with ESMTP id QAA10271 for ; Mon, 22 Jul 2002 16:07:13 -0700 (MST)] Received: by IL27EXM07.cig.mot.com with Internet Mail Service (5.5.2654.52) id <3FLZ5SS4>; Mon, 22 Jul 2002 18:06:58 -0500 Message-ID: <35DBB8B7AC89D4118E98009027B1009B08AD55EA@IL27EXM10.cig.mot.com> From: Nakhjiri Madjid-MNAKHJI1 To: "'john.loughney@nokia.com'" , Nakhjiri Madjid-MNAKHJI1 , seamoby@ietf.org Cc: mankin@psg.com Subject: RE: [Seamoby] Section 5.2 in CT Requirements Date: Mon, 22 Jul 2002 18:06:57 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.52) Content-Type: text/plain; charset="iso-8859-1" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Hi John, Well I won't say no to a giving hand :) If you like to take on this effort, that is fine, as long as the reliability requirements of CT and CT requirement RFC process does not have a dependancy on completion of this draft. I am glad James brought the IAPP example, already we are seeing people moving away from IETF CT because it has been delayed so much. I think James' effort in reviving the CT work is very valid and constructive (given that some of us now have some hindsight with CT, we have dealt with reliability issues in our draft making zero assumptions about transport layer. Please let me know if I can send our draft to you). I think James is leading in the right direction, given that CT needs some CPR right now, and then once we get into solutions and specific features, things will become more clear. Regards, Madjid -----Original Message----- From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] Sent: Sunday, July 21, 2002 10:43 PM To: Madjid Nakhjiri; seamoby@ietf.org Cc: mankin@psg.com Subject: RE: [Seamoby] Section 5.2 in CT Requirements Hi Madjid, > I think this will just delay things, the reason: > you need to look at each protocol individually and determine > its reliability needs, not to mention design scenarios for every > person's network. > > Not to mention that you have found somebody who wants to do this > study :) I think we have waited long enough for requirement. What I think we want to do is progress the requirements, without a detailed discussion on reliability, as that has been a rathole. I think we need a short document, listing some transport options, and with some pro's & con's. This could be a living document. I'd be happy to edit folks suggestions into a document. I see the following options: 1) ICMP 2) UDP 3) TCP a) reuse existing TCP connections b) dynamic TCP connections 4) SCTP a) reuse existing TCP connections b) dynamic TCP connections c) PR-SCTP 5) DCCP 6) other a) routing protocol extensions b) ? John _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Tue Jul 23 02:24:14 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA00842 for ; Tue, 23 Jul 2002 02:24:14 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA15750; Tue, 23 Jul 2002 02:22:02 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA15719 for ; Tue, 23 Jul 2002 02:22:00 -0400 (EDT) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA00774 for ; Tue, 23 Jul 2002 02:20:58 -0400 (EDT) From: john.loughney@nokia.com Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g6N6MWi06337 for ; Tue, 23 Jul 2002 09:22:32 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 23 Jul 2002 09:21:58 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Tue, 23 Jul 2002 09:21:58 +0300 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Subject: RE: [Seamoby] Section 5.2 in CT Requirements Date: Tue, 23 Jul 2002 09:21:58 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC657AF@esebe004.NOE.Nokia.com> Thread-Topic: [Seamoby] Section 5.2 in CT Requirements Thread-Index: AcIxnXc2z338IwPVTw+PIXdxmodDIAAc6vlQ To: , X-OriginalArrivalTime: 23 Jul 2002 06:21:58.0898 (UTC) FILETIME=[3FFA0D20:01C23211] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id CAA15720 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 8bit Hi James, > > Additionally, I don't think that we want to get into defining new > > transport protocols or behaviors. > > > > > That is exactly why I proposed this requirement. The intent > of this requirement, > together with the newly proposed Section 5.8, is that it > would be up to the > particular feature context profile to specify the transport. > > Here's an example of why I think the requirement is needed. > 802.11 specifies > its own context transfer protocol, namely IAPP. If we specify > that, for example, > SCTP is required for transport, vendors on 802.11 would have > to implement two > context transfer protocols, IAPP and the Seamoby SCTP-based > protocol. IMHO, it > makes sense to only have one context transfer protocol and > leverage a particular > transport for the feature contexts that need it. > > Does this make sense? It makes sense, but this sounds much more like solution space than requirements. John _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@ns.ietf.org Tue Jul 23 02:24:15 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA00850 for ; Tue, 23 Jul 2002 02:24:15 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id CAA15841 for seamoby-archive@odin.ietf.org; Tue, 23 Jul 2002 02:25:16 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA15750; Tue, 23 Jul 2002 02:22:02 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA15719 for ; Tue, 23 Jul 2002 02:22:00 -0400 (EDT) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA00774 for ; Tue, 23 Jul 2002 02:20:58 -0400 (EDT) From: john.loughney@nokia.com Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g6N6MWi06337 for ; Tue, 23 Jul 2002 09:22:32 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 23 Jul 2002 09:21:58 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Tue, 23 Jul 2002 09:21:58 +0300 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Subject: RE: [Seamoby] Section 5.2 in CT Requirements Date: Tue, 23 Jul 2002 09:21:58 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC657AF@esebe004.NOE.Nokia.com> Thread-Topic: [Seamoby] Section 5.2 in CT Requirements Thread-Index: AcIxnXc2z338IwPVTw+PIXdxmodDIAAc6vlQ To: , X-OriginalArrivalTime: 23 Jul 2002 06:21:58.0898 (UTC) FILETIME=[3FFA0D20:01C23211] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id CAA15720 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 8bit Hi James, > > Additionally, I don't think that we want to get into defining new > > transport protocols or behaviors. > > > > > That is exactly why I proposed this requirement. The intent > of this requirement, > together with the newly proposed Section 5.8, is that it > would be up to the > particular feature context profile to specify the transport. > > Here's an example of why I think the requirement is needed. > 802.11 specifies > its own context transfer protocol, namely IAPP. If we specify > that, for example, > SCTP is required for transport, vendors on 802.11 would have > to implement two > context transfer protocols, IAPP and the Seamoby SCTP-based > protocol. IMHO, it > makes sense to only have one context transfer protocol and > leverage a particular > transport for the feature contexts that need it. > > Does this make sense? It makes sense, but this sounds much more like solution space than requirements. John _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Tue Jul 23 11:38:48 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18712 for ; Tue, 23 Jul 2002 11:38:48 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA19309; Tue, 23 Jul 2002 11:31:43 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA19253 for ; Tue, 23 Jul 2002 11:31:35 -0400 (EDT) Received: from fridge.docomolabs-usa.com (fwuser@key1.docomolabs-usa.com [216.98.102.225]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17801 for ; Tue, 23 Jul 2002 11:30:34 -0400 (EDT) Message-ID: <007801c2325d$cb182620$296015ac@T23KEMPF> From: "James Kempf" To: , References: <0C1353ABB1DEB74DB067ADFF749C4EEFC657AF@esebe004.NOE.Nokia.com> Subject: Re: [Seamoby] Section 5.2 in CT Requirements Date: Tue, 23 Jul 2002 08:29:54 -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-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit John, > > > Additionally, I don't think that we want to get into defining new > > > transport protocols or behaviors. > > > > > > > > > That is exactly why I proposed this requirement. The intent > > of this requirement, > > together with the newly proposed Section 5.8, is that it > > would be up to the > > particular feature context profile to specify the transport. > > > > Here's an example of why I think the requirement is needed. > > 802.11 specifies > > its own context transfer protocol, namely IAPP. If we specify > > that, for example, > > SCTP is required for transport, vendors on 802.11 would have > > to implement two > > context transfer protocols, IAPP and the Seamoby SCTP-based > > protocol. IMHO, it > > makes sense to only have one context transfer protocol and > > leverage a particular > > transport for the feature contexts that need it. > > > > Does this make sense? > > It makes sense, but this sounds much more like solution space > than requirements. > It is solution space, but it motivates the requirement that the generic CT protocol not specify a particular transport. jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Tue Jul 23 12:24:35 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18720 for ; Tue, 23 Jul 2002 11:38:48 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA20325 for seamoby-archive@odin.ietf.org; Tue, 23 Jul 2002 11:39:49 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA19309; Tue, 23 Jul 2002 11:31:43 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA19253 for ; Tue, 23 Jul 2002 11:31:35 -0400 (EDT) Received: from fridge.docomolabs-usa.com (fwuser@key1.docomolabs-usa.com [216.98.102.225]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17801 for ; Tue, 23 Jul 2002 11:30:34 -0400 (EDT) Message-ID: <007801c2325d$cb182620$296015ac@T23KEMPF> From: "James Kempf" To: , References: <0C1353ABB1DEB74DB067ADFF749C4EEFC657AF@esebe004.NOE.Nokia.com> Subject: Re: [Seamoby] Section 5.2 in CT Requirements Date: Tue, 23 Jul 2002 08:29:54 -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-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit John, > > > Additionally, I don't think that we want to get into defining new > > > transport protocols or behaviors. > > > > > > > > > That is exactly why I proposed this requirement. The intent > > of this requirement, > > together with the newly proposed Section 5.8, is that it > > would be up to the > > particular feature context profile to specify the transport. > > > > Here's an example of why I think the requirement is needed. > > 802.11 specifies > > its own context transfer protocol, namely IAPP. If we specify > > that, for example, > > SCTP is required for transport, vendors on 802.11 would have > > to implement two > > context transfer protocols, IAPP and the Seamoby SCTP-based > > protocol. IMHO, it > > makes sense to only have one context transfer protocol and > > leverage a particular > > transport for the feature contexts that need it. > > > > Does this make sense? > > It makes sense, but this sounds much more like solution space > than requirements. > It is solution space, but it motivates the requirement that the generic CT protocol not specify a particular transport. jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Tue Jul 23 12:44:01 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22402 for ; Tue, 23 Jul 2002 12:44:01 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA26868; Tue, 23 Jul 2002 12:37:44 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA26836 for ; Tue, 23 Jul 2002 12:37:42 -0400 (EDT) Received: from fridge.docomolabs-usa.com (fwuser@key1.docomolabs-usa.com [216.98.102.225]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22018 for ; Tue, 23 Jul 2002 12:36:40 -0400 (EDT) Message-ID: <011701c23267$07bea4b0$296015ac@T23KEMPF> From: "James Kempf" To: "Nakhjiri Madjid-MNAKHJI1" , References: <35DBB8B7AC89D4118E98009027B1009B08AD55E9@IL27EXM10.cig.mot.com> Subject: Re: [Seamoby] New Section 5.8 - Requirements on Feature Context Specifications Date: Tue, 23 Jul 2002 09:36:01 -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-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit Madjid, The additions look fine to me. I'll fold them into the proposed text. We need to wait until Gary is back from vacation to see what he has to say. jak ----- Original Message ----- From: "Nakhjiri Madjid-MNAKHJI1" To: "'James Kempf'" ; Sent: Monday, July 22, 2002 3:55 PM Subject: RE: [Seamoby] New Section 5.8 - Requirements on Feature Context Specifications > James, > > thanks for making the effort you made on this section. > and thanks for trying to expedite this process. > I like most of it except a few minor comments > based on the history of discussions. > > Please see below. > > BR, > > Madjid > > -----Original Message----- > From: James Kempf [mailto:kempf@docomolabs-usa.com] > Sent: Friday, July 19, 2002 8:26 PM > To: seamoby@ietf.org > Subject: [Seamoby] New Section 5.8 - Requirements on Feature Context > Specifications > > > I'd like to propose the following new section for the CT requirments listing > requirements on feature context specifications. Note that this section does not > place requirements on the feature context protocols themselves, but only on > their specifications. > > jak > > ------------------------------------------ > > 5.8 Feature Context Specifications > > The context transfer protocol provides a basic framework in which feature > contexts of varying types can be transfered. Recognizing that the particular > feature contexts may have very different needs with regard to update, > synchronization, and transport, this section contains requirements on the > feature context specifications. Note that these requirements do not constrain > the actual feature context protocols themselves, but only their specification. > > 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. > > 5.8.2 A feature context specification MUST define the byte layout of the > individual elements of the feature context, and how those map into the context > transfer protocol's container. The byte layout SHOULD obey standard IETF > conventions with regard to mapping of data into on the wire format. > > 5.8.3 A feature context specification MUST define the transport to be used. If > the feature context is transferred using an IETF transport layer protocol , then > the feature context specification MUST include the full details of how the > transport layer protocol is used. > > Madjid>> This would impose a little bit of vertical design and might again lead to > heated debates on whether to use UDP/SCTP.... Don't know if the following > addition within <> helps: > > Madjid>> > "If the feature context is transferred using an IETF transport layer protocol , > reliability or timing mechanisms>, then > the feature context specification MUST include the full details of how the > transport layer protocol is used. transport mechanisms for different feature context might lead to limited > possibility of multiplexing various feature contexts>" > > > > 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 through a non-IETF > protocol (such as IAPP [4]), then the feature context protocol specification > MUST define how the standard context transfer container is mapped into the > non-IETF transport. > > > > 5.8.4 A feature context specification MUST indicate whether update to context > information is allowed if changes in the source occur after the context is > transferred. If such changes are allowed, the feature context specification MUST > define the change protocol message format using the standard context transfer > container, and MUST include details of how the update is accomplished . > > Madjid>> See the addition above. The external trigger might be needed. > > 5.8.5 A feature context specification MUST indicate whether the context transfer > is tightly synchronized with external events, such as handover. The freature > context specification MUST indicate what event or events trigger transfer. > > 6.0 References > > [4] "Recommended Practice for Multi-vendor Interaccess Point Interoperability > via an Inter-access Point Protocol Across Distribution Systems Supporting IEEE > 802.11 Operation," IEEE Std. 802.11f/D3, January, 2002. > > > > _______________________________________________ > 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 From daemon@optimus.ietf.org Tue Jul 23 12:44:01 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22414 for ; Tue, 23 Jul 2002 12:44:01 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA27472 for seamoby-archive@odin.ietf.org; Tue, 23 Jul 2002 12:45:02 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA26868; Tue, 23 Jul 2002 12:37:44 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA26836 for ; Tue, 23 Jul 2002 12:37:42 -0400 (EDT) Received: from fridge.docomolabs-usa.com (fwuser@key1.docomolabs-usa.com [216.98.102.225]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22018 for ; Tue, 23 Jul 2002 12:36:40 -0400 (EDT) Message-ID: <011701c23267$07bea4b0$296015ac@T23KEMPF> From: "James Kempf" To: "Nakhjiri Madjid-MNAKHJI1" , References: <35DBB8B7AC89D4118E98009027B1009B08AD55E9@IL27EXM10.cig.mot.com> Subject: Re: [Seamoby] New Section 5.8 - Requirements on Feature Context Specifications Date: Tue, 23 Jul 2002 09:36:01 -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-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit Madjid, The additions look fine to me. I'll fold them into the proposed text. We need to wait until Gary is back from vacation to see what he has to say. jak ----- Original Message ----- From: "Nakhjiri Madjid-MNAKHJI1" To: "'James Kempf'" ; Sent: Monday, July 22, 2002 3:55 PM Subject: RE: [Seamoby] New Section 5.8 - Requirements on Feature Context Specifications > James, > > thanks for making the effort you made on this section. > and thanks for trying to expedite this process. > I like most of it except a few minor comments > based on the history of discussions. > > Please see below. > > BR, > > Madjid > > -----Original Message----- > From: James Kempf [mailto:kempf@docomolabs-usa.com] > Sent: Friday, July 19, 2002 8:26 PM > To: seamoby@ietf.org > Subject: [Seamoby] New Section 5.8 - Requirements on Feature Context > Specifications > > > I'd like to propose the following new section for the CT requirments listing > requirements on feature context specifications. Note that this section does not > place requirements on the feature context protocols themselves, but only on > their specifications. > > jak > > ------------------------------------------ > > 5.8 Feature Context Specifications > > The context transfer protocol provides a basic framework in which feature > contexts of varying types can be transfered. Recognizing that the particular > feature contexts may have very different needs with regard to update, > synchronization, and transport, this section contains requirements on the > feature context specifications. Note that these requirements do not constrain > the actual feature context protocols themselves, but only their specification. > > 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. > > 5.8.2 A feature context specification MUST define the byte layout of the > individual elements of the feature context, and how those map into the context > transfer protocol's container. The byte layout SHOULD obey standard IETF > conventions with regard to mapping of data into on the wire format. > > 5.8.3 A feature context specification MUST define the transport to be used. If > the feature context is transferred using an IETF transport layer protocol , then > the feature context specification MUST include the full details of how the > transport layer protocol is used. > > Madjid>> This would impose a little bit of vertical design and might again lead to > heated debates on whether to use UDP/SCTP.... Don't know if the following > addition within <> helps: > > Madjid>> > "If the feature context is transferred using an IETF transport layer protocol , > reliability or timing mechanisms>, then > the feature context specification MUST include the full details of how the > transport layer protocol is used. transport mechanisms for different feature context might lead to limited > possibility of multiplexing various feature contexts>" > > > > 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 through a non-IETF > protocol (such as IAPP [4]), then the feature context protocol specification > MUST define how the standard context transfer container is mapped into the > non-IETF transport. > > > > 5.8.4 A feature context specification MUST indicate whether update to context > information is allowed if changes in the source occur after the context is > transferred. If such changes are allowed, the feature context specification MUST > define the change protocol message format using the standard context transfer > container, and MUST include details of how the update is accomplished . > > Madjid>> See the addition above. The external trigger might be needed. > > 5.8.5 A feature context specification MUST indicate whether the context transfer > is tightly synchronized with external events, such as handover. The freature > context specification MUST indicate what event or events trigger transfer. > > 6.0 References > > [4] "Recommended Practice for Multi-vendor Interaccess Point Interoperability > via an Inter-access Point Protocol Across Distribution Systems Supporting IEEE > 802.11 Operation," IEEE Std. 802.11f/D3, January, 2002. > > > > _______________________________________________ > 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 From seamoby-admin@ietf.org Tue Jul 23 16:42:16 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03501 for ; Tue, 23 Jul 2002 16:42:16 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA16520; Tue, 23 Jul 2002 16:40:31 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA16491 for ; Tue, 23 Jul 2002 16:40:29 -0400 (EDT) Received: from mail4.svr.pol.co.uk (mail4.svr.pol.co.uk [195.92.193.211]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03422 for ; Tue, 23 Jul 2002 16:39:26 -0400 (EDT) Received: from [195.92.168.141] (helo=tmailb1.svr.pol.co.uk) by mail4.svr.pol.co.uk with esmtp (Exim 3.35 #1) id 17X6SI-0005qr-00 for seamoby@ietf.org; Tue, 23 Jul 2002 21:40:26 +0100 Received: from modem-3298.tiger.dialup.pol.co.uk ([62.136.220.226] helo=email.com) by tmailb1.svr.pol.co.uk with smtp (Exim 3.35 #1) id 17X6SH-0005RF-00 for seamoby@ietf.org; Tue, 23 Jul 2002 21:40:25 +0100 From: "Discount Calls UK" To: Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit Date: Tue, 23 Jul 2002 21:47:50 +0100 Reply-To: "Discount Calls UK" Message-Id: Content-Transfer-Encoding: 8bit Subject: [Seamoby] WE CAN HALVE YOUR COMPANY'S UK TELEPHONE BILLS!! Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 8bit With our UK National Calls costing as little as 1.8p per minute! we can save your company a fortune! That's less than half the "BT choices 1" rate, and about a quarter of the price of the BT standard rate! Our local & international rates offer massive discounts as well. With our simple registration process, you can begin saving money straight away- no set up charge & no long contract periods. You keep your BT account & continue to pay your rental -we simply divert your calls to our reliable, low cost system at the BT exchange. Try it for a month, if you are not completely satisfied, you can return to BT. Join the thousands of satisfied businesses both large & small that have dramatically reduced telephone bills!!---Can you think of a reason not to do it? Hand this important document to your financial director For more information reply to mailto:discountcalls@devilnet-uk.net?subject=information-please To be removed from the mail list reply to mailto:discountcalls@devilnet-uk.net?subject=remove-please We never intend to spam, or irritate with unsolicited emails, we always try to target companies that would benefit from our cost saving offers. This oportunity to save you money will be offered once only - you will not be emailed by us again. If you are an individual & not a company, then please accept our appoligies for us sending this email to you. _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Tue Jul 23 16:44:44 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03602 for ; Tue, 23 Jul 2002 16:44:44 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA16642; Tue, 23 Jul 2002 16:43:21 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA16600 for ; Tue, 23 Jul 2002 16:43:13 -0400 (EDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03498 for ; Tue, 23 Jul 2002 16:42:11 -0400 (EDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id NAA27816; Tue, 23 Jul 2002 13:42:41 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g6NKgeZ18679; Tue, 23 Jul 2002 13:42:40 -0700 X-mProtect: <200207232042> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.90, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpds9YK7f; Tue, 23 Jul 2002 13:42:38 PDT Message-ID: <3D3DBFBE.3BD723AB@iprg.nokia.com> Date: Tue, 23 Jul 2002 13:42:38 -0700 From: Rajeev Koodli Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: James Kempf CC: Nakhjiri Madjid-MNAKHJI1 , seamoby@ietf.org Subject: Re: [Seamoby] New Section 5.8 - Requirements on Feature Context Specifications References: <35DBB8B7AC89D4118E98009027B1009B08AD55E9@IL27EXM10.cig.mot.com> <011701c23267$07bea4b0$296015ac@T23KEMPF> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit Madjid, Jim, I have few comments. - it is not clear to me, from the proposed text, what requirements do the requirements on feature context specification impose on the CT protocol. Shouldn't we be concerned with requirements of the CT protocol in this particular document ? - regarding the transport text, if a particular feature indicates UDP/TCP or SCTP, isn't that sufficient ? Even if it can provide more information, how is that going to be useful if it is not supported by the underlying transport protocol ? - which scenarios demand context updates ? It seems to me that once you transfer state, you would like to use the state on the new node as soon as possible (right away) and stop using state on the old node as the reference. Since this does not impose any special requirements on the CT protocol itself, I do not have objections, but only wondering about the usage scenarios.. Thanks, -Rajeev James Kempf wrote: > Madjid, > > The additions look fine to me. I'll fold them into the proposed text. We need to > wait until Gary is back from vacation to see what he has to say. > > jak > > ----- Original Message ----- > From: "Nakhjiri Madjid-MNAKHJI1" > To: "'James Kempf'" ; > Sent: Monday, July 22, 2002 3:55 PM > Subject: RE: [Seamoby] New Section 5.8 - Requirements on Feature Context > Specifications > > > James, > > > > thanks for making the effort you made on this section. > > and thanks for trying to expedite this process. > > I like most of it except a few minor comments > > based on the history of discussions. > > > > Please see below. > > > > BR, > > > > Madjid > > > > -----Original Message----- > > From: James Kempf [mailto:kempf@docomolabs-usa.com] > > Sent: Friday, July 19, 2002 8:26 PM > > To: seamoby@ietf.org > > Subject: [Seamoby] New Section 5.8 - Requirements on Feature Context > > Specifications > > > > > > I'd like to propose the following new section for the CT requirments listing > > requirements on feature context specifications. Note that this section does > not > > place requirements on the feature context protocols themselves, but only on > > their specifications. > > > > jak > > > > ------------------------------------------ > > > > 5.8 Feature Context Specifications > > > > The context transfer protocol provides a basic framework in which feature > > contexts of varying types can be transfered. Recognizing that the particular > > feature contexts may have very different needs with regard to update, > > synchronization, and transport, this section contains requirements on the > > feature context specifications. Note that these requirements do not constrain > > the actual feature context protocols themselves, but only their specification. > > > > 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. > > > > 5.8.2 A feature context specification MUST define the byte layout of the > > individual elements of the feature context, and how those map into the context > > transfer protocol's container. The byte layout SHOULD obey standard IETF > > conventions with regard to mapping of data into on the wire format. > > > > 5.8.3 A feature context specification MUST define the transport to be used. If > > the feature context is transferred using an IETF transport layer protocol , > then > > the feature context specification MUST include the full details of how the > > transport layer protocol is used. > > > > Madjid>> This would impose a little bit of vertical design and might again > lead to > > heated debates on whether to use UDP/SCTP.... Don't know if the following > > addition within <> helps: > > > > Madjid>> > > "If the feature context is transferred using an IETF transport layer protocol > , > > > reliability or timing mechanisms>, then > > the feature context specification MUST include the full details of how the > > transport layer protocol is used. > transport mechanisms for different feature context might lead to limited > > possibility of multiplexing various feature contexts>" > > > > > > > > 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 through a > non-IETF > > protocol (such as IAPP [4]), then the feature context protocol specification > > MUST define how the standard context transfer container is mapped into the > > non-IETF transport. > > > > > > > > 5.8.4 A feature context specification MUST indicate whether update to context > > information is allowed if changes in the source occur after the context is > > transferred. If such changes are allowed, the feature context specification > MUST > > define the change protocol message format using the standard context transfer > > container, and MUST include details of how the update is accomplished triggered>. > > > > Madjid>> See the addition above. The external trigger might be needed. > > > > 5.8.5 A feature context specification MUST indicate whether the context > transfer > > is tightly synchronized with external events, such as handover. The freature > > context specification MUST indicate what event or events trigger transfer. > > > > 6.0 References > > > > [4] "Recommended Practice for Multi-vendor Interaccess Point Interoperability > > via an Inter-access Point Protocol Across Distribution Systems Supporting IEEE > > 802.11 Operation," IEEE Std. 802.11f/D3, January, 2002. > > > > > > > > _______________________________________________ > > 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 From seamoby-admin@ietf.org Tue Jul 23 16:56:42 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04077 for ; Tue, 23 Jul 2002 16:56:42 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA17042; Tue, 23 Jul 2002 16:54:39 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA17011 for ; Tue, 23 Jul 2002 16:54:37 -0400 (EDT) Received: from ftpbox.mot.com (ftpbox.mot.com [129.188.136.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03960 for ; Tue, 23 Jul 2002 16:53:35 -0400 (EDT) Received: [from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id NAA02152 for ; Tue, 23 Jul 2002 13:54:35 -0700 (MST)] Received: [from il27exm07.cig.mot.com (IL27EXM07.cig.mot.com [136.182.15.116]) by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id NAA11306 for ; Tue, 23 Jul 2002 13:53:11 -0700 (MST)] Received: by IL27EXM07.cig.mot.com with Internet Mail Service (5.5.2654.52) id <3FLZ62DY>; Tue, 23 Jul 2002 15:54:34 -0500 Message-ID: <35DBB8B7AC89D4118E98009027B1009B08AD55FC@IL27EXM10.cig.mot.com> From: Nakhjiri Madjid-MNAKHJI1 To: "'Rajeev Koodli'" , James Kempf Cc: Nakhjiri Madjid-MNAKHJI1 , seamoby@ietf.org Subject: RE: [Seamoby] New Section 5.8 - Requirements on Feature Context Specifications Date: Tue, 23 Jul 2002 15:54:33 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.52) Content-Type: text/plain Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Rajeev, please see below, Regards, Madjid -----Original Message----- From: Rajeev Koodli [mailto:rajeev@iprg.nokia.com] Sent: Tuesday, July 23, 2002 3:43 PM To: James Kempf Cc: Nakhjiri Madjid-MNAKHJI1; seamoby@ietf.org Subject: Re: [Seamoby] New Section 5.8 - Requirements on Feature Context Specifications Madjid, Jim, I have few comments. - it is not clear to me, from the proposed text, what requirements do the requirements on feature context specification impose on the CT protocol. Shouldn't we be concerned with requirements of the CT protocol in this particular document ? Madjid>> Agreed, That is why I have been advocating for SHOULDs whenever there is a requirement that is not needed for all features, and striving to keep requirements as generic as possible. - regarding the transport text, if a particular feature indicates UDP/TCP or SCTP, isn't that sufficient ? Even if it can provide more information, how is that going to be useful if it is not supported by the underlying transport protocol ? Madjid>> First of all, not everybody and every feature need an advanced transport and I know we agree on this. However, say in 6 months we are debating an specific feature that does need reliability. This text is to protect us from sloppy design. If you remember Jeff Schiller saying: Don't come and say use IPSec if you want security, you need to work on the security details. Example of a case which even SCTP is not going to cut it (this is answer to your next question as well): say you are sending a very dynamic context (packet count or HC context) and you want reliability (and you got time to resend stuff...). You send the context, but due to do channel conditions don't get it through, next time, you have to send updates. This has to come from the feature unit and not from transport layer. If had just said use SCTP for reliability that would not be a robust design. - which scenarios demand context updates ? It seems to me that once you transfer state, you would like to use the state on the new node as soon as possible (right away) and stop using state on the old node as the reference. Since this does not impose any special requirements on the CT protocol itself, I do not have objections, but only wondering about the usage scenarios.. Thanks, -Rajeev James Kempf wrote: > Madjid, > > The additions look fine to me. I'll fold them into the proposed text. We need to > wait until Gary is back from vacation to see what he has to say. > > jak > > ----- Original Message ----- > From: "Nakhjiri Madjid-MNAKHJI1" > To: "'James Kempf'" ; > Sent: Monday, July 22, 2002 3:55 PM > Subject: RE: [Seamoby] New Section 5.8 - Requirements on Feature Context > Specifications > > > James, > > > > thanks for making the effort you made on this section. > > and thanks for trying to expedite this process. > > I like most of it except a few minor comments > > based on the history of discussions. > > > > Please see below. > > > > BR, > > > > Madjid > > > > -----Original Message----- > > From: James Kempf [mailto:kempf@docomolabs-usa.com] > > Sent: Friday, July 19, 2002 8:26 PM > > To: seamoby@ietf.org > > Subject: [Seamoby] New Section 5.8 - Requirements on Feature Context > > Specifications > > > > > > I'd like to propose the following new section for the CT requirments listing > > requirements on feature context specifications. Note that this section does > not > > place requirements on the feature context protocols themselves, but only on > > their specifications. > > > > jak > > > > ------------------------------------------ > > > > 5.8 Feature Context Specifications > > > > The context transfer protocol provides a basic framework in which feature > > contexts of varying types can be transfered. Recognizing that the particular > > feature contexts may have very different needs with regard to update, > > synchronization, and transport, this section contains requirements on the > > feature context specifications. Note that these requirements do not constrain > > the actual feature context protocols themselves, but only their specification. > > > > 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. > > > > 5.8.2 A feature context specification MUST define the byte layout of the > > individual elements of the feature context, and how those map into the context > > transfer protocol's container. The byte layout SHOULD obey standard IETF > > conventions with regard to mapping of data into on the wire format. > > > > 5.8.3 A feature context specification MUST define the transport to be used. If > > the feature context is transferred using an IETF transport layer protocol , > then > > the feature context specification MUST include the full details of how the > > transport layer protocol is used. > > > > Madjid>> This would impose a little bit of vertical design and might again > lead to > > heated debates on whether to use UDP/SCTP.... Don't know if the following > > addition within <> helps: > > > > Madjid>> > > "If the feature context is transferred using an IETF transport layer protocol > , > > > reliability or timing mechanisms>, then > > the feature context specification MUST include the full details of how the > > transport layer protocol is used. > transport mechanisms for different feature context might lead to limited > > possibility of multiplexing various feature contexts>" > > > > > > > > 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 through a > non-IETF > > protocol (such as IAPP [4]), then the feature context protocol specification > > MUST define how the standard context transfer container is mapped into the > > non-IETF transport. > > > > > > > > 5.8.4 A feature context specification MUST indicate whether update to context > > information is allowed if changes in the source occur after the context is > > transferred. If such changes are allowed, the feature context specification > MUST > > define the change protocol message format using the standard context transfer > > container, and MUST include details of how the update is accomplished triggered>. > > > > Madjid>> See the addition above. The external trigger might be needed. > > > > 5.8.5 A feature context specification MUST indicate whether the context > transfer > > is tightly synchronized with external events, such as handover. The freature > > context specification MUST indicate what event or events trigger transfer. > > > > 6.0 References > > > > [4] "Recommended Practice for Multi-vendor Interaccess Point Interoperability > > via an Inter-access Point Protocol Across Distribution Systems Supporting IEEE > > 802.11 Operation," IEEE Std. 802.11f/D3, January, 2002. > > > > > > > > _______________________________________________ > > 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 From daemon@ns.ietf.org Tue Jul 23 16:56:46 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04090 for ; Tue, 23 Jul 2002 16:56:46 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA17277 for seamoby-archive@odin.ietf.org; Tue, 23 Jul 2002 16:57:44 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA17042; Tue, 23 Jul 2002 16:54:39 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA17011 for ; Tue, 23 Jul 2002 16:54:37 -0400 (EDT) Received: from ftpbox.mot.com (ftpbox.mot.com [129.188.136.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03960 for ; Tue, 23 Jul 2002 16:53:35 -0400 (EDT) Received: [from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id NAA02152 for ; Tue, 23 Jul 2002 13:54:35 -0700 (MST)] Received: [from il27exm07.cig.mot.com (IL27EXM07.cig.mot.com [136.182.15.116]) by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id NAA11306 for ; Tue, 23 Jul 2002 13:53:11 -0700 (MST)] Received: by IL27EXM07.cig.mot.com with Internet Mail Service (5.5.2654.52) id <3FLZ62DY>; Tue, 23 Jul 2002 15:54:34 -0500 Message-ID: <35DBB8B7AC89D4118E98009027B1009B08AD55FC@IL27EXM10.cig.mot.com> From: Nakhjiri Madjid-MNAKHJI1 To: "'Rajeev Koodli'" , James Kempf Cc: Nakhjiri Madjid-MNAKHJI1 , seamoby@ietf.org Subject: RE: [Seamoby] New Section 5.8 - Requirements on Feature Context Specifications Date: Tue, 23 Jul 2002 15:54:33 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.52) Content-Type: text/plain Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Rajeev, please see below, Regards, Madjid -----Original Message----- From: Rajeev Koodli [mailto:rajeev@iprg.nokia.com] Sent: Tuesday, July 23, 2002 3:43 PM To: James Kempf Cc: Nakhjiri Madjid-MNAKHJI1; seamoby@ietf.org Subject: Re: [Seamoby] New Section 5.8 - Requirements on Feature Context Specifications Madjid, Jim, I have few comments. - it is not clear to me, from the proposed text, what requirements do the requirements on feature context specification impose on the CT protocol. Shouldn't we be concerned with requirements of the CT protocol in this particular document ? Madjid>> Agreed, That is why I have been advocating for SHOULDs whenever there is a requirement that is not needed for all features, and striving to keep requirements as generic as possible. - regarding the transport text, if a particular feature indicates UDP/TCP or SCTP, isn't that sufficient ? Even if it can provide more information, how is that going to be useful if it is not supported by the underlying transport protocol ? Madjid>> First of all, not everybody and every feature need an advanced transport and I know we agree on this. However, say in 6 months we are debating an specific feature that does need reliability. This text is to protect us from sloppy design. If you remember Jeff Schiller saying: Don't come and say use IPSec if you want security, you need to work on the security details. Example of a case which even SCTP is not going to cut it (this is answer to your next question as well): say you are sending a very dynamic context (packet count or HC context) and you want reliability (and you got time to resend stuff...). You send the context, but due to do channel conditions don't get it through, next time, you have to send updates. This has to come from the feature unit and not from transport layer. If had just said use SCTP for reliability that would not be a robust design. - which scenarios demand context updates ? It seems to me that once you transfer state, you would like to use the state on the new node as soon as possible (right away) and stop using state on the old node as the reference. Since this does not impose any special requirements on the CT protocol itself, I do not have objections, but only wondering about the usage scenarios.. Thanks, -Rajeev James Kempf wrote: > Madjid, > > The additions look fine to me. I'll fold them into the proposed text. We need to > wait until Gary is back from vacation to see what he has to say. > > jak > > ----- Original Message ----- > From: "Nakhjiri Madjid-MNAKHJI1" > To: "'James Kempf'" ; > Sent: Monday, July 22, 2002 3:55 PM > Subject: RE: [Seamoby] New Section 5.8 - Requirements on Feature Context > Specifications > > > James, > > > > thanks for making the effort you made on this section. > > and thanks for trying to expedite this process. > > I like most of it except a few minor comments > > based on the history of discussions. > > > > Please see below. > > > > BR, > > > > Madjid > > > > -----Original Message----- > > From: James Kempf [mailto:kempf@docomolabs-usa.com] > > Sent: Friday, July 19, 2002 8:26 PM > > To: seamoby@ietf.org > > Subject: [Seamoby] New Section 5.8 - Requirements on Feature Context > > Specifications > > > > > > I'd like to propose the following new section for the CT requirments listing > > requirements on feature context specifications. Note that this section does > not > > place requirements on the feature context protocols themselves, but only on > > their specifications. > > > > jak > > > > ------------------------------------------ > > > > 5.8 Feature Context Specifications > > > > The context transfer protocol provides a basic framework in which feature > > contexts of varying types can be transfered. Recognizing that the particular > > feature contexts may have very different needs with regard to update, > > synchronization, and transport, this section contains requirements on the > > feature context specifications. Note that these requirements do not constrain > > the actual feature context protocols themselves, but only their specification. > > > > 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. > > > > 5.8.2 A feature context specification MUST define the byte layout of the > > individual elements of the feature context, and how those map into the context > > transfer protocol's container. The byte layout SHOULD obey standard IETF > > conventions with regard to mapping of data into on the wire format. > > > > 5.8.3 A feature context specification MUST define the transport to be used. If > > the feature context is transferred using an IETF transport layer protocol , > then > > the feature context specification MUST include the full details of how the > > transport layer protocol is used. > > > > Madjid>> This would impose a little bit of vertical design and might again > lead to > > heated debates on whether to use UDP/SCTP.... Don't know if the following > > addition within <> helps: > > > > Madjid>> > > "If the feature context is transferred using an IETF transport layer protocol > , > > > reliability or timing mechanisms>, then > > the feature context specification MUST include the full details of how the > > transport layer protocol is used. > transport mechanisms for different feature context might lead to limited > > possibility of multiplexing various feature contexts>" > > > > > > > > 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 through a > non-IETF > > protocol (such as IAPP [4]), then the feature context protocol specification > > MUST define how the standard context transfer container is mapped into the > > non-IETF transport. > > > > > > > > 5.8.4 A feature context specification MUST indicate whether update to context > > information is allowed if changes in the source occur after the context is > > transferred. If such changes are allowed, the feature context specification > MUST > > define the change protocol message format using the standard context transfer > > container, and MUST include details of how the update is accomplished triggered>. > > > > Madjid>> See the addition above. The external trigger might be needed. > > > > 5.8.5 A feature context specification MUST indicate whether the context > transfer > > is tightly synchronized with external events, such as handover. The freature > > context specification MUST indicate what event or events trigger transfer. > > > > 6.0 References > > > > [4] "Recommended Practice for Multi-vendor Interaccess Point Interoperability > > via an Inter-access Point Protocol Across Distribution Systems Supporting IEEE > > 802.11 Operation," IEEE Std. 802.11f/D3, January, 2002. > > > > > > > > _______________________________________________ > > 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 From seamoby-admin@ietf.org Tue Jul 23 17:17:45 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04496 for ; Tue, 23 Jul 2002 17:17:45 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA19102; Tue, 23 Jul 2002 17:14:03 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA19071 for ; Tue, 23 Jul 2002 17:14:01 -0400 (EDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04422 for ; Tue, 23 Jul 2002 17:12:58 -0400 (EDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id OAA00174; Tue, 23 Jul 2002 14:13:26 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g6NLDQS32732; Tue, 23 Jul 2002 14:13:26 -0700 X-mProtect: <200207232113> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.90, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdS4f8Xf; Tue, 23 Jul 2002 14:13:23 PDT Message-ID: <3D3DC6F3.AFCEE27B@iprg.nokia.com> Date: Tue, 23 Jul 2002 14:13:24 -0700 From: Rajeev Koodli Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: James Kempf CC: Gary Kenward , seamoby@ietf.org, mankin@psg.com Subject: Re: [Seamoby] Section 5.2 in CT Requirements References: <9FBD322B7824D511B36900508BF93C9C01AA4C3C@zcard031.ca.nortel.com> <005601c22eae$bb314230$056015ac@T23KEMPF> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit I pretty much agree with 5.2.1 (not 5.1 I suppose) -Rajeev James Kempf wrote: > Gary, > > It isn't a question of debate. We've been talking about these requirements for a > year and a half, it is time to complete them. > We need to nail down this section. > > Do you have any specific technical comments on the requirement? > > jak > > ----- Original Message ----- > From: "Gary Kenward" > To: "'James Kempf'" ; > Cc: > Sent: Thursday, July 18, 2002 8:16 AM > Subject: RE: [Seamoby] Section 5.2 in CT Requirements > > > James: > > > > There was a long and arduous debate over transport reliability. > > The wording you are objecting to was, I believe, Allison's suggestion. > > At the very lease, it was inserted with her approval in order to move > > the requirements forward. > > > > Of course, you can open the debate again, but I don't expect it to > > be resolved any better then it was the last time through. The problem > > is that there seems to be some very different ideas in the wg as to > > what the CT protocol looks like, with contradicting assumptions as > > to what is needed from a transport layer. > > > > Gary > > > > > -----Original Message----- > > > From: James Kempf [mailto:kempf@docomolabs-usa.com] > > > Sent: July 18, 2002 07:14 > > > To: seamoby@ietf.org > > > Cc: mankin@psg.com > > > Subject: [Seamoby] Section 5.2 in CT Requirements > > > > > > > > > Folks, > > > > > > So recently I had another look at the CT Requirements > > > document and I was > > > suprised to find Section 5.2. It says this: > > > > > > 5.2 Transport Reliability > > > > > > This section is intentionally left blank as the > > > working group is > > > waiting for a questionnaire from the transport > > > directorate. The result > > > of the questionnaire will create requirements that > > > will be added in this > > > section in a later revision of this specification. > > > > > > It is completely unacceptable that we sent this document to > > > the IESG with this > > > section in it. When a document passes through last call, it > > > should be complete. > > > As WG chairs, Pat and I naturally must accept responsibility > > > for this, but this > > > should really have been caught in WG Last Call. > > > > > > I would like suggest replacing Section 5.2 with the following: > > > > > > 5.2 Transport Requirements > > > > > > This section contains requirements on the context > > > transfer transport. > > > > > > 5.1 Independence of Underlying Transport > > > > > > The context transfer solution MUST be independent of > > > the underlying > > > transport. It SHOULD be possible to transfer > > > context directly on top of reliable transports, such > > > as TCP or SCTP, > > > unreliable transports, such as UDP, or as an > > > option or extention on another protocol, such as > > > handover signaling. > > > > > > Comments? > > > > > > > > > jak > > > u > > > > > > > > > > > > _______________________________________________ > > > 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 From daemon@ns.ietf.org Tue Jul 23 17:17:45 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04502 for ; Tue, 23 Jul 2002 17:17:45 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA19296 for seamoby-archive@odin.ietf.org; Tue, 23 Jul 2002 17:18:47 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA19102; Tue, 23 Jul 2002 17:14:03 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA19071 for ; Tue, 23 Jul 2002 17:14:01 -0400 (EDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04422 for ; Tue, 23 Jul 2002 17:12:58 -0400 (EDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id OAA00174; Tue, 23 Jul 2002 14:13:26 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g6NLDQS32732; Tue, 23 Jul 2002 14:13:26 -0700 X-mProtect: <200207232113> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.90, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdS4f8Xf; Tue, 23 Jul 2002 14:13:23 PDT Message-ID: <3D3DC6F3.AFCEE27B@iprg.nokia.com> Date: Tue, 23 Jul 2002 14:13:24 -0700 From: Rajeev Koodli Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: James Kempf CC: Gary Kenward , seamoby@ietf.org, mankin@psg.com Subject: Re: [Seamoby] Section 5.2 in CT Requirements References: <9FBD322B7824D511B36900508BF93C9C01AA4C3C@zcard031.ca.nortel.com> <005601c22eae$bb314230$056015ac@T23KEMPF> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit I pretty much agree with 5.2.1 (not 5.1 I suppose) -Rajeev James Kempf wrote: > Gary, > > It isn't a question of debate. We've been talking about these requirements for a > year and a half, it is time to complete them. > We need to nail down this section. > > Do you have any specific technical comments on the requirement? > > jak > > ----- Original Message ----- > From: "Gary Kenward" > To: "'James Kempf'" ; > Cc: > Sent: Thursday, July 18, 2002 8:16 AM > Subject: RE: [Seamoby] Section 5.2 in CT Requirements > > > James: > > > > There was a long and arduous debate over transport reliability. > > The wording you are objecting to was, I believe, Allison's suggestion. > > At the very lease, it was inserted with her approval in order to move > > the requirements forward. > > > > Of course, you can open the debate again, but I don't expect it to > > be resolved any better then it was the last time through. The problem > > is that there seems to be some very different ideas in the wg as to > > what the CT protocol looks like, with contradicting assumptions as > > to what is needed from a transport layer. > > > > Gary > > > > > -----Original Message----- > > > From: James Kempf [mailto:kempf@docomolabs-usa.com] > > > Sent: July 18, 2002 07:14 > > > To: seamoby@ietf.org > > > Cc: mankin@psg.com > > > Subject: [Seamoby] Section 5.2 in CT Requirements > > > > > > > > > Folks, > > > > > > So recently I had another look at the CT Requirements > > > document and I was > > > suprised to find Section 5.2. It says this: > > > > > > 5.2 Transport Reliability > > > > > > This section is intentionally left blank as the > > > working group is > > > waiting for a questionnaire from the transport > > > directorate. The result > > > of the questionnaire will create requirements that > > > will be added in this > > > section in a later revision of this specification. > > > > > > It is completely unacceptable that we sent this document to > > > the IESG with this > > > section in it. When a document passes through last call, it > > > should be complete. > > > As WG chairs, Pat and I naturally must accept responsibility > > > for this, but this > > > should really have been caught in WG Last Call. > > > > > > I would like suggest replacing Section 5.2 with the following: > > > > > > 5.2 Transport Requirements > > > > > > This section contains requirements on the context > > > transfer transport. > > > > > > 5.1 Independence of Underlying Transport > > > > > > The context transfer solution MUST be independent of > > > the underlying > > > transport. It SHOULD be possible to transfer > > > context directly on top of reliable transports, such > > > as TCP or SCTP, > > > unreliable transports, such as UDP, or as an > > > option or extention on another protocol, such as > > > handover signaling. > > > > > > Comments? > > > > > > > > > jak > > > u > > > > > > > > > > > > _______________________________________________ > > > 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 From seamoby-admin@ietf.org Tue Jul 23 17:26:08 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04696 for ; Tue, 23 Jul 2002 17:26:07 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA19578; Tue, 23 Jul 2002 17:25:03 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA19549 for ; Tue, 23 Jul 2002 17:25:01 -0400 (EDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04636 for ; Tue, 23 Jul 2002 17:23:57 -0400 (EDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id OAA00907; Tue, 23 Jul 2002 14:24:28 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g6NLOQp16191; Tue, 23 Jul 2002 14:24:26 -0700 X-mProtect: <200207232124> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.90, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd9K5MWL; Tue, 23 Jul 2002 14:24:23 PDT Message-ID: <3D3DC987.F5989DC2@iprg.nokia.com> Date: Tue, 23 Jul 2002 14:24:23 -0700 From: Rajeev Koodli Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Nakhjiri Madjid-MNAKHJI1 CC: James Kempf , seamoby@ietf.org Subject: Re: [Seamoby] New Section 5.8 - Requirements on Feature Context Specifications References: <35DBB8B7AC89D4118E98009027B1009B08AD55FC@IL27EXM10.cig.mot.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit Hello Madjid, Nakhjiri Madjid-MNAKHJI1 wrote: > - regarding the transport text, if a particular feature indicates UDP/TCP > or SCTP, isn't that sufficient ? Even if it can provide more information, > how > is that going to be useful if it is not supported by the underlying > transport > protocol ? > > Madjid>> First of all, not everybody and every feature need an advanced > transport and I know we agree on this. > However, say in 6 months we are debating an specific feature that does need > reliability. This text is to protect us from sloppy design. > If you remember Jeff Schiller saying: Don't come and say use > IPSec if you want security, you need to work on the security details. > > Example of a case which even SCTP is not going to cut it (this is > answer to your next question as well): say you are sending a very > dynamic context (packet count or HC context) and you want reliability > (and you got time to resend stuff...). > You send the context, but due to do channel conditions don't get it through, > next time, you have to send updates. This has to come from the feature unit > and not from transport layer. If had just said use SCTP for reliability that > would not be a robust design. > When you have to send an update, you do it whether or not SCTP failed to get it through in the first case, right ? What SCTP or a reliable transport protocol will offer you is the ability to send a message reliably. When you have a new message or an update, I agree the feature code has to supply it (and SCTP has to get to the destination reliably)! I hope you are not indicating that each feature has to design its own reliable transmission protocol. The way each feature uses SCTP or UDP is internal to the feature, and is not a function of the CT protocol itself. The CT protocol should define a set of messages that can be carried over different transport protocols. Regards, -Rajeev _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@ns.ietf.org Tue Jul 23 17:26:08 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04703 for ; Tue, 23 Jul 2002 17:26:08 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA19656 for seamoby-archive@odin.ietf.org; Tue, 23 Jul 2002 17:27:10 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA19578; Tue, 23 Jul 2002 17:25:03 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA19549 for ; Tue, 23 Jul 2002 17:25:01 -0400 (EDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04636 for ; Tue, 23 Jul 2002 17:23:57 -0400 (EDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id OAA00907; Tue, 23 Jul 2002 14:24:28 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g6NLOQp16191; Tue, 23 Jul 2002 14:24:26 -0700 X-mProtect: <200207232124> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.90, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd9K5MWL; Tue, 23 Jul 2002 14:24:23 PDT Message-ID: <3D3DC987.F5989DC2@iprg.nokia.com> Date: Tue, 23 Jul 2002 14:24:23 -0700 From: Rajeev Koodli Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Nakhjiri Madjid-MNAKHJI1 CC: James Kempf , seamoby@ietf.org Subject: Re: [Seamoby] New Section 5.8 - Requirements on Feature Context Specifications References: <35DBB8B7AC89D4118E98009027B1009B08AD55FC@IL27EXM10.cig.mot.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit Hello Madjid, Nakhjiri Madjid-MNAKHJI1 wrote: > - regarding the transport text, if a particular feature indicates UDP/TCP > or SCTP, isn't that sufficient ? Even if it can provide more information, > how > is that going to be useful if it is not supported by the underlying > transport > protocol ? > > Madjid>> First of all, not everybody and every feature need an advanced > transport and I know we agree on this. > However, say in 6 months we are debating an specific feature that does need > reliability. This text is to protect us from sloppy design. > If you remember Jeff Schiller saying: Don't come and say use > IPSec if you want security, you need to work on the security details. > > Example of a case which even SCTP is not going to cut it (this is > answer to your next question as well): say you are sending a very > dynamic context (packet count or HC context) and you want reliability > (and you got time to resend stuff...). > You send the context, but due to do channel conditions don't get it through, > next time, you have to send updates. This has to come from the feature unit > and not from transport layer. If had just said use SCTP for reliability that > would not be a robust design. > When you have to send an update, you do it whether or not SCTP failed to get it through in the first case, right ? What SCTP or a reliable transport protocol will offer you is the ability to send a message reliably. When you have a new message or an update, I agree the feature code has to supply it (and SCTP has to get to the destination reliably)! I hope you are not indicating that each feature has to design its own reliable transmission protocol. The way each feature uses SCTP or UDP is internal to the feature, and is not a function of the CT protocol itself. The CT protocol should define a set of messages that can be carried over different transport protocols. Regards, -Rajeev _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@ns.ietf.org Tue Jul 23 17:39:36 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03507 for ; Tue, 23 Jul 2002 16:42:16 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA16603 for seamoby-archive@odin.ietf.org; Tue, 23 Jul 2002 16:43:18 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA16520; Tue, 23 Jul 2002 16:40:31 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA16491 for ; Tue, 23 Jul 2002 16:40:29 -0400 (EDT) Received: from mail4.svr.pol.co.uk (mail4.svr.pol.co.uk [195.92.193.211]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03422 for ; Tue, 23 Jul 2002 16:39:26 -0400 (EDT) Received: from [195.92.168.141] (helo=tmailb1.svr.pol.co.uk) by mail4.svr.pol.co.uk with esmtp (Exim 3.35 #1) id 17X6SI-0005qr-00 for seamoby@ietf.org; Tue, 23 Jul 2002 21:40:26 +0100 Received: from modem-3298.tiger.dialup.pol.co.uk ([62.136.220.226] helo=email.com) by tmailb1.svr.pol.co.uk with smtp (Exim 3.35 #1) id 17X6SH-0005RF-00 for seamoby@ietf.org; Tue, 23 Jul 2002 21:40:25 +0100 From: "Discount Calls UK" To: Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit Date: Tue, 23 Jul 2002 21:47:50 +0100 Reply-To: "Discount Calls UK" Message-Id: Content-Transfer-Encoding: 8bit Subject: [Seamoby] WE CAN HALVE YOUR COMPANY'S UK TELEPHONE BILLS!! Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 8bit With our UK National Calls costing as little as 1.8p per minute! we can save your company a fortune! That's less than half the "BT choices 1" rate, and about a quarter of the price of the BT standard rate! Our local & international rates offer massive discounts as well. With our simple registration process, you can begin saving money straight away- no set up charge & no long contract periods. You keep your BT account & continue to pay your rental -we simply divert your calls to our reliable, low cost system at the BT exchange. Try it for a month, if you are not completely satisfied, you can return to BT. Join the thousands of satisfied businesses both large & small that have dramatically reduced telephone bills!!---Can you think of a reason not to do it? Hand this important document to your financial director For more information reply to mailto:discountcalls@devilnet-uk.net?subject=information-please To be removed from the mail list reply to mailto:discountcalls@devilnet-uk.net?subject=remove-please We never intend to spam, or irritate with unsolicited emails, we always try to target companies that would benefit from our cost saving offers. This oportunity to save you money will be offered once only - you will not be emailed by us again. If you are an individual & not a company, then please accept our appoligies for us sending this email to you. _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@ns.ietf.org Tue Jul 23 17:39:37 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03606 for ; Tue, 23 Jul 2002 16:44:44 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA16733 for seamoby-archive@odin.ietf.org; Tue, 23 Jul 2002 16:45:46 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA16642; Tue, 23 Jul 2002 16:43:21 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA16600 for ; Tue, 23 Jul 2002 16:43:13 -0400 (EDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03498 for ; Tue, 23 Jul 2002 16:42:11 -0400 (EDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id NAA27816; Tue, 23 Jul 2002 13:42:41 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g6NKgeZ18679; Tue, 23 Jul 2002 13:42:40 -0700 X-mProtect: <200207232042> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.90, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpds9YK7f; Tue, 23 Jul 2002 13:42:38 PDT Message-ID: <3D3DBFBE.3BD723AB@iprg.nokia.com> Date: Tue, 23 Jul 2002 13:42:38 -0700 From: Rajeev Koodli Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: James Kempf CC: Nakhjiri Madjid-MNAKHJI1 , seamoby@ietf.org Subject: Re: [Seamoby] New Section 5.8 - Requirements on Feature Context Specifications References: <35DBB8B7AC89D4118E98009027B1009B08AD55E9@IL27EXM10.cig.mot.com> <011701c23267$07bea4b0$296015ac@T23KEMPF> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit Madjid, Jim, I have few comments. - it is not clear to me, from the proposed text, what requirements do the requirements on feature context specification impose on the CT protocol. Shouldn't we be concerned with requirements of the CT protocol in this particular document ? - regarding the transport text, if a particular feature indicates UDP/TCP or SCTP, isn't that sufficient ? Even if it can provide more information, how is that going to be useful if it is not supported by the underlying transport protocol ? - which scenarios demand context updates ? It seems to me that once you transfer state, you would like to use the state on the new node as soon as possible (right away) and stop using state on the old node as the reference. Since this does not impose any special requirements on the CT protocol itself, I do not have objections, but only wondering about the usage scenarios.. Thanks, -Rajeev James Kempf wrote: > Madjid, > > The additions look fine to me. I'll fold them into the proposed text. We need to > wait until Gary is back from vacation to see what he has to say. > > jak > > ----- Original Message ----- > From: "Nakhjiri Madjid-MNAKHJI1" > To: "'James Kempf'" ; > Sent: Monday, July 22, 2002 3:55 PM > Subject: RE: [Seamoby] New Section 5.8 - Requirements on Feature Context > Specifications > > > James, > > > > thanks for making the effort you made on this section. > > and thanks for trying to expedite this process. > > I like most of it except a few minor comments > > based on the history of discussions. > > > > Please see below. > > > > BR, > > > > Madjid > > > > -----Original Message----- > > From: James Kempf [mailto:kempf@docomolabs-usa.com] > > Sent: Friday, July 19, 2002 8:26 PM > > To: seamoby@ietf.org > > Subject: [Seamoby] New Section 5.8 - Requirements on Feature Context > > Specifications > > > > > > I'd like to propose the following new section for the CT requirments listing > > requirements on feature context specifications. Note that this section does > not > > place requirements on the feature context protocols themselves, but only on > > their specifications. > > > > jak > > > > ------------------------------------------ > > > > 5.8 Feature Context Specifications > > > > The context transfer protocol provides a basic framework in which feature > > contexts of varying types can be transfered. Recognizing that the particular > > feature contexts may have very different needs with regard to update, > > synchronization, and transport, this section contains requirements on the > > feature context specifications. Note that these requirements do not constrain > > the actual feature context protocols themselves, but only their specification. > > > > 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. > > > > 5.8.2 A feature context specification MUST define the byte layout of the > > individual elements of the feature context, and how those map into the context > > transfer protocol's container. The byte layout SHOULD obey standard IETF > > conventions with regard to mapping of data into on the wire format. > > > > 5.8.3 A feature context specification MUST define the transport to be used. If > > the feature context is transferred using an IETF transport layer protocol , > then > > the feature context specification MUST include the full details of how the > > transport layer protocol is used. > > > > Madjid>> This would impose a little bit of vertical design and might again > lead to > > heated debates on whether to use UDP/SCTP.... Don't know if the following > > addition within <> helps: > > > > Madjid>> > > "If the feature context is transferred using an IETF transport layer protocol > , > > > reliability or timing mechanisms>, then > > the feature context specification MUST include the full details of how the > > transport layer protocol is used. > transport mechanisms for different feature context might lead to limited > > possibility of multiplexing various feature contexts>" > > > > > > > > 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 through a > non-IETF > > protocol (such as IAPP [4]), then the feature context protocol specification > > MUST define how the standard context transfer container is mapped into the > > non-IETF transport. > > > > > > > > 5.8.4 A feature context specification MUST indicate whether update to context > > information is allowed if changes in the source occur after the context is > > transferred. If such changes are allowed, the feature context specification > MUST > > define the change protocol message format using the standard context transfer > > container, and MUST include details of how the update is accomplished triggered>. > > > > Madjid>> See the addition above. The external trigger might be needed. > > > > 5.8.5 A feature context specification MUST indicate whether the context > transfer > > is tightly synchronized with external events, such as handover. The freature > > context specification MUST indicate what event or events trigger transfer. > > > > 6.0 References > > > > [4] "Recommended Practice for Multi-vendor Interaccess Point Interoperability > > via an Inter-access Point Protocol Across Distribution Systems Supporting IEEE > > 802.11 Operation," IEEE Std. 802.11f/D3, January, 2002. > > > > > > > > _______________________________________________ > > 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 From seamoby-admin@ietf.org Tue Jul 23 19:06:50 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06888 for ; Tue, 23 Jul 2002 19:06:50 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA24243; Tue, 23 Jul 2002 19:04:53 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA24175 for ; Tue, 23 Jul 2002 19:04:50 -0400 (EDT) Received: from fridge.docomolabs-usa.com (fwuser@key1.docomolabs-usa.com [216.98.102.225]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06856 for ; Tue, 23 Jul 2002 19:03:48 -0400 (EDT) Message-ID: <01ef01c2329d$1a4096d0$296015ac@T23KEMPF> From: "James Kempf" To: "Rajeev Koodli" Cc: "Nakhjiri Madjid-MNAKHJI1" , References: <35DBB8B7AC89D4118E98009027B1009B08AD55E9@IL27EXM10.cig.mot.com> <011701c23267$07bea4b0$296015ac@T23KEMPF> <3D3DBFBE.3BD723AB@iprg.nokia.com> Subject: Re: [Seamoby] New Section 5.8 - Requirements on Feature Context Specifications Date: Tue, 23 Jul 2002 16:03:03 -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-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit Rajeev, > - it is not clear to me, from the proposed text, what requirements do the > requirements on feature context specification impose on the CT protocol. > Shouldn't we be concerned with requirements of the CT protocol in this > particular document ? > The intent of the requirements on feature context specification is to clarify why certain aspects of the CT protocol requirements are unspecified or not required, to provide the IESG with a more crisp description of why the requirements are as they are. For example, if we decide either to specify that any transport can be used or leave it unspecified, adding the section requiring feature context specifications to nail down the transport explains why, rather than that the general CT protocol requirements are vague. Do you have a suggestion about how to better to do this? Perhaps not include the requirements on the feature contexts as requirements, but as some explanatory text in a separate paragraph? > - regarding the transport text, if a particular feature indicates UDP/TCP > or SCTP, isn't that sufficient ? Even if it can provide more information, how > is that going to be useful if it is not supported by the underlying transport > protocol ? > WhatI had in mind here was things like retransmits for UDP or exponential backoff, the kinds of details required by implementors who want to implement the protocol. Typically, these don't tend to be such a problem with TCP (also maybe SCTP thought I have never used it so I couldn't say for sure), but often there is more to specifying transport with UDP than just saying to use UDP. > - which scenarios demand context updates ? > It seems to me that once you transfer state, you would > like to use the state on the new node as soon as possible (right away) and stop > using state on the old node as the reference. > Since this does not impose any special requirements on the CT protocol > itself, I do not have objections, but only wondering about the usage scenarios.. > Gary has some scenarios in mind. For example, proactively transferring a user's SLA to a router well in advance of a handover, then having the SLA changed because the user's subscription ran out or they decided to downgrade their service. Update would not typically apply to cases where tight synchronization with a handover was required, such as for header compression context. jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Tue Jul 23 19:32:41 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07348 for ; Tue, 23 Jul 2002 19:32:41 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA24925; Tue, 23 Jul 2002 19:27:40 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA24883 for ; Tue, 23 Jul 2002 19:27:38 -0400 (EDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07261 for ; Tue, 23 Jul 2002 19:26:36 -0400 (EDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id QAA09153; Tue, 23 Jul 2002 16:27:06 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g6NNR5j29537; Tue, 23 Jul 2002 16:27:05 -0700 X-mProtect: <200207232327> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.90, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdFnvQwg; Tue, 23 Jul 2002 16:27:02 PDT Message-ID: <3D3DE647.733CC500@iprg.nokia.com> Date: Tue, 23 Jul 2002 16:27:03 -0700 From: Rajeev Koodli Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: James Kempf CC: Nakhjiri Madjid-MNAKHJI1 , seamoby@ietf.org Subject: Re: [Seamoby] New Section 5.8 - Requirements on Feature Context Specifications References: <35DBB8B7AC89D4118E98009027B1009B08AD55E9@IL27EXM10.cig.mot.com> <011701c23267$07bea4b0$296015ac@T23KEMPF> <3D3DBFBE.3BD723AB@iprg.nokia.com> <01ef01c2329d$1a4096d0$296015ac@T23KEMPF> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit James Kempf wrote: > Rajeev, > > > - it is not clear to me, from the proposed text, what requirements do the > > requirements on feature context specification impose on the CT protocol. > > Shouldn't we be concerned with requirements of the CT protocol in this > > particular document ? > > > > The intent of the requirements on feature context specification is to clarify > why certain aspects of the CT protocol requirements are unspecified or not > required, to provide the IESG with a more crisp description of why the > requirements are as they are. For example, if we decide either to specify that > any transport can be used or leave it unspecified, adding the section requiring > feature context specifications to nail down the transport explains why, rather > than that the general CT protocol requirements are vague. > > Do you have a suggestion about how to better to do this? Perhaps not include the > requirements on the feature contexts as requirements, but as some explanatory > text in a separate paragraph? Including a descriptive text makes sense and we should do that. > > > > - regarding the transport text, if a particular feature indicates UDP/TCP > > or SCTP, isn't that sufficient ? Even if it can provide more information, how > > is that going to be useful if it is not supported by the underlying transport > > protocol ? > > > > WhatI had in mind here was things like retransmits for UDP or exponential > backoff, the kinds of details required by implementors who want to implement the > protocol. Typically, these don't tend to be such a problem with TCP (also maybe > SCTP thought I have never used it so I couldn't say for sure), but often there > is more to specifying transport with UDP than just saying to use UDP. > If a feature needs UDP and expects multiple retransmissions (more than say 2), then it must use something like DCP. We should have normative text discouraging features to develop their own congestion control mechanisms. > > > - which scenarios demand context updates ? > > It seems to me that once you transfer state, you would > > like to use the state on the new node as soon as possible (right away) and > stop > > using state on the old node as the reference. > > Since this does not impose any special requirements on the CT protocol > > itself, I do not have objections, but only wondering about the usage > scenarios.. > > > > Gary has some scenarios in mind. For example, proactively transferring a user's > SLA to a router well in advance of a handover, then having the SLA changed > because the user's subscription ran out or they decided to downgrade their > service. Update would not typically apply to cases where tight synchronization > with a handover was required, such as for header compression context. > Like many other things, this is feature-dependent. I am begining to think we should put some text stating that each feature is responsible for defining its own behavior and the CT protocol itself is a carrier of message blobs. May be the paragrpah you mentioned above could state this as well.. -Rajeev > > jak > > _______________________________________________ > 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 From daemon@ns.ietf.org Tue Jul 23 19:54:36 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06893 for ; Tue, 23 Jul 2002 19:06:50 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id TAA24282 for seamoby-archive@odin.ietf.org; Tue, 23 Jul 2002 19:07:51 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA24243; Tue, 23 Jul 2002 19:04:53 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA24175 for ; Tue, 23 Jul 2002 19:04:50 -0400 (EDT) Received: from fridge.docomolabs-usa.com (fwuser@key1.docomolabs-usa.com [216.98.102.225]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06856 for ; Tue, 23 Jul 2002 19:03:48 -0400 (EDT) Message-ID: <01ef01c2329d$1a4096d0$296015ac@T23KEMPF> From: "James Kempf" To: "Rajeev Koodli" Cc: "Nakhjiri Madjid-MNAKHJI1" , References: <35DBB8B7AC89D4118E98009027B1009B08AD55E9@IL27EXM10.cig.mot.com> <011701c23267$07bea4b0$296015ac@T23KEMPF> <3D3DBFBE.3BD723AB@iprg.nokia.com> Subject: Re: [Seamoby] New Section 5.8 - Requirements on Feature Context Specifications Date: Tue, 23 Jul 2002 16:03:03 -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-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit Rajeev, > - it is not clear to me, from the proposed text, what requirements do the > requirements on feature context specification impose on the CT protocol. > Shouldn't we be concerned with requirements of the CT protocol in this > particular document ? > The intent of the requirements on feature context specification is to clarify why certain aspects of the CT protocol requirements are unspecified or not required, to provide the IESG with a more crisp description of why the requirements are as they are. For example, if we decide either to specify that any transport can be used or leave it unspecified, adding the section requiring feature context specifications to nail down the transport explains why, rather than that the general CT protocol requirements are vague. Do you have a suggestion about how to better to do this? Perhaps not include the requirements on the feature contexts as requirements, but as some explanatory text in a separate paragraph? > - regarding the transport text, if a particular feature indicates UDP/TCP > or SCTP, isn't that sufficient ? Even if it can provide more information, how > is that going to be useful if it is not supported by the underlying transport > protocol ? > WhatI had in mind here was things like retransmits for UDP or exponential backoff, the kinds of details required by implementors who want to implement the protocol. Typically, these don't tend to be such a problem with TCP (also maybe SCTP thought I have never used it so I couldn't say for sure), but often there is more to specifying transport with UDP than just saying to use UDP. > - which scenarios demand context updates ? > It seems to me that once you transfer state, you would > like to use the state on the new node as soon as possible (right away) and stop > using state on the old node as the reference. > Since this does not impose any special requirements on the CT protocol > itself, I do not have objections, but only wondering about the usage scenarios.. > Gary has some scenarios in mind. For example, proactively transferring a user's SLA to a router well in advance of a handover, then having the SLA changed because the user's subscription ran out or they decided to downgrade their service. Update would not typically apply to cases where tight synchronization with a handover was required, such as for header compression context. jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@ns.ietf.org Tue Jul 23 20:24:36 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07353 for ; Tue, 23 Jul 2002 19:32:42 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id TAA25507 for seamoby-archive@odin.ietf.org; Tue, 23 Jul 2002 19:33:43 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA24925; Tue, 23 Jul 2002 19:27:40 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA24883 for ; Tue, 23 Jul 2002 19:27:38 -0400 (EDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07261 for ; Tue, 23 Jul 2002 19:26:36 -0400 (EDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id QAA09153; Tue, 23 Jul 2002 16:27:06 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g6NNR5j29537; Tue, 23 Jul 2002 16:27:05 -0700 X-mProtect: <200207232327> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.90, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdFnvQwg; Tue, 23 Jul 2002 16:27:02 PDT Message-ID: <3D3DE647.733CC500@iprg.nokia.com> Date: Tue, 23 Jul 2002 16:27:03 -0700 From: Rajeev Koodli Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: James Kempf CC: Nakhjiri Madjid-MNAKHJI1 , seamoby@ietf.org Subject: Re: [Seamoby] New Section 5.8 - Requirements on Feature Context Specifications References: <35DBB8B7AC89D4118E98009027B1009B08AD55E9@IL27EXM10.cig.mot.com> <011701c23267$07bea4b0$296015ac@T23KEMPF> <3D3DBFBE.3BD723AB@iprg.nokia.com> <01ef01c2329d$1a4096d0$296015ac@T23KEMPF> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit James Kempf wrote: > Rajeev, > > > - it is not clear to me, from the proposed text, what requirements do the > > requirements on feature context specification impose on the CT protocol. > > Shouldn't we be concerned with requirements of the CT protocol in this > > particular document ? > > > > The intent of the requirements on feature context specification is to clarify > why certain aspects of the CT protocol requirements are unspecified or not > required, to provide the IESG with a more crisp description of why the > requirements are as they are. For example, if we decide either to specify that > any transport can be used or leave it unspecified, adding the section requiring > feature context specifications to nail down the transport explains why, rather > than that the general CT protocol requirements are vague. > > Do you have a suggestion about how to better to do this? Perhaps not include the > requirements on the feature contexts as requirements, but as some explanatory > text in a separate paragraph? Including a descriptive text makes sense and we should do that. > > > > - regarding the transport text, if a particular feature indicates UDP/TCP > > or SCTP, isn't that sufficient ? Even if it can provide more information, how > > is that going to be useful if it is not supported by the underlying transport > > protocol ? > > > > WhatI had in mind here was things like retransmits for UDP or exponential > backoff, the kinds of details required by implementors who want to implement the > protocol. Typically, these don't tend to be such a problem with TCP (also maybe > SCTP thought I have never used it so I couldn't say for sure), but often there > is more to specifying transport with UDP than just saying to use UDP. > If a feature needs UDP and expects multiple retransmissions (more than say 2), then it must use something like DCP. We should have normative text discouraging features to develop their own congestion control mechanisms. > > > - which scenarios demand context updates ? > > It seems to me that once you transfer state, you would > > like to use the state on the new node as soon as possible (right away) and > stop > > using state on the old node as the reference. > > Since this does not impose any special requirements on the CT protocol > > itself, I do not have objections, but only wondering about the usage > scenarios.. > > > > Gary has some scenarios in mind. For example, proactively transferring a user's > SLA to a router well in advance of a handover, then having the SLA changed > because the user's subscription ran out or they decided to downgrade their > service. Update would not typically apply to cases where tight synchronization > with a handover was required, such as for header compression context. > Like many other things, this is feature-dependent. I am begining to think we should put some text stating that each feature is responsible for defining its own behavior and the CT protocol itself is a carrier of message blobs. May be the paragrpah you mentioned above could state this as well.. -Rajeev > > jak > > _______________________________________________ > 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 From seamoby-admin@ietf.org Tue Jul 23 23:59:13 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA13509 for ; Tue, 23 Jul 2002 23:59:12 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA06607; Tue, 23 Jul 2002 23:54:59 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA06578 for ; Tue, 23 Jul 2002 23:54:57 -0400 (EDT) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA13431 for ; Tue, 23 Jul 2002 23:53:54 -0400 (EDT) From: john.loughney@nokia.com Received: from esvir02nok.ntc.nokia.com (esvir02nokt.ntc.nokia.com [172.21.143.34]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g6O3tRi29055 for ; Wed, 24 Jul 2002 06:55:28 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir02nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 24 Jul 2002 06:54:55 +0300 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Wed, 24 Jul 2002 06:54:54 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Wed, 24 Jul 2002 06:54:54 +0300 content-class: urn:content-classes:message Subject: RE: [Seamoby] Section 5.2 in CT Requirements MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Wed, 24 Jul 2002 06:54:53 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC657CF@esebe004.NOE.Nokia.com> X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Thread-Topic: [Seamoby] Section 5.2 in CT Requirements Thread-Index: AcIyXgbiSLv+bbxRRxeaYU58YtyGugAZ8LMg To: , X-OriginalArrivalTime: 24 Jul 2002 03:54:54.0468 (UTC) FILETIME=[DE9EA440:01C232C5] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id XAA06579 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 8bit Hi James, > > It makes sense, but this sounds much more like solution space > > than requirements. > > > > It is solution space, but it motivates the requirement that > the generic CT protocol not specify a particular transport. Sounds OK to me then, let's put this one to bed. John _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@ns.ietf.org Tue Jul 23 23:59:13 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA13522 for ; Tue, 23 Jul 2002 23:59:13 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id AAA06849 for seamoby-archive@odin.ietf.org; Wed, 24 Jul 2002 00:00:15 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA06607; Tue, 23 Jul 2002 23:54:59 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA06578 for ; Tue, 23 Jul 2002 23:54:57 -0400 (EDT) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA13431 for ; Tue, 23 Jul 2002 23:53:54 -0400 (EDT) From: john.loughney@nokia.com Received: from esvir02nok.ntc.nokia.com (esvir02nokt.ntc.nokia.com [172.21.143.34]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g6O3tRi29055 for ; Wed, 24 Jul 2002 06:55:28 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir02nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 24 Jul 2002 06:54:55 +0300 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Wed, 24 Jul 2002 06:54:54 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Wed, 24 Jul 2002 06:54:54 +0300 content-class: urn:content-classes:message Subject: RE: [Seamoby] Section 5.2 in CT Requirements MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Wed, 24 Jul 2002 06:54:53 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC657CF@esebe004.NOE.Nokia.com> X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Thread-Topic: [Seamoby] Section 5.2 in CT Requirements Thread-Index: AcIyXgbiSLv+bbxRRxeaYU58YtyGugAZ8LMg To: , X-OriginalArrivalTime: 24 Jul 2002 03:54:54.0468 (UTC) FILETIME=[DE9EA440:01C232C5] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id XAA06579 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 8bit Hi James, > > It makes sense, but this sounds much more like solution space > > than requirements. > > > > It is solution space, but it motivates the requirement that > the generic CT protocol not specify a particular transport. Sounds OK to me then, let's put this one to bed. John _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Jul 24 19:29:08 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05687 for ; Wed, 24 Jul 2002 19:29:07 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA03413; Wed, 24 Jul 2002 19:20:19 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA03388 for ; Wed, 24 Jul 2002 19:20:17 -0400 (EDT) Received: from ftpbox.mot.com (ftpbox.mot.com [129.188.136.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05453 for ; Wed, 24 Jul 2002 19:19:13 -0400 (EDT) Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id QAA23724 for ; Wed, 24 Jul 2002 16:20:18 -0700 (MST)] Received: [from il27exb01.cig.mot.com (il27exb01.cig.mot.com [136.182.15.100]) by mothost.mot.com (MOT-pobox 2.0) with ESMTP id QAA16773 for ; Wed, 24 Jul 2002 16:20:34 -0700 (MST)] Received: by il27exb01.cig.mot.com with Internet Mail Service (5.5.2654.52) id ; Wed, 24 Jul 2002 18:20:17 -0500 Message-ID: <35DBB8B7AC89D4118E98009027B1009B08AD560D@IL27EXM10.cig.mot.com> From: Nakhjiri Madjid-MNAKHJI1 To: "'Rajeev Koodli'" Cc: James Kempf , seamoby@ietf.org Subject: RE: [Seamoby] New Section 5.8 - Requirements on Feature Context Specifications Date: Wed, 24 Jul 2002 18:20:15 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.52) Content-Type: text/plain Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Rajeev, sorry for the delay. see below. -----Original Message----- From: Rajeev Koodli [mailto:rajeev@iprg.nokia.com] Sent: Tuesday, July 23, 2002 4:24 PM To: Nakhjiri Madjid-MNAKHJI1 Cc: James Kempf; seamoby@ietf.org Subject: Re: [Seamoby] New Section 5.8 - Requirements on Feature Context Specifications Hello Madjid, Nakhjiri Madjid-MNAKHJI1 wrote: > - regarding the transport text, if a particular feature indicates UDP/TCP > or SCTP, isn't that sufficient ? Even if it can provide more information, > how > is that going to be useful if it is not supported by the underlying > transport > protocol ? > > Madjid>> First of all, not everybody and every feature need an advanced > transport and I know we agree on this. > However, say in 6 months we are debating an specific feature that does need > reliability. This text is to protect us from sloppy design. > If you remember Jeff Schiller saying: Don't come and say use > IPSec if you want security, you need to work on the security details. > > Example of a case which even SCTP is not going to cut it (this is > answer to your next question as well): say you are sending a very > dynamic context (packet count or HC context) and you want reliability > (and you got time to resend stuff...). > You send the context, but due to do channel conditions don't get it through, > next time, you have to send updates. This has to come from the feature unit > and not from transport layer. If had just said use SCTP for reliability that > would not be a robust design. > When you have to send an update, you do it whether or not SCTP failed to get it through in the first case, right ? What SCTP or a reliable transport protocol will offer you is the ability to send a message reliably. When you have a new message or an update, I agree the feature code has to supply it (and SCTP has to get to the destination reliably)! Madjid>> True, furthermore, if you use a reliable protocol like SCTP, you need to take extra care with CT, so the receiver doesn't mix up updates from app. layer, with retx from transport. I hope you are not indicating that each feature has to design its own reliable transmission protocol. The way each feature uses SCTP or UDP is internal to the feature, and is not a function of the CT protocol itself. The CT protocol should define a set of messages that can be carried over different transport protocols. Madjid>> No, No, however, If we add a set of minimal support (like what I mentioned above) to the generic protocol, then provide the option for the feature to use it or not we are covered. If we completely ignore reliability completely, we will write off CT as a useful protocol, I think! BR, Madjid Regards, -Rajeev _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Wed Jul 24 19:29:09 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05700 for ; Wed, 24 Jul 2002 19:29:09 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id TAA03782 for seamoby-archive@odin.ietf.org; Wed, 24 Jul 2002 19:30:13 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA03413; Wed, 24 Jul 2002 19:20:19 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA03388 for ; Wed, 24 Jul 2002 19:20:17 -0400 (EDT) Received: from ftpbox.mot.com (ftpbox.mot.com [129.188.136.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05453 for ; Wed, 24 Jul 2002 19:19:13 -0400 (EDT) Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id QAA23724 for ; Wed, 24 Jul 2002 16:20:18 -0700 (MST)] Received: [from il27exb01.cig.mot.com (il27exb01.cig.mot.com [136.182.15.100]) by mothost.mot.com (MOT-pobox 2.0) with ESMTP id QAA16773 for ; Wed, 24 Jul 2002 16:20:34 -0700 (MST)] Received: by il27exb01.cig.mot.com with Internet Mail Service (5.5.2654.52) id ; Wed, 24 Jul 2002 18:20:17 -0500 Message-ID: <35DBB8B7AC89D4118E98009027B1009B08AD560D@IL27EXM10.cig.mot.com> From: Nakhjiri Madjid-MNAKHJI1 To: "'Rajeev Koodli'" Cc: James Kempf , seamoby@ietf.org Subject: RE: [Seamoby] New Section 5.8 - Requirements on Feature Context Specifications Date: Wed, 24 Jul 2002 18:20:15 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.52) Content-Type: text/plain Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Rajeev, sorry for the delay. see below. -----Original Message----- From: Rajeev Koodli [mailto:rajeev@iprg.nokia.com] Sent: Tuesday, July 23, 2002 4:24 PM To: Nakhjiri Madjid-MNAKHJI1 Cc: James Kempf; seamoby@ietf.org Subject: Re: [Seamoby] New Section 5.8 - Requirements on Feature Context Specifications Hello Madjid, Nakhjiri Madjid-MNAKHJI1 wrote: > - regarding the transport text, if a particular feature indicates UDP/TCP > or SCTP, isn't that sufficient ? Even if it can provide more information, > how > is that going to be useful if it is not supported by the underlying > transport > protocol ? > > Madjid>> First of all, not everybody and every feature need an advanced > transport and I know we agree on this. > However, say in 6 months we are debating an specific feature that does need > reliability. This text is to protect us from sloppy design. > If you remember Jeff Schiller saying: Don't come and say use > IPSec if you want security, you need to work on the security details. > > Example of a case which even SCTP is not going to cut it (this is > answer to your next question as well): say you are sending a very > dynamic context (packet count or HC context) and you want reliability > (and you got time to resend stuff...). > You send the context, but due to do channel conditions don't get it through, > next time, you have to send updates. This has to come from the feature unit > and not from transport layer. If had just said use SCTP for reliability that > would not be a robust design. > When you have to send an update, you do it whether or not SCTP failed to get it through in the first case, right ? What SCTP or a reliable transport protocol will offer you is the ability to send a message reliably. When you have a new message or an update, I agree the feature code has to supply it (and SCTP has to get to the destination reliably)! Madjid>> True, furthermore, if you use a reliable protocol like SCTP, you need to take extra care with CT, so the receiver doesn't mix up updates from app. layer, with retx from transport. I hope you are not indicating that each feature has to design its own reliable transmission protocol. The way each feature uses SCTP or UDP is internal to the feature, and is not a function of the CT protocol itself. The CT protocol should define a set of messages that can be carried over different transport protocols. Madjid>> No, No, however, If we add a set of minimal support (like what I mentioned above) to the generic protocol, then provide the option for the feature to use it or not we are covered. If we completely ignore reliability completely, we will write off CT as a useful protocol, I think! BR, Madjid Regards, -Rajeev _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Tue Jul 30 05:07:46 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09379 for ; Tue, 30 Jul 2002 05:07:46 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA06959; Tue, 30 Jul 2002 03:53:21 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA06543 for ; Tue, 30 Jul 2002 03:53:01 -0400 (EDT) Received: from ns3.super-hosts.com ([216.12.213.215]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA07464; Tue, 30 Jul 2002 03:51:52 -0400 (EDT) Received: (from apache@localhost) by ns3.super-hosts.com (8.11.6/8.11.6) id g6U81tu19553; Tue, 30 Jul 2002 04:01:55 -0400 Date: Tue, 30 Jul 2002 04:01:55 -0400 Message-Id: <200207300801.g6U81tu19553@ns3.super-hosts.com> To: seamoby@ietf.org, seamoby-request@ietf.org, sar@epilogue.com, sigtran@ietf.org, sigtran-request@ietf.org, brian.rosen@marconi.com, dean.willis@softarmor.com, rohan@cisco.com, sipping@ietf.org, sipping-request@ietf.org From: mike@winners.com () Subject: [Seamoby] GET OVER $500 CASH in 2 minutes!!! Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Below is the result of your feedback form. It was submitted by (mike@winners.com) on Tuesday, July 30, 19102 at 04:01:55 --------------------------------------------------------------------------- message: GET OVER $500 DOLLARS CASH!!! Just Click Here!!!! - http://www.reelten.com/redirect/500/index.htm - If you have received this Email in error please contact: lon_chaney_jr@hotmail.com with subject: remove. --------------------------------------------------------------------------- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Tue Jul 30 05:07:47 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09387 for ; Tue, 30 Jul 2002 05:07:47 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id FAA12823 for seamoby-archive@odin.ietf.org; Tue, 30 Jul 2002 05:08:55 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA06959; Tue, 30 Jul 2002 03:53:21 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA06543 for ; Tue, 30 Jul 2002 03:53:01 -0400 (EDT) Received: from ns3.super-hosts.com ([216.12.213.215]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA07464; Tue, 30 Jul 2002 03:51:52 -0400 (EDT) Received: (from apache@localhost) by ns3.super-hosts.com (8.11.6/8.11.6) id g6U81tu19553; Tue, 30 Jul 2002 04:01:55 -0400 Date: Tue, 30 Jul 2002 04:01:55 -0400 Message-Id: <200207300801.g6U81tu19553@ns3.super-hosts.com> To: seamoby@ietf.org, seamoby-request@ietf.org, sar@epilogue.com, sigtran@ietf.org, sigtran-request@ietf.org, brian.rosen@marconi.com, dean.willis@softarmor.com, rohan@cisco.com, sipping@ietf.org, sipping-request@ietf.org From: mike@winners.com () Subject: [Seamoby] GET OVER $500 CASH in 2 minutes!!! Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Below is the result of your feedback form. It was submitted by (mike@winners.com) on Tuesday, July 30, 19102 at 04:01:55 --------------------------------------------------------------------------- message: GET OVER $500 DOLLARS CASH!!! Just Click Here!!!! - http://www.reelten.com/redirect/500/index.htm - If you have received this Email in error please contact: lon_chaney_jr@hotmail.com with subject: remove. --------------------------------------------------------------------------- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Jul 31 16:20:21 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16610 for ; Wed, 31 Jul 2002 16:20:21 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA07531; Wed, 31 Jul 2002 16:16:17 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA07499 for ; Wed, 31 Jul 2002 16:16:15 -0400 (EDT) Received: from fridge.docomolabs-usa.com (fwuser@key1.docomolabs-usa.com [216.98.102.225]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16339 for ; Wed, 31 Jul 2002 16:15:05 -0400 (EDT) Message-ID: <010d01c238ce$e22acf30$296015ac@T23KEMPF> From: "James Kempf" To: "Nakhjiri Madjid-MNAKHJI1" , "'Rajeev Koodli'" Cc: References: <35DBB8B7AC89D4118E98009027B1009B08AD560D@IL27EXM10.cig.mot.com> Subject: Re: [Seamoby] New Section 5.8 - Requirements on Feature Context Specifications Date: Wed, 31 Jul 2002 13:14:32 -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-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit Madjid, Do you have some specific text you would like to propose regarding the transport? jak ----- Original Message ----- From: "Nakhjiri Madjid-MNAKHJI1" To: "'Rajeev Koodli'" Cc: "James Kempf" ; Sent: Wednesday, July 24, 2002 4:20 PM Subject: RE: [Seamoby] New Section 5.8 - Requirements on Feature Context Specifications > Rajeev, > > sorry for the delay. see below. > > -----Original Message----- > From: Rajeev Koodli [mailto:rajeev@iprg.nokia.com] > Sent: Tuesday, July 23, 2002 4:24 PM > To: Nakhjiri Madjid-MNAKHJI1 > Cc: James Kempf; seamoby@ietf.org > Subject: Re: [Seamoby] New Section 5.8 - Requirements on Feature Context > Specifications > > > > Hello Madjid, > > Nakhjiri Madjid-MNAKHJI1 wrote: > > > - regarding the transport text, if a particular feature indicates UDP/TCP > > or SCTP, isn't that sufficient ? Even if it can provide more information, > > how > > is that going to be useful if it is not supported by the underlying > > transport > > protocol ? > > > > Madjid>> First of all, not everybody and every feature need an advanced > > transport and I know we agree on this. > > However, say in 6 months we are debating an specific feature that does need > > reliability. This text is to protect us from sloppy design. > > If you remember Jeff Schiller saying: Don't come and say use > > IPSec if you want security, you need to work on the security details. > > > > Example of a case which even SCTP is not going to cut it (this is > > answer to your next question as well): say you are sending a very > > dynamic context (packet count or HC context) and you want reliability > > (and you got time to resend stuff...). > > You send the context, but due to do channel conditions don't get it through, > > next time, you have to send updates. This has to come from the feature unit > > and not from transport layer. If had just said use SCTP for reliability that > > would not be a robust design. > > > > When you have to send an update, you do it whether or not SCTP failed to > get it through in the first case, right ? What SCTP or a reliable transport > protocol will offer you is the ability to send a message reliably. When you > have a new message or an update, I agree the feature code has to supply it > (and SCTP has to get to the destination reliably)! > > Madjid>> True, furthermore, if you use a reliable protocol like > SCTP, you need to take extra care with CT, so the receiver doesn't mix up > updates from app. layer, with retx from transport. > > > I hope you are not indicating that each feature has to design its own reliable > transmission protocol. The way each feature uses SCTP or UDP is internal > to the feature, and is not a function of the CT protocol itself. The > CT protocol > should define a set of messages that can be carried over different transport > protocols. > > Madjid>> No, No, however, If we add a set of minimal support (like > what I mentioned above) to the generic protocol, then provide the option > for the feature to use it or not we are covered. > If we completely ignore reliability > completely, we will write off CT as a useful protocol, I think! > > BR, > > Madjid > > Regards, > > -Rajeev > > > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Wed Jul 31 16:20:22 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16616 for ; Wed, 31 Jul 2002 16:20:22 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA07858 for seamoby-archive@odin.ietf.org; Wed, 31 Jul 2002 16:21:31 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA07531; Wed, 31 Jul 2002 16:16:17 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA07499 for ; Wed, 31 Jul 2002 16:16:15 -0400 (EDT) Received: from fridge.docomolabs-usa.com (fwuser@key1.docomolabs-usa.com [216.98.102.225]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16339 for ; Wed, 31 Jul 2002 16:15:05 -0400 (EDT) Message-ID: <010d01c238ce$e22acf30$296015ac@T23KEMPF> From: "James Kempf" To: "Nakhjiri Madjid-MNAKHJI1" , "'Rajeev Koodli'" Cc: References: <35DBB8B7AC89D4118E98009027B1009B08AD560D@IL27EXM10.cig.mot.com> Subject: Re: [Seamoby] New Section 5.8 - Requirements on Feature Context Specifications Date: Wed, 31 Jul 2002 13:14:32 -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-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit Madjid, Do you have some specific text you would like to propose regarding the transport? jak ----- Original Message ----- From: "Nakhjiri Madjid-MNAKHJI1" To: "'Rajeev Koodli'" Cc: "James Kempf" ; Sent: Wednesday, July 24, 2002 4:20 PM Subject: RE: [Seamoby] New Section 5.8 - Requirements on Feature Context Specifications > Rajeev, > > sorry for the delay. see below. > > -----Original Message----- > From: Rajeev Koodli [mailto:rajeev@iprg.nokia.com] > Sent: Tuesday, July 23, 2002 4:24 PM > To: Nakhjiri Madjid-MNAKHJI1 > Cc: James Kempf; seamoby@ietf.org > Subject: Re: [Seamoby] New Section 5.8 - Requirements on Feature Context > Specifications > > > > Hello Madjid, > > Nakhjiri Madjid-MNAKHJI1 wrote: > > > - regarding the transport text, if a particular feature indicates UDP/TCP > > or SCTP, isn't that sufficient ? Even if it can provide more information, > > how > > is that going to be useful if it is not supported by the underlying > > transport > > protocol ? > > > > Madjid>> First of all, not everybody and every feature need an advanced > > transport and I know we agree on this. > > However, say in 6 months we are debating an specific feature that does need > > reliability. This text is to protect us from sloppy design. > > If you remember Jeff Schiller saying: Don't come and say use > > IPSec if you want security, you need to work on the security details. > > > > Example of a case which even SCTP is not going to cut it (this is > > answer to your next question as well): say you are sending a very > > dynamic context (packet count or HC context) and you want reliability > > (and you got time to resend stuff...). > > You send the context, but due to do channel conditions don't get it through, > > next time, you have to send updates. This has to come from the feature unit > > and not from transport layer. If had just said use SCTP for reliability that > > would not be a robust design. > > > > When you have to send an update, you do it whether or not SCTP failed to > get it through in the first case, right ? What SCTP or a reliable transport > protocol will offer you is the ability to send a message reliably. When you > have a new message or an update, I agree the feature code has to supply it > (and SCTP has to get to the destination reliably)! > > Madjid>> True, furthermore, if you use a reliable protocol like > SCTP, you need to take extra care with CT, so the receiver doesn't mix up > updates from app. layer, with retx from transport. > > > I hope you are not indicating that each feature has to design its own reliable > transmission protocol. The way each feature uses SCTP or UDP is internal > to the feature, and is not a function of the CT protocol itself. The > CT protocol > should define a set of messages that can be carried over different transport > protocols. > > Madjid>> No, No, however, If we add a set of minimal support (like > what I mentioned above) to the generic protocol, then provide the option > for the feature to use it or not we are covered. > If we completely ignore reliability > completely, we will write off CT as a useful protocol, I think! > > BR, > > Madjid > > Regards, > > -Rajeev > > > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby