From owner-seamoby@diameter.org Sun Apr 1 16:19:11 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA01166 for ; Sun, 1 Apr 2001 16:19:10 -0400 (EDT) Received: (from majordomo@localhost) by charizard.diameter.org (8.11.3/8.11.3) id f31JKY120978 for seamoby-list; Sun, 1 Apr 2001 12:20:34 -0700 X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f Received: from netmail.alcatel.com (netmail.alcatel.com [128.251.168.50]) by charizard.diameter.org (8.11.3/8.11.3) with ESMTP id f31JKWF20973; Sun, 1 Apr 2001 12:20:32 -0700 Received: from auds951.usa.alcatel.com (auds951.usa.alcatel.com [143.209.238.80]) by netmail.alcatel.com (8.9.1/8.9.1) with ESMTP id NAA04057; Sun, 1 Apr 2001 13:29:56 -0500 (CDT) Received: from usa.alcatel.com (localhost [127.0.0.1]) by auds951.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id f31ITN826447; Sun, 1 Apr 2001 13:29:23 -0500 (CDT) Message-ID: <3AC76560.DF6C117C@usa.alcatel.com> Date: Sun, 01 Apr 2001 13:29:04 -0400 From: Behcet Sarikaya X-Mailer: Mozilla 4.76 [en]C-CCK-MCD BDPjm-Sony3 (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: mankin@ISI.EDU CC: James Kempf , seamoby@diameter.org, seamoby-paging@diameter.org Subject: Re: [seamoby-paging] Re: [seamoby] Paging or Not References: <10103310154.AA17116@maia.east.isi.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-seamoby@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit Allison, I am the editor of the paging requirements documents. I was also one of the coauthors of a IP paging protocol I-D. In Minneapolis, I discussed with several experts in the area and got their committment to work in the design team. I think that some good things can be done, should you people give us a goahead. Regards, Allison Mankin wrote: > Jim, > > As AD, I approved going ahead with starting on requirements work > for paging already, based on the results when Pat last called > the problem statement. > > In general, my observation has agreed with Pat's that there is > IETF-style (that is, tumultuous, but sound) consensus to go ahead. > > There is a remaining step, which is the IESG review of the problem > statement, which will secure the paging task in the Seamoby charter, > and may return some specific feedback. > > The IESG will review the problem statement during our telechat this > coming week, and I'll make sure to report the results to the list. > > Regards, > > Allison > > > Pat/Allison/All, > > > > Behcet, the design team members, and I have committed ourselves to working > > fairly intensively on the paging problem over the next months until > > IETF 51. Recently, there has been some email about whether or not > > paging should even be considered by IETF. I had thought that we > > were beyond this point. This was in response to Pat's email of > > a few days ago. > > > > The conclusion of the design team, which I presented at IETF 50, was > > that there is a problem to be solved. It is not unsolvable by > > using mobile IP, but the solution is difficult. > > > > Frankly, I am not about to spend the next 4 months waging an email battle > > with bomb throwers who want to derail progress. If we > > don't have agreement on doing requirements, I would like to suggest > > we can this activity right now. I've got plenty of other things I could > > be spending time on, and I'm sure the other paging design team > > members feel the same. > > > > Are we going forward with requirements on paging or not? -- Behcet From owner-seamoby@diameter.org Mon Apr 2 06:28:10 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA26762 for ; Mon, 2 Apr 2001 06:28:09 -0400 (EDT) Received: (from majordomo@localhost) by charizard.diameter.org (8.11.3/8.11.3) id f329hL022810 for seamoby-list; Mon, 2 Apr 2001 02:43:21 -0700 X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f Received: from auemlsrv.firewall.lucent.com (auemail1.lucent.com [192.11.223.161]) by charizard.diameter.org (8.11.3/8.11.3) with ESMTP id f329gMF22805 for ; Mon, 2 Apr 2001 02:42:22 -0700 Received: from auemlsrv.firewall.lucent.com (localhost [127.0.0.1]) by auemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id EAA04130 for ; Mon, 2 Apr 2001 04:51:48 -0400 (EDT) Received: from uk0006exch001h.wins.lucent.com (h135-86-160-150.lucent.com [135.86.160.150]) by auemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id EAA04104 for ; Mon, 2 Apr 2001 04:51:48 -0400 (EDT) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2650.21) id ; Mon, 2 Apr 2001 09:51:46 +0100 Message-ID: <976F7C55E3B2D111A0720008C728549C097CC2AC@en0060exch001u.uk.lucent.com> From: "Casati, Alessio (Alessio)" To: "'Patrice Calhoun'" , "Casati, Alessio (Alessio)" Cc: "'James Kempf'" , seamoby@cdma-2000.org Subject: RE: [seamoby] To page, or not to page Date: Mon, 2 Apr 2001 09:51:34 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: owner-seamoby@diameter.org Precedence: bulk Pat, *Alessio, * *First, could I kindly request that you prefix your comments to *Jim. It is very *difficult for me to figure out what you are saying since it is *all mixed up. * Hope this helps *Second, it appears to me as if the problem is not with paging, but the *requirements. Again, you stated that you haven't read the *problem statement, No, I have read it, Exactly in the midlle of last week. However, later than the expiration of the deadline for last call. The trigger for me to read that was reading some not so sound e-mails on creative definitions of L2 paging and use of Paging channels in cellular nets. *but seem to have lots of ideas on what is needed, and what is *not. Could I *convince you to read the problem statement, and then provide *comments on the *spec? I did already, although I recognize you must have had a hard time to read thru them given the absence of some proper formatting of my messages... *Lastly, could I also encourage you to work on the *requirements, following e *normal IETF process, to make sure that your needs are met? Unfortunatley I don't have cycles enough to do that. Can I send to this list my comments on the work that gets done here, despite this, when I happen to have a few cycles and comments? By the way, I hear people talking about fixing routing via this "Paging thing". I wonder then why this is in the transport area... Possibly another BOF in another area would be more appropriate, according to IETF process... Final remark: Paging is used for link establishment in cellular nets. What you are trying to do could be, at best, local repair of routing. This needs to be addressed with a routing area protocol. It would be my requirement that the Handset does not participate in this protocol and this is totally transparent to the mobile. The problem statement is not at all clear about this, and it needs a re-spin, including changing the name "Paging" (misleading and inappropriate) and possibly taking it to the routing area would not be a bad idea. Possibly, it is more a Mobile IP WG work item proposal. Have a nice week. Alessio From owner-seamoby@diameter.org Mon Apr 2 06:50:42 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA28289 for ; Mon, 2 Apr 2001 06:50:41 -0400 (EDT) Received: (from majordomo@localhost) by charizard.diameter.org (8.11.3/8.11.3) id f32ALsR22903 for seamoby-list; Mon, 2 Apr 2001 03:21:54 -0700 X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f Received: from hoemail2.firewall.lucent.com (hoemail2.lucent.com [192.11.226.163]) by charizard.diameter.org (8.11.3/8.11.3) with ESMTP id f32ALpF22898; Mon, 2 Apr 2001 03:21:51 -0700 Received: from hoemail2.firewall.lucent.com (localhost [127.0.0.1]) by hoemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id FAA18537; Mon, 2 Apr 2001 05:31:17 -0400 (EDT) Received: from uk0006exch001h.wins.lucent.com (h135-86-160-150.lucent.com [135.86.160.150]) by hoemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id FAA18512; Mon, 2 Apr 2001 05:31:16 -0400 (EDT) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2650.21) id ; Mon, 2 Apr 2001 10:31:16 +0100 Message-ID: <976F7C55E3B2D111A0720008C728549C097CC2AE@en0060exch001u.uk.lucent.com> From: "Casati, Alessio (Alessio)" To: "'mankin@ISI.EDU'" Cc: seamoby@diameter.org, seamoby-paging@diameter.org Subject: RE: [seamoby] Paging or Not Date: Mon, 2 Apr 2001 10:31:10 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: owner-seamoby@diameter.org Precedence: bulk * *Jim, * *As AD, I approved going ahead with starting on requirements work *for paging already, based on the results when Pat last called *the problem statement. * *In general, my observation has agreed with Pat's that there is *IETF-style (that is, tumultuous, but sound) consensus to go ahead. * *There is a remaining step, which is the IESG review of the problem *statement, which will secure the paging task in the Seamoby charter, *and may return some specific feedback. * *The IESG will review the problem statement during our telechat this *coming week, and I'll make sure to report the results to the list. * *Regards, * *Allison * Dear transport area AD, Since the reason behind paging seems to addressing routing protocol defects, according to a quote from the editor of the Paging problem statement document here below: "So you want to handle a defect in the routing protocol by falling back on TCP retransmission, or, if TCP isn't used, whatever application specific UDP retransmit protocol happens to be there? IHMO, it is poor design practice to depend on error mechanisms to handle the a defect in the routing design." I'd suggest the IESG in the telechat to consider whether the transport area is the right one. I think it is not. I'd like you to report on this too. Respectfully alessio From owner-seamoby@diameter.org Mon Apr 2 11:50:50 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA16623 for ; Mon, 2 Apr 2001 11:50:50 -0400 (EDT) Received: (from majordomo@localhost) by charizard.diameter.org (8.11.3/8.11.3) id f32F1NR23873 for seamoby-list; Mon, 2 Apr 2001 08:01:23 -0700 X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f Received: from atlsnmx1.nextel.com (atlsnmx1.nextel.com [167.20.198.200]) by charizard.diameter.org (8.11.3/8.11.3) with ESMTP id f32F1JF23868 for ; Mon, 2 Apr 2001 08:01:20 -0700 Received: from atlntgw02.nextel.com (atlntgw02.nextel.com [10.8.79.186]) by atlsnmx1.nextel.com (8.8.8+Sun/8.8.6) with ESMTP id KAA28748; Mon, 2 Apr 2001 10:10:30 -0400 (EDT) Received: by atlntgw02.nextel.com with Internet Mail Service (5.5.2650.21) id ; Mon, 2 Apr 2001 10:11:00 -0400 Message-ID: <020A5EC56F3FD411B5230008C716D085868583@nhqntex01.nextel.com> From: "Martin, David P" To: "'Kulwinder Atwal'" , "'Michael Thomas'" , "Martin, David P" Cc: "'David R. Oran'" , seamoby@diameter.org Subject: RE: [seamoby] L2/L3 Paging Date: Mon, 2 Apr 2001 10:05:34 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-seamoby@diameter.org Precedence: bulk > > Mobile left town, battery died, ... all fall under the catagory: link > failure. > > It can be resolved with an implementation specific Link > Timeout Timer, where > if no packets are transferred for Link Timeout seconds link failure is > assumed. Link reliability is an L2 issue. > > - Kulwinder. Yes that is one solution, but how should the timer be set? Different link protocols, different applications, different RF conditions, etc would affect what the optimum timeout should be ... From owner-seamoby@diameter.org Mon Apr 2 12:11:06 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA17725 for ; Mon, 2 Apr 2001 12:11:05 -0400 (EDT) Received: (from majordomo@localhost) by charizard.diameter.org (8.11.3/8.11.3) id f32DrXS23655 for seamoby-list; Mon, 2 Apr 2001 06:53:33 -0700 X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f Received: from atlsnmx1.nextel.com (atlsnmx1.nextel.com [167.20.198.200]) by charizard.diameter.org (8.11.3/8.11.3) with ESMTP id f32DrVF23650 for ; Mon, 2 Apr 2001 06:53:31 -0700 Received: from atlntgw02.nextel.com (atlntgw02.nextel.com [10.8.79.186]) by atlsnmx1.nextel.com (8.8.8+Sun/8.8.6) with ESMTP id JAA19864; Mon, 2 Apr 2001 09:02:54 -0400 (EDT) Received: by atlntgw02.nextel.com with Internet Mail Service (5.5.2650.21) id ; Mon, 2 Apr 2001 09:03:26 -0400 Message-ID: <020A5EC56F3FD411B5230008C716D085868580@nhqntex01.nextel.com> From: "Martin, David P" To: "'Michael Thomas'" , "Martin, David P" Cc: "'David R. Oran'" , seamoby@diameter.org Subject: RE: [seamoby] L2/L3 Paging Date: Mon, 2 Apr 2001 08:58:01 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-seamoby@diameter.org Precedence: bulk >> One problem is which interface(s) to deliver >> packets to, the other problem is what to do if the mobile >> doesn't respond in a timely fashion. > > I believe that any paging protocol needs to face > this possibility though. Agree, but I know of only one solution (timer), however, since we are in the requirements stage I will withold judgement until we have consensus on the requirements. >> The second problem of what to do if the mobile is not >> reachable is a separate issue. I feel that it probably *is* >> a worthwhile problem to solve. > I dunno. Nothing extrordinary happens when my > DSL line goes down right now. Do we really need > to figure out a way backhaul my annoyance > dotted with four letter words when that > happens? :-) In wireless, being unreachable is sometimes a transient event (lasting from milliseconds to days). So mechanisms could be invented that address the transient nature of these *some* of these outages. My concern is where do you draw the line between which outages are addressed and which are not. > > Hmm. Application by application usually sets > of the boil-the-ocean klaxon in my head. Would > it be sufficient to set up an access control > list on the access router to block all but, > say, SIP and whatever other protocols you > wanted to listen for while you're dormant? > When I say "application by application" I mean it in the same context as QoS, which also will vary by application. From owner-seamoby@diameter.org Mon Apr 2 14:44:19 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA25689 for ; Mon, 2 Apr 2001 14:44:17 -0400 (EDT) Received: (from majordomo@localhost) by charizard.diameter.org (8.11.3/8.11.3) id f32GDxd24039 for seamoby-list; Mon, 2 Apr 2001 09:13:59 -0700 X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f Received: from zcars04f.ca.nortel.com (zcars04f.nortelnetworks.com [47.129.242.57]) by charizard.diameter.org (8.11.3/8.11.3) with ESMTP id f32GDuF24034 for ; Mon, 2 Apr 2001 09:13:56 -0700 Received: from zcard015.ca.nortel.com by zcars04f.ca.nortel.com; Mon, 2 Apr 2001 10:46:50 -0400 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 2 Apr 2001 10:46:08 -0400 Message-ID: <13E2EF604DE5D111B2E50000F80824E8057A8EAA@zwdld001.ca.nortel.com> From: "Gary Kenward" To: "'Charles E. Perkins'" Cc: seamoby@diameter.org, "Hamid Syed" , "'seamoby_context'" Subject: [seamoby] RE: draft-hamid-seamoby-ct-reqs-00.txt Date: Mon, 2 Apr 2001 10:46:04 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0BB83.A4AB3F10" X-Orig: Sender: owner-seamoby@diameter.org Precedence: bulk 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_01C0BB83.A4AB3F10 Content-Type: text/plain; charset="iso-8859-1" Charlie: Thanks for the comments. Very much appreciated (and many are not far off of some of the internal debates we have been having). I have some questions concerning your suggestions, for you or anyone else who may wish to answer. BTW: there is a 01 version of the document. We did confuse the situation a tad but submitting both during the IETF meeting. The 01 version hopefully reads a somewhat better, and may even address some of your points. http://search.ietf.org/internet-drafts/draft-hamid-seamoby-ct-reqs-01.txt Gary > -----Original Message----- > From: Charles E. Perkins [mailto:charliep@IPRG.nokia.com] > Sent: Friday, March 30, 2001 4:57 PM > To: Kenward, Gary [WDLN2:AN10:EXCH]; Syed, Hamid [WDLN2:AN22:EXCH] > Cc: seamoby@diameter.org > Subject: draft-hamid-seamoby-ct-reqs-00.txt > > > > Hello folks, > > All in all, the requirements draft seems to be a very worthwhile > effort, from which good solutions are likely to be developed. Thanks! > > Here are some comments. > > 1. Security needs discussion. Unsecured context transfers are > to be avoided. I see that the word "integrity" appears in > section 4.2, but somehow I didn't think that the entire discussion > about security was intended to be distilled into that single word. Absolutely. We explicitly wanted to be cautious about getting too deep into this discussion with our draft, as neither of us are active in the security discussions, which we know to be very dynamic. Hopefully, someone will help us with the text. > > 2. Supporting one-to-many context transfers might be useful. > It might also be complicated. It almost certainly is not so > crucial that its lack would break the protocol. Thus, I would > rate it no more than a "SHOULD", instead of a "MUST". Understood, although I would say we should wait and see what the solution looks like. We are not talking about general multicasting here. I suspect that one-to-one context transfer could actually be more complex in a real wireless scenario due to the ambiguity of the handover "direction" at any given moment. > > 3. Conversely, reactive context transfer will sometimes be the > only available option. Thus, it has to be a MUST, not a SHOULD. Agreed. I had thought we had made that change in the -01 version. It will be in the -02 version. > > 4. Terms like "micro-flow" and "integrity" need to be defined in the > terminology section -- or, perhaps better, replaced by more > specific or more common terms in the body of the text. > Specifically > regarding "micro-flow" as you have used it, a protocol would need > some identification mechanism. This mechanism needs elaboration > in the requirements draft, I think -- it is important. Microflow seems to be a far more controversial term then I would have expected. We were using the definition in the problem statement, namely, the 5-tuple definition. Actually, the refers to RFC2475 and RFC2207 (the latter is referenced to cover the scenario where the IP packets are encrypted). Is this acceptable? I really would not want to generate a new definition of microflow if one already exists. > > 5. Discussions about interworking with "the micro-mobility mechanism" > are probably better deleted for now, although I agree with > the spirit > of that suggestion. Would it be more acceptable to change "the micro-mobility mechanism" to the "mobility mechanisms"? > > 6. 100% reliability is impossible(*). Furthermore, even high > reliability > may be undesirable as a requirement. High reliability means > retransmissions, backoff algorithms, algorithmic complexity, > and longer time delays in case of errors. All of these are > opposed to the goal of context transfer as a way to get timely > service without protracted renegotiations. Maybe, in fact, it > should be the case that [seamoby] should explicitly declare that > highly reliable context transfer is "out of scope"! I imagine > that more than a single retransmission won't be worthwhile. > [proof of (*): consider network partition or nuclear war] No proof needed. Reliability is always a process of exponentially diminishing returns. We certainly did not mean to imply re-transmission, etc. Rather we would like to leave the level of "transport reliability" to the network engineers. And, as you indicate, data integrity is the real issue: it is likely more harmful to deliver erroneous context then it is to fail to deliver the information at all. We will rework the text. > > 7. I'd suggest adding the context transfer problem statement design > team members to the acknowledgements. There was certainly a lot of > discussion on the mailing list from those folks, so I reckon they > did a lot of work shaping the form of this draft. Intuitively, > the design team seems to have made a stronger contribution than > those who were explicitly mentioned, but I wasn't there so > I clearly > cannot say with any certainty. Actually, this is not really correct, most of the concepts were developed long before the creation of the design team. Having said this, this was a personal submission, and the contributors from the design team will be added to the authors list of the wg draft (we are deciding today if this draft forms the basis for the dt requirements draft). > > 8. At the end of section 4.1, the last sentence refers to the number > of messages being less. Less than what? The sentence before is > missing a word after "simply". > > 9. At the top of page 5, the word "appropriate" should probably be > "desired", because appropriateness would need a lot more > definition. And desired does not? > > > > Editorial: > > "captured" --> "described" > "sustain" --> "preserve" > "rest of the ARs" --> "target ARs" (maybe worthwhile to put > in terminology) > "ensure" --> "mean" (in the paragraph preceding > the bullet item > about supporting reactive > context transfer We'll have to look over the context of these changes. For example, I know the denotation of "sustain", and it fits perfectly; "preserve" could be involve archiving the information. > > In the sentence containing "cardinality between" -- perhaps > you meant "correspondence between the number of". There are > some misspelled words, missing articles, missing parentheses, > and syntax errors that need proofreading, which if need be I > can type in later. The text of the draft is too close both to > the header and to the footers. Thanks. You might want to look at the -01 draft before you do more typing. Again, sorry for the confusion. Your comments will be useful in producing the next revision. It is a work in progress. Tally ho, Gary > > Regards, > Charlie P. > ------_=_NextPart_001_01C0BB83.A4AB3F10 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: draft-hamid-seamoby-ct-reqs-00.txt

Charlie:

  Thanks for the comments. Very much appreciated = (and many are not
far off of some of the internal debates we have been = having).

   I have some questions concerning your = suggestions, for you or anyone
else who may wish to answer.

   BTW: there is a 01 version of the = document. We did confuse the situation
a tad but submitting both during the IETF meeting. = The 01 version hopefully
reads a somewhat better, and may even address some = of your points.
http://search.ietf.org/internet-drafts/draft-hamid-sea= moby-ct-reqs-01.txt

Gary

> -----Original Message-----
> From: Charles E. Perkins [mailto:charliep@IPRG.nokia.com]
> Sent: Friday, March 30, 2001 4:57 PM
> To: Kenward, Gary [WDLN2:AN10:EXCH]; Syed, = Hamid [WDLN2:AN22:EXCH]
> Cc: seamoby@diameter.org
> Subject: = draft-hamid-seamoby-ct-reqs-00.txt
>
>
>
> Hello folks,
>
> All in all, the requirements draft seems to be = a very worthwhile
> effort, from which good solutions are likely to = be developed.  Thanks!
>
> Here are some comments.
>
> 1. Security needs discussion.  Unsecured = context transfers are
>    to be avoided.  I see = that the word "integrity" appears in
>    section 4.2, but somehow I = didn't think that the entire discussion
>    about security was intended = to be distilled into that single word.

Absolutely. We explicitly wanted to be cautious about = getting too
deep into this discussion with our draft, as neither = of us are active
in the security discussions, which we know to be = very dynamic.

Hopefully, someone will help us with the text.

>
> 2. Supporting one-to-many context transfers = might be useful.
>    It might also be = complicated.  It almost certainly is not so
>    crucial that its lack would = break the protocol.  Thus, I would
>    rate it no more than a = "SHOULD", instead of a "MUST".

Understood, although I would say we should wait and = see what
the solution looks like. We are not talking about = general multicasting
here. I suspect that one-to-one context transfer = could actually be
more complex in a real wireless scenario due to the = ambiguity of
the handover "direction" at any given = moment.

>
> 3. Conversely, reactive context transfer will = sometimes be the
>    only available option.  = Thus, it has to be a MUST, not a SHOULD.

Agreed. I had thought we had made that change in the = -01 version.
It will be in the -02 version.

>
> 4. Terms like "micro-flow" and = "integrity" need to be defined in the
>    terminology section -- or, = perhaps better, replaced by more
>    specific or more common terms = in the body of the text. 
> Specifically
>    regarding = "micro-flow" as you have used it, a protocol would = need
>    some identification = mechanism.  This mechanism needs elaboration
>    in the requirements draft, I = think -- it is important.

Microflow seems to be a far more controversial term = then I would have
expected. We were using the definition in the = problem statement, namely,
the 5-tuple definition.

Actually, the refers to RFC2475 and RFC2207 (the = latter is referenced to
cover the scenario where the IP packets are = encrypted). Is this acceptable?
I really would not want to generate a new definition = of microflow if one
already exists.

>
> 5. Discussions about interworking with = "the micro-mobility mechanism"
>    are probably better deleted = for now, although I agree with
> the spirit
>    of that suggestion.

Would it be more acceptable to change "the = micro-mobility mechanism"
to the "mobility mechanisms"?

>
> 6. 100% reliability is impossible(*).  = Furthermore, even high
> reliability
>    may be undesirable as a = requirement.  High reliability means
>    retransmissions, backoff = algorithms, algorithmic complexity,
>    and longer time delays in = case of errors.  All of these are
>    opposed to the goal of = context transfer as a way to get timely
>    service without protracted = renegotiations.  Maybe, in fact, it
>    should be the case that = [seamoby] should explicitly declare that
>    highly reliable context = transfer is "out of scope"!  I imagine
>    that more than a single = retransmission won't be worthwhile.
>    [proof of (*): consider = network partition or nuclear war]

No proof needed. Reliability is always a process of = exponentially
diminishing returns.

We certainly did not mean to imply re-transmission, = etc. Rather we
would like to leave the level of "transport = reliability" to the network
engineers.

And, as you indicate, data integrity is the real issue= : it is likely more
harmful to deliver erroneous context then it is to = fail to deliver the
information at all.

We will rework the text.

>
> 7. I'd suggest adding the context transfer = problem statement design
>    team members to the = acknowledgements.  There was certainly a lot of
>    discussion on the mailing = list from those folks, so I reckon they
>    did a lot of work shaping the = form of this draft.  Intuitively,
>    the design team seems to have = made a stronger contribution than
>    those who were explicitly = mentioned, but I wasn't there so
> I clearly
>    cannot say with any = certainty.

Actually, this is not really correct, most of the = concepts were developed
long before the creation of the design team. Having = said this, this was a
personal submission, and the contributors from the = design team will
be added to the authors list of the wg draft (we are = deciding today if
this draft forms the basis for the dt requirements = draft).

>
> 8. At the end of section 4.1, the last sentence = refers to the number
>    of messages being less.  = Less than what?  The sentence before is
>    missing a word after = "simply".
>
> 9. At the top of page 5, the word = "appropriate" should probably be
>    "desired", because = appropriateness would need a lot more
> definition.

And desired does not?

>
>
>
> Editorial:
>
> = "captured"         = -->  "described"
> = "sustain"         = ; -->  "preserve"
> "rest of the ARs"  -->  = "target ARs" (maybe worthwhile to put
> in terminology)
> = "ensure"         =   -->  "mean"    (in the = paragraph preceding
> the bullet item
>          = ;            = ;            = ;  about supporting reactive
> context transfer

We'll have to look over the context of these = changes.  For example,
I know the denotation of "sustain", and it = fits perfectly; "preserve"
could be involve archiving the information.

>
> In the sentence containing "cardinality = between" -- perhaps
> you meant "correspondence between the = number of".  There are
> some misspelled words, missing articles, = missing parentheses,
> and syntax errors that need proofreading, which = if need be I
> can type in later.  The text of the draft = is too close both to
> the header and to the footers.

Thanks. You might want to look at the -01 draft = before you do more
typing. Again, sorry for the confusion. Your = comments will be useful
in producing the next revision. It is a work in = progress.

Tally ho,
Gary

>
> Regards,
> Charlie P.
>

------_=_NextPart_001_01C0BB83.A4AB3F10-- From owner-seamoby@diameter.org Mon Apr 2 15:22:25 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA26668 for ; Mon, 2 Apr 2001 15:22:25 -0400 (EDT) Received: (from majordomo@localhost) by charizard.diameter.org (8.11.3/8.11.3) id f32IbSk24416 for seamoby-list; Mon, 2 Apr 2001 11:37:28 -0700 X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f Received: from NEPTUNE.zucotto.com ([216.95.209.154]) by charizard.diameter.org (8.11.3/8.11.3) with ESMTP id f32IbMF24411 for ; Mon, 2 Apr 2001 11:37:23 -0700 Received: by NEPTUNE.zucotto.com with Internet Mail Service (5.5.2653.19) id ; Mon, 2 Apr 2001 13:46:49 -0400 Message-ID: <6833D86F1B05CA4FBAB3C73DD98BD8B90D2AC3@NEPTUNE.zucotto.com> From: Kulwinder Atwal To: "'Martin, David P'" , Kulwinder Atwal , "'Michael Thomas'" Cc: "'David R. Oran'" , seamoby@diameter.org Subject: RE: [seamoby] L2/L3 Paging Date: Mon, 2 Apr 2001 13:46:49 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-seamoby@diameter.org Precedence: bulk > -----Original Message----- > From: Martin, David P [mailto:David.P.Martin@nextel.com] > Sent: Monday, April 02, 2001 10:06 AM > To: 'Kulwinder Atwal'; 'Michael Thomas'; Martin, David P > Cc: 'David R. Oran'; seamoby@diameter.org > Subject: RE: [seamoby] L2/L3 Paging > > > > > > Mobile left town, battery died, ... all fall under the > catagory: link > > failure. > > > > It can be resolved with an implementation specific Link > > Timeout Timer, where > > if no packets are transferred for Link Timeout seconds link > failure is > > assumed. Link reliability is an L2 issue. > > > > - Kulwinder. > > Yes that is one solution, but how should the timer be set? > Different link > protocols, different applications, different RF conditions, > etc would affect > what the optimum timeout should be ... What I am suggesting is for us to simply consider an abstract L2 Trigger, and let different L2s deal with how they wish for the L2 timer to be set. Otherwise, we may find ourselves creating timers that compete with Link Layer timers. In some instances the L2 Trigger will be a timer, but in other instances it will be a low Radio Signal Strength that will trigger a change in the network. L2 Trigger Case 1: The mobile user's battery dies unexpectedly ( L2 Timer ) L2 Trigger Case 2: The mobile moves away while sending ( low Radio Signal Strength) - Kulwinder. > From owner-seamoby@diameter.org Mon Apr 2 15:56:16 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA27859 for ; Mon, 2 Apr 2001 15:56:16 -0400 (EDT) Received: (from majordomo@localhost) by charizard.diameter.org (8.11.3/8.11.3) id f32IBI724356 for seamoby-list; Mon, 2 Apr 2001 11:11:18 -0700 X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by charizard.diameter.org (8.11.3/8.11.3) with ESMTP id f32IBBF24351 for ; Mon, 2 Apr 2001 11:11:12 -0700 Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA20615; Mon, 2 Apr 2001 10:20:34 -0700 (PDT) Received: from nasnfs.Eng.Sun.COM (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA29399; Mon, 2 Apr 2001 10:20:32 -0700 (PDT) Received: from darius (darius [10.6.84.105]) by nasnfs.Eng.Sun.COM (8.9.3+Sun/8.9.1) with SMTP id KAA25192; Mon, 2 Apr 2001 10:20:21 -0700 (PDT) Date: Mon, 2 Apr 2001 10:20:19 -0700 (PDT) From: Patrice Calhoun Reply-To: Patrice Calhoun Subject: RE: [seamoby] L2/L3 Paging To: Michael Thomas Cc: "Martin, David P" , "'David R. Oran'" , seamoby@diameter.org In-Reply-To: "Your message with ID" <15045.350.744410.794532@thomasm-u1.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-seamoby@diameter.org Precedence: bulk > Martin, David P writes: > > I'm trying to understand which non-reachability problems we will attempt > to > > address. If the only problem we are trying to solve is reaching a dormant > > mode, I am in full agreement with the problem statement. > > As far as I know, this is all we're trying to > address. > > > However, if we want a protocol that we deal with *all* non-reachability > > issues (link failures, mobile left town, battery died, etc) then I think > > that is two distinct problems. One problem is which interface(s) to > deliver > > packets to, the other problem is what to do if the mobile doesn't respond > in > > a timely fashion. > > I believe that any paging protocol needs to face > this possibility though. We cannot add arbitrary items to the charter, and we are only chartered for the first case. Having said that, I am not quite sure who the network would know whether silence is the result of the first or second case. So paging request failures (or timeouts?) have to be supported. PatC From owner-seamoby@diameter.org Mon Apr 2 17:46:14 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA02287 for ; Mon, 2 Apr 2001 17:46:13 -0400 (EDT) Received: (from majordomo@localhost) by charizard.diameter.org (8.11.3/8.11.3) id f32L9cH24854 for seamoby-list; Mon, 2 Apr 2001 14:09:38 -0700 X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f Received: from c007.snv.cp.net (c007-h008.c007.snv.cp.net [209.228.33.214]) by charizard.diameter.org (8.11.3/8.11.3) with SMTP id f32L9ZF24849 for ; Mon, 2 Apr 2001 14:09:35 -0700 Received: (cpmta 29243 invoked from network); 2 Apr 2001 13:00:24 -0700 Received: from unknown (HELO philneum) (64.193.0.129) by smtp.telocity.com (209.228.33.214) with SMTP; 2 Apr 2001 13:00:24 -0700 X-Sent: 2 Apr 2001 20:00:24 GMT Message-ID: <000b01c0bbaf$672012c0$6501a8c0@philneum> Reply-To: "Phil Neumiller" From: "Phil Neumiller" To: "Kulwinder Atwal" , "'Martin, David P'" , "'Michael Thomas'" Cc: "'David R. Oran'" , References: <6833D86F1B05CA4FBAB3C73DD98BD8B90D2AC3@NEPTUNE.zucotto.com> Subject: Re: [seamoby] L2/L3 Paging Date: Mon, 2 Apr 2001 14:59:10 -0500 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-seamoby@diameter.org Precedence: bulk Hi Kulwinder, Well hush my mouth and echo from the past... Nice thinking here Kulwinder. I want to re-emphasize that I think Kulwinder is really on to something here and this is precisely the kind of thing that the new fangled sub-IP WG should do if/when it gets created, the again Kulwinder since you are the co-Chair of the Bluetooth WG you could start making sure that the bottom half of Bluetooth is already doing this. ;-) ----- Original Message ----- From: "Kulwinder Atwal" > > From: Martin, David P [mailto:David.P.Martin@nextel.com] > What I am suggesting is for us to simply consider an abstract L2 Trigger, > and let different L2s deal with how they wish for the L2 timer to be set. > - Kulwinder. This is very CRAPS-esque I might add. I like this a whole lot and I have bored many an IETFr with this rant, of course mine was always longer for some reason. :-) -pdn From owner-seamoby@diameter.org Tue Apr 3 16:15:44 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA15545 for ; Tue, 3 Apr 2001 16:15:43 -0400 (EDT) Received: (from majordomo@localhost) by charizard.diameter.org (8.11.3/8.11.3) id f33JMhY28584 for seamoby-list; Tue, 3 Apr 2001 12:22:43 -0700 X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49]) by charizard.diameter.org (8.11.3/8.11.3) with SMTP id f33JMeF28579 for ; Tue, 3 Apr 2001 12:22:40 -0700 Received: from scummy.research.bell-labs.com ([135.104.2.10]) by crufty; Tue Apr 3 14:29:46 EDT 2001 Received: from king.research.bell-labs.com ([135.1.152.1]) by scummy; Tue Apr 3 14:31:52 EDT 2001 Received: from notmafia.research.bell-labs.com.research.bell-labs.com (notmafia [135.1.152.230]) by king.research.bell-labs.com (Postfix) with SMTP id EEEBA5701F; Tue, 3 Apr 2001 13:31:51 -0500 (CDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Pete McCann To: kempf@heliopolis.Eng.Sun.COM Cc: mobile-ip@sunroof.eng.sun.com, rohc@cdt.luth.se, seamoby@diameter.org Subject: RE: [seamoby] RE: [rohc] RE: Restarting Compressor on Mobile IPv6 Handover In-Reply-To: <8572CF1E2A95D211A1190008C7EAA2460213BB7A@daeis05nok> References: <8572CF1E2A95D211A1190008C7EAA2460213BB7A@daeis05nok> X-Mailer: VM 6.33 under Emacs 19.34.2 Message-Id: <20010403183152.EEEBA5701F@king.research.bell-labs.com> Date: Tue, 3 Apr 2001 13:31:52 -0500 (CDT) Sender: owner-seamoby@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi, I think there is a simpler solution to this problem that most people are overlooking. It should be possible to keep the compressor/decompressor state at the old access router and to tunnel the already-compressed packets to and from the new access router. Then the MN and new access router can renegotiate header compression state from scratch and take as long as they want to do so, because the MN is still getting service in the meantime. Someone earlier asked about support for ROHC on IP tunnels and I think this would be a good application for that. We are trying to move the mountain to Mohammed and I don't see why we can't do the reverse instead. -Pete From owner-seamoby@diameter.org Tue Apr 3 19:53:53 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA20565 for ; Tue, 3 Apr 2001 19:53:52 -0400 (EDT) Received: (from majordomo@localhost) by charizard.diameter.org (8.11.3/8.11.3) id f33MdSM29260 for seamoby-list; Tue, 3 Apr 2001 15:39:28 -0700 X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216]) by charizard.diameter.org (8.11.3/8.11.3) with ESMTP id f33MdJF29255 for ; Tue, 3 Apr 2001 15:39:20 -0700 Received: from davir03nok.americas.nokia.com (davir03nok.americas.nokia.com [172.18.242.86]) by mgw-dax1.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f33LR7g15023 for ; Tue, 3 Apr 2001 16:27:17 -0500 (CDT) Received: from daebh01nok.americas.nokia.com (unverified) by davir03nok.americas.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Tue, 3 Apr 2001 16:26:12 -0500 Received: by daebh01nok with Internet Mail Service (5.5.2652.78) id ; Tue, 3 Apr 2001 16:26:12 -0500 Message-ID: From: rajeev.koodli@nokia.com To: mccap@research.bell-labs.com, kempf@heliopolis.Eng.Sun.COM Cc: mobile-ip@sunroof.eng.sun.com, rohc@cdt.luth.se, seamoby@diameter.org Subject: RE: [seamoby] RE: [rohc] RE: Restarting Compressor on Mobile IPv6 Handover Date: Tue, 3 Apr 2001 16:26:11 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-seamoby@diameter.org Precedence: bulk Hi, How does this avoid the core problem of context _re-initialization_ ? You would still need to send IR packets (to new access router over the air interface) subsequent to handover in order to start a new context.. Anchoring it at the previous router may buy you some time, but not the bits. I reckon anchoring will bring its own set of problems. Regards, -Rajeev > -----Original Message----- > From: ext Pete McCann [mailto:mccap@research.bell-labs.com] > Sent: Tuesday, April 03, 2001 11:32 AM > To: kempf@heliopolis.Eng.Sun.COM > Cc: mobile-ip@sunroof.eng.sun.com; rohc@cdt.luth.se; > seamoby@diameter.org > Subject: RE: [seamoby] RE: [rohc] RE: Restarting Compressor on Mobile > IPv6 Handover > > > > Hi, > > I think there is a simpler solution to this problem that most people > are overlooking. > > It should be possible to keep the compressor/decompressor state at the > old access router and to tunnel the already-compressed packets to and > from the new access router. Then the MN and new access router can > renegotiate header compression state from scratch and take as long as > they want to do so, because the MN is still getting service in the > meantime. > > Someone earlier asked about support for ROHC on IP tunnels and I think > this would be a good application for that. > > We are trying to move the mountain to Mohammed and I don't see why we > can't do the reverse instead. > > -Pete > > > --- > Mailing list for Robust Header Compression WG > Archive: http://www.cdt.luth.se/rohc/ > From owner-seamoby@diameter.org Tue Apr 3 21:46:11 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA22863 for ; Tue, 3 Apr 2001 21:46:11 -0400 (EDT) Received: (from majordomo@localhost) by charizard.diameter.org (8.11.3/8.11.3) id f341KYV29823 for seamoby-list; Tue, 3 Apr 2001 18:20:34 -0700 X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6]) by charizard.diameter.org (8.11.3/8.11.3) with SMTP id f341KVF29818 for ; Tue, 3 Apr 2001 18:20:31 -0700 Received: from scummy.research.bell-labs.com ([135.104.2.10]) by dirty; Tue Apr 3 20:29:39 EDT 2001 Received: from king.research.bell-labs.com ([135.1.152.1]) by scummy; Tue Apr 3 20:29:38 EDT 2001 Received: from notmafia.research.bell-labs.com.research.bell-labs.com (notmafia [135.1.152.230]) by king.research.bell-labs.com (Postfix) with SMTP id 9D6C25701F; Tue, 3 Apr 2001 19:29:37 -0500 (CDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Pete McCann To: rajeev.koodli@nokia.com Cc: kempf@heliopolis.Eng.Sun.COM, mobile-ip@sunroof.eng.sun.com, rohc@cdt.luth.se, seamoby@diameter.org Subject: RE: [seamoby] RE: [rohc] RE: Restarting Compressor on Mobile IPv6 Handover In-Reply-To: References: X-Mailer: VM 6.33 under Emacs 19.34.2 Message-Id: <20010404002937.9D6C25701F@king.research.bell-labs.com> Date: Tue, 3 Apr 2001 19:29:37 -0500 (CDT) Sender: owner-seamoby@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit Yes, you would need to re-initialize the context over the air, but I don't think the bandwidth usage is high enough to matter. In a wide-area cellular environment IP handoffs will be relatively infrequent. The important consideration is the "glitch" experienced in voice traffic at handoff time, and this can be minimized by temporarily anchoring the compressor. -Pete rajeev.koodli@nokia.com (rk) writes: rk> Hi, rk> How does this avoid the core problem of context rk> _re-initialization_ ? You would still need to send IR packets (to rk> new access router over the air interface) subsequent to handover rk> in order to start a new context.. Anchoring it at the previous rk> router may buy you some time, but not the bits. I reckon rk> anchoring will bring its own set of problems. rk> Regards, rk> -Rajeev >> -----Original Message----- >> From: ext Pete McCann [mailto:mccap@research.bell-labs.com] >> Sent: Tuesday, April 03, 2001 11:32 AM >> To: kempf@heliopolis.Eng.Sun.COM >> Cc: mobile-ip@sunroof.eng.sun.com; rohc@cdt.luth.se; >> seamoby@diameter.org >> Subject: RE: [seamoby] RE: [rohc] RE: Restarting Compressor on Mobile >> IPv6 Handover >> >> >> >> Hi, >> >> I think there is a simpler solution to this problem that most people >> are overlooking. >> >> It should be possible to keep the compressor/decompressor state at the >> old access router and to tunnel the already-compressed packets to and >> from the new access router. Then the MN and new access router can >> renegotiate header compression state from scratch and take as long as >> they want to do so, because the MN is still getting service in the >> meantime. >> >> Someone earlier asked about support for ROHC on IP tunnels and I think >> this would be a good application for that. >> >> We are trying to move the mountain to Mohammed and I don't see why we >> can't do the reverse instead. >> >> -Pete >> >> >> --- >> Mailing list for Robust Header Compression WG >> Archive: http://www.cdt.luth.se/rohc/ >> rk> --- rk> Mailing list for Robust Header Compression WG rk> Archive: http://www.cdt.luth.se/rohc/ From owner-seamoby@diameter.org Tue Apr 3 22:39:59 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA24462 for ; Tue, 3 Apr 2001 22:39:59 -0400 (EDT) Received: (from majordomo@localhost) by charizard.diameter.org (8.11.3/8.11.3) id f341o0b29874 for seamoby-list; Tue, 3 Apr 2001 18:50:00 -0700 X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216]) by charizard.diameter.org (8.11.3/8.11.3) with ESMTP id f341nnF29869 for ; Tue, 3 Apr 2001 18:49:49 -0700 Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax1.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f340xNg28567 for ; Tue, 3 Apr 2001 19:59:23 -0500 (CDT) Received: from daebh01nok.americas.nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Tue, 3 Apr 2001 19:58:46 -0500 Received: by daebh01nok with Internet Mail Service (5.5.2652.78) id ; Tue, 3 Apr 2001 19:58:46 -0500 Message-ID: From: rajeev.koodli@nokia.com To: mccap@research.bell-labs.com, rajeev.koodli@nokia.com Cc: kempf@heliopolis.Eng.Sun.COM, mobile-ip@sunroof.eng.sun.com, rohc@cdt.luth.se, seamoby@diameter.org Subject: RE: [seamoby] RE: [rohc] RE: Restarting Compressor on Mobile IPv6 Handover Date: Tue, 3 Apr 2001 19:58:45 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-seamoby@diameter.org Precedence: bulk > -----Original Message----- > From: ext Pete McCann [mailto:mccap@research.bell-labs.com] > Sent: Tuesday, April 03, 2001 5:30 PM > To: rajeev.koodli@nokia.com > Cc: kempf@heliopolis.Eng.Sun.COM; mobile-ip@sunroof.eng.sun.com; > rohc@cdt.luth.se; seamoby@diameter.org > Subject: RE: [seamoby] RE: [rohc] RE: Restarting Compressor on Mobile > IPv6 Handover > > > > > Yes, you would need to re-initialize the context over the air, but I > don't think the bandwidth usage is high enough to matter. In a > wide-area cellular environment IP handoffs will be relatively > infrequent. The important consideration is the "glitch" experienced > in voice traffic at handoff time, and this can be minimized by > temporarily anchoring the compressor. > I don't agree with you comments that you could ignore bandwidth usage and assume infrequent handovers. a> 84 bytes of IPv6/UDP/RTP headers with Mobile-IPv6 Home Address option for a voice payload of 20 - 30 bytes. Several such packets sent per each stream. b> With fast user mobility, each BTS/AP being a router, I can imagine frequent handovers. In any case, context relocation addresses a>, does not assume infrequent handovers, as well as attempts to provide "glitch-free" voice. When the context is already present at the target router before the MN starts sending compressed packets, the application should not see the glitch. I know there is work to be done here, so let's try to focus on that! Regards, -Rajeev > -Pete > > rajeev.koodli@nokia.com (rk) writes: > > rk> Hi, > > rk> How does this avoid the core problem of context > rk> _re-initialization_ ? You would still need to send IR packets (to > rk> new access router over the air interface) subsequent to handover > rk> in order to start a new context.. Anchoring it at the previous > rk> router may buy you some time, but not the bits. I reckon > rk> anchoring will bring its own set of problems. > > rk> Regards, > > rk> -Rajeev > > > >> -----Original Message----- > >> From: ext Pete McCann [mailto:mccap@research.bell-labs.com] > >> Sent: Tuesday, April 03, 2001 11:32 AM > >> To: kempf@heliopolis.Eng.Sun.COM > >> Cc: mobile-ip@sunroof.eng.sun.com; rohc@cdt.luth.se; > >> seamoby@diameter.org > >> Subject: RE: [seamoby] RE: [rohc] RE: Restarting > Compressor on Mobile > >> IPv6 Handover > >> > >> > >> > >> Hi, > >> > >> I think there is a simpler solution to this problem that > most people > >> are overlooking. > >> > >> It should be possible to keep the compressor/decompressor > state at the > >> old access router and to tunnel the already-compressed > packets to and > >> from the new access router. Then the MN and new access router can > >> renegotiate header compression state from scratch and take > as long as > >> they want to do so, because the MN is still getting service in the > >> meantime. > >> > >> Someone earlier asked about support for ROHC on IP tunnels > and I think > >> this would be a good application for that. > >> > >> We are trying to move the mountain to Mohammed and I don't > see why we > >> can't do the reverse instead. > >> > >> -Pete > >> > >> > >> --- > >> Mailing list for Robust Header Compression WG > >> Archive: http://www.cdt.luth.se/rohc/ > >> > rk> --- > rk> Mailing list for Robust Header Compression WG > rk> Archive: http://www.cdt.luth.se/rohc/ > From owner-seamoby@diameter.org Tue Apr 3 23:04:42 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA24779 for ; Tue, 3 Apr 2001 23:04:41 -0400 (EDT) Received: (from majordomo@localhost) by charizard.diameter.org (8.11.3/8.11.3) id f342Bnr29934 for seamoby-list; Tue, 3 Apr 2001 19:11:49 -0700 X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by charizard.diameter.org (8.11.3/8.11.3) with ESMTP id f342BlF29929 for ; Tue, 3 Apr 2001 19:11:47 -0700 Received: from mira-sjcm-2.cisco.com (mira-sjcm-2.cisco.com [171.69.43.98]) by sj-msg-core-3.cisco.com (8.9.3/8.9.1) with ESMTP id SAA15378; Tue, 3 Apr 2001 18:19:55 -0700 (PDT) Received: from tmima-w2k.cisco.com (dhcp-171-70-57-96.cisco.com [171.70.57.96]) by mira-sjcm-2.cisco.com (Mirapoint) with ESMTP id ABX02451; Tue, 3 Apr 2001 18:19:35 -0700 (PDT) Message-Id: <4.3.2.7.2.20010403180901.02fb3798@mira-sjcm-2.cisco.com> X-Sender: tmima@mira-sjcm-2.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 03 Apr 2001 18:18:59 -0700 To: rajeev.koodli@nokia.com, mccap@research.bell-labs.com, rajeev.koodli@nokia.com From: Tmima Koren Subject: RE: [seamoby] RE: [rohc] RE: Restarting Compressor on Mobile IPv6 Handover Cc: kempf@heliopolis.Eng.Sun.COM, mobile-ip@sunroof.eng.sun.com, rohc@cdt.luth.se, seamoby@diameter.org In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-seamoby@diameter.org Precedence: bulk I wonder if it's possible to do both: The new router sends a request for context transfer, but continues to forward the compressed packets to the old router, AND queues a copy of the packets he forwarded. Once he receives the context, the new router applies the necessary changes to the context from the queued packets. Now his context is good and he can continue decompressing. Tmima At 07:58 PM 4/3/2001 -0500, rajeev.koodli@nokia.com wrote: > > -----Original Message----- > > From: ext Pete McCann [mailto:mccap@research.bell-labs.com] > > Sent: Tuesday, April 03, 2001 5:30 PM > > To: rajeev.koodli@nokia.com > > Cc: kempf@heliopolis.Eng.Sun.COM; mobile-ip@sunroof.eng.sun.com; > > rohc@cdt.luth.se; seamoby@diameter.org > > Subject: RE: [seamoby] RE: [rohc] RE: Restarting Compressor on Mobile > > IPv6 Handover > > > > > > > > > > Yes, you would need to re-initialize the context over the air, but I > > don't think the bandwidth usage is high enough to matter. In a > > wide-area cellular environment IP handoffs will be relatively > > infrequent. The important consideration is the "glitch" experienced > > in voice traffic at handoff time, and this can be minimized by > > temporarily anchoring the compressor. > > > >I don't agree with you comments that you could ignore bandwidth usage and >assume infrequent handovers. > >a> 84 bytes of IPv6/UDP/RTP headers with Mobile-IPv6 Home Address option for >a voice payload of 20 - 30 bytes. Several such packets sent per each stream. > >b> With fast user mobility, each BTS/AP being a router, I can imagine >frequent handovers. > >In any case, context relocation addresses a>, does not assume infrequent >handovers, as well as attempts to provide "glitch-free" voice. When the >context is already present at the target router before the MN starts sending >compressed packets, the application should not see the glitch. >I know there is work to be done here, so let's try to focus on that! > >Regards, > >-Rajeev > > > > -Pete > > > > rajeev.koodli@nokia.com (rk) writes: > > > > rk> Hi, > > > > rk> How does this avoid the core problem of context > > rk> _re-initialization_ ? You would still need to send IR packets (to > > rk> new access router over the air interface) subsequent to handover > > rk> in order to start a new context.. Anchoring it at the previous > > rk> router may buy you some time, but not the bits. I reckon > > rk> anchoring will bring its own set of problems. > > > > rk> Regards, > > > > rk> -Rajeev > > > > > > >> -----Original Message----- > > >> From: ext Pete McCann [mailto:mccap@research.bell-labs.com] > > >> Sent: Tuesday, April 03, 2001 11:32 AM > > >> To: kempf@heliopolis.Eng.Sun.COM > > >> Cc: mobile-ip@sunroof.eng.sun.com; rohc@cdt.luth.se; > > >> seamoby@diameter.org > > >> Subject: RE: [seamoby] RE: [rohc] RE: Restarting > > Compressor on Mobile > > >> IPv6 Handover > > >> > > >> > > >> > > >> Hi, > > >> > > >> I think there is a simpler solution to this problem that > > most people > > >> are overlooking. > > >> > > >> It should be possible to keep the compressor/decompressor > > state at the > > >> old access router and to tunnel the already-compressed > > packets to and > > >> from the new access router. Then the MN and new access router can > > >> renegotiate header compression state from scratch and take > > as long as > > >> they want to do so, because the MN is still getting service in the > > >> meantime. > > >> > > >> Someone earlier asked about support for ROHC on IP tunnels > > and I think > > >> this would be a good application for that. > > >> > > >> We are trying to move the mountain to Mohammed and I don't > > see why we > > >> can't do the reverse instead. > > >> > > >> -Pete > > >> > > >> > > >> --- > > >> Mailing list for Robust Header Compression WG > > >> Archive: http://www.cdt.luth.se/rohc/ > > >> > > rk> --- > > rk> Mailing list for Robust Header Compression WG > > rk> Archive: http://www.cdt.luth.se/rohc/ > > From owner-seamoby@diameter.org Tue Apr 3 23:05:16 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA24790 for ; Tue, 3 Apr 2001 23:05:15 -0400 (EDT) Received: (from majordomo@localhost) by charizard.diameter.org (8.11.3/8.11.3) id f342Uo229982 for seamoby-list; Tue, 3 Apr 2001 19:30:50 -0700 X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216]) by charizard.diameter.org (8.11.3/8.11.3) with ESMTP id f342UmF29977 for ; Tue, 3 Apr 2001 19:30:48 -0700 Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax1.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f341eOg00104 for ; Tue, 3 Apr 2001 20:40:24 -0500 (CDT) Received: from daebh02nok.americas.nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Tue, 3 Apr 2001 20:39:49 -0500 Received: by daebh02nok with Internet Mail Service (5.5.2652.78) id ; Tue, 3 Apr 2001 20:39:49 -0500 Message-ID: From: rajeev.koodli@nokia.com To: tmima@cisco.com, mccap@research.bell-labs.com Cc: kempf@heliopolis.Eng.Sun.COM, mobile-ip@sunroof.eng.sun.com, rohc@cdt.luth.se, seamoby@diameter.org Subject: RE: [seamoby] RE: [rohc] RE: Restarting Compressor on Mobile IPv6 Handover Date: Tue, 3 Apr 2001 20:39:49 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-seamoby@diameter.org Precedence: bulk Hello Tmima, some comments below. Regards, -Rajeev > -----Original Message----- > From: ext Tmima Koren [mailto:tmima@cisco.com] > Sent: Tuesday, April 03, 2001 6:19 PM > To: rajeev.koodli@nokia.com; mccap@research.bell-labs.com; > rajeev.koodli@nokia.com > Cc: kempf@heliopolis.Eng.Sun.COM; mobile-ip@sunroof.eng.sun.com; > rohc@cdt.luth.se; seamoby@diameter.org > Subject: RE: [seamoby] RE: [rohc] RE: Restarting Compressor on Mobile > IPv6 Handover > > > I wonder if it's possible to do both: > The new router sends a request for context transfer, but continues to > forward the compressed packets to the old router, AND queues > a copy of the > packets he forwarded. Once he receives the context, the new > router applies > the necessary changes to the context from the queued packets. Now his > context is good and he can continue decompressing. > Tmima > It may be possible to do both, perhaps should not be necessary. One of the requirements for seamoby will be to meet a fast response time requirement that would mean that the context has to be present at the new router when compressed packets arrive. In your proposal, I also see the need for synchronizing (more than one) compressed buffered packets with the context that arrives later. This may be non-trivial. Regards, -Rajeev > At 07:58 PM 4/3/2001 -0500, rajeev.koodli@nokia.com wrote: > > > -----Original Message----- > > > From: ext Pete McCann [mailto:mccap@research.bell-labs.com] > > > Sent: Tuesday, April 03, 2001 5:30 PM > > > To: rajeev.koodli@nokia.com > > > Cc: kempf@heliopolis.Eng.Sun.COM; mobile-ip@sunroof.eng.sun.com; > > > rohc@cdt.luth.se; seamoby@diameter.org > > > Subject: RE: [seamoby] RE: [rohc] RE: Restarting > Compressor on Mobile > > > IPv6 Handover > > > > > > > > > > > > > > > Yes, you would need to re-initialize the context over the > air, but I > > > don't think the bandwidth usage is high enough to matter. In a > > > wide-area cellular environment IP handoffs will be relatively > > > infrequent. The important consideration is the "glitch" > experienced > > > in voice traffic at handoff time, and this can be minimized by > > > temporarily anchoring the compressor. > > > > > > >I don't agree with you comments that you could ignore > bandwidth usage and > >assume infrequent handovers. > > > >a> 84 bytes of IPv6/UDP/RTP headers with Mobile-IPv6 Home > Address option for > >a voice payload of 20 - 30 bytes. Several such packets sent > per each stream. > > > >b> With fast user mobility, each BTS/AP being a router, I can imagine > >frequent handovers. > > > >In any case, context relocation addresses a>, does not > assume infrequent > >handovers, as well as attempts to provide "glitch-free" > voice. When the > >context is already present at the target router before the > MN starts sending > >compressed packets, the application should not see the glitch. > >I know there is work to be done here, so let's try to focus on that! > > > >Regards, > > > >-Rajeev > > > > > > > -Pete > > > > > > rajeev.koodli@nokia.com (rk) writes: > > > > > > rk> Hi, > > > > > > rk> How does this avoid the core problem of context > > > rk> _re-initialization_ ? You would still need to send IR > packets (to > > > rk> new access router over the air interface) subsequent > to handover > > > rk> in order to start a new context.. Anchoring it at > the previous > > > rk> router may buy you some time, but not the bits. I reckon > > > rk> anchoring will bring its own set of problems. > > > > > > rk> Regards, > > > > > > rk> -Rajeev > > > > > > > > > >> -----Original Message----- > > > >> From: ext Pete McCann [mailto:mccap@research.bell-labs.com] > > > >> Sent: Tuesday, April 03, 2001 11:32 AM > > > >> To: kempf@heliopolis.Eng.Sun.COM > > > >> Cc: mobile-ip@sunroof.eng.sun.com; rohc@cdt.luth.se; > > > >> seamoby@diameter.org > > > >> Subject: RE: [seamoby] RE: [rohc] RE: Restarting > > > Compressor on Mobile > > > >> IPv6 Handover > > > >> > > > >> > > > >> > > > >> Hi, > > > >> > > > >> I think there is a simpler solution to this problem that > > > most people > > > >> are overlooking. > > > >> > > > >> It should be possible to keep the compressor/decompressor > > > state at the > > > >> old access router and to tunnel the already-compressed > > > packets to and > > > >> from the new access router. Then the MN and new > access router can > > > >> renegotiate header compression state from scratch and take > > > as long as > > > >> they want to do so, because the MN is still getting > service in the > > > >> meantime. > > > >> > > > >> Someone earlier asked about support for ROHC on IP tunnels > > > and I think > > > >> this would be a good application for that. > > > >> > > > >> We are trying to move the mountain to Mohammed and I don't > > > see why we > > > >> can't do the reverse instead. > > > >> > > > >> -Pete > > > >> > > > >> > > > >> --- > > > >> Mailing list for Robust Header Compression WG > > > >> Archive: http://www.cdt.luth.se/rohc/ > > > >> > > > rk> --- > > > rk> Mailing list for Robust Header Compression WG > > > rk> Archive: http://www.cdt.luth.se/rohc/ > > > > From owner-seamoby@diameter.org Wed Apr 4 01:55:18 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA02560 for ; Wed, 4 Apr 2001 01:55:17 -0400 (EDT) Received: (from majordomo@localhost) by charizard.diameter.org (8.11.3/8.11.3) id f3457uB32133 for seamoby-list; Tue, 3 Apr 2001 22:07:56 -0700 X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216]) by charizard.diameter.org (8.11.3/8.11.3) with ESMTP id f3456iF32128 for ; Tue, 3 Apr 2001 22:06:44 -0700 Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax1.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f344G8g02576 for ; Tue, 3 Apr 2001 23:16:09 -0500 (CDT) Received: from daebh01nok.americas.nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Tue, 3 Apr 2001 23:15:35 -0500 Received: by daebh01nok with Internet Mail Service (5.5.2652.78) id ; Tue, 3 Apr 2001 23:15:35 -0500 Message-ID: <8572CF1E2A95D211A1190008C7EAA246027208F3@daeis05nok> From: khiem.le@nokia.com To: tmima@cisco.com, rajeev.koodli@nokia.com, mccap@research.bell-labs.com, rajeev.koodli@nokia.com Cc: kempf@heliopolis.Eng.Sun.COM, mobile-ip@sunroof.eng.sun.com, rohc@cdt.luth.se, seamoby@diameter.org Subject: RE: [seamoby] RE: [rohc] RE: Restarting Compressor on Mobile IPv6 Handover Date: Tue, 3 Apr 2001 23:15:33 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-seamoby@diameter.org Precedence: bulk Hello Tmima, Your idea is very similar to the one I had some time ago (refer to http://www.cdt.luth.se/robhc/msg01274.html). Essentially the idea is to relax the timing constraints and allow some time to establish the context at the new compressor/decompressor. During that context establishment time, the packets transit through the new compressor/decompressor, but also transit through the old which continues to do compression/decompression. Once the context is established, the new can take over the compression/decompression process. The old compressor/decompressor helps the new compressor/decompressor establish its context by sending some context information. One way (as you described, correct me if I am wrong) is to take a snapshot of the context and send it. To maintain context synchronization between the old and new, the new may do some update of the received context snapshot to account for the fact that the context may have been updated by the old after it took the snapshot. However, the problem is that packets may be lost when sent from the old to the new. So the new may do a context update based on packet j, but that update was not done by the old, since packet j was never received by the old. One way to solve this problem is to modify the mechanism to send the context information from old to new. Instead of sending a context snapshot, the old sends the context-related information in pieces, so the new can gradually build up its context. This corresponds to the Relocation-deferred-after-Link-Switching (RDLS)scheme in http://www.cdt.luth.se/robhc/msg01274.html. You can look at it for details. The case where the old takes a snapshot of its context and sends to the new for immediate transfer of compression/decompression role corresponds to Relocation-concurrent-with-Link-Switching (RCLS). RDLS addresses the timing problem in a very reliable manner, but is more complex than RCLS. It also requires a higher capacity connection between the old and new. So each approach has its pros and cons. In any case, I believe the context transfer (whether RCLS or RDLS) is doable, and the advantages over brute force reinitialization over the wireless link outweigh the costs. Khiem > -----Original Message----- > From: ext Tmima Koren [mailto:tmima@cisco.com] > Sent: Tuesday, April 03, 2001 8:19 PM > To: rajeev.koodli@nokia.com; mccap@research.bell-labs.com; > rajeev.koodli@nokia.com > Cc: kempf@heliopolis.Eng.Sun.COM; mobile-ip@sunroof.eng.sun.com; > rohc@cdt.luth.se; seamoby@diameter.org > Subject: RE: [seamoby] RE: [rohc] RE: Restarting Compressor on Mobile > IPv6 Handover > > > I wonder if it's possible to do both: > The new router sends a request for context transfer, but continues to > forward the compressed packets to the old router, AND queues > a copy of the > packets he forwarded. Once he receives the context, the new > router applies > the necessary changes to the context from the queued packets. Now his > context is good and he can continue decompressing. > Tmima > > At 07:58 PM 4/3/2001 -0500, rajeev.koodli@nokia.com wrote: > > > -----Original Message----- > > > From: ext Pete McCann [mailto:mccap@research.bell-labs.com] > > > Sent: Tuesday, April 03, 2001 5:30 PM > > > To: rajeev.koodli@nokia.com > > > Cc: kempf@heliopolis.Eng.Sun.COM; mobile-ip@sunroof.eng.sun.com; > > > rohc@cdt.luth.se; seamoby@diameter.org > > > Subject: RE: [seamoby] RE: [rohc] RE: Restarting > Compressor on Mobile > > > IPv6 Handover > > > > > > > > > > > > > > > Yes, you would need to re-initialize the context over the > air, but I > > > don't think the bandwidth usage is high enough to matter. In a > > > wide-area cellular environment IP handoffs will be relatively > > > infrequent. The important consideration is the "glitch" > experienced > > > in voice traffic at handoff time, and this can be minimized by > > > temporarily anchoring the compressor. > > > > > > >I don't agree with you comments that you could ignore > bandwidth usage and > >assume infrequent handovers. > > > >a> 84 bytes of IPv6/UDP/RTP headers with Mobile-IPv6 Home > Address option for > >a voice payload of 20 - 30 bytes. Several such packets sent > per each stream. > > > >b> With fast user mobility, each BTS/AP being a router, I can imagine > >frequent handovers. > > > >In any case, context relocation addresses a>, does not > assume infrequent > >handovers, as well as attempts to provide "glitch-free" > voice. When the > >context is already present at the target router before the > MN starts sending > >compressed packets, the application should not see the glitch. > >I know there is work to be done here, so let's try to focus on that! > > > >Regards, > > > >-Rajeev > > > > > > > -Pete > > > > > > rajeev.koodli@nokia.com (rk) writes: > > > > > > rk> Hi, > > > > > > rk> How does this avoid the core problem of context > > > rk> _re-initialization_ ? You would still need to send IR > packets (to > > > rk> new access router over the air interface) subsequent > to handover > > > rk> in order to start a new context.. Anchoring it at > the previous > > > rk> router may buy you some time, but not the bits. I reckon > > > rk> anchoring will bring its own set of problems. > > > > > > rk> Regards, > > > > > > rk> -Rajeev > > > > > > > > > >> -----Original Message----- > > > >> From: ext Pete McCann [mailto:mccap@research.bell-labs.com] > > > >> Sent: Tuesday, April 03, 2001 11:32 AM > > > >> To: kempf@heliopolis.Eng.Sun.COM > > > >> Cc: mobile-ip@sunroof.eng.sun.com; rohc@cdt.luth.se; > > > >> seamoby@diameter.org > > > >> Subject: RE: [seamoby] RE: [rohc] RE: Restarting > > > Compressor on Mobile > > > >> IPv6 Handover > > > >> > > > >> > > > >> > > > >> Hi, > > > >> > > > >> I think there is a simpler solution to this problem that > > > most people > > > >> are overlooking. > > > >> > > > >> It should be possible to keep the compressor/decompressor > > > state at the > > > >> old access router and to tunnel the already-compressed > > > packets to and > > > >> from the new access router. Then the MN and new > access router can > > > >> renegotiate header compression state from scratch and take > > > as long as > > > >> they want to do so, because the MN is still getting > service in the > > > >> meantime. > > > >> > > > >> Someone earlier asked about support for ROHC on IP tunnels > > > and I think > > > >> this would be a good application for that. > > > >> > > > >> We are trying to move the mountain to Mohammed and I don't > > > see why we > > > >> can't do the reverse instead. > > > >> > > > >> -Pete > > > >> > > > >> > > > >> --- > > > >> Mailing list for Robust Header Compression WG > > > >> Archive: http://www.cdt.luth.se/rohc/ > > > >> > > > rk> --- > > > rk> Mailing list for Robust Header Compression WG > > > rk> Archive: http://www.cdt.luth.se/rohc/ > > > > > --- > Mailing list for Robust Header Compression WG > Archive: http://www.cdt.luth.se/rohc/ > From owner-seamoby@diameter.org Wed Apr 4 06:42:05 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA12909 for ; Wed, 4 Apr 2001 06:42:05 -0400 (EDT) Received: (from majordomo@localhost) by charizard.diameter.org (8.11.3/8.11.3) id f349mNH32653 for seamoby-list; Wed, 4 Apr 2001 02:48:23 -0700 X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f Received: from c007.snv.cp.net (c007-h011.c007.snv.cp.net [209.228.33.217]) by charizard.diameter.org (8.11.3/8.11.3) with SMTP id f349mLF32648 for ; Wed, 4 Apr 2001 02:48:21 -0700 Received: (cpmta 24904 invoked from network); 4 Apr 2001 01:57:48 -0700 Received: from dsl-64-193-0-129.telocity.com (HELO philneum) (64.193.0.129) by smtp.telocity.com (209.228.33.217) with SMTP; 4 Apr 2001 01:57:48 -0700 X-Sent: 4 Apr 2001 08:57:48 GMT Message-ID: <00f201c0bce5$2dc08be0$6501a8c0@philneum> Reply-To: "Phil Neumiller" From: "Phil Neumiller" To: , , , Cc: , , , References: <8572CF1E2A95D211A1190008C7EAA246027208F3@daeis05nok> Subject: Re: [seamoby] RE: [rohc] RE: Restarting Compressor on Mobile IPv6 Handover Date: Wed, 4 Apr 2001 03:56:32 -0500 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-seamoby@diameter.org Precedence: bulk Of coures I like make-before-break and Moore's law and run two compressors in the MN and discard one when I no longer need it. -pdn ;-) ----- Original Message ----- > Hello Tmima, > > Your idea is very similar to the one I had some time ago (refer to > http://www.cdt.luth.se/robhc/msg01274.html). > From owner-seamoby@diameter.org Wed Apr 4 08:52:25 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA16713 for ; Wed, 4 Apr 2001 08:52:24 -0400 (EDT) Received: (from majordomo@localhost) by charizard.diameter.org (8.11.3/8.11.3) id f34CQeV00693 for seamoby-list; Wed, 4 Apr 2001 05:26:40 -0700 X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f Received: from atlsnmx1.nextel.com (atlsnmx1.nextel.com [167.20.198.200]) by charizard.diameter.org (8.11.3/8.11.3) with ESMTP id f34CQcF00688 for ; Wed, 4 Apr 2001 05:26:38 -0700 Received: from atlntgw01.nextel.com (atlntgw01.nextel.com [10.8.79.187]) by atlsnmx1.nextel.com (8.8.8+Sun/8.8.6) with ESMTP id HAA19711; Wed, 4 Apr 2001 07:32:15 -0400 (EDT) Received: by atlntgw01.nextel.com with Internet Mail Service (5.5.2650.21) id <2GYMVLXW>; Wed, 4 Apr 2001 07:32:39 -0400 Message-ID: <020A5EC56F3FD411B5230008C716D0858685AF@nhqntex01.nextel.com> From: "Martin, David P" To: "'khiem.le@nokia.com'" , tmima@cisco.com, rajeev.koodli@nokia.com, mccap@research.bell-labs.com, rajeev.koodli@nokia.com Cc: kempf@heliopolis.Eng.Sun.COM, mobile-ip@sunroof.eng.sun.com, rohc@cdt.luth.se, seamoby@diameter.org Subject: RE: [seamoby] RE: [rohc] RE: Restarting Compressor on Mobile IPv6 Handover Date: Wed, 4 Apr 2001 07:27:22 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-seamoby@diameter.org Precedence: bulk >In any case, I believe the context transfer (whether RCLS or RDLS) is >doable, and the advantages over brute force reinitialization over the >wireless link outweigh the costs. > >Khiem Why shouldn't the protocol support both methods and let the implementors choose the approrpriate solution for their networks? From owner-seamoby@diameter.org Wed Apr 4 11:23:18 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA22948 for ; Wed, 4 Apr 2001 11:23:15 -0400 (EDT) Received: (from majordomo@localhost) by charizard.diameter.org (8.11.3/8.11.3) id f34ExjT01042 for seamoby-list; Wed, 4 Apr 2001 07:59:45 -0700 X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f Received: from zcars04f.ca.nortel.com (zcars04f.nortelnetworks.com [47.129.242.57]) by charizard.diameter.org (8.11.3/8.11.3) with ESMTP id f34ExgF01037 for ; Wed, 4 Apr 2001 07:59:42 -0700 Received: from zcard015.ca.nortel.com by zcars04f.ca.nortel.com; Wed, 4 Apr 2001 09:46:52 -0400 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 4 Apr 2001 09:46:52 -0400 Message-ID: <13E2EF604DE5D111B2E50000F80824E8057A8ECE@zwdld001.ca.nortel.com> From: "Gary Kenward" To: "'khiem.le@nokia.com'" , tmima@cisco.com, mccap@research.bell-labs.com, rajeev.koodli@nokia.com Cc: kempf@heliopolis.Eng.Sun.COM, mobile-ip@sunroof.eng.sun.com, rohc@cdt.luth.se, seamoby@diameter.org Subject: RE: [seamoby] RE: [rohc] RE: Restarting Compressor on Mobile IPv6 Handover Date: Wed, 4 Apr 2001 09:46:47 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0BD0D.B1A3F230" X-Orig: Sender: owner-seamoby@diameter.org Precedence: bulk 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_01C0BD0D.B1A3F230 Content-Type: text/plain; charset="iso-8859-1" Many real time context synchronization problems can be solved through "bi-casting", which is, I believe, the essence of what you describe. Gary > -----Original Message----- > From: khiem.le@nokia.com [mailto:khiem.le@nokia.com] > Sent: Wednesday, April 04, 2001 12:16 AM > To: tmima@cisco.com; rajeev.koodli@nokia.com; > mccap@research.bell-labs.com; rajeev.koodli@nokia.com > Cc: kempf@heliopolis.Eng.Sun.COM; mobile-ip@sunroof.eng.sun.com; > rohc@cdt.luth.se; seamoby@diameter.org > Subject: RE: [seamoby] RE: [rohc] RE: Restarting Compressor on Mobile > IPv6 Handover > > > Hello Tmima, > > Your idea is very similar to the one I had some time ago (refer to > http://www.cdt.luth.se/robhc/msg01274.html). > > Essentially the idea is to relax the timing constraints and > allow some time > to establish the context at the new compressor/decompressor. > During that > context establishment time, the packets transit through the new > compressor/decompressor, but also transit through the old > which continues to > do compression/decompression. Once the context is > established, the new can > take over the compression/decompression process. > > The old compressor/decompressor helps the new compressor/decompressor > establish its context by sending some context information. > One way (as you > described, correct me if I am wrong) is to take a snapshot of > the context > and send it. To maintain context synchronization between the > old and new, > the new may do some update of the received context snapshot > to account for > the fact that the context may have been updated by the old > after it took the > snapshot. However, the problem is that packets may be lost > when sent from > the old to the new. So the new may do a context update based > on packet j, > but that update was not done by the old, since packet j was > never received > by the old. One way to solve this problem is to modify the > mechanism to send > the context information from old to new. Instead of sending a context > snapshot, the old sends the context-related information in > pieces, so the > new can gradually build up its context. This corresponds to the > Relocation-deferred-after-Link-Switching (RDLS)scheme in > http://www.cdt.luth.se/robhc/msg01274.html. You can look at > it for details. > > The case where the old takes a snapshot of its context and > sends to the new > for immediate transfer of compression/decompression role > corresponds to > Relocation-concurrent-with-Link-Switching (RCLS). > > RDLS addresses the timing problem in a very reliable manner, > but is more > complex than RCLS. It also requires a higher capacity > connection between the > old and new. So each approach has its pros and cons. > > In any case, I believe the context transfer (whether RCLS or RDLS) is > doable, and the advantages over brute force reinitialization over the > wireless link outweigh the costs. > > Khiem > > > -----Original Message----- > > From: ext Tmima Koren [mailto:tmima@cisco.com] > > Sent: Tuesday, April 03, 2001 8:19 PM > > To: rajeev.koodli@nokia.com; mccap@research.bell-labs.com; > > rajeev.koodli@nokia.com > > Cc: kempf@heliopolis.Eng.Sun.COM; mobile-ip@sunroof.eng.sun.com; > > rohc@cdt.luth.se; seamoby@diameter.org > > Subject: RE: [seamoby] RE: [rohc] RE: Restarting Compressor > on Mobile > > IPv6 Handover > > > > > > I wonder if it's possible to do both: > > The new router sends a request for context transfer, but > continues to > > forward the compressed packets to the old router, AND queues > > a copy of the > > packets he forwarded. Once he receives the context, the new > > router applies > > the necessary changes to the context from the queued > packets. Now his > > context is good and he can continue decompressing. > > Tmima > > > > At 07:58 PM 4/3/2001 -0500, rajeev.koodli@nokia.com wrote: > > > > -----Original Message----- > > > > From: ext Pete McCann [mailto:mccap@research.bell-labs.com] > > > > Sent: Tuesday, April 03, 2001 5:30 PM > > > > To: rajeev.koodli@nokia.com > > > > Cc: kempf@heliopolis.Eng.Sun.COM; mobile-ip@sunroof.eng.sun.com; > > > > rohc@cdt.luth.se; seamoby@diameter.org > > > > Subject: RE: [seamoby] RE: [rohc] RE: Restarting > > Compressor on Mobile > > > > IPv6 Handover > > > > > > > > > > > > > > > > > > > > Yes, you would need to re-initialize the context over the > > air, but I > > > > don't think the bandwidth usage is high enough to matter. In a > > > > wide-area cellular environment IP handoffs will be relatively > > > > infrequent. The important consideration is the "glitch" > > experienced > > > > in voice traffic at handoff time, and this can be minimized by > > > > temporarily anchoring the compressor. > > > > > > > > > >I don't agree with you comments that you could ignore > > bandwidth usage and > > >assume infrequent handovers. > > > > > >a> 84 bytes of IPv6/UDP/RTP headers with Mobile-IPv6 Home > > Address option for > > >a voice payload of 20 - 30 bytes. Several such packets sent > > per each stream. > > > > > >b> With fast user mobility, each BTS/AP being a router, I > can imagine > > >frequent handovers. > > > > > >In any case, context relocation addresses a>, does not > > assume infrequent > > >handovers, as well as attempts to provide "glitch-free" > > voice. When the > > >context is already present at the target router before the > > MN starts sending > > >compressed packets, the application should not see the glitch. > > >I know there is work to be done here, so let's try to > focus on that! > > > > > >Regards, > > > > > >-Rajeev > > > > > > > > > > -Pete > > > > > > > > rajeev.koodli@nokia.com (rk) writes: > > > > > > > > rk> Hi, > > > > > > > > rk> How does this avoid the core problem of context > > > > rk> _re-initialization_ ? You would still need to send IR > > packets (to > > > > rk> new access router over the air interface) subsequent > > to handover > > > > rk> in order to start a new context.. Anchoring it at > > the previous > > > > rk> router may buy you some time, but not the bits. I reckon > > > > rk> anchoring will bring its own set of problems. > > > > > > > > rk> Regards, > > > > > > > > rk> -Rajeev > > > > > > > > > > > > >> -----Original Message----- > > > > >> From: ext Pete McCann [mailto:mccap@research.bell-labs.com] > > > > >> Sent: Tuesday, April 03, 2001 11:32 AM > > > > >> To: kempf@heliopolis.Eng.Sun.COM > > > > >> Cc: mobile-ip@sunroof.eng.sun.com; rohc@cdt.luth.se; > > > > >> seamoby@diameter.org > > > > >> Subject: RE: [seamoby] RE: [rohc] RE: Restarting > > > > Compressor on Mobile > > > > >> IPv6 Handover > > > > >> > > > > >> > > > > >> > > > > >> Hi, > > > > >> > > > > >> I think there is a simpler solution to this problem that > > > > most people > > > > >> are overlooking. > > > > >> > > > > >> It should be possible to keep the compressor/decompressor > > > > state at the > > > > >> old access router and to tunnel the already-compressed > > > > packets to and > > > > >> from the new access router. Then the MN and new > > access router can > > > > >> renegotiate header compression state from scratch and take > > > > as long as > > > > >> they want to do so, because the MN is still getting > > service in the > > > > >> meantime. > > > > >> > > > > >> Someone earlier asked about support for ROHC on IP tunnels > > > > and I think > > > > >> this would be a good application for that. > > > > >> > > > > >> We are trying to move the mountain to Mohammed and I don't > > > > see why we > > > > >> can't do the reverse instead. > > > > >> > > > > >> -Pete > > > > >> > > > > >> > > > > >> --- > > > > >> Mailing list for Robust Header Compression WG > > > > >> Archive: http://www.cdt.luth.se/rohc/ > > > > >> > > > > rk> --- > > > > rk> Mailing list for Robust Header Compression WG > > > > rk> Archive: http://www.cdt.luth.se/rohc/ > > > > > > > > --- > > Mailing list for Robust Header Compression WG > > Archive: http://www.cdt.luth.se/rohc/ > > > ------_=_NextPart_001_01C0BD0D.B1A3F230 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [seamoby] RE: [rohc] RE: Restarting Compressor on Mobile = IPv6 Handover

Many real time context synchronization problems can = be solved
through "bi-casting", which is, I believe, = the essence of what you
describe.

Gary

> -----Original Message-----
> From: khiem.le@nokia.com [mailto:khiem.le@nokia.com]=
> Sent: Wednesday, April 04, 2001 12:16 AM
> To: tmima@cisco.com; = rajeev.koodli@nokia.com;
> mccap@research.bell-labs.com; = rajeev.koodli@nokia.com
> Cc: kempf@heliopolis.Eng.Sun.COM; = mobile-ip@sunroof.eng.sun.com;
> rohc@cdt.luth.se; seamoby@diameter.org
> Subject: RE: [seamoby] RE: [rohc] RE: = Restarting Compressor on Mobile
> IPv6 Handover
>
>
> Hello Tmima,
>
> Your idea is very similar to the one I had some = time ago (refer to
> http://www.cdt.luth.se/robhc/msg01274.html).
>
> Essentially the idea is to relax the timing = constraints and
> allow some time
> to establish the context at the new = compressor/decompressor.
> During that
> context establishment time, the packets transit = through the new
> compressor/decompressor, but also transit = through the old
> which continues to
> do compression/decompression. Once the context = is
> established, the new can
> take over the compression/decompression = process.
>
> The old compressor/decompressor helps the new = compressor/decompressor
> establish its context by sending some context = information.
> One way (as you
> described, correct me if I am wrong) is to take = a snapshot of
> the context
> and send it. To maintain context = synchronization between the
> old and new,
> the new may do some update of the received = context snapshot
> to account for
> the fact that the context may have been updated = by the old
> after it took the
> snapshot. However, the problem is that packets = may be lost
> when sent from
> the old to the new. So the new may do a context = update based
> on packet j,
> but that update was not done by the old, since = packet j was
> never received
> by the old. One way to solve this problem is to = modify the
> mechanism to send
> the context information from old to new. = Instead of sending a context
> snapshot, the old sends the context-related = information in
> pieces, so the
> new can gradually build up its context. This = corresponds to the
> Relocation-deferred-after-Link-Switching = (RDLS)scheme in
> http://www.cdt.luth.se/robhc/msg01274.html. You = can look at
> it for details.
>
> The case where the old takes a snapshot of its = context and
> sends to the new
> for immediate transfer of = compression/decompression role
> corresponds to
> Relocation-concurrent-with-Link-Switching = (RCLS).
>
> RDLS addresses the timing problem in a very = reliable manner,
> but is more
> complex than RCLS. It also requires a higher = capacity
> connection between the
> old and new. So each approach has its pros and = cons.
>
> In any case, I believe the context transfer = (whether RCLS or RDLS) is
> doable, and the advantages over brute force = reinitialization over the
> wireless link outweigh the costs.
>
> Khiem
>
> > -----Original Message-----
> > From: ext Tmima Koren [mailto:tmima@cisco.com]
> > Sent: Tuesday, April 03, 2001 8:19 = PM
> > To: rajeev.koodli@nokia.com; = mccap@research.bell-labs.com;
> > rajeev.koodli@nokia.com
> > Cc: kempf@heliopolis.Eng.Sun.COM; = mobile-ip@sunroof.eng.sun.com;
> > rohc@cdt.luth.se; = seamoby@diameter.org
> > Subject: RE: [seamoby] RE: [rohc] RE: = Restarting Compressor
> on Mobile
> > IPv6 Handover
> >
> >
> > I wonder if it's possible to do = both:
> > The new router sends a request for context = transfer, but
> continues to
> > forward the compressed packets to the old = router, AND queues
> > a copy of the
> > packets he forwarded. Once he receives the = context, the new
> > router applies
> > the necessary changes to the context from = the queued
> packets. Now his
> > context is good and he can continue = decompressing.
> > Tmima
> >
> > At 07:58 PM 4/3/2001 -0500, = rajeev.koodli@nokia.com wrote:
> > > > -----Original = Message-----
> > > > From: ext Pete McCann [mailto:mccap@research.bell-= labs.com]
> > > > Sent: Tuesday, April 03, 2001 = 5:30 PM
> > > > To: = rajeev.koodli@nokia.com
> > > > Cc: = kempf@heliopolis.Eng.Sun.COM; mobile-ip@sunroof.eng.sun.com;
> > > > rohc@cdt.luth.se; = seamoby@diameter.org
> > > > Subject: RE: [seamoby] RE: = [rohc] RE: Restarting
> > Compressor on Mobile
> > > > IPv6 Handover
> > > >
> > > >
> > > >
> > > >
> > > > Yes, you would need to = re-initialize the context over the
> > air, but I
> > > > don't think the bandwidth usage = is high enough to matter.  In a
> > > > wide-area cellular environment = IP handoffs will be relatively
> > > > infrequent.  The important = consideration is the "glitch"
> > experienced
> > > > in voice traffic at handoff = time, and this can be minimized by
> > > > temporarily anchoring the = compressor.
> > > >
> > >
> > >I don't agree with you comments that = you could ignore
> > bandwidth usage and
> > >assume infrequent handovers.
> > >
> > >a> 84 bytes of IPv6/UDP/RTP headers = with Mobile-IPv6 Home
> > Address option for
> > >a voice payload of 20 - 30 bytes. = Several such packets sent
> > per each stream.
> > >
> > >b> With fast user mobility, each = BTS/AP being a router, I
> can imagine
> > >frequent handovers.
> > >
> > >In any case, context relocation = addresses a>, does not
> > assume infrequent
> > >handovers, as well as attempts to = provide "glitch-free"
> > voice. When the
> > >context is already present at the = target router before the
> > MN starts sending
> > >compressed packets, the application = should not see the glitch.
> > >I know there is work to be done here, = so let's try to
> focus on that!
> > >
> > >Regards,
> > >
> > >-Rajeev
> > >
> > >
> > > > -Pete
> > > >
> > > > rajeev.koodli@nokia.com (rk) = writes:
> > > >
> > > > rk> Hi,
> > > >
> > > > rk> How does this avoid the = core problem of context
> > > > rk> _re-initialization_ ? You = would still need to send IR
> > packets (to
> > > > rk> new access router over = the air interface) subsequent
> > to handover
> > > > rk> in order to start a new = context..  Anchoring it at
> > the previous
> > > > rk> router may buy you some = time, but not the bits.  I reckon
> > > > rk> anchoring will bring its = own set of problems.
> > > >
> > > > rk> Regards,
> > > >
> > > > rk> -Rajeev
> > > >
> > > >
> > > > >> -----Original = Message-----
> > > > >> From: ext Pete McCann = [mailto:mccap@research.bell-= labs.com]
> > > > >> Sent: Tuesday, April = 03, 2001 11:32 AM
> > > > >> To: = kempf@heliopolis.Eng.Sun.COM
> > > > >> Cc: = mobile-ip@sunroof.eng.sun.com; rohc@cdt.luth.se;
> > > > >> = seamoby@diameter.org
> > > > >> Subject: RE: [seamoby] = RE: [rohc] RE: Restarting
> > > > Compressor on Mobile
> > > > >> IPv6 Handover
> > > > >>
> > > > >>
> > > > >>
> > > > >> Hi,
> > > > >>
> > > > >> I think there is a = simpler solution to this problem that
> > > > most people
> > > > >> are overlooking.
> > > > >>
> > > > >> It should be possible = to keep the compressor/decompressor
> > > > state at the
> > > > >> old access router and = to tunnel the already-compressed
> > > > packets to and
> > > > >> from the new access = router.  Then the MN and new
> > access router can
> > > > >> renegotiate header = compression state from scratch and take
> > > > as long as
> > > > >> they want to do so, = because the MN is still getting
> > service in the
> > > > >> meantime.
> > > > >>
> > > > >> Someone earlier asked = about support for ROHC on IP tunnels
> > > > and I think
> > > > >> this would be a good = application for that.
> > > > >>
> > > > >> We are trying to move = the mountain to Mohammed and I don't
> > > > see why we
> > > > >> can't do the reverse = instead.
> > > > >>
> > > > >> -Pete
> > > > >>
> > > > >>
> > > > >> ---
> > > > >> Mailing list for Robust = Header Compression WG
> > > > >> Archive: http://www.cdt.luth.se/rohc/
> > > > >>
> > > > rk> ---
> > > > rk> Mailing list for Robust = Header Compression WG
> > > > rk> Archive: http://www.cdt.luth.se/rohc/
> > > >
> >
> > ---
> > Mailing list for Robust Header Compression = WG
> > Archive: http://www.cdt.luth.se/rohc/
> >
>

------_=_NextPart_001_01C0BD0D.B1A3F230-- From owner-seamoby@diameter.org Wed Apr 4 14:00:14 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA27554 for ; Wed, 4 Apr 2001 14:00:13 -0400 (EDT) Received: (from majordomo@localhost) by charizard.diameter.org (8.11.3/8.11.3) id f34HDkS02245 for seamoby-list; Wed, 4 Apr 2001 10:13:46 -0700 X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by charizard.diameter.org (8.11.3/8.11.3) with ESMTP id f34HDhF02240 for ; Wed, 4 Apr 2001 10:13:43 -0700 Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA13070 for ; Wed, 4 Apr 2001 09:23:17 -0700 (PDT) Received: from nasnfs.Eng.Sun.COM (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA13001; Wed, 4 Apr 2001 09:23:16 -0700 (PDT) Received: from darius (darius [10.6.84.105]) by nasnfs.Eng.Sun.COM (8.9.3+Sun/8.9.1) with SMTP id JAA24383; Wed, 4 Apr 2001 09:23:14 -0700 (PDT) Date: Wed, 4 Apr 2001 09:23:13 -0700 (PDT) From: Patrice Calhoun Reply-To: Patrice Calhoun Subject: [seamoby] Mail Server Administration today To: pcalhoun@eng.sun.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-seamoby@diameter.org Precedence: bulk All, I will be taking the mail server today between 1 and 5 PST for maintenance reasons. I will be moving from sendmail to qmail. The primary reason for this change is that sendmail is causing too much latency in the mailing lists. I have been debugging the problem, and the number of sendmail children is hitting the max, while the processes are stuck waiting for the other mail server to respond, and eventually timeout. My server, btw, is running at around 93% idle, even when the lists are busy, and my pipe still has plenty of bandwidth. Of course, the best fix is to delete lots of people from the mailing lists, but it isn't their fault that their mail server is broken. If you do send mail to either the Diameter, Seamoby (or any of the design team lists), you will most likely receive an unable to deliver message, but your mail server should keep retrying. I hope to have the work done prior to 5pm today, but need to keep a buffer. Thanks, PatC From owner-seamoby@diameter.org Wed Apr 4 14:16:38 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA27982 for ; Wed, 4 Apr 2001 14:16:34 -0400 (EDT) Received: (from majordomo@localhost) by charizard.diameter.org (8.11.3/8.11.3) id f34HV3302335 for seamoby-list; Wed, 4 Apr 2001 10:31:03 -0700 X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-seamoby@diameter.org using -f Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216]) by charizard.diameter.org (8.11.3/8.11.3) with ESMTP id f34HV1F02330 for ; Wed, 4 Apr 2001 10:31:01 -0700 Received: from davir03nok.americas.nokia.com (davir03nok.americas.nokia.com [172.18.242.86]) by mgw-dax1.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f34Gecg07648 for ; Wed, 4 Apr 2001 11:40:38 -0500 (CDT) Received: from daebh01nok.americas.nokia.com (unverified) by davir03nok.americas.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Wed, 4 Apr 2001 11:39:50 -0500 Received: by daebh01nok with Internet Mail Service (5.5.2652.78) id ; Wed, 4 Apr 2001 11:39:49 -0500 Message-ID: <8572CF1E2A95D211A1190008C7EAA246027208F9@daeis05nok> From: khiem.le@nokia.com To: neumiller@telocity.com, khiem.le@nokia.com, tmima@cisco.com, rajeev.koodli@nokia.com, mccap@research.bell-labs.com Cc: kempf@heliopolis.Eng.Sun.COM, mobile-ip@sunroof.eng.sun.com, rohc@cdt.luth.se, seamoby@diameter.org Subject: RE: [seamoby] RE: [rohc] RE: Restarting Compressor on Mobile IPv6 Handover Date: Wed, 4 Apr 2001 11:39:49 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-seamoby@diameter.org Precedence: bulk Hi, One of the main points of my proposal (RDLS case) is that the compression/decompression process in the MN is absolutely not affected by handoff. Actually it is not even aware handoff happened. So one compressor in the MN is enough.:-) Khiem > -----Original Message----- > From: ext Phil Neumiller [mailto:neumiller@telocity.com] > Sent: Wednesday, April 04, 2001 3:57 AM > To: khiem.le@nokia.com; tmima@cisco.com; rajeev.koodli@nokia.com; > mccap@research.bell-labs.com > Cc: kempf@heliopolis.Eng.Sun.COM; mobile-ip@sunroof.eng.sun.com; > rohc@cdt.luth.se; seamoby@diameter.org > Subject: Re: [seamoby] RE: [rohc] RE: Restarting Compressor on Mobile > IPv6 Handover > > > Of coures I like make-before-break and Moore's law and run two > compressors in the MN and discard one when I no longer need it. > > -pdn ;-) > > ----- Original Message ----- > Hello Tmima, > > > > Your idea is very similar to the one I had some time ago (refer to > > http://www.cdt.luth.se/robhc/msg01274.html). > > > > > From owner-seamoby@diameter.org Wed Apr 4 17:18:13 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA02142 for ; Wed, 4 Apr 2001 17:18:12 -0400 (EDT) Received: (qmail 3852 invoked by alias); 4 Apr 2001 22:07:10 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 3848 invoked by uid 200); 4 Apr 2001 22:07:09 -0000 Received: (qmail 3843 invoked from network); 4 Apr 2001 22:07:08 -0000 Received: from patan.sun.com (192.18.98.43) by c900656-a.plstn1.sfba.home.com with SMTP; 4 Apr 2001 22:07:08 -0000 Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA29368 for ; Wed, 4 Apr 2001 14:16:42 -0700 (PDT) Received: from nasnfs.Eng.Sun.COM (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA01024 for ; Wed, 4 Apr 2001 14:16:41 -0700 (PDT) Received: from darius (darius [10.6.84.105]) by nasnfs.Eng.Sun.COM (8.9.3+Sun/8.9.1) with SMTP id OAA29910 for ; Wed, 4 Apr 2001 14:16:40 -0700 (PDT) Date: Wed, 4 Apr 2001 14:16:39 -0700 (PDT) From: Patrice Calhoun Reply-To: Patrice Calhoun Subject: [seamoby] New Mail server software test To: seamoby@cdma-2000.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-seamoby@diameter.org Precedence: bulk All, If you've received this, the main seamoby list is now up and running. It should hopefully be much faster than the old sendmail code. PatC From owner-seamoby@diameter.org Wed Apr 4 19:06:24 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA04188 for ; Wed, 4 Apr 2001 19:06:24 -0400 (EDT) Received: (qmail 5453 invoked by alias); 4 Apr 2001 23:53:24 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 5418 invoked by uid 200); 4 Apr 2001 23:53:21 -0000 Received: (qmail 5387 invoked from network); 4 Apr 2001 23:53:14 -0000 Received: from patan.sun.com (192.18.98.43) by c900656-a.plstn1.sfba.home.com with SMTP; 4 Apr 2001 23:53:14 -0000 Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA03170; Wed, 4 Apr 2001 16:02:47 -0700 (PDT) Received: from nasnfs.Eng.Sun.COM (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA09245; Wed, 4 Apr 2001 16:02:47 -0700 (PDT) Received: from darius (darius [10.6.84.105]) by nasnfs.Eng.Sun.COM (8.9.3+Sun/8.9.1) with SMTP id QAA01833; Wed, 4 Apr 2001 16:02:44 -0700 (PDT) Date: Wed, 4 Apr 2001 16:02:43 -0700 (PDT) From: Patrice Calhoun Reply-To: Patrice Calhoun Subject: [seamoby] The Lists are now up!!! To: pcalhoun@eng.sun.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-seamoby@diameter.org Precedence: bulk All, As some of you may know, I switched over from sendmail to qmail to eliminate some of the performance problems we've been experiencing. All of the lists are now up and running, and have been down for the past 3 hours. I hope that performance will be better, but if anyone does see any problems, please send me a private e-mail. Your humble e-mail administrator, PatC From owner-seamoby@diameter.org Wed Apr 4 21:37:20 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA06684 for ; Wed, 4 Apr 2001 21:37:19 -0400 (EDT) Received: (qmail 10173 invoked by alias); 5 Apr 2001 02:24:02 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 10166 invoked by uid 200); 5 Apr 2001 02:24:01 -0000 Received: (qmail 10155 invoked from network); 5 Apr 2001 02:23:59 -0000 Received: from mailhost.iprg.nokia.com (205.226.5.12) by c900656-a.plstn1.sfba.home.com with SMTP; 5 Apr 2001 02:23:59 -0000 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 SAA28720; Wed, 4 Apr 2001 18:33:04 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f351X2C12009; Wed, 4 Apr 2001 18:33:02 -0700 X-mProtect: Wed, 4 Apr 2001 18:33:02 -0700 Nokia Silicon Valley Messaging Protection Received: from mvdhcp14166.americas.nokia.com (172.18.141.66, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(WTS.12.69) smtpd36poot; Wed, 04 Apr 2001 18:32:10 PDT Message-ID: <3ACBCAFF.A03747A@iprg.nokia.com> Date: Wed, 04 Apr 2001 18:31:43 -0700 From: Rajeev Koodli Reply-To: Rajeev.Koodli@nokia.com Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "'seamoby-context'" CC: seamoby@diameter.org Subject: [seamoby] Some generic requirements Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-seamoby@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit Hello Hamid and CT folks, Following the spirit of the discussion during the last conference call, I have tried to outline a few requirements, some stemming from header compression context relocation. Here they are, 1. A context MUST have an inter-operable representation. In other words, each context (carried in a context transfer protocol) must be able to, in a standard manner, indicate to the receiver what type of context it is. Representing contexts using well-known objects (such as IANA type numbers) should be considered to facilitate this inter-operability. 2. Each context definition MUST NOT introduce a transfer protocol of its own, in order to be useful. In other words, a context should be separable from the protocol used to carry it. 3. A context transfer protocol MUST have fast response time. Specifically, for some applications (such as header compression), the context needs to be present at the new access router almost as soon as the link-layer handover is considered complete. In other words, an application may start using the feature immediately after IP connectivity is established assuming that the relevant context is present. The absence of context in such scenarios may result in packet loss and expensive re-initialization overheads. 4. A context transfer protocol MUST introduce minimal signaling overhead. The overall number of messages, including those over the air interface and the wireline links, must be kept small. And, the sizes of those messages that are carried over an air interface must be kept small as well. Comments are welcome. Regards, -Rajeev From owner-seamoby@diameter.org Thu Apr 5 06:42:41 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA26698 for ; Thu, 5 Apr 2001 06:42:41 -0400 (EDT) Received: (qmail 13928 invoked by alias); 5 Apr 2001 11:31:50 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 13921 invoked by uid 200); 5 Apr 2001 11:31:50 -0000 Message-ID: <20010405113150.13920.qmail@charizard.diameter.org> Received: (qmail 13916 invoked from network); 5 Apr 2001 11:31:49 -0000 Received: from plmta00.chello.pl (213.46.248.62) by c900656-a.plstn1.sfba.home.com with SMTP; 5 Apr 2001 11:31:49 -0000 Received: from hetnet.nl ([213.93.48.181]) by plmta00.chello.pl (Post.Office MTA v3.5.3 release 223 ID# 0-0U10L2S100V35) with SMTP id pl for ; Thu, 5 Apr 2001 08:02:52 -0100 From: "Rita de Groot" To: Subject: [seamoby] huidziekte Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Date: Thu, 5 Apr 2001 11:00:23 +0200 Content-Transfer-Encoding: 8bit Sender: owner-seamoby@diameter.org Precedence: bulk Content-Transfer-Encoding: 8bit Vijf jaar voordat deze foto's werden genomen werd bij mij diagnose reumatische artritis gesteld en als zodanig ook behandeld. Niets hielp. Toen de ziekte zich zo manifesteerde zoals u hieronder kunt zien.......... http://www.naardedokter.com/testimonials/sys_lup_eryth.htm From owner-seamoby@diameter.org Thu Apr 5 10:27:45 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA03123 for ; Thu, 5 Apr 2001 10:27:44 -0400 (EDT) Received: (qmail 16114 invoked by alias); 5 Apr 2001 15:16:44 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 16108 invoked by uid 200); 5 Apr 2001 15:16:44 -0000 Received: (qmail 16101 invoked from network); 5 Apr 2001 15:16:41 -0000 Received: from patan.sun.com (192.18.98.43) by c900656-a.plstn1.sfba.home.com with SMTP; 5 Apr 2001 15:16:41 -0000 Received: from centralmail1.Central.Sun.COM ([129.147.62.10]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA05362; Thu, 5 Apr 2001 07:26:18 -0700 (PDT) Received: from esun1as-mm. (esun1as-mm.Central.Sun.COM [129.147.34.144]) by centralmail1.Central.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id IAA21528; Thu, 5 Apr 2001 08:26:17 -0600 (MDT) Received: from sunyata.sun.com by esun1as-mm. (SMI-8.6/SMI-SVR4) id IAA12198; Thu, 5 Apr 2001 08:29:58 -0600 Message-Id: <5.0.0.25.1.20010405230514.00a1d530@localhost> X-Sender: kempf@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Thu, 05 Apr 2001 23:21:23 +0900 To: seamoby@diameter.org From: James Kempf Subject: [seamoby] Response of Mobile Operator to Request for Info on Realistic Paging Cc: makin@isi.edu In-Reply-To: <10104051404.AA26183@maia.east.isi.edu> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-seamoby@diameter.org Precedence: bulk Okay, folks, I spoke with a mobile operator here at MWIF in Korea. Alessio, I'm really sorry they can't post themselves, but they generally don't hang out on specific IETF working group lists. One of them will be at IETF 51, and hopefully involved in a requirements discussion via email beforehand (as soon as we can set up the list), so you can ask him there if you think I'm making this up. Some background on the operator. The operator I talked with has had over 10 years of experience deploying GSM networks in Asia, and is a major technical contributor to a leading European cellular provider. He is very critical of the direction being taken by 3GPP, sees IETF as a promising possiblity to make the mobile Internet happen the way most IETFer's would like to see it happen. His view is therefore likely to be different from someone who thinks 3GPP is the bees knees, however, technically, this guy is at the top of the pack. He knows cellular. Anyway, I explained to him the problem statement, and that we were designing for a target network in which the HLR and VLR were replaced by mobile IP and AAA. That is to say, we are not just desiging for GPRS or 3GPP2 IOS because they already have solutions to this problem, however imperfect. His response was that it is important and necessary that no a priori connection be assumed between subnets and paging areas. Another example, not cited in the draft which came out in our conversation, involves overlapping paging areas. It is sometimes necessary to configure a paging area entirely within another paging area, due to hotspots where there are lots of mobile nodes in dormant mode. There absolutely cannot be any constraint as to subnet in this case, because the inner, donut hole may have an arbitrary relation to the subnets. BTW, I also asked him about the case where wCDMA allows a mobile node to have more than one paging identifier, and he said this was because the mobile node could be in soft handoff between two RNCs that were in two different location areas. It would therefore require a paging identifier for both. I suppose it is possible to spin this however you want if you do or don't believe the problem statement, but, to me, it seems a pretty clear endorsement of the problem statement. jak From owner-seamoby@diameter.org Thu Apr 5 12:32:38 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA07258 for ; Thu, 5 Apr 2001 12:32:27 -0400 (EDT) Received: (qmail 19585 invoked by alias); 5 Apr 2001 17:20:55 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 19579 invoked by uid 200); 5 Apr 2001 17:20:54 -0000 Received: (qmail 19574 invoked from network); 5 Apr 2001 17:20:53 -0000 Received: from ihemail2.lucent.com (HELO ihemail2.firewall.lucent.com) (192.11.222.163) by c900656-a.plstn1.sfba.home.com with SMTP; 5 Apr 2001 17:20:53 -0000 Received: from ihemail2.firewall.lucent.com (localhost [127.0.0.1]) by ihemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id MAA10136 for ; Thu, 5 Apr 2001 12:30:30 -0400 (EDT) Received: from uk0006exch001h.wins.lucent.com (h135-86-160-150.lucent.com [135.86.160.150]) by ihemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id MAA10107 for ; Thu, 5 Apr 2001 12:30:29 -0400 (EDT) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2650.21) id ; Thu, 5 Apr 2001 17:30:28 +0100 Message-ID: <976F7C55E3B2D111A0720008C728549C097CC30D@en0060exch001u.uk.lucent.com> From: "Casati, Alessio \(Alessio\)" To: "'James Kempf'" , seamoby@diameter.org Cc: makin@isi.edu Subject: RE: [seamoby] Response of Mobile Operator to Request for Info on Realistic Paging Date: Thu, 5 Apr 2001 17:27:56 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: owner-seamoby@diameter.org Precedence: bulk *Okay, folks, I spoke with a mobile operator here at MWIF in Korea. *Alessio, I'm really sorry they can't post themselves, but they *generally *don't hang out on specific IETF working group lists. One of *them will be *at IETF 51, and hopefully involved in a requirements discussion via *email beforehand (as soon as we can set up the list), so you *can ask him there *if you think I'm making this up. I don't think you are making this up. I think I need his e-mail address so that I'm enabled to ask him though. If I could have his name, I could also know how to start my message in a polite way. *Some background on the operator. I guess this is a man, not an operator... *The operator I talked with *has had over 10 *years of experience deploying GSM networks in Asia, and is a major *technical contributor to a leading European cellular provider. *He is very *critical of the direction being taken *by 3GPP, *sees IETF as a promising possiblity to make the *mobile Internet *happen the way most IETFer's would like to see it happen. Me too, but the mobile Inernet is not bound to configuring multiple subnets to a paging area. *His *view is therefore *likely to be different from someone who thinks 3GPP is the *bees knees, however, *technically, this guy is at the top of the pack. He knows cellular. This WG needs badly this sort of folks. He should be contributing more. *His response was that it is important and necessary that no a *priori connection *be assumed between subnets and paging areas. Another example, not *cited in the draft which came out in our conversation, *involves overlapping *paging areas. It is sometimes necessary to configure a paging *area entirely *within another paging area, due to hotspots where there are *lots of mobile *nodes in dormant mode. There absolutely cannot be any constraint as to *subnet in this case, because the inner, donut hole may have an *arbitrary *relation to the subnets. Yes, but IP does not care since these paging areas are used to establish a link. When the link is established, the mobile will be attached to the same point of the attachement to the internet where it was last attached at the last Mobile IP registration request. If this does not happen, it has to be considered a failure of the mobile IP model (and a MS or network misconfiguration). Infact, the home agent could never be assured to be sending data to the MN, when it tunnels to the FA. *BTW, I also asked him about the case where wCDMA allows a mobile node *to have more than one paging identifier, and he said this was because *the mobile node could be in soft handoff between two RNCs that were in *two different location areas. It would therefore require a *paging identifier *for both. So what? Are we discussing about the operation of WCMA or assessing a problem statement you are editor of? How does it relate to the topic at hand? Which is: "we need paging at level 3 since there can be more subnets mapped to a paging area". On this I fairly disagree. On this the guy you interviewed seem to agree instead, but you have not told us what is the benefit of such config. Yet. *I suppose it is possible to spin this however you want if you *do or don't *believe *the problem statement, but, to me, it seems a pretty clear *endorsement of *the problem statement. I cannot but abide by your thoughts, since you own them. I would however disagree on a non technical and technical grounds. 1) I don't think the IETF can work by receiving endorsements by some anonymous people... At least this is not in the process so far. We need technical discussion to happen. And the issuer of opinions must be identifiable via an email account. 2)If a single paging area maps to multiple subnets, then any incoming packet over any of those subnets will be sent eventually over a link linked to the same access net the user was previously attached to. It turns out that in mobile IP, if the user does not send a registration request that changes the subnet the COA is associated to, the packet will be incoming over the expected subnet. Otherwise mobile IP is not operating correctly. So: packet is iscoming on the correct subnet, the link is in the access net where the mobile was before it went asleep, as such there is no problem to be solved. If a packet is incoming at a subnet other that the one the mobile was attached to, it will be discarded. If the mobile is attached to another subnet but at the same access net as before, it must have sent a mobile IP registration request to get the COA moved to that subnet. best redards. alessio From owner-seamoby@diameter.org Thu Apr 5 13:18:43 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA08669 for ; Thu, 5 Apr 2001 13:18:39 -0400 (EDT) Received: (qmail 20525 invoked by alias); 5 Apr 2001 18:06:51 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 20519 invoked by uid 200); 5 Apr 2001 18:06:50 -0000 Received: (qmail 20514 invoked from network); 5 Apr 2001 18:06:49 -0000 Received: from sj-msg-core-1.cisco.com (171.71.163.11) by c900656-a.plstn1.sfba.home.com with SMTP; 5 Apr 2001 18:06:49 -0000 Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id KAA27244; Thu, 5 Apr 2001 10:15:59 -0700 (PDT) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id ADP30399; Thu, 5 Apr 2001 10:15:53 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id KAA05560; Thu, 5 Apr 2001 10:15:53 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15052.43081.261727.428743@thomasm-u1.cisco.com> Date: Thu, 5 Apr 2001 10:15:53 -0700 (PDT) To: "Casati, Alessio \(Alessio\)" Cc: "'James Kempf'" , seamoby@diameter.org Subject: RE: [seamoby] Response of Mobile Operator to Request for Info on Realistic Paging In-Reply-To: <976F7C55E3B2D111A0720008C728549C097CC30D@en0060exch001u.uk.lucent.com> References: <976F7C55E3B2D111A0720008C728549C097CC30D@en0060exch001u.uk.lucent.com> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-seamoby@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit Alessio, It's clear that you think that there is not a problem to be solved in the paging area. A consensus of people here disagree. There are lot of things that I think are useless and should not be done too, but there is little point to expending effort trying to stop something that already has consensus to go forward. The market will eventually decide who was right. In the mean time, if it's not your intention to just be disruptive to slow things down, it would nice to know that so that I don't have to make a new procmail recipe. Mike Casati, Alessio \(Alessio\) writes: > > *Okay, folks, I spoke with a mobile operator here at MWIF in Korea. > *Alessio, I'm really sorry they can't post themselves, but they > *generally > *don't hang out on specific IETF working group lists. One of > *them will be > *at IETF 51, and hopefully involved in a requirements discussion via > *email beforehand (as soon as we can set up the list), so you > *can ask him there > *if you think I'm making this up. > > I don't think you are making this up. I think I need his e-mail address > so that I'm enabled to ask him though. If I could have his name, I could > also know how to start my message in a polite way. > > *Some background on the operator. > > I guess this is a man, not an operator... > > *The operator I talked with > *has had over 10 > *years of experience deploying GSM networks in Asia, and is a major > *technical contributor to a leading European cellular provider. > *He is very > *critical of the direction being taken > *by 3GPP, > *sees IETF as a promising possiblity to make the > *mobile Internet > *happen the way most IETFer's would like to see it happen. > > Me too, but the mobile Inernet is not bound to configuring > multiple subnets to a paging area. > > *His > *view is therefore > *likely to be different from someone who thinks 3GPP is the > *bees knees, however, > *technically, this guy is at the top of the pack. He knows cellular. > > This WG needs badly this sort of folks. He should be contributing more. > > *His response was that it is important and necessary that no a > *priori connection > *be assumed between subnets and paging areas. Another example, not > *cited in the draft which came out in our conversation, > *involves overlapping > *paging areas. It is sometimes necessary to configure a paging > *area entirely > *within another paging area, due to hotspots where there are > *lots of mobile > *nodes in dormant mode. There absolutely cannot be any constraint as to > *subnet in this case, because the inner, donut hole may have an > *arbitrary > *relation to the subnets. > > Yes, but IP does not care since these paging areas are used to establish a > link. > When the link is established, the mobile will be attached to the same > point of the attachement to the internet where it was last attached > at the last Mobile IP registration request. If this does not happen, it has > to > be considered a failure of the mobile IP model (and a MS or network > misconfiguration). > Infact, the home agent could never be assured to be sending data to the MN, > when it tunnels to the FA. > > *BTW, I also asked him about the case where wCDMA allows a mobile node > *to have more than one paging identifier, and he said this was because > *the mobile node could be in soft handoff between two RNCs that were in > *two different location areas. It would therefore require a > *paging identifier > *for both. > > So what? Are we discussing about the operation of WCMA or assessing > a problem statement you are editor of? How does it relate > to the topic at hand? Which is: > > > "we need paging at level 3 since there can be more subnets mapped to > a paging area". > On this I fairly disagree. On this the guy you interviewed seem to agree > instead, but you have not told us what is the benefit of such config. > Yet. > > *I suppose it is possible to spin this however you want if you > *do or don't > *believe > *the problem statement, but, to me, it seems a pretty clear > *endorsement of > *the problem statement. > > I cannot but abide by your thoughts, since you own them. > > I would however disagree on a non technical and technical grounds. > > 1) I don't think the IETF can work by receiving endorsements by > some anonymous people... At least this is not in the process so > far. We need technical discussion to happen. And the issuer of opinions > must be identifiable via an email account. > > 2)If a single paging area maps to multiple subnets, then any incoming packet > over any of those > subnets will be sent eventually over a link linked to the same > access net the user was previously attached to. It turns out that in mobile > IP, if the user does not send a registration request that changes the subnet > the COA > is associated to, the packet will be incoming over the expected subnet. > Otherwise mobile IP is not operating correctly. > > So: packet is iscoming on the correct subnet, the link is in the access net > where > the mobile was before it went asleep, as such there is no problem to be > solved. > > If a packet is incoming at a subnet other that the one the mobile was > attached to, > it will be discarded. If the mobile is attached to another subnet but at the > same access net > as before, it must have sent a mobile IP registration request to get the COA > moved to that > subnet. > > best redards. > > alessio From owner-seamoby@diameter.org Thu Apr 5 13:39:52 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA09211 for ; Thu, 5 Apr 2001 13:39:51 -0400 (EDT) Received: (qmail 21113 invoked by alias); 5 Apr 2001 18:29:09 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 21107 invoked by uid 200); 5 Apr 2001 18:29:08 -0000 Received: (qmail 21102 invoked from network); 5 Apr 2001 18:29:07 -0000 Received: from auemail1.lucent.com (HELO auemlsrv.firewall.lucent.com) (192.11.223.161) by c900656-a.plstn1.sfba.home.com with SMTP; 5 Apr 2001 18:29:07 -0000 Received: from auemlsrv.firewall.lucent.com (localhost [127.0.0.1]) by auemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id NAA07823 for ; Thu, 5 Apr 2001 13:38:43 -0400 (EDT) Received: from uk0006exch001h.wins.lucent.com (h135-86-160-150.lucent.com [135.86.160.150]) by auemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id NAA07811 for ; Thu, 5 Apr 2001 13:38:43 -0400 (EDT) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2650.21) id ; Thu, 5 Apr 2001 18:38:42 +0100 Message-ID: <976F7C55E3B2D111A0720008C728549C097CC310@en0060exch001u.uk.lucent.com> From: "Casati, Alessio \(Alessio\)" To: "'Michael Thomas'" Cc: "'James Kempf'" , seamoby@diameter.org Subject: RE: [seamoby] Response of Mobile Operator to Request for Info on Realistic Paging Date: Thu, 5 Apr 2001 18:38:38 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: owner-seamoby@diameter.org Precedence: bulk * *Alessio, * *It's clear that you think that there is not a *problem to be solved in the paging area. A *consensus of people here disagree. There are lot *of things that I think are useless and should not *be done too, but there is little point to *expending effort trying to stop something that *already has consensus to go forward. The market *will eventually decide who was right. In the mean *time, if it's not your intention to just be *disruptive to slow things down, it would nice to *know that so that I don't have to make a new *procmail recipe. * * Mike The consensus can also be achieved if there is a small subset of well motivated people that are able to discourage the "contrarians" to write to the list using blanket statements like yours. This does not help the quality of the work being done here, though :). What I'm looking for is a problem statement that can help people understand what you want to do... I just happened to read the problem statement by chance and I must say it is poor and not clear. Not IETF quality, as people used to say. In the meanwhile, nothing prevents you from working on the requirements, since this has been allowed by the AD. Who knows, perhaps someboby will contribute to the reqs in a way tha make things clear. You are welcome to work on Procmail recipes too. Let us know if you'll be succesfull at it. alessio From owner-seamoby@diameter.org Thu Apr 5 15:15:01 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA11604 for ; Thu, 5 Apr 2001 15:15:00 -0400 (EDT) Received: (qmail 22166 invoked by alias); 5 Apr 2001 20:03:20 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 22160 invoked by uid 200); 5 Apr 2001 20:03:20 -0000 Received: (qmail 22155 invoked from network); 5 Apr 2001 20:03:18 -0000 Received: from sj-msg-core-4.cisco.com (171.71.163.10) by c900656-a.plstn1.sfba.home.com with SMTP; 5 Apr 2001 20:03:18 -0000 Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-4.cisco.com (8.9.3/8.9.1) with ESMTP id MAA29138; Thu, 5 Apr 2001 12:12:17 -0700 (PDT) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id ADP33882; Thu, 5 Apr 2001 12:12:11 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id MAA05573; Thu, 5 Apr 2001 12:12:11 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15052.50059.587796.726267@thomasm-u1.cisco.com> Date: Thu, 5 Apr 2001 12:12:11 -0700 (PDT) To: "Dr. Carsten Bormann" Cc: "Lars-Erik Jonsson \(EPL\)" , "'Michael Thomas'" , , Subject: RE: [seamoby] RE: [rohc] RE: Restarting Compressor on Mobile IPv6 Handover In-Reply-To: References: X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-seamoby@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit Dr. Carsten Bormann writes: > > > My understanding about cellular traffic channels > > > -- and I would be happy to find out differently -- > > > is that they do not deal well with variable rate > > > traffic well. This is unsurprising since they are > > > heavily optimized for voice traffic which has very > > > regular periodicity and payload sizes. > > > > This basically means that these links are not that capable of > > handling IP traffic. > > Actually, they are. They are just not good at handling traffic whose > payload already maxes out the link. > > If the objective is to use only exactly as much capacity as is needed for > the payload, my humble advice would be not to run IP over the link. > > (Oh, and one aspect often forgotten about wireless links is that you can > often play with the channel coding. This gives you *some* form of VBR -- > combined with variable BER, unfortunately.) I certainly can't disagree with your general sentiment -- there's obviously a bandwidth price to be paid with packetization. However, there are certain MAC layers which are not friendly to variable rate compression schemes. DOCSIS cable is one of them given the way you'd like to transport RTP (eg using unsolicited grants at the MAC layer). I hope that you don't consider me as being antagonistic to ROHC (or CRTP) because that is not the case. My questions here were mainly a sanity check as to whether the places people want to do ROHC will actually be on a MAC layer which is friendly to ROHC. My sense is that some or all of the important ones (cellular) will not which is an important consideration when it comes down to priorities and making a good case to get this through the IESG. Mike From owner-seamoby@diameter.org Thu Apr 5 21:50:49 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA18683 for ; Thu, 5 Apr 2001 21:50:49 -0400 (EDT) Received: (qmail 25230 invoked by alias); 6 Apr 2001 02:40:00 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 25224 invoked by uid 200); 6 Apr 2001 02:39:59 -0000 Received: (qmail 25219 invoked from network); 6 Apr 2001 02:39:57 -0000 Received: from patan.sun.com (192.18.98.43) by c900656-a.plstn1.sfba.home.com with SMTP; 6 Apr 2001 02:39:57 -0000 Received: from centralmail1.Central.Sun.COM ([129.147.62.10]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA19019; Thu, 5 Apr 2001 18:49:33 -0700 (PDT) Received: from esun1as-mm. (esun1as-mm.Central.Sun.COM [129.147.34.144]) by centralmail1.Central.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id TAA10580; Thu, 5 Apr 2001 19:49:32 -0600 (MDT) Received: from sunyata.sun.com by esun1as-mm. (SMI-8.6/SMI-SVR4) id TAA02240; Thu, 5 Apr 2001 19:53:15 -0600 Message-Id: <5.0.0.25.1.20010406104208.00a11eb0@localhost> X-Sender: kempf@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Fri, 06 Apr 2001 10:44:34 +0900 To: "Casati, Alessio \(Alessio\)" , "'Michael Thomas'" From: James Kempf Subject: RE: [seamoby] Response of Mobile Operator to Request for Info on Realistic Paging Cc: seamoby@diameter.org In-Reply-To: <976F7C55E3B2D111A0720008C728549C097CC310@en0060exch001u.uk .lucent.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-seamoby@diameter.org Precedence: bulk Alessio, Your opinion is not shared by either the working group chair nor by the AD. When the AD reports back to us, we will see whether it is shared by the IESG. We are not talking about GPRS nor 3GPP2, we are talking about a future network where there is no HLR or VLR. My observation is that you keep bringing up the same points, which I keep answering. To that extent, Mike's comment that you seem to be disruptive is appropriate. Remember, IETF operates on *rough* concensus. jak At 06:38 PM 4/5/01 +0100, Casati, Alessio (Alessio) wrote: >* >*Alessio, >* >*It's clear that you think that there is not a >*problem to be solved in the paging area. A >*consensus of people here disagree. There are lot >*of things that I think are useless and should not >*be done too, but there is little point to >*expending effort trying to stop something that >*already has consensus to go forward. The market >*will eventually decide who was right. In the mean >*time, if it's not your intention to just be >*disruptive to slow things down, it would nice to >*know that so that I don't have to make a new >*procmail recipe. >* >* Mike > > >The consensus can also be achieved if >there is a small subset of well motivated people >that are able to discourage >the "contrarians" to write to the list using >blanket statements like yours. >This does not help the quality of the work being >done here, though :). What I'm looking for is a problem statement that >can help people understand what you want to do... >I just happened to read the problem statement by chance >and I must say it is poor and not clear. Not IETF quality, >as people used to say. > >In the meanwhile, nothing prevents you from working on the requirements, >since this has been allowed by the AD. Who knows, >perhaps someboby will contribute to the reqs in a way tha make >things clear. > >You are welcome to work on Procmail recipes too. Let us know >if you'll be succesfull at it. > >alessio From owner-seamoby@diameter.org Thu Apr 5 22:05:52 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA18794 for ; Thu, 5 Apr 2001 22:05:51 -0400 (EDT) Received: (qmail 24778 invoked by alias); 6 Apr 2001 02:33:23 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 24772 invoked by uid 200); 6 Apr 2001 02:33:22 -0000 Received: (qmail 24767 invoked from network); 6 Apr 2001 02:33:21 -0000 Received: from patan.sun.com (192.18.98.43) by c900656-a.plstn1.sfba.home.com with SMTP; 6 Apr 2001 02:33:21 -0000 Received: from centralmail1.Central.Sun.COM ([129.147.62.10]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA16514; Thu, 5 Apr 2001 18:42:58 -0700 (PDT) Received: from esun1as-mm. (esun1as-mm.Central.Sun.COM [129.147.34.144]) by centralmail1.Central.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id TAA09656; Thu, 5 Apr 2001 19:42:57 -0600 (MDT) Received: from sunyata.sun.com by esun1as-mm. (SMI-8.6/SMI-SVR4) id TAA02146; Thu, 5 Apr 2001 19:46:37 -0600 Message-Id: <5.0.0.25.1.20010406103218.00a0beb0@localhost> X-Sender: kempf@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Fri, 06 Apr 2001 10:37:52 +0900 To: "Casati, Alessio \(Alessio\)" , seamoby@diameter.org From: James Kempf Subject: RE: [seamoby] Response of Mobile Operator to Request for Info on Realistic Paging Cc: makin@isi.edu In-Reply-To: <976F7C55E3B2D111A0720008C728549C097CC30D@en0060exch001u.uk .lucent.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-seamoby@diameter.org Precedence: bulk Alessio, I'm not going to answer your comments in detail because, quite frankly, I've spent enough time discussing this issue with you to convince myself that you are never going to agree that IP paging is necessary. We've gone over the issues in the problem statement draft several times now. So, IMHO, it is a waste of time. I will take whatever direction the IESG and Pat give me as design team lead and go with that. Regarding the person at the operator I described, he will be more active in the IETF in the future, and I will make sure there is an announcement on this list about the email locale for discussion of operator requirements for the mobile Internet. These are operators that are unhappy with the 3GPP direction and are concerned that IETF is listening to them too much. I'm working with them to get something set up where they can present their concerns to IETF in a way that is consistent with IETF procedure. jak At 05:27 PM 4/5/01 +0100, Casati, Alessio (Alessio) wrote: >*Okay, folks, I spoke with a mobile operator here at MWIF in Korea. >*Alessio, I'm really sorry they can't post themselves, but they >*generally >*don't hang out on specific IETF working group lists. One of >*them will be >*at IETF 51, and hopefully involved in a requirements discussion via >*email beforehand (as soon as we can set up the list), so you >*can ask him there >*if you think I'm making this up. > >I don't think you are making this up. I think I need his e-mail address >so that I'm enabled to ask him though. If I could have his name, I could >also know how to start my message in a polite way. > >*Some background on the operator. > >I guess this is a man, not an operator... > >*The operator I talked with >*has had over 10 >*years of experience deploying GSM networks in Asia, and is a major >*technical contributor to a leading European cellular provider. >*He is very >*critical of the direction being taken >*by 3GPP, >*sees IETF as a promising possiblity to make the >*mobile Internet >*happen the way most IETFer's would like to see it happen. > >Me too, but the mobile Inernet is not bound to configuring >multiple subnets to a paging area. > >*His >*view is therefore >*likely to be different from someone who thinks 3GPP is the >*bees knees, however, >*technically, this guy is at the top of the pack. He knows cellular. > >This WG needs badly this sort of folks. He should be contributing more. > >*His response was that it is important and necessary that no a >*priori connection >*be assumed between subnets and paging areas. Another example, not >*cited in the draft which came out in our conversation, >*involves overlapping >*paging areas. It is sometimes necessary to configure a paging >*area entirely >*within another paging area, due to hotspots where there are >*lots of mobile >*nodes in dormant mode. There absolutely cannot be any constraint as to >*subnet in this case, because the inner, donut hole may have an >*arbitrary >*relation to the subnets. > >Yes, but IP does not care since these paging areas are used to establish a >link. >When the link is established, the mobile will be attached to the same >point of the attachement to the internet where it was last attached >at the last Mobile IP registration request. If this does not happen, it has >to >be considered a failure of the mobile IP model (and a MS or network >misconfiguration). >Infact, the home agent could never be assured to be sending data to the MN, >when it tunnels to the FA. > >*BTW, I also asked him about the case where wCDMA allows a mobile node >*to have more than one paging identifier, and he said this was because >*the mobile node could be in soft handoff between two RNCs that were in >*two different location areas. It would therefore require a >*paging identifier >*for both. > >So what? Are we discussing about the operation of WCMA or assessing >a problem statement you are editor of? How does it relate >to the topic at hand? Which is: > > >"we need paging at level 3 since there can be more subnets mapped to >a paging area". >On this I fairly disagree. On this the guy you interviewed seem to agree >instead, but you have not told us what is the benefit of such config. >Yet. > >*I suppose it is possible to spin this however you want if you >*do or don't >*believe >*the problem statement, but, to me, it seems a pretty clear >*endorsement of >*the problem statement. > >I cannot but abide by your thoughts, since you own them. > >I would however disagree on a non technical and technical grounds. > >1) I don't think the IETF can work by receiving endorsements by >some anonymous people... At least this is not in the process so >far. We need technical discussion to happen. And the issuer of opinions >must be identifiable via an email account. > >2)If a single paging area maps to multiple subnets, then any incoming packet >over any of those >subnets will be sent eventually over a link linked to the same >access net the user was previously attached to. It turns out that in mobile >IP, if the user does not send a registration request that changes the subnet >the COA >is associated to, the packet will be incoming over the expected subnet. >Otherwise mobile IP is not operating correctly. > >So: packet is iscoming on the correct subnet, the link is in the access net >where >the mobile was before it went asleep, as such there is no problem to be >solved. > >If a packet is incoming at a subnet other that the one the mobile was >attached to, >it will be discarded. If the mobile is attached to another subnet but at the >same access net >as before, it must have sent a mobile IP registration request to get the COA >moved to that >subnet. > >best redards. > >alessio From owner-seamoby@diameter.org Fri Apr 6 10:32:35 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA10352 for ; Fri, 6 Apr 2001 10:32:28 -0400 (EDT) Received: (qmail 30969 invoked by alias); 6 Apr 2001 15:19:52 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 30963 invoked by uid 200); 6 Apr 2001 15:19:52 -0000 Received: (qmail 30958 invoked from network); 6 Apr 2001 15:19:50 -0000 Received: from zcars04f.nortelnetworks.com (HELO zcars04f.ca.nortel.com) (47.129.242.57) by c900656-a.plstn1.sfba.home.com with SMTP; 6 Apr 2001 15:19:50 -0000 Received: from zcard015.ca.nortel.com by zcars04f.ca.nortel.com; Fri, 6 Apr 2001 10:03:56 -0400 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 6 Apr 2001 10:03:57 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C125764@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'James Kempf'" , seamoby@diameter.org Cc: makin@isi.edu Subject: RE: [seamoby] Response of Mobile Operator to Request for Info on Realistic Paging Date: Fri, 6 Apr 2001 10:03:53 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0BEA2.69E3F3A0" X-Orig: Sender: owner-seamoby@diameter.org Precedence: bulk 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_01C0BEA2.69E3F3A0 Content-Type: text/plain; charset="iso-8859-1" Interesting James, but was it this anonymous persons opinion that the really significant flaw in 3GPP was HLR/VLRs? Or did he have other issues, like the many problems with the packet transport? the access model? I am not defending 3GPP. It is simply that there is sooooo much more to wireless IP access then mobile IP and AAA. Gary > -----Original Message----- > From: James Kempf [mailto:james.kempf@sun.com] > Sent: Thursday, April 05, 2001 10:21 AM > To: seamoby@diameter.org > Cc: makin@isi.edu > Subject: [seamoby] Response of Mobile Operator to Request for Info on > Realistic Paging > > > Okay, folks, I spoke with a mobile operator here at MWIF in Korea. > Alessio, I'm really sorry they can't post themselves, but > they generally > don't hang out on specific IETF working group lists. One of > them will be > at IETF 51, and hopefully involved in a requirements discussion via > email beforehand (as soon as we can set up the list), so you > can ask him there > if you think I'm making this up. > > Some background on the operator. The operator I talked with > has had over 10 > years of experience deploying GSM networks in Asia, and is a major > technical contributor to a leading European cellular > provider. He is very > critical of the direction being taken > by 3GPP, sees IETF as a promising possiblity to make the > mobile Internet > happen the way most IETFer's would like to see it happen. His > view is therefore > likely to be different from someone who thinks 3GPP is the > bees knees, however, > technically, this guy is at the top of the pack. He knows cellular. > > Anyway, I explained to him the problem statement, and that we > were designing > for a target network in which the HLR and VLR were replaced by mobile > IP and AAA. That is to say, we are not just desiging for GPRS or 3GPP2 > IOS because they already have solutions to this problem, > however imperfect. > > His response was that it is important and necessary that no a > priori connection > be assumed between subnets and paging areas. Another example, not > cited in the draft which came out in our conversation, > involves overlapping > paging areas. It is sometimes necessary to configure a paging > area entirely > within another paging area, due to hotspots where there are > lots of mobile > nodes in dormant mode. There absolutely cannot be any > constraint as to > subnet in this case, because the inner, donut hole may have > an arbitrary > relation to the subnets. > > BTW, I also asked him about the case where wCDMA allows a mobile node > to have more than one paging identifier, and he said this was because > the mobile node could be in soft handoff between two RNCs that were in > two different location areas. It would therefore require a > paging identifier > for both. > > I suppose it is possible to spin this however you want if you > do or don't > believe > the problem statement, but, to me, it seems a pretty clear > endorsement of > the problem statement. > > jak > > ------_=_NextPart_001_01C0BEA2.69E3F3A0 Content-Type: text/html; charset="iso-8859-1" RE: [seamoby] Response of Mobile Operator to Request for Info on Realistic Paging

Interesting James, but was it this anonymous persons opinion that the really significant
flaw in 3GPP was HLR/VLRs? Or did he have other issues, like the many problems
with the packet transport? the access model?

I am not defending 3GPP. It is simply that there is sooooo much more to wireless IP access then mobile IP and AAA.

Gary

> -----Original Message-----
> From: James Kempf [mailto:james.kempf@sun.com]
> Sent: Thursday, April 05, 2001 10:21 AM
> To: seamoby@diameter.org
> Cc: makin@isi.edu
> Subject: [seamoby] Response of Mobile Operator to Request for Info on
> Realistic Paging
>
>
> Okay, folks, I spoke with a mobile operator here at MWIF in Korea.
> Alessio, I'm really sorry they can't post themselves, but
> they generally
> don't hang out on specific IETF working group lists. One of
> them will be
> at IETF 51, and hopefully involved in a requirements discussion via
> email beforehand (as soon as we can set up the list), so you
> can ask him there
> if you think I'm making this up.
>
> Some background on the operator. The operator I talked with
> has had over 10
> years of experience deploying GSM networks in Asia, and is a major
> technical contributor to a leading European cellular
> provider. He is very
> critical of the direction being taken
> by 3GPP, sees IETF as a promising possiblity to make the
> mobile Internet
> happen the way most IETFer's would like to see it happen. His
> view is therefore
> likely to be different from someone who thinks 3GPP is the
> bees knees, however,
> technically, this guy is at the top of the pack. He knows cellular.
>
> Anyway, I explained to him the problem statement, and that we
> were designing
> for a target network in which the HLR and VLR were replaced by mobile
> IP and AAA. That is to say, we are not just desiging for GPRS or 3GPP2
> IOS because they already have solutions to this problem,
> however imperfect.
>
> His response was that it is important and necessary that no a
> priori connection
> be assumed between subnets and paging areas. Another example, not
> cited in the draft which came out in our conversation,
> involves overlapping
> paging areas. It is sometimes necessary to configure a paging
> area entirely
> within another paging area, due to hotspots where there are
> lots of mobile
> nodes in dormant mode. There absolutely cannot be any
> constraint as to
> subnet in this case, because the inner, donut hole may have
> an arbitrary
> relation to the subnets.
>
> BTW, I also asked him about the case where wCDMA allows a mobile node
> to have more than one paging identifier, and he said this was because
> the mobile node could be in soft handoff between two RNCs that were in
> two different location areas. It would therefore require a
> paging identifier
> for both.
>
> I suppose it is possible to spin this however you want if you
> do or don't
> believe
> the problem statement, but, to me, it seems a pretty clear
> endorsement of
> the problem statement.
>
>               jak
>
>

------_=_NextPart_001_01C0BEA2.69E3F3A0-- From owner-seamoby@diameter.org Fri Apr 6 10:35:45 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA10544 for ; Fri, 6 Apr 2001 10:35:44 -0400 (EDT) Received: (qmail 31108 invoked by alias); 6 Apr 2001 15:21:08 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 31103 invoked by uid 200); 6 Apr 2001 15:21:08 -0000 Received: (qmail 31097 invoked from network); 6 Apr 2001 15:21:06 -0000 Received: from ihemail1.lucent.com (HELO ihemail1.firewall.lucent.com) (192.11.222.161) by c900656-a.plstn1.sfba.home.com with SMTP; 6 Apr 2001 15:21:06 -0000 Received: from ihemail1.firewall.lucent.com (localhost [127.0.0.1]) by ihemail1.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id KAA19449 for ; Fri, 6 Apr 2001 10:30:43 -0400 (EDT) Received: from uk0006exch001h.wins.lucent.com (h135-86-160-150.lucent.com [135.86.160.150]) by ihemail1.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id KAA19416 for ; Fri, 6 Apr 2001 10:30:42 -0400 (EDT) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2650.21) id ; Fri, 6 Apr 2001 15:30:41 +0100 Message-ID: <976F7C55E3B2D111A0720008C728549C097CC318@en0060exch001u.uk.lucent.com> From: "Casati, Alessio \(Alessio\)" To: "Seamoby \(E-mail\)" Subject: [seamoby] Response of Mobile Operator to Request for Info on Re alistic Paging Date: Fri, 6 Apr 2001 15:30:40 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-seamoby@diameter.org Precedence: bulk Your opinion is not shared by either the working group chair nor by the AD. When the AD reports back to us, we will see whether it is shared by the IESG. We are not talking about GPRS nor 3GPP2, we are talking about a future network where there is no HLR or VLR. So, this should be written in the problem statement. However this does not change the validity of what I wrote. By the way there are a few operators out there that are happy to use HLR and VLR. Those concepts I wrote will remain valid, although technology and naming of for the same functionality will evolve. So, something meaningless today (such as a wireless net without HLR and VLR functionality, will be meaningless in the future). Need of L3 paging is meaningless today as it will be tomorrow (unless what you are doing is what the GTP PDU notification does today, in which case you are doing really nothing new, since this was done years ago in ETSI - if you are doing that then I can point you to where you could look this up not to reinvent the wheel too much) My observation is that you keep bringing up the same points, which I keep answering. To that extent, Mike's comment that you seem to be disruptive is appropriate. The same points are brought insofar as no response is given to them. I wonder why I get no answer other than " we work by rough consensus". It is depressing :). alessio From owner-seamoby@diameter.org Fri Apr 6 11:04:22 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA11445 for ; Fri, 6 Apr 2001 11:04:17 -0400 (EDT) Received: (qmail 31849 invoked by alias); 6 Apr 2001 15:26:39 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 31835 invoked by uid 200); 6 Apr 2001 15:26:38 -0000 Received: (qmail 31812 invoked from network); 6 Apr 2001 15:26:33 -0000 Received: from idcmail.interdigital.com (HELO idcpa4.pa.interdigital.com) (12.32.197.142) by c900656-a.plstn1.sfba.home.com with SMTP; 6 Apr 2001 15:26:33 -0000 Received: by idcpa4.pa.interdigital.com with Internet Mail Service (5.5.2653.19) id ; Fri, 6 Apr 2001 10:34:48 -0400 Message-ID: From: "Shahrier, Sharif M." To: "'Gary Kenward'" , "Shahrier, Sharif M." Cc: "'seamoby@cdma-2000.org'" , "Kiernan, Brian G." Subject: [seamoby] RE: [seamoby-context] requirements Date: Fri, 6 Apr 2001 10:34:44 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0BEA6.B9031750" Sender: owner-seamoby@diameter.org Precedence: bulk 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_01C0BEA6.B9031750 Content-Type: text/plain; charset="iso-8859-1" Gary, Thanks for responding. Saw that you were having problems with the mailins-list -- same here. Pat had some issues with the msec items that he wanted some clarification. I had sent him a response. I would like to send the comments to you as well. Please get back to us after you've had a chance to read it .... Sharif. --------------------------------------------------------------------- Pat: This is a slightly revised response to your earlier question. Please disregard the e-mail I sent earlier. Thanks. I believe we had agreed that "security" is an important item when considering the transfer of context from one peer to another -- did we not? Well, "multicast security" is a natural extention of this. In any well defined network there will be multicast goups, i.e. a number of MNs, attached to a single context. Authorized MNs will be allowed to enter and leave the group at will. Thus, we need to have a security protocol to handle this case. Let's choose as an example a multiparty videoconference within a private corporation. In this scanraio, a context is maintained; has to be protected by some security means, so that only authorized members can add to the group, and members may freely leave the group. I refer to this as a "local multiparty privacy". Now, on top of this security, there is a firewall, preventing outside users from getting into the company's enterprise network. Suppose that there is an authorized MN for the multicast group, which is outside the firewall. Thus, to join the group that MN has to get in through the firewall and authenticate itself to join the multiparty videoconference. Thus, there are two levels of security for MNs oustside of the enterprise network. Two question: what consitutes a "context transfer" when "multicast groups" are invloved? what authentication procedures are involved after "context transfer" when "multicast groups" are present? The first question is complicated I don't have an answer to as yet; needs to be discussion by the group. The second question is what I am concerned with here wrt requirements. Thanks. I hope this answers your questions. If you have any other questions please send me a note otherwise if it is agreed to add a section on theis I will be glad to provide the text. Look forward to hearing back ..... Sharif. ---------------------------------------------------------------------------- ------------------ Before we agree to even consider adding msec in the I-D, please explain to me its relevance in context transfer. PatC > Pat, > -----Original Message----- From: Gary Kenward [mailto:gkenward@nortelnetworks.com] Sent: Wednesday, April 04, 2001 2:47 PM To: 'Shahrier, Sharif M.' Subject: RE: [seamoby-context] requirements Thanks Sharif. -----Original Message----- From: Shahrier, Sharif M. [mailto:Sharif.Shahrier@interdigital.com] Sent: Wednesday, April 04, 2001 2:12 PM To: 'seamoby-context@cdma-2000.org' Cc: Kenward, Gary [WDLN2:AN10:EXCH]; Shahrier, Sharif M. Subject: [seamoby-context] requirements Gary, I am in agreement with all of these. In addition, I would like you and the group to consider some additional ones, mostly regarding multicast security. This is currently not fully exploited even within the fixed network community in my opinion, thus I was wondering how much importance to lay on them for mobile networks at this time. All comments are welcome. Multicast Security: Authentication protocol for multicast groups of MNs that are authorized to access a perticular context set. The protocol should allow authorized MNs to freely enter and leave the group. Multicast Security: Authorized MNs may join or leave a multicast group, while the "context transfer" is in progress from one entity to another one. New authentication procedures for authorized MNs to join the multicast group; removal of MNs from the authentication list during this process. Multicast Security: Sub-sets of the multicast group are authorized access to specific sub-context within a context. Develop an authentication protocol to allow this occur in a non-overlapping manner. Multicast Security: Like case (2) above, authorized MNs may join or leave the multicast group for case (3). Local Privacy: A set of MNs are authorized access to context/sub-context within an administrative domain. Authorization & authentication protocols MUST allow members to be added or deleted from the set. Higher level security allows MNs outside the administrative domain to be authenticated and authorized access to the whole or part of the context. Sharif -----Original Message----- From: Kenward, Gary [WDLN2:AN10:EXCH] [mailto:gkenward@americasm01.nt.com] Sent: Tuesday, April 03, 2001 5:02 PM To: seamoby_context@marvin.baynetworks.com; seamoby_context@marvin.corpeast.baynetworks.com Subject: RE: text for security requirement on CT protocol. These statements look to me to be good candidates for the requirements document, not the problem statement. Gayr > -----Original Message----- > From: Theo Pagtzis [ mailto:t.pagtzis@cs.ucl.ac.uk ] > Sent: Friday, March 30, 2001 6:38 PM > To: seamoby_context@marvin.corpeast.baynetworks.com > Subject: Re: text for security requirement on CT protocol. > > > Gary/all, > > I think that after Allisson's comments it would be better > to provide a small section on the > actual problem statement, not the appendix, about what MUST > be the security considerations. For > that purpose allow me to contribute the following text: > > > Security Considerations > > Context transfer MUST be effected securely between > participating entities. Depending on the > communication scenario such entities will encompass one or > more Access Routers and/or an > individual Mobile Node. The dimensions of security are > dependent on the type of context > transfer communications between the participating entities. > > The cases that need be considered are: > > 1. context transfer communications between two peer Access > Router entities. > > 2. context transfer communications between more than two > Access Router entities. > > 3. context transfer communications between a mobile node and > an Access Router entity. > > > > 1. CT comms between one-to-one AR entities > > The two AR communicating entities MUST be mutually > authenticated prior to context transfer > signaling. This is to ensure that the validity of the > participating entities and prevent > potential man-in-the-middle attacks in subsequent context > state transfer. Each authenticating > entity MUST be equipped with symmetric or asymmetric keying > information that MUST be instigated > manually or automaticaly. > > The AR entities MUST be capable of preventing by appropriate > secure mechanisms replay attacks, > such as ensuring freshness of context transfer signalling messages. > > Each AR entity SHOULD be able to provide encryption services > over specific feature contexts > such as AAA information. Each AR MUST advertise encryption > capabilities as well as the > supported feature contexts for which encryption services can > be offered. > > Each AR MAY provide out of band PFS capabilities to its > communicating entities for the purposes > of context state transfer. Such capability if so supported > MUST be effected out of band with > respect to the communicated context state transfer in either > reactive or proactive cases. This > is to ensure that potential compromize of a link cannot > persist for long periods of time. > > Each AR SHOULD provide transitive authentication capability > by exploiting transitive trust > (web of trust) as effected by examples such as PGP. This MAY > provide potential speedups in the > relevant security function during transfer of context state. > > > 2. CT comms between one-to-many AR entities > > More than two AR entities communicating for the purposes of > context state transfer in a network > domain MUST fulfill the requirements of the above case. > However, the distribution of keying > material, for the purposes of scalability MAY be constrained > to an subset or group AR shared > secret; this is in favour of scalability issue that may arise > from distributions issues of > individual AR keying material, depending on the methods of > distribution. > > 3. CT comms between an AR and an MN entity > > The MN MUST be informed about from its CURRENT (or NEW) AR > entity on the set of context > transfer state that is required by the upcoming visiting > AR(s). Such information will assist > the mobile node to assess the viability of sustaining its > connection state within the upcoming > visiting domain and as such the accomodating AR. This is > particularly important over AAA > functions where the mobile node is expected to incur charges > as a result of its upcoming > movement towards a particular AR (domain). > > For the purposes of seamlessness the AR SHOULD not be > required to await authorization by a > mobile node entity for the purposes of effecting transfer of > any type of context state. This > will be mainly the case for proactive context transfer, where > the AR may attempt to provide > context state in advance of the mobile node's movement. This > important for the purposes of > seamless context transfer where any latency may count against > the transparent of the mobile > node's transition between ARs or domains. > > The reactive case for context transfer does not present the > above issue since the movement of > the mobile node towards a particular AR indicates an explicit > instruction to the accomodating > network that the mobile node accepts the implications of its > movement pattern. We assume that > the node is also in control of its connection and as such can > explicitly refuse accomodation in > the visiting network by terminating its connection. > > With regard to location privacy, the context transfer between > two or more ARs SHOULD not > provide the current location of the MN iff such function can > be supported by the underlying > mobility protocol. > > > Theo > > UCL/ Mobile Systems > > > > Michael Thomas wrote: > > > Madjid, > > > > I think it would better to not go down the rathole > > of how you key a security association (cf AAA reference), > > but instead make some definitive statements about: > > > > o Message Integrity > > o Confidentiality > > o Authentication > > o Authorization > > > > For the CT protocol. If pressed for what those would > > be, I'd say: > > > > o Message Integrity must be provided for to > > counter insertion/deletion/replacement and > > replay attacks > > o Confidentiality must be kept if transfering > > confidential information, or if prefered by the > > mobile node and/or AR > > o Authentication: the CT peers must be able to > > mutually authentiate one another > > o Authorization: a CT peer must be able to decide > > which pieces of context the other peer is authorized > > to receive. Also: the mobile node must ultimately > > authorize any CT which happens between CT peers > > (explicitly or implicitly). > > > > or something along these lines. > > > > Mike > > > > Nakhjiri Madjid-MNAKHJI1 writes: > > > Gary, > > > > > > Yes, please see the following text (revised from A9 in > problem statement) > > > > > > Regards, > > > > > > Madjid > > > > > > > > > SubSection - Context Transfer Security Requirements > > > > > > The mechanisms for establishing trust between the two > parties involved > > > in context transfer in order to transfer context data securely > > > (as described below) should be provided. > > > Prior to the process of context transfer, a mutual > authentication > > > Between the CT peers should happen (this could utilize the AAA > > > Hierarchy, in case AAA admin domains are present). During this > > > Authentication, the party receiving the context and the party > > > transmitting the context, each provides proof of legitimacy to > > > the other side. Data integrity protection should > provided, so that > > > the context information is protected from tampering > by a third party. > > > Encryption of context data might be necessary, in > case MH location > > > privacy and network topology and policy protection > are required. > > > In case security and AAA context are being > transferred, the context > > > Data must be encrypted. > > > > > > The mobile node could ultimately retain control over > whether it moves > > > or not, and under what conditions it consents to have > a network > > > based move done on its behalf. In particular, the > mobile node must > > > have the ability to veto a move that could happen > transparently, but > > > may result in higher access charges, unexpected > service degradation, > > > loss of privacy, or other policy based exclusions. > > > > > > -----Original Message----- > > > From: Kenward, Gary [WDLN2:AN10:EXCH] > [ mailto:gkenward@AMERICASM01.NT.COM ] > > > Sent: Monday, March 26, 2001 4:20 PM > > > To: SEAMOBY_CONTEXT@STANDARDS.NORTELNETWORKS.COM > > > Subject: Re: some requirements items > > > > > > > > > Obviously, there seems to be a consensus concerning what > > > Allison intended concerning security: that it was a recognized > > > example for the problem statement. > > > However, Sharif is correct in identifying an additional topic > > > for the requirements draft(s): security of the context transfer > > > itself. Definitely worth exploring, as long as we keep to the > > > requirements space for now. > > > Anyone care to volunteer to describe the requirements for > > > "security context transfer" (we should be able to use them > > > in the problem statement as well as in the requirements > > > document). > > > Gary > > > > -----Original Message----- > > > > From: Peter Lei [ mailto:peter.lei@ieee.org ] > > > > Sent: Monday, March 26, 2001 4:42 PM > > > > To: seamoby_context@standards.nortelnetworks.com > > > > Subject: Re: some requirements items > > > > > > > > > > > > This is not what I got from the teleconference at > all... Rather, > > > > I believe Allison was suggesting that we should use ROHC and > > > > security as examples of things which would benefit from context > > > > transfer, which would then make a clearer case for the problem > > > > statement. (ie. it was not about secure transfer of context). > > > > > > > > --peter > > > > > > > > > Gary, > > > > > > > > > > Based on what the AD said in today's teleconference, > security is > > > > > indeed an important issue on context transfer. Thus, > whether or not > > > > > we ultimately decide to tranfer the context via a > encrypted tunnel, > > > > > secure transfer of the context must be taken seriously. > > > > > > > > > > you are right, we are closing in on a common > agreement, and if > > > > > nobody in the team has any objections, I would be > glad to look into > > > > > the requirements issues for (a) quality of service, > and (b) secure > > > > > transfer on context. > > > > > > > > > > Comments please ........... > > > > > > > > > > Sharif > > > > > > > > > > > > --- > > > > You are currently subscribed to seamoby_context as: > > > > gkenward@americasm01.nt.com > > > > To unsubscribe send a blank email to > > > > leave-seamoby_context-1413E@lyris.nortelnetworks.com > > > > > > > > > > > > > --- > > > You are currently subscribed to seamoby_context as: mat@cisco.com > > > To unsubscribe send a blank email to > leave-seamoby_context-1413E@lyris.nortelnetworks.com > > > > --- > > You are currently subscribed to seamoby_context as: > t.pagtzis@cs.ucl.ac.uk > > To unsubscribe send a blank email to > leave-seamoby_context-1413E@lyris.nortelnetworks.com > > > > --- > You are currently subscribed to seamoby_context as: > gkenward@americasm01.nt.com > To unsubscribe send a blank email to > leave-seamoby_context-1413E@lyris.nortelnetworks.com > --- You are currently subscribed to seamoby_context as: sharif.shahrier@interdigital.com To unsubscribe send a blank email to leave-seamoby_context-1413E@lyris.nortelnetworks.com ------_=_NextPart_001_01C0BEA6.B9031750 Content-Type: text/html; charset="iso-8859-1" RE: text for security requirement on CT protocol.
Gary,
 
    Thanks for responding. Saw that you were having problems with the mailins-list -- same here.
 
Pat had some issues with the msec items that he wanted some clarification. I had sent him a response. I would like to send the comments to you as well.
 
Please get back to us after you've had a chance to read it ....
 
Sharif.
 
---------------------------------------------------------------------

Pat:

This is a slightly revised response to your earlier question. Please disregard the e-mail I sent earlier. Thanks.

 

 

I believe we had agreed that "security" is an important item when considering the transfer of context from one peer to another -- did we not?

Well, "multicast security" is a natural extention of this.

In any well defined network there will be multicast goups, i.e. a number of MNs, attached to a single context. Authorized MNs will be allowed to enter and leave the group at will. Thus, we need to have a security protocol to handle this case.

Let's choose as an example a multiparty videoconference within a private corporation.

In this scanraio, a context is maintained; has to be protected by some security means, so that only authorized members can add to the group, and members may freely leave the group.

I refer to this as a "local multiparty privacy".

Now, on top of this security, there is a firewall, preventing outside users from getting into the company's enterprise network. Suppose that there is an authorized MN for the multicast group, which is outside the firewall. Thus, to join the group that MN has to get in through the firewall and authenticate itself to join the multiparty videoconference. Thus, there are two levels of security for MNs oustside of the enterprise network.

Two question: what consitutes a "context transfer" when "multicast groups" are invloved?

              what authentication procedures are involved after "context transfer" when "multicast    groups" are present?

The first question is complicated I don't have an answer to as yet; needs to be discussion by the group.

The second question is what I am concerned with here wrt requirements.

Thanks. I hope this answers your questions. If you have any other questions please send me a note otherwise if it is agreed to add a section on theis I will be glad to provide the text.

Look forward to hearing back .....

Sharif.

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

 

Before we agree to even consider adding msec in the I-D, please explain to me

its relevance in context transfer.

PatC

> Pat,

>

-----Original Message-----
From: Gary Kenward [mailto:gkenward@nortelnetworks.com]
Sent: Wednesday, April 04, 2001 2:47 PM
To: 'Shahrier, Sharif M.'
Subject: RE: [seamoby-context] requirements

Thanks Sharif.
-----Original Message-----
From: Shahrier, Sharif M. [mailto:Sharif.Shahrier@interdigital.com]
Sent: Wednesday, April 04, 2001 2:12 PM
To: 'seamoby-context@cdma-2000.org'
Cc: Kenward, Gary [WDLN2:AN10:EXCH]; Shahrier, Sharif M.
Subject: [seamoby-context] requirements



 
Gary,
 
    I am in agreement with all of these. In addition, I would like you and the group to consider some additional ones, mostly regarding multicast security. This is currently not fully exploited even within the fixed network community in my opinion, thus I was wondering how much importance to lay on them for mobile networks  at this time. All comments are welcome.
 
   

Multicast Security: Authentication protocol for multicast groups of MNs that are authorized to access a perticular context set. The protocol should allow authorized MNs to freely enter and leave the group.

Multicast Security: Authorized MNs may join or leave a multicast group, while the "context transfer" is in progress from one entity to another one. New authentication procedures for authorized MNs to join the multicast group; removal of MNs from the authentication list during this process.

Multicast Security: Sub-sets of the multicast group are authorized access to specific sub-context within a context. Develop an authentication protocol to allow this occur in a non-overlapping manner.

Multicast Security: Like case (2) above, authorized MNs may join or leave the multicast group for case (3).

Local Privacy: A set of MNs are authorized access to context/sub-context within an administrative domain. Authorization & authentication protocols MUST allow members to be added or deleted from the set.

Higher level security allows MNs outside the administrative domain to be authenticated and authorized access to the whole or part of the context.

Sharif

-----Original Message-----
From: Kenward, Gary [WDLN2:AN10:EXCH] [mailto:gkenward@americasm01.nt.com]
Sent: Tuesday, April 03, 2001 5:02 PM
To: seamoby_context@marvin.baynetworks.com; seamoby_context@marvin.corpeast.baynetworks.com
Subject: RE: text for security requirement on CT protocol.

These statements look to me to be good candidates for the requirements
document, not the problem statement.

Gayr

> -----Original Message-----
> From: Theo Pagtzis [mailto:t.pagtzis@cs.ucl.ac.uk]
> Sent: Friday, March 30, 2001 6:38 PM
> To: seamoby_context@marvin.corpeast.baynetworks.com
> Subject: Re: text for security requirement on CT protocol.
>
>
> Gary/all,
>
>   I think that after Allisson's comments it would be better
> to provide a small section on the
> actual problem statement, not the appendix, about what MUST
> be the security considerations. For
> that purpose allow me to contribute the following text:
>
>
> Security Considerations
>
> Context transfer MUST be effected securely between
> participating entities. Depending on the
> communication scenario such entities will encompass one or
> more Access Routers and/or an
> individual Mobile Node. The dimensions of security are
> dependent on the type of context
> transfer communications between the participating entities.
>
> The cases that need be considered are:
>
> 1. context transfer communications between two peer Access
> Router entities.
>
> 2. context transfer communications between more than two
> Access Router entities.
>
> 3. context transfer communications between a mobile node and
> an Access Router entity.
>
>
>
> 1. CT comms between one-to-one AR entities
>
> The two AR communicating entities MUST be mutually
> authenticated prior to context transfer
> signaling. This is to ensure that the validity of the
> participating entities and prevent
> potential man-in-the-middle attacks in subsequent context
> state transfer. Each authenticating
> entity MUST be equipped with symmetric or asymmetric keying
> information that MUST be instigated
> manually or automaticaly.
>
> The AR entities MUST be capable of preventing by appropriate
> secure mechanisms replay attacks,
> such as ensuring freshness of context transfer signalling messages.
>
> Each AR entity SHOULD be able to provide encryption services
> over specific feature contexts
> such as AAA information. Each AR MUST advertise encryption
> capabilities as well as the
> supported feature contexts for which encryption services can
> be offered.
>
> Each AR MAY provide out of band PFS capabilities to its
> communicating entities for the purposes
> of context state transfer. Such capability if so supported
> MUST be effected out of band with
> respect to the communicated context state transfer in either
> reactive or proactive cases. This
> is to ensure that potential compromize of a link cannot
> persist for long periods of time.
>
> Each AR SHOULD provide transitive authentication capability
> by exploiting transitive trust
> (web of trust) as effected by examples such as PGP. This MAY
> provide potential speedups in the
> relevant security function during transfer of context state.
>
>
> 2. CT comms between one-to-many AR entities
>
> More than two AR entities communicating for the purposes of
> context state transfer in a network
> domain MUST fulfill the requirements of the above case.
> However, the distribution of keying
> material, for the purposes of scalability MAY be constrained
> to an subset or group AR shared
> secret; this is in favour of scalability issue that may arise
> from distributions issues of
> individual AR keying material, depending on the methods of
> distribution.
>
> 3.  CT comms between an AR and an MN entity
>
> The MN MUST be informed about from its CURRENT (or NEW) AR
> entity on the set of context
> transfer state that is required by the upcoming visiting
> AR(s). Such information will assist
> the mobile node to assess the viability of sustaining its
> connection state within the upcoming
> visiting domain and as such the accomodating AR. This is
> particularly important over AAA
> functions where the mobile node is expected to incur charges
> as a result of its upcoming
> movement towards a particular AR (domain).
>
> For the purposes of seamlessness the AR SHOULD not be
> required to await authorization by a
> mobile node entity for the purposes of effecting transfer of
> any type of context state. This
> will be mainly the case for proactive context transfer, where
> the AR may attempt to provide
> context state in advance of the mobile node's movement. This
> important for the purposes of
> seamless context transfer where any latency may count against
> the transparent of the mobile
> node's transition between ARs or domains.
>
> The reactive case for context transfer does not present the
> above issue since the movement of
> the mobile node towards a particular AR indicates an explicit
> instruction to the accomodating
> network that the mobile node accepts the implications of its
> movement pattern. We assume that
> the node is also in control of its connection and as such can
> explicitly refuse accomodation in
> the visiting network by terminating its connection.
>
> With regard to location privacy, the context transfer between
> two or more ARs SHOULD not
> provide the current location of the MN iff such function can
> be supported by the underlying
> mobility protocol.
>
>
> Theo
>
> UCL/ Mobile Systems
>
>
>
> Michael Thomas wrote:
>
> > Madjid,
> >
> > I think it would better to not go down the rathole
> > of how you key a security association (cf AAA reference),
> > but instead make some definitive statements about:
> >
> > o Message Integrity
> > o Confidentiality
> > o Authentication
> > o Authorization
> >
> > For the CT protocol. If pressed for what those would
> > be, I'd say:
> >
> > o Message Integrity must be provided for to
> >   counter insertion/deletion/replacement and
> >   replay attacks
> > o Confidentiality must be kept if transfering
> >   confidential information, or if prefered by the
> >   mobile node and/or AR
> > o Authentication: the CT peers must be able to
> >   mutually authentiate one another
> > o Authorization: a CT peer must be able to decide
> >   which pieces of context the other peer is authorized
> >   to receive. Also: the mobile node must ultimately
> >   authorize any CT which happens between CT peers
> >   (explicitly or implicitly).
> >
> >   or something along these lines.
> >
> >               Mike
> >
> > Nakhjiri Madjid-MNAKHJI1 writes:
> >  > Gary,
> >  >
> >  > Yes, please see the following text (revised from A9 in
> problem statement)
> >  >
> >  > Regards,
> >  >
> >  > Madjid
> >  >
> >  >
> >  > SubSection - Context Transfer Security Requirements
> >  >
> >  >    The mechanisms for establishing trust between the two
> parties involved
> >  >    in context transfer in order to transfer context data securely
> >  >   (as described below) should be provided.
> >  >    Prior to the process of context transfer, a mutual
> authentication
> >  >    Between the CT peers should happen (this could utilize the AAA
> >  >    Hierarchy, in case AAA admin domains are present). During this
> >  >    Authentication, the party receiving the context and the party
> >  >    transmitting the context, each provides proof of legitimacy to
> >  >    the other side. Data integrity protection should
> provided, so that
> >  >    the context information is protected from tampering
> by a third party.
> >  >    Encryption of context data might be necessary, in
> case MH location
> >  >    privacy and network topology and policy protection
> are required.
> >  >    In case security and AAA context are being
> transferred, the context
> >  >    Data must be encrypted.
> >  >
> >  >    The mobile node could ultimately retain control over
> whether it moves
> >  >    or not, and under what conditions it consents to have
> a network
> >  >    based move done on its behalf. In particular, the
> mobile node must
> >  >    have the ability to veto a move that could happen
> transparently, but
> >  >    may result in higher access charges, unexpected
> service degradation,
> >  >    loss of privacy, or other policy based exclusions.
> >  >
> >  > -----Original Message-----
> >  > From: Kenward, Gary [WDLN2:AN10:EXCH]
> [mailto:gkenward@AMERICASM01.NT.COM]
> >  > Sent: Monday, March 26, 2001 4:20 PM
> >  > To: SEAMOBY_CONTEXT@STANDARDS.NORTELNETWORKS.COM
> >  > Subject: Re: some requirements items
> >  >
> >  >
> >  > Obviously, there seems to be a consensus concerning what
> >  > Allison intended concerning security: that it was a recognized
> >  > example for the problem statement.
> >  > However, Sharif is correct in identifying an additional topic
> >  > for the requirements draft(s): security of the context transfer
> >  > itself. Definitely worth exploring, as long as we keep to the
> >  > requirements space for now.
> >  > Anyone care to volunteer to describe the requirements for
> >  > "security context transfer" (we should be able to use them
> >  > in the problem statement as well as in the requirements
> >  > document).
> >  > Gary
> >  > > -----Original Message-----
> >  > > From: Peter Lei [mailto:peter.lei@ieee.org]
> >  > > Sent: Monday, March 26, 2001 4:42 PM
> >  > > To: seamoby_context@standards.nortelnetworks.com
> >  > > Subject: Re: some requirements items
> >  > >
> >  > >
> >  > > This is not what I got from the teleconference at
> all...  Rather,
> >  > > I believe Allison was suggesting that we should use ROHC and
> >  > > security as examples of things which would benefit from context
> >  > > transfer, which would then make a clearer case for the problem
> >  > > statement. (ie. it was not about secure transfer of context).
> >  > >
> >  > > --peter
> >  > >
> >  > > > Gary,
> >  > > >
> >  > > > Based on what the AD said in today's teleconference,
> security is
> >  > > > indeed an important issue on context transfer. Thus,
> whether or not
> >  > > > we ultimately decide to tranfer the context via a
> encrypted tunnel,
> >  > > > secure transfer of the context must be taken seriously.
> >  > > >
> >  > > > you are right, we are closing in on a common
> agreement, and if
> >  > > > nobody in the team has any objections, I would be
> glad to look into
> >  > > > the requirements issues for (a) quality of service,
> and (b) secure
> >  > > > transfer on context.
> >  > > >
> >  > > > Comments please ...........
> >  > > >
> >  > > > Sharif
> >  > >
> >  > >
> >  > > ---
> >  > > You are currently subscribed to seamoby_context as:
> >  > > gkenward@americasm01.nt.com
> >  > > To unsubscribe send a blank email to
> >  > > leave-seamoby_context-1413E@lyris.nortelnetworks.com
> >  > >
> >  >
> >  >
> >  > ---
> >  > You are currently subscribed to seamoby_context as: mat@cisco.com
> >  > To unsubscribe send a blank email to
> leave-seamoby_context-1413E@lyris.nortelnetworks.com
> >
> > ---
> > You are currently subscribed to seamoby_context as:
> t.pagtzis@cs.ucl.ac.uk
> > To unsubscribe send a blank email to
> leave-seamoby_context-1413E@lyris.nortelnetworks.com
>
>
>
> ---
> You are currently subscribed to seamoby_context as:
> gkenward@americasm01.nt.com
> To unsubscribe send a blank email to
> leave-seamoby_context-1413E@lyris.nortelnetworks.com
>

---
You are currently subscribed to seamoby_context as: sharif.shahrier@interdigital.com
To unsubscribe send a blank email to leave-seamoby_context-1413E@lyris.nortelnetworks.com
------_=_NextPart_001_01C0BEA6.B9031750-- From owner-seamoby@diameter.org Fri Apr 6 11:29:51 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA12169 for ; Fri, 6 Apr 2001 11:29:51 -0400 (EDT) Received: (qmail 32196 invoked by alias); 6 Apr 2001 15:31:34 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 32190 invoked by uid 200); 6 Apr 2001 15:31:33 -0000 Received: (qmail 32183 invoked from network); 6 Apr 2001 15:31:26 -0000 Received: from patan.sun.com (192.18.98.43) by c900656-a.plstn1.sfba.home.com with SMTP; 6 Apr 2001 15:31:26 -0000 Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA16348; Fri, 6 Apr 2001 07:40:44 -0700 (PDT) Received: from nasnfs.Eng.Sun.COM (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA11687; Fri, 6 Apr 2001 07:40:43 -0700 (PDT) Received: from darius (darius [10.6.84.105]) by nasnfs.Eng.Sun.COM (8.9.3+Sun/8.9.1) with SMTP id HAA23503; Fri, 6 Apr 2001 07:40:41 -0700 (PDT) Date: Fri, 6 Apr 2001 07:40:40 -0700 (PDT) From: Patrice Calhoun Reply-To: Patrice Calhoun Subject: Re: [seamoby] Response of Mobile Operator to Request for Info on Re alistic Paging To: "Casati, Alessio \(Alessio\)" Cc: "Seamoby \(E-mail\)" In-Reply-To: "Your message with ID" <976F7C55E3B2D111A0720008C728549C097CC318@en0060exch001u.uk.lucent.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-seamoby@diameter.org Precedence: bulk I have been trying to sit by the sidelines, and allow everyone to express their opinion, but it is apparent to me that there is no possible compromise here. Alessio is insistent that this is useless, and others do not think so. They find this work useful, and have stated their opinions as well. So, in the spirit of cooperation, perhaps we can put this thread aside, and start working on the requirements. Please kill this thread. If the market does in fact not find this work useful, then like many other things from the IETF, it will not have much deployment. As for HLR/VLR, I know that there is significant work going on to eliminate them in *some* of the SDOs. Again, whether or not carriers will use the new standards is nothing more than a guess any one of us could do. So, let's get to work! PatC > > > Your opinion is not shared by either the working group chair > nor by the AD. > When the AD reports back to us, we will see whether it is shared by > the > IESG. We are not talking about GPRS nor 3GPP2, we are talking > about a future network where there is no HLR or VLR. > > So, this should be written in the problem statement. > However this does not change the validity of > what I wrote. By the way there are > a few operators out there that are happy to use HLR > and VLR. Those concepts I wrote will remain valid, although technology > and naming of for the same functionality will evolve. So, something > meaningless today (such as a wireless net without HLR and VLR > functionality, > will be meaningless in the future). Need of L3 paging is > meaningless today > as it will be tomorrow (unless what you are doing is what the GTP > PDU notification does today, in which case you are doing really nothing > new, since this was done years ago in ETSI - if you are doing that > then I can point you to where you could look this up not to > reinvent the wheel > too much) > > My observation is that you keep bringing up the same points, > which I keep > answering. To that extent, Mike's comment that you seem to be > disruptive > is appropriate. > > The same points are brought insofar as no response is given to > them. I wonder why I get no answer other than " we work by > rough consensus". > It is depressing :). > > > alessio From owner-seamoby@diameter.org Fri Apr 6 11:58:13 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA12945 for ; Fri, 6 Apr 2001 11:57:46 -0400 (EDT) Received: (qmail 1798 invoked by alias); 6 Apr 2001 16:45:04 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 1792 invoked by uid 200); 6 Apr 2001 16:45:04 -0000 Received: (qmail 1787 invoked from network); 6 Apr 2001 16:45:02 -0000 Received: from mgw-dax1.ext.nokia.com (63.78.179.216) by c900656-a.plstn1.sfba.home.com with SMTP; 6 Apr 2001 16:45:02 -0000 Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax1.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f36FsRg19346 for ; Fri, 6 Apr 2001 10:54:37 -0500 (CDT) Received: from daebh02nok.americas.nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Fri, 6 Apr 2001 10:52:53 -0500 Received: by daebh02nok with Internet Mail Service (5.5.2652.78) id ; Fri, 6 Apr 2001 10:52:53 -0500 Message-ID: <8572CF1E2A95D211A1190008C7EAA2460272091B@daeis05nok> From: khiem.le@nokia.com To: gkenward@nortelnetworks.com, khiem.le@nokia.com, tmima@cisco.com, mccap@research.bell-labs.com, rajeev.koodli@nokia.com Cc: kempf@heliopolis.Eng.Sun.COM, mobile-ip@sunroof.eng.sun.com, rohc@cdt.luth.se, seamoby@diameter.org Subject: RE: [seamoby] RE: [rohc] RE: Restarting Compressor on Mobile IPv6 Handover Date: Fri, 6 Apr 2001 10:52:51 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-seamoby@diameter.org Precedence: bulk Hi Gary, No this is not bicasting. The path taken by the packets (during the context establishment at the new compressor/decompressor) is as follows: -------> Old compressor/decompressor ----------> New compressor/decompressor -------------> MN <------ Old compressor/decompressor <---------- New compressor/decompressor <------------- MN Khiem -----Original Message----- From: ext Gary Kenward [mailto:gkenward@nortelnetworks.com] Sent: Wednesday, April 04, 2001 8:47 AM To: 'khiem.le@nokia.com'; tmima@cisco.com; mccap@research.bell-labs.com; rajeev.koodli@nokia.com Cc: kempf@heliopolis.Eng.Sun.COM; mobile-ip@sunroof.eng.sun.com; rohc@cdt.luth.se; seamoby@diameter.org Subject: RE: [seamoby] RE: [rohc] RE: Restarting Compressor on Mobile IPv6 Handover Many real time context synchronization problems can be solved through "bi-casting", which is, I believe, the essence of what you describe. Gary > -----Original Message----- > From: khiem.le@nokia.com [ mailto:khiem.le@nokia.com ] > Sent: Wednesday, April 04, 2001 12:16 AM > To: tmima@cisco.com; rajeev.koodli@nokia.com; > mccap@research.bell-labs.com; rajeev.koodli@nokia.com > Cc: kempf@heliopolis.Eng.Sun.COM; mobile-ip@sunroof.eng.sun.com; > rohc@cdt.luth.se; seamoby@diameter.org > Subject: RE: [seamoby] RE: [rohc] RE: Restarting Compressor on Mobile > IPv6 Handover > > > Hello Tmima, > > Your idea is very similar to the one I had some time ago (refer to > http://www.cdt.luth.se/robhc/msg01274.html ). > > Essentially the idea is to relax the timing constraints and > allow some time > to establish the context at the new compressor/decompressor. > During that > context establishment time, the packets transit through the new > compressor/decompressor, but also transit through the old > which continues to > do compression/decompression. Once the context is > established, the new can > take over the compression/decompression process. > > The old compressor/decompressor helps the new compressor/decompressor > establish its context by sending some context information. > One way (as you > described, correct me if I am wrong) is to take a snapshot of > the context > and send it. To maintain context synchronization between the > old and new, > the new may do some update of the received context snapshot > to account for > the fact that the context may have been updated by the old > after it took the > snapshot. However, the problem is that packets may be lost > when sent from > the old to the new. So the new may do a context update based > on packet j, > but that update was not done by the old, since packet j was > never received > by the old. One way to solve this problem is to modify the > mechanism to send > the context information from old to new. Instead of sending a context > snapshot, the old sends the context-related information in > pieces, so the > new can gradually build up its context. This corresponds to the > Relocation-deferred-after-Link-Switching (RDLS)scheme in > http://www.cdt.luth.se/robhc/msg01274.html . You can look at > it for details. > > The case where the old takes a snapshot of its context and > sends to the new > for immediate transfer of compression/decompression role > corresponds to > Relocation-concurrent-with-Link-Switching (RCLS). > > RDLS addresses the timing problem in a very reliable manner, > but is more > complex than RCLS. It also requires a higher capacity > connection between the > old and new. So each approach has its pros and cons. > > In any case, I believe the context transfer (whether RCLS or RDLS) is > doable, and the advantages over brute force reinitialization over the > wireless link outweigh the costs. > > Khiem > > > -----Original Message----- > > From: ext Tmima Koren [ mailto:tmima@cisco.com ] > > Sent: Tuesday, April 03, 2001 8:19 PM > > To: rajeev.koodli@nokia.com; mccap@research.bell-labs.com; > > rajeev.koodli@nokia.com > > Cc: kempf@heliopolis.Eng.Sun.COM; mobile-ip@sunroof.eng.sun.com; > > rohc@cdt.luth.se; seamoby@diameter.org > > Subject: RE: [seamoby] RE: [rohc] RE: Restarting Compressor > on Mobile > > IPv6 Handover > > > > > > I wonder if it's possible to do both: > > The new router sends a request for context transfer, but > continues to > > forward the compressed packets to the old router, AND queues > > a copy of the > > packets he forwarded. Once he receives the context, the new > > router applies > > the necessary changes to the context from the queued > packets. Now his > > context is good and he can continue decompressing. > > Tmima > > > > At 07:58 PM 4/3/2001 -0500, rajeev.koodli@nokia.com wrote: > > > > -----Original Message----- > > > > From: ext Pete McCann [ mailto:mccap@research.bell-labs.com ] > > > > Sent: Tuesday, April 03, 2001 5:30 PM > > > > To: rajeev.koodli@nokia.com > > > > Cc: kempf@heliopolis.Eng.Sun.COM; mobile-ip@sunroof.eng.sun.com; > > > > rohc@cdt.luth.se; seamoby@diameter.org > > > > Subject: RE: [seamoby] RE: [rohc] RE: Restarting > > Compressor on Mobile > > > > IPv6 Handover > > > > > > > > > > > > > > > > > > > > Yes, you would need to re-initialize the context over the > > air, but I > > > > don't think the bandwidth usage is high enough to matter. In a > > > > wide-area cellular environment IP handoffs will be relatively > > > > infrequent. The important consideration is the "glitch" > > experienced > > > > in voice traffic at handoff time, and this can be minimized by > > > > temporarily anchoring the compressor. > > > > > > > > > >I don't agree with you comments that you could ignore > > bandwidth usage and > > >assume infrequent handovers. > > > > > >a> 84 bytes of IPv6/UDP/RTP headers with Mobile-IPv6 Home > > Address option for > > >a voice payload of 20 - 30 bytes. Several such packets sent > > per each stream. > > > > > >b> With fast user mobility, each BTS/AP being a router, I > can imagine > > >frequent handovers. > > > > > >In any case, context relocation addresses a>, does not > > assume infrequent > > >handovers, as well as attempts to provide "glitch-free" > > voice. When the > > >context is already present at the target router before the > > MN starts sending > > >compressed packets, the application should not see the glitch. > > >I know there is work to be done here, so let's try to > focus on that! > > > > > >Regards, > > > > > >-Rajeev > > > > > > > > > > -Pete > > > > > > > > rajeev.koodli@nokia.com (rk) writes: > > > > > > > > rk> Hi, > > > > > > > > rk> How does this avoid the core problem of context > > > > rk> _re-initialization_ ? You would still need to send IR > > packets (to > > > > rk> new access router over the air interface) subsequent > > to handover > > > > rk> in order to start a new context.. Anchoring it at > > the previous > > > > rk> router may buy you some time, but not the bits. I reckon > > > > rk> anchoring will bring its own set of problems. > > > > > > > > rk> Regards, > > > > > > > > rk> -Rajeev > > > > > > > > > > > > >> -----Original Message----- > > > > >> From: ext Pete McCann [ mailto:mccap@research.bell-labs.com ] > > > > >> Sent: Tuesday, April 03, 2001 11:32 AM > > > > >> To: kempf@heliopolis.Eng.Sun.COM > > > > >> Cc: mobile-ip@sunroof.eng.sun.com; rohc@cdt.luth.se; > > > > >> seamoby@diameter.org > > > > >> Subject: RE: [seamoby] RE: [rohc] RE: Restarting > > > > Compressor on Mobile > > > > >> IPv6 Handover > > > > >> > > > > >> > > > > >> > > > > >> Hi, > > > > >> > > > > >> I think there is a simpler solution to this problem that > > > > most people > > > > >> are overlooking. > > > > >> > > > > >> It should be possible to keep the compressor/decompressor > > > > state at the > > > > >> old access router and to tunnel the already-compressed > > > > packets to and > > > > >> from the new access router. Then the MN and new > > access router can > > > > >> renegotiate header compression state from scratch and take > > > > as long as > > > > >> they want to do so, because the MN is still getting > > service in the > > > > >> meantime. > > > > >> > > > > >> Someone earlier asked about support for ROHC on IP tunnels > > > > and I think > > > > >> this would be a good application for that. > > > > >> > > > > >> We are trying to move the mountain to Mohammed and I don't > > > > see why we > > > > >> can't do the reverse instead. > > > > >> > > > > >> -Pete > > > > >> > > > > >> > > > > >> --- > > > > >> Mailing list for Robust Header Compression WG > > > > >> Archive: http://www.cdt.luth.se/rohc/ > > > > >> > > > > rk> --- > > > > rk> Mailing list for Robust Header Compression WG > > > > rk> Archive: http://www.cdt.luth.se/rohc/ > > > > > > > > --- > > Mailing list for Robust Header Compression WG > > Archive: http://www.cdt.luth.se/rohc/ > > > From owner-seamoby@diameter.org Fri Apr 6 12:05:04 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA13138 for ; Fri, 6 Apr 2001 12:05:02 -0400 (EDT) Received: (qmail 2278 invoked by alias); 6 Apr 2001 16:54:20 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 2272 invoked by uid 200); 6 Apr 2001 16:54:19 -0000 Received: (qmail 2267 invoked from network); 6 Apr 2001 16:54:17 -0000 Received: from c007-h008.c007.snv.cp.net (HELO c007.snv.cp.net) (209.228.33.214) by c900656-a.plstn1.sfba.home.com with SMTP; 6 Apr 2001 16:54:17 -0000 Received: (cpmta 22127 invoked from network); 6 Apr 2001 09:03:27 -0700 Received: from unknown (HELO philneum) (64.193.0.129) by smtp.telocity.com (209.228.33.214) with SMTP; 6 Apr 2001 09:03:27 -0700 X-Sent: 6 Apr 2001 16:03:27 GMT Message-ID: <02aa01c0beb2$fcba5560$6501a8c0@philneum> Reply-To: "Phil Neumiller" From: "Phil Neumiller" To: , , , , Cc: , , , References: <8572CF1E2A95D211A1190008C7EAA2460272091B@daeis05nok> Subject: Re: [seamoby] RE: [rohc] RE: Restarting Compressor on Mobile IPv6 Handover Date: Fri, 6 Apr 2001 11:02:30 -0500 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-seamoby@diameter.org Precedence: bulk I think Gary is right. How is the compression relevant if it is acting simply as a router? ----- Original Message ----- From: To: ; ; ; ; Cc: ; ; ; Sent: Friday, April 06, 2001 10:52 AM Subject: RE: [seamoby] RE: [rohc] RE: Restarting Compressor on Mobile IPv6 Handover > Hi Gary, > > No this is not bicasting. The path taken by the packets (during the context > establishment at the new compressor/decompressor) is as follows: > > > -------> Old compressor/decompressor ----------> New compressor/decompressor > -------------> MN > > <------ Old compressor/decompressor <---------- New compressor/decompressor > <------------- MN > > Khiem From owner-seamoby@diameter.org Fri Apr 6 12:09:58 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA13353 for ; Fri, 6 Apr 2001 12:09:56 -0400 (EDT) Received: (qmail 2714 invoked by alias); 6 Apr 2001 16:56:38 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 2709 invoked by uid 200); 6 Apr 2001 16:56:38 -0000 Received: (qmail 2704 invoked from network); 6 Apr 2001 16:56:36 -0000 Received: from sj-msg-core-4.cisco.com (171.71.163.10) by c900656-a.plstn1.sfba.home.com with SMTP; 6 Apr 2001 16:56:36 -0000 Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-4.cisco.com (8.9.3/8.9.1) with ESMTP id JAA02112; Fri, 6 Apr 2001 09:05:05 -0700 (PDT) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id ADQ06034; Fri, 6 Apr 2001 09:04:59 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id JAA05886; Fri, 6 Apr 2001 09:04:59 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15053.59691.250834.778697@thomasm-u1.cisco.com> Date: Fri, 6 Apr 2001 09:04:59 -0700 (PDT) To: khiem.le@nokia.com Cc: gkenward@nortelnetworks.com, tmima@cisco.com, mccap@research.bell-labs.com, rajeev.koodli@nokia.com, kempf@heliopolis.Eng.Sun.COM, mobile-ip@sunroof.eng.sun.com, rohc@cdt.luth.se, seamoby@diameter.org Subject: RE: [seamoby] RE: [rohc] RE: Restarting Compressor on Mobile IPv6 Handover In-Reply-To: <8572CF1E2A95D211A1190008C7EAA2460272091B@daeis05nok> References: <8572CF1E2A95D211A1190008C7EAA2460272091B@daeis05nok> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-seamoby@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit Can somebody explain to me how this has any possible applicability if you are using FMIP during the transition? FMIP requires a new tunnel for which there will be no compression state in the old access router. All of these interactions with MIP, FMIP, HMIP etc, etc make it look to me like this is a losing situation. It may be the better part of valor to say that fast/smooth handoffs are inherently more bandwidth consumptive and that one of the casualties is header compression state in the mean time. Trying to extend a point to point L2 compression mechanism across an arbitrary internet is just *bizzare*. L2TP is bad enough. Mike khiem.le@nokia.com writes: > Hi Gary, > > No this is not bicasting. The path taken by the packets (during the context > establishment at the new compressor/decompressor) is as follows: > > > -------> Old compressor/decompressor ----------> New compressor/decompressor > -------------> MN > > <------ Old compressor/decompressor <---------- New compressor/decompressor > <------------- MN > > Khiem > > -----Original Message----- > From: ext Gary Kenward [mailto:gkenward@nortelnetworks.com] > Sent: Wednesday, April 04, 2001 8:47 AM > To: 'khiem.le@nokia.com'; tmima@cisco.com; mccap@research.bell-labs.com; > rajeev.koodli@nokia.com > Cc: kempf@heliopolis.Eng.Sun.COM; mobile-ip@sunroof.eng.sun.com; > rohc@cdt.luth.se; seamoby@diameter.org > Subject: RE: [seamoby] RE: [rohc] RE: Restarting Compressor on Mobile IPv6 > Handover > > > > Many real time context synchronization problems can be solved > through "bi-casting", which is, I believe, the essence of what you > describe. > > Gary > > > -----Original Message----- > > From: khiem.le@nokia.com [ mailto:khiem.le@nokia.com > ] > > Sent: Wednesday, April 04, 2001 12:16 AM > > To: tmima@cisco.com; rajeev.koodli@nokia.com; > > mccap@research.bell-labs.com; rajeev.koodli@nokia.com > > Cc: kempf@heliopolis.Eng.Sun.COM; mobile-ip@sunroof.eng.sun.com; > > rohc@cdt.luth.se; seamoby@diameter.org > > Subject: RE: [seamoby] RE: [rohc] RE: Restarting Compressor on Mobile > > IPv6 Handover > > > > > > Hello Tmima, > > > > Your idea is very similar to the one I had some time ago (refer to > > http://www.cdt.luth.se/robhc/msg01274.html > ). > > > > Essentially the idea is to relax the timing constraints and > > allow some time > > to establish the context at the new compressor/decompressor. > > During that > > context establishment time, the packets transit through the new > > compressor/decompressor, but also transit through the old > > which continues to > > do compression/decompression. Once the context is > > established, the new can > > take over the compression/decompression process. > > > > The old compressor/decompressor helps the new compressor/decompressor > > establish its context by sending some context information. > > One way (as you > > described, correct me if I am wrong) is to take a snapshot of > > the context > > and send it. To maintain context synchronization between the > > old and new, > > the new may do some update of the received context snapshot > > to account for > > the fact that the context may have been updated by the old > > after it took the > > snapshot. However, the problem is that packets may be lost > > when sent from > > the old to the new. So the new may do a context update based > > on packet j, > > but that update was not done by the old, since packet j was > > never received > > by the old. One way to solve this problem is to modify the > > mechanism to send > > the context information from old to new. Instead of sending a context > > snapshot, the old sends the context-related information in > > pieces, so the > > new can gradually build up its context. This corresponds to the > > Relocation-deferred-after-Link-Switching (RDLS)scheme in > > http://www.cdt.luth.se/robhc/msg01274.html > . You can look at > > it for details. > > > > The case where the old takes a snapshot of its context and > > sends to the new > > for immediate transfer of compression/decompression role > > corresponds to > > Relocation-concurrent-with-Link-Switching (RCLS). > > > > RDLS addresses the timing problem in a very reliable manner, > > but is more > > complex than RCLS. It also requires a higher capacity > > connection between the > > old and new. So each approach has its pros and cons. > > > > In any case, I believe the context transfer (whether RCLS or RDLS) is > > doable, and the advantages over brute force reinitialization over the > > wireless link outweigh the costs. > > > > Khiem > > > > > -----Original Message----- > > > From: ext Tmima Koren [ mailto:tmima@cisco.com > ] > > > Sent: Tuesday, April 03, 2001 8:19 PM > > > To: rajeev.koodli@nokia.com; mccap@research.bell-labs.com; > > > rajeev.koodli@nokia.com > > > Cc: kempf@heliopolis.Eng.Sun.COM; mobile-ip@sunroof.eng.sun.com; > > > rohc@cdt.luth.se; seamoby@diameter.org > > > Subject: RE: [seamoby] RE: [rohc] RE: Restarting Compressor > > on Mobile > > > IPv6 Handover > > > > > > > > > I wonder if it's possible to do both: > > > The new router sends a request for context transfer, but > > continues to > > > forward the compressed packets to the old router, AND queues > > > a copy of the > > > packets he forwarded. Once he receives the context, the new > > > router applies > > > the necessary changes to the context from the queued > > packets. Now his > > > context is good and he can continue decompressing. > > > Tmima > > > > > > At 07:58 PM 4/3/2001 -0500, rajeev.koodli@nokia.com wrote: > > > > > -----Original Message----- > > > > > From: ext Pete McCann [ mailto:mccap@research.bell-labs.com > ] > > > > > Sent: Tuesday, April 03, 2001 5:30 PM > > > > > To: rajeev.koodli@nokia.com > > > > > Cc: kempf@heliopolis.Eng.Sun.COM; mobile-ip@sunroof.eng.sun.com; > > > > > rohc@cdt.luth.se; seamoby@diameter.org > > > > > Subject: RE: [seamoby] RE: [rohc] RE: Restarting > > > Compressor on Mobile > > > > > IPv6 Handover > > > > > > > > > > > > > > > > > > > > > > > > > Yes, you would need to re-initialize the context over the > > > air, but I > > > > > don't think the bandwidth usage is high enough to matter. In a > > > > > wide-area cellular environment IP handoffs will be relatively > > > > > infrequent. The important consideration is the "glitch" > > > experienced > > > > > in voice traffic at handoff time, and this can be minimized by > > > > > temporarily anchoring the compressor. > > > > > > > > > > > > >I don't agree with you comments that you could ignore > > > bandwidth usage and > > > >assume infrequent handovers. > > > > > > > >a> 84 bytes of IPv6/UDP/RTP headers with Mobile-IPv6 Home > > > Address option for > > > >a voice payload of 20 - 30 bytes. Several such packets sent > > > per each stream. > > > > > > > >b> With fast user mobility, each BTS/AP being a router, I > > can imagine > > > >frequent handovers. > > > > > > > >In any case, context relocation addresses a>, does not > > > assume infrequent > > > >handovers, as well as attempts to provide "glitch-free" > > > voice. When the > > > >context is already present at the target router before the > > > MN starts sending > > > >compressed packets, the application should not see the glitch. > > > >I know there is work to be done here, so let's try to > > focus on that! > > > > > > > >Regards, > > > > > > > >-Rajeev > > > > > > > > > > > > > -Pete > > > > > > > > > > rajeev.koodli@nokia.com (rk) writes: > > > > > > > > > > rk> Hi, > > > > > > > > > > rk> How does this avoid the core problem of context > > > > > rk> _re-initialization_ ? You would still need to send IR > > > packets (to > > > > > rk> new access router over the air interface) subsequent > > > to handover > > > > > rk> in order to start a new context.. Anchoring it at > > > the previous > > > > > rk> router may buy you some time, but not the bits. I reckon > > > > > rk> anchoring will bring its own set of problems. > > > > > > > > > > rk> Regards, > > > > > > > > > > rk> -Rajeev > > > > > > > > > > > > > > > >> -----Original Message----- > > > > > >> From: ext Pete McCann [ mailto:mccap@research.bell-labs.com > ] > > > > > >> Sent: Tuesday, April 03, 2001 11:32 AM > > > > > >> To: kempf@heliopolis.Eng.Sun.COM > > > > > >> Cc: mobile-ip@sunroof.eng.sun.com; rohc@cdt.luth.se; > > > > > >> seamoby@diameter.org > > > > > >> Subject: RE: [seamoby] RE: [rohc] RE: Restarting > > > > > Compressor on Mobile > > > > > >> IPv6 Handover > > > > > >> > > > > > >> > > > > > >> > > > > > >> Hi, > > > > > >> > > > > > >> I think there is a simpler solution to this problem that > > > > > most people > > > > > >> are overlooking. > > > > > >> > > > > > >> It should be possible to keep the compressor/decompressor > > > > > state at the > > > > > >> old access router and to tunnel the already-compressed > > > > > packets to and > > > > > >> from the new access router. Then the MN and new > > > access router can > > > > > >> renegotiate header compression state from scratch and take > > > > > as long as > > > > > >> they want to do so, because the MN is still getting > > > service in the > > > > > >> meantime. > > > > > >> > > > > > >> Someone earlier asked about support for ROHC on IP tunnels > > > > > and I think > > > > > >> this would be a good application for that. > > > > > >> > > > > > >> We are trying to move the mountain to Mohammed and I don't > > > > > see why we > > > > > >> can't do the reverse instead. > > > > > >> > > > > > >> -Pete > > > > > >> > > > > > >> > > > > > >> --- > > > > > >> Mailing list for Robust Header Compression WG > > > > > >> Archive: http://www.cdt.luth.se/rohc/ > > > > > > >> > > > > > rk> --- > > > > > rk> Mailing list for Robust Header Compression WG > > > > > rk> Archive: http://www.cdt.luth.se/rohc/ > > > > > > > > > > > > --- > > > Mailing list for Robust Header Compression WG > > > Archive: http://www.cdt.luth.se/rohc/ > > > > > > From owner-seamoby@diameter.org Fri Apr 6 13:48:16 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA15471 for ; Fri, 6 Apr 2001 13:48:15 -0400 (EDT) Received: (qmail 4693 invoked by alias); 6 Apr 2001 18:37:24 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 4687 invoked by uid 200); 6 Apr 2001 18:37:23 -0000 Received: (qmail 4682 invoked from network); 6 Apr 2001 18:37:21 -0000 Received: from sj-msg-core-4.cisco.com (171.71.163.10) by c900656-a.plstn1.sfba.home.com with SMTP; 6 Apr 2001 18:37:21 -0000 Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-4.cisco.com (8.9.3/8.9.1) with ESMTP id KAA07101; Fri, 6 Apr 2001 10:46:07 -0700 (PDT) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id ADQ08695; Fri, 6 Apr 2001 10:46:01 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id KAA05908; Fri, 6 Apr 2001 10:46:00 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15054.216.855827.88928@thomasm-u1.cisco.com> Date: Fri, 6 Apr 2001 10:46:00 -0700 (PDT) To: Cc: mat@cisco.com, khiem.le@nokia.com, gkenward@nortelnetworks.com, tmima@cisco.com, mccap@research.bell-labs.com, kempf@heliopolis.Eng.Sun.COM, mobile-ip@sunroof.eng.sun.com, rohc@cdt.luth.se, seamoby@diameter.org Subject: RE: [seamoby] RE: [rohc] RE: Restarting Compressor on Mobile IPv6 Handover In-Reply-To: References: X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-seamoby@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit rajeev.koodli@nokia.com writes: > > From: ext Michael Thomas [mailto:mat@cisco.com] > > Can somebody explain to me how this has any > > possible applicability if you are using FMIP > > during the transition? FMIP requires a new tunnel > > for which there will be no compression state in > > the old access router. > > > > If there is no compression state at the old router, why would you try to > relocate it ? There's compression state there, but not the compression state that matters: when I'm receiving packets from the old AR during the FMIP transition time, there will be a *new* IP header appended toward the MN. This is because those packets will have to be tunneled to the MN. This means that it is a *new* compression context, not an old existing one. > > All of these interactions with MIP, FMIP, HMIP > > etc, etc make it look to me like this is a losing > > situation. It may be the better part of valor to > > say that fast/smooth handoffs are inherently more > > bandwidth consumptive and that one of the > > casualties is header compression state in the mean > > time. > > Can you justify your claim above ? I can't prove negatives. I'm afraid that it is your place to prove that context transfer of header compression state in the face of all of these extenuating circumstances is still worthwhile. > >Trying to extend a point to point L2 > > compression mechanism across an arbitrary internet > > is just *bizzare*. L2TP is bad enough. > > > > You are compressing IP and transport headers! This should work on ANY link. > That's why you try to CT header compression state. Get it ? Oh sure, I get it... I "get" VoMPLS too, but that doesn't make it any less bizarre. Mike From owner-seamoby@diameter.org Fri Apr 6 13:59:54 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA15789 for ; Fri, 6 Apr 2001 13:59:53 -0400 (EDT) Received: (qmail 4178 invoked by alias); 6 Apr 2001 18:24:15 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 4172 invoked by uid 200); 6 Apr 2001 18:24:15 -0000 Received: (qmail 4167 invoked from network); 6 Apr 2001 18:24:13 -0000 Received: from mgw-dax1.ext.nokia.com (63.78.179.216) by c900656-a.plstn1.sfba.home.com with SMTP; 6 Apr 2001 18:24:13 -0000 Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85]) by mgw-dax1.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f36HXWg07300 for ; Fri, 6 Apr 2001 12:33:32 -0500 (CDT) Received: from daebh02nok.americas.nokia.com (unverified) by davir02nok.americas.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Fri, 6 Apr 2001 12:32:24 -0500 Received: by daebh02nok with Internet Mail Service (5.5.2652.78) id ; Fri, 6 Apr 2001 12:32:24 -0500 Message-ID: From: rajeev.koodli@nokia.com To: mat@cisco.com, khiem.le@nokia.com Cc: gkenward@nortelnetworks.com, tmima@cisco.com, mccap@research.bell-labs.com, rajeev.koodli@nokia.com, kempf@heliopolis.Eng.Sun.COM, mobile-ip@sunroof.eng.sun.com, rohc@cdt.luth.se, seamoby@diameter.org Subject: RE: [seamoby] RE: [rohc] RE: Restarting Compressor on Mobile IPv6 Handover Date: Fri, 6 Apr 2001 12:32:23 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-seamoby@diameter.org Precedence: bulk Hello, > -----Original Message----- > From: ext Michael Thomas [mailto:mat@cisco.com] > Sent: Friday, April 06, 2001 9:05 AM > To: khiem.le@nokia.com > Cc: gkenward@nortelnetworks.com; tmima@cisco.com; > mccap@research.bell-labs.com; rajeev.koodli@nokia.com; > kempf@heliopolis.Eng.Sun.COM; mobile-ip@sunroof.eng.sun.com; > rohc@cdt.luth.se; seamoby@diameter.org > Subject: RE: [seamoby] RE: [rohc] RE: Restarting Compressor on Mobile > IPv6 Handover > > > > Can somebody explain to me how this has any > possible applicability if you are using FMIP > during the transition? FMIP requires a new tunnel > for which there will be no compression state in > the old access router. > If there is no compression state at the old router, why would you try to relocate it ? > All of these interactions with MIP, FMIP, HMIP > etc, etc make it look to me like this is a losing > situation. It may be the better part of valor to > say that fast/smooth handoffs are inherently more > bandwidth consumptive and that one of the > casualties is header compression state in the mean > time. Can you justify your claim above ? >Trying to extend a point to point L2 > compression mechanism across an arbitrary internet > is just *bizzare*. L2TP is bad enough. > You are compressing IP and transport headers! This should work on ANY link. That's why you try to CT header compression state. Get it ? Regards, -Rajeev > Mike > > khiem.le@nokia.com writes: > > Hi Gary, > > > > No this is not bicasting. The path taken by the packets > (during the context > > establishment at the new compressor/decompressor) is as follows: > > > > > > -------> Old compressor/decompressor ----------> New > compressor/decompressor > > -------------> MN > > > > <------ Old compressor/decompressor <---------- New > compressor/decompressor > > <------------- MN > > > > Khiem > > > > -----Original Message----- > > From: ext Gary Kenward [mailto:gkenward@nortelnetworks.com] > > Sent: Wednesday, April 04, 2001 8:47 AM > > To: 'khiem.le@nokia.com'; tmima@cisco.com; > mccap@research.bell-labs.com; > > rajeev.koodli@nokia.com > > Cc: kempf@heliopolis.Eng.Sun.COM; mobile-ip@sunroof.eng.sun.com; > > rohc@cdt.luth.se; seamoby@diameter.org > > Subject: RE: [seamoby] RE: [rohc] RE: Restarting > Compressor on Mobile IPv6 > > Handover > > > > > > > > Many real time context synchronization problems can be solved > > through "bi-casting", which is, I believe, the essence of what you > > describe. > > > > Gary > > > > > -----Original Message----- > > > From: khiem.le@nokia.com [ mailto:khiem.le@nokia.com > > ] > > > Sent: Wednesday, April 04, 2001 12:16 AM > > > To: tmima@cisco.com; rajeev.koodli@nokia.com; > > > mccap@research.bell-labs.com; rajeev.koodli@nokia.com > > > Cc: kempf@heliopolis.Eng.Sun.COM; mobile-ip@sunroof.eng.sun.com; > > > rohc@cdt.luth.se; seamoby@diameter.org > > > Subject: RE: [seamoby] RE: [rohc] RE: Restarting > Compressor on Mobile > > > IPv6 Handover > > > > > > > > > Hello Tmima, > > > > > > Your idea is very similar to the one I had some time ago > (refer to > > > http://www.cdt.luth.se/robhc/msg01274.html > > ). > > > > > > Essentially the idea is to relax the timing constraints and > > > allow some time > > > to establish the context at the new compressor/decompressor. > > > During that > > > context establishment time, the packets transit through the new > > > compressor/decompressor, but also transit through the old > > > which continues to > > > do compression/decompression. Once the context is > > > established, the new can > > > take over the compression/decompression process. > > > > > > The old compressor/decompressor helps the new > compressor/decompressor > > > establish its context by sending some context information. > > > One way (as you > > > described, correct me if I am wrong) is to take a snapshot of > > > the context > > > and send it. To maintain context synchronization between the > > > old and new, > > > the new may do some update of the received context snapshot > > > to account for > > > the fact that the context may have been updated by the old > > > after it took the > > > snapshot. However, the problem is that packets may be lost > > > when sent from > > > the old to the new. So the new may do a context update based > > > on packet j, > > > but that update was not done by the old, since packet j was > > > never received > > > by the old. One way to solve this problem is to modify the > > > mechanism to send > > > the context information from old to new. Instead of > sending a context > > > snapshot, the old sends the context-related information in > > > pieces, so the > > > new can gradually build up its context. This corresponds to the > > > Relocation-deferred-after-Link-Switching (RDLS)scheme in > > > http://www.cdt.luth.se/robhc/msg01274.html > > . You can look at > > > it for details. > > > > > > The case where the old takes a snapshot of its context and > > > sends to the new > > > for immediate transfer of compression/decompression role > > > corresponds to > > > Relocation-concurrent-with-Link-Switching (RCLS). > > > > > > RDLS addresses the timing problem in a very reliable manner, > > > but is more > > > complex than RCLS. It also requires a higher capacity > > > connection between the > > > old and new. So each approach has its pros and cons. > > > > > > In any case, I believe the context transfer (whether > RCLS or RDLS) is > > > doable, and the advantages over brute force > reinitialization over the > > > wireless link outweigh the costs. > > > > > > Khiem > > > > > > > -----Original Message----- > > > > From: ext Tmima Koren [ mailto:tmima@cisco.com > > > ] > > > > Sent: Tuesday, April 03, 2001 8:19 PM > > > > To: rajeev.koodli@nokia.com; mccap@research.bell-labs.com; > > > > rajeev.koodli@nokia.com > > > > Cc: kempf@heliopolis.Eng.Sun.COM; > mobile-ip@sunroof.eng.sun.com; > > > > rohc@cdt.luth.se; seamoby@diameter.org > > > > Subject: RE: [seamoby] RE: [rohc] RE: Restarting Compressor > > > on Mobile > > > > IPv6 Handover > > > > > > > > > > > > I wonder if it's possible to do both: > > > > The new router sends a request for context transfer, but > > > continues to > > > > forward the compressed packets to the old router, AND queues > > > > a copy of the > > > > packets he forwarded. Once he receives the context, the new > > > > router applies > > > > the necessary changes to the context from the queued > > > packets. Now his > > > > context is good and he can continue decompressing. > > > > Tmima > > > > > > > > At 07:58 PM 4/3/2001 -0500, rajeev.koodli@nokia.com wrote: > > > > > > -----Original Message----- > > > > > > From: ext Pete McCann [ mailto:mccap@research.bell-labs.com > > ] > > > > > > Sent: Tuesday, April 03, 2001 5:30 PM > > > > > > To: rajeev.koodli@nokia.com > > > > > > Cc: kempf@heliopolis.Eng.Sun.COM; > mobile-ip@sunroof.eng.sun.com; > > > > > > rohc@cdt.luth.se; seamoby@diameter.org > > > > > > Subject: RE: [seamoby] RE: [rohc] RE: Restarting > > > > Compressor on Mobile > > > > > > IPv6 Handover > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Yes, you would need to re-initialize the context over the > > > > air, but I > > > > > > don't think the bandwidth usage is high enough to > matter. In a > > > > > > wide-area cellular environment IP handoffs will be > relatively > > > > > > infrequent. The important consideration is the "glitch" > > > > experienced > > > > > > in voice traffic at handoff time, and this can be > minimized by > > > > > > temporarily anchoring the compressor. > > > > > > > > > > > > > > > >I don't agree with you comments that you could ignore > > > > bandwidth usage and > > > > >assume infrequent handovers. > > > > > > > > > >a> 84 bytes of IPv6/UDP/RTP headers with Mobile-IPv6 Home > > > > Address option for > > > > >a voice payload of 20 - 30 bytes. Several such packets sent > > > > per each stream. > > > > > > > > > >b> With fast user mobility, each BTS/AP being a router, I > > > can imagine > > > > >frequent handovers. > > > > > > > > > >In any case, context relocation addresses a>, does not > > > > assume infrequent > > > > >handovers, as well as attempts to provide "glitch-free" > > > > voice. When the > > > > >context is already present at the target router before the > > > > MN starts sending > > > > >compressed packets, the application should not see > the glitch. > > > > >I know there is work to be done here, so let's try to > > > focus on that! > > > > > > > > > >Regards, > > > > > > > > > >-Rajeev > > > > > > > > > > > > > > > > -Pete > > > > > > > > > > > > rajeev.koodli@nokia.com (rk) writes: > > > > > > > > > > > > rk> Hi, > > > > > > > > > > > > rk> How does this avoid the core problem of context > > > > > > rk> _re-initialization_ ? You would still need to send IR > > > > packets (to > > > > > > rk> new access router over the air interface) subsequent > > > > to handover > > > > > > rk> in order to start a new context.. Anchoring it at > > > > the previous > > > > > > rk> router may buy you some time, but not the > bits. I reckon > > > > > > rk> anchoring will bring its own set of problems. > > > > > > > > > > > > rk> Regards, > > > > > > > > > > > > rk> -Rajeev > > > > > > > > > > > > > > > > > > >> -----Original Message----- > > > > > > >> From: ext Pete McCann [ mailto:mccap@research.bell-labs.com > ] > > > > > >> Sent: Tuesday, April 03, 2001 11:32 AM > > > > > >> To: kempf@heliopolis.Eng.Sun.COM > > > > > >> Cc: mobile-ip@sunroof.eng.sun.com; rohc@cdt.luth.se; > > > > > >> seamoby@diameter.org > > > > > >> Subject: RE: [seamoby] RE: [rohc] RE: Restarting > > > > > Compressor on Mobile > > > > > >> IPv6 Handover > > > > > >> > > > > > >> > > > > > >> > > > > > >> Hi, > > > > > >> > > > > > >> I think there is a simpler solution to this problem that > > > > > most people > > > > > >> are overlooking. > > > > > >> > > > > > >> It should be possible to keep the compressor/decompressor > > > > > state at the > > > > > >> old access router and to tunnel the already-compressed > > > > > packets to and > > > > > >> from the new access router. Then the MN and new > > > access router can > > > > > >> renegotiate header compression state from scratch and take > > > > > as long as > > > > > >> they want to do so, because the MN is still getting > > > service in the > > > > > >> meantime. > > > > > >> > > > > > >> Someone earlier asked about support for ROHC on IP tunnels > > > > > and I think > > > > > >> this would be a good application for that. > > > > > >> > > > > > >> We are trying to move the mountain to Mohammed and I don't > > > > > see why we > > > > > >> can't do the reverse instead. > > > > > >> > > > > > >> -Pete > > > > > >> > > > > > >> > > > > > >> --- > > > > > >> Mailing list for Robust Header Compression WG > > > > > >> Archive: http://www.cdt.luth.se/rohc/ > > > > > > >> > > > > > rk> --- > > > > > rk> Mailing list for Robust Header Compression WG > > > > > rk> Archive: http://www.cdt.luth.se/rohc/ > > > > > > > > > > > > --- > > > Mailing list for Robust Header Compression WG > > > Archive: http://www.cdt.luth.se/rohc/ > > > > > > From owner-seamoby@diameter.org Fri Apr 6 14:15:09 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA16267 for ; Fri, 6 Apr 2001 14:15:08 -0400 (EDT) Received: (qmail 5435 invoked by alias); 6 Apr 2001 19:04:17 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 5428 invoked by uid 200); 6 Apr 2001 19:04:16 -0000 Received: (qmail 5423 invoked from network); 6 Apr 2001 19:04:14 -0000 Received: from mgw-dax1.ext.nokia.com (63.78.179.216) by c900656-a.plstn1.sfba.home.com with SMTP; 6 Apr 2001 19:04:14 -0000 Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax1.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f36IDwg13497 for ; Fri, 6 Apr 2001 13:13:58 -0500 (CDT) Received: from daebh01nok.americas.nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Fri, 6 Apr 2001 13:13:13 -0500 Received: by daebh01nok with Internet Mail Service (5.5.2652.78) id ; Fri, 6 Apr 2001 13:13:13 -0500 Message-ID: From: rajeev.koodli@nokia.com To: mat@cisco.com, rajeev.koodli@nokia.com Cc: khiem.le@nokia.com, gkenward@nortelnetworks.com, tmima@cisco.com, mccap@research.bell-labs.com, kempf@heliopolis.Eng.Sun.COM, mobile-ip@sunroof.eng.sun.com, rohc@cdt.luth.se, seamoby@diameter.org Subject: RE: [seamoby] RE: [rohc] RE: Restarting Compressor on Mobile IPv6 Handover Date: Fri, 6 Apr 2001 13:13:11 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-seamoby@diameter.org Precedence: bulk > > > rajeev.koodli@nokia.com writes: > > > From: ext Michael Thomas [mailto:mat@cisco.com] > > > > Can somebody explain to me how this has any > > > possible applicability if you are using FMIP > > > during the transition? FMIP requires a new tunnel > > > for which there will be no compression state in > > > the old access router. > > > > > > > If there is no compression state at the old router, why > would you try to > > relocate it ? > > There's compression state there, but not the > compression state that matters: when I'm > receiving packets from the old AR during the > FMIP transition time, there will be a *new* > IP header appended toward the MN. This is > because those packets will have to be tunneled to the > MN. This means that it is a *new* compression > context, not an old existing one. > I don't have sufficient details to comment.. > > > All of these interactions with MIP, FMIP, HMIP > > > etc, etc make it look to me like this is a losing > > > situation. It may be the better part of valor to > > > say that fast/smooth handoffs are inherently more > > > bandwidth consumptive and that one of the > > > casualties is header compression state in the mean > > > time. > > > > Can you justify your claim above ? > > I can't prove negatives. I'm afraid that it > is your place to prove that context transfer > of header compression state in the face of all > of these extenuating circumstances is still > worthwhile. > You can't justify your claims. So, before you raise issues (related/unrelated), try to make an effort to understand the work done by others. As far as I am concerned, how about all the e-mail discussion during the last two weeks ? Please take a look! > > >Trying to extend a point to point L2 > > > compression mechanism across an arbitrary internet > > > is just *bizzare*. L2TP is bad enough. > > > > > > > You are compressing IP and transport headers! This should > work on ANY link. > > That's why you try to CT header compression state. Get it ? > > Oh sure, I get it... I "get" VoMPLS too, but > that doesn't make it any less bizarre. > If you got it, you would probably re-think! If you were to re-think and understand the issues, you would probably question yourself what's bizarre, and then write. -Rajeev > Mike > From owner-seamoby@diameter.org Fri Apr 6 15:00:32 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA17464 for ; Fri, 6 Apr 2001 15:00:13 -0400 (EDT) Received: (qmail 6212 invoked by alias); 6 Apr 2001 19:21:06 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 6206 invoked by uid 200); 6 Apr 2001 19:21:05 -0000 Received: (qmail 6201 invoked from network); 6 Apr 2001 19:21:03 -0000 Received: from zcars04e.nortelnetworks.com (47.129.242.56) by c900656-a.plstn1.sfba.home.com with SMTP; 6 Apr 2001 19:21:03 -0000 Received: from zcard015.ca.nortel.com (actually zcard015) by zcars04e.nortelnetworks.com; Fri, 6 Apr 2001 14:29:33 -0400 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 6 Apr 2001 14:29:33 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C12576A@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'khiem.le@nokia.com'" , tmima@cisco.com, mccap@research.bell-labs.com, rajeev.koodli@nokia.com Cc: kempf@heliopolis.Eng.Sun.COM, mobile-ip@sunroof.eng.sun.com, rohc@cdt.luth.se, seamoby@diameter.org Subject: RE: [seamoby] RE: [rohc] RE: Restarting Compressor on Mobile IPv6 Handover Date: Fri, 6 Apr 2001 14:29:33 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0BEC7.86C264F0" X-Orig: Sender: owner-seamoby@diameter.org Precedence: bulk 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_01C0BEC7.86C264F0 Content-Type: text/plain; charset="iso-8859-1" Khiem: You are right, it is not bicasting. I misunderstood. However, the approach is the same, with the complication that now you have a triangular route to clean up. Is there an advantage? Gary > -----Original Message----- > From: khiem.le@nokia.com [mailto:khiem.le@nokia.com] > Sent: Friday, April 06, 2001 11:53 AM > To: Kenward, Gary [WDLN2:AN10:EXCH]; khiem.le@nokia.com; > tmima@cisco.com; mccap@research.bell-labs.com; rajeev.koodli@nokia.com > Cc: kempf@heliopolis.Eng.Sun.COM; mobile-ip@sunroof.eng.sun.com; > rohc@cdt.luth.se; seamoby@diameter.org > Subject: RE: [seamoby] RE: [rohc] RE: Restarting Compressor on Mobile > IPv6 Handover > > > Hi Gary, > > No this is not bicasting. The path taken by the packets > (during the context > establishment at the new compressor/decompressor) is as follows: > > > -------> Old compressor/decompressor ----------> New > compressor/decompressor > -------------> MN > > <------ Old compressor/decompressor <---------- New > compressor/decompressor > <------------- MN > > Khiem > > -----Original Message----- > From: ext Gary Kenward [mailto:gkenward@nortelnetworks.com] > Sent: Wednesday, April 04, 2001 8:47 AM > To: 'khiem.le@nokia.com'; tmima@cisco.com; > mccap@research.bell-labs.com; > rajeev.koodli@nokia.com > Cc: kempf@heliopolis.Eng.Sun.COM; mobile-ip@sunroof.eng.sun.com; > rohc@cdt.luth.se; seamoby@diameter.org > Subject: RE: [seamoby] RE: [rohc] RE: Restarting Compressor > on Mobile IPv6 > Handover > > > > Many real time context synchronization problems can be solved > through "bi-casting", which is, I believe, the essence of what you > describe. > > Gary > > > -----Original Message----- > > From: khiem.le@nokia.com [ mailto:khiem.le@nokia.com > ] > > Sent: Wednesday, April 04, 2001 12:16 AM > > To: tmima@cisco.com; rajeev.koodli@nokia.com; > > mccap@research.bell-labs.com; rajeev.koodli@nokia.com > > Cc: kempf@heliopolis.Eng.Sun.COM; mobile-ip@sunroof.eng.sun.com; > > rohc@cdt.luth.se; seamoby@diameter.org > > Subject: RE: [seamoby] RE: [rohc] RE: Restarting Compressor > on Mobile > > IPv6 Handover > > > > > > Hello Tmima, > > > > Your idea is very similar to the one I had some time ago (refer to > > http://www.cdt.luth.se/robhc/msg01274.html > ). > > > > Essentially the idea is to relax the timing constraints and > > allow some time > > to establish the context at the new compressor/decompressor. > > During that > > context establishment time, the packets transit through the new > > compressor/decompressor, but also transit through the old > > which continues to > > do compression/decompression. Once the context is > > established, the new can > > take over the compression/decompression process. > > > > The old compressor/decompressor helps the new > compressor/decompressor > > establish its context by sending some context information. > > One way (as you > > described, correct me if I am wrong) is to take a snapshot of > > the context > > and send it. To maintain context synchronization between the > > old and new, > > the new may do some update of the received context snapshot > > to account for > > the fact that the context may have been updated by the old > > after it took the > > snapshot. However, the problem is that packets may be lost > > when sent from > > the old to the new. So the new may do a context update based > > on packet j, > > but that update was not done by the old, since packet j was > > never received > > by the old. One way to solve this problem is to modify the > > mechanism to send > > the context information from old to new. Instead of sending > a context > > snapshot, the old sends the context-related information in > > pieces, so the > > new can gradually build up its context. This corresponds to the > > Relocation-deferred-after-Link-Switching (RDLS)scheme in > > http://www.cdt.luth.se/robhc/msg01274.html > . You can look at > > it for details. > > > > The case where the old takes a snapshot of its context and > > sends to the new > > for immediate transfer of compression/decompression role > > corresponds to > > Relocation-concurrent-with-Link-Switching (RCLS). > > > > RDLS addresses the timing problem in a very reliable manner, > > but is more > > complex than RCLS. It also requires a higher capacity > > connection between the > > old and new. So each approach has its pros and cons. > > > > In any case, I believe the context transfer (whether RCLS > or RDLS) is > > doable, and the advantages over brute force > reinitialization over the > > wireless link outweigh the costs. > > > > Khiem > > > > > -----Original Message----- > > > From: ext Tmima Koren [ mailto:tmima@cisco.com > > ] > > > Sent: Tuesday, April 03, 2001 8:19 PM > > > To: rajeev.koodli@nokia.com; mccap@research.bell-labs.com; > > > rajeev.koodli@nokia.com > > > Cc: kempf@heliopolis.Eng.Sun.COM; mobile-ip@sunroof.eng.sun.com; > > > rohc@cdt.luth.se; seamoby@diameter.org > > > Subject: RE: [seamoby] RE: [rohc] RE: Restarting Compressor > > on Mobile > > > IPv6 Handover > > > > > > > > > I wonder if it's possible to do both: > > > The new router sends a request for context transfer, but > > continues to > > > forward the compressed packets to the old router, AND queues > > > a copy of the > > > packets he forwarded. Once he receives the context, the new > > > router applies > > > the necessary changes to the context from the queued > > packets. Now his > > > context is good and he can continue decompressing. > > > Tmima > > > > > > At 07:58 PM 4/3/2001 -0500, rajeev.koodli@nokia.com wrote: > > > > > -----Original Message----- > > > > > From: ext Pete McCann [ mailto:mccap@research.bell-labs.com > ] > > > > > Sent: Tuesday, April 03, 2001 5:30 PM > > > > > To: rajeev.koodli@nokia.com > > > > > Cc: kempf@heliopolis.Eng.Sun.COM; > mobile-ip@sunroof.eng.sun.com; > > > > > rohc@cdt.luth.se; seamoby@diameter.org > > > > > Subject: RE: [seamoby] RE: [rohc] RE: Restarting > > > Compressor on Mobile > > > > > IPv6 Handover > > > > > > > > > > > > > > > > > > > > > > > > > Yes, you would need to re-initialize the context over the > > > air, but I > > > > > don't think the bandwidth usage is high enough to > matter. In a > > > > > wide-area cellular environment IP handoffs will be relatively > > > > > infrequent. The important consideration is the "glitch" > > > experienced > > > > > in voice traffic at handoff time, and this can be > minimized by > > > > > temporarily anchoring the compressor. > > > > > > > > > > > > >I don't agree with you comments that you could ignore > > > bandwidth usage and > > > >assume infrequent handovers. > > > > > > > >a> 84 bytes of IPv6/UDP/RTP headers with Mobile-IPv6 Home > > > Address option for > > > >a voice payload of 20 - 30 bytes. Several such packets sent > > > per each stream. > > > > > > > >b> With fast user mobility, each BTS/AP being a router, I > > can imagine > > > >frequent handovers. > > > > > > > >In any case, context relocation addresses a>, does not > > > assume infrequent > > > >handovers, as well as attempts to provide "glitch-free" > > > voice. When the > > > >context is already present at the target router before the > > > MN starts sending > > > >compressed packets, the application should not see the glitch. > > > >I know there is work to be done here, so let's try to > > focus on that! > > > > > > > >Regards, > > > > > > > >-Rajeev > > > > > > > > > > > > > -Pete > > > > > > > > > > rajeev.koodli@nokia.com (rk) writes: > > > > > > > > > > rk> Hi, > > > > > > > > > > rk> How does this avoid the core problem of context > > > > > rk> _re-initialization_ ? You would still need to send IR > > > packets (to > > > > > rk> new access router over the air interface) subsequent > > > to handover > > > > > rk> in order to start a new context.. Anchoring it at > > > the previous > > > > > rk> router may buy you some time, but not the bits. I reckon > > > > > rk> anchoring will bring its own set of problems. > > > > > > > > > > rk> Regards, > > > > > > > > > > rk> -Rajeev > > > > > > > > > > > > > > > >> -----Original Message----- > > > > > >> From: ext Pete McCann [ mailto:mccap@research.bell-labs.com > ] > > > > > >> Sent: Tuesday, April 03, 2001 11:32 AM > > > > > >> To: kempf@heliopolis.Eng.Sun.COM > > > > > >> Cc: mobile-ip@sunroof.eng.sun.com; rohc@cdt.luth.se; > > > > > >> seamoby@diameter.org > > > > > >> Subject: RE: [seamoby] RE: [rohc] RE: Restarting > > > > > Compressor on Mobile > > > > > >> IPv6 Handover > > > > > >> > > > > > >> > > > > > >> > > > > > >> Hi, > > > > > >> > > > > > >> I think there is a simpler solution to this problem that > > > > > most people > > > > > >> are overlooking. > > > > > >> > > > > > >> It should be possible to keep the compressor/decompressor > > > > > state at the > > > > > >> old access router and to tunnel the already-compressed > > > > > packets to and > > > > > >> from the new access router. Then the MN and new > > > access router can > > > > > >> renegotiate header compression state from scratch and take > > > > > as long as > > > > > >> they want to do so, because the MN is still getting > > > service in the > > > > > >> meantime. > > > > > >> > > > > > >> Someone earlier asked about support for ROHC on IP tunnels > > > > > and I think > > > > > >> this would be a good application for that. > > > > > >> > > > > > >> We are trying to move the mountain to Mohammed and I don't > > > > > see why we > > > > > >> can't do the reverse instead. > > > > > >> > > > > > >> -Pete > > > > > >> > > > > > >> > > > > > >> --- > > > > > >> Mailing list for Robust Header Compression WG > > > > > >> Archive: http://www.cdt.luth.se/rohc/ > > > > > > >> > > > > > rk> --- > > > > > rk> Mailing list for Robust Header Compression WG > > > > > rk> Archive: http://www.cdt.luth.se/rohc/ > > > > > > > > > > > > --- > > > Mailing list for Robust Header Compression WG > > > Archive: http://www.cdt.luth.se/rohc/ > > > ------_=_NextPart_001_01C0BEC7.86C264F0 Content-Type: text/html; charset="iso-8859-1" RE: [seamoby] RE: [rohc] RE: Restarting Compressor on Mobile IPv6 Handover

Khiem:

  You are right, it is not bicasting. I misunderstood. However, the approach is
the same, with the complication that now you have a triangular route to clean
up. Is there an advantage?

Gary

> -----Original Message-----
> From: khiem.le@nokia.com [mailto:khiem.le@nokia.com]
> Sent: Friday, April 06, 2001 11:53 AM
> To: Kenward, Gary [WDLN2:AN10:EXCH]; khiem.le@nokia.com;
> tmima@cisco.com; mccap@research.bell-labs.com; rajeev.koodli@nokia.com
> Cc: kempf@heliopolis.Eng.Sun.COM; mobile-ip@sunroof.eng.sun.com;
> rohc@cdt.luth.se; seamoby@diameter.org
> Subject: RE: [seamoby] RE: [rohc] RE: Restarting Compressor on Mobile
> IPv6 Handover
>
>
> Hi Gary,
> 
> No this is not bicasting. The path taken by the packets
> (during the context
> establishment at the new compressor/decompressor) is as follows:
> 
> 
> -------> Old compressor/decompressor ----------> New
> compressor/decompressor
> -------------> MN
> 
> <------ Old compressor/decompressor <---------- New
> compressor/decompressor
> <------------- MN
> 
> Khiem
>
> -----Original Message-----
> From: ext Gary Kenward [mailto:gkenward@nortelnetworks.com]
> Sent: Wednesday, April 04, 2001 8:47 AM
> To: 'khiem.le@nokia.com'; tmima@cisco.com;
> mccap@research.bell-labs.com;
> rajeev.koodli@nokia.com
> Cc: kempf@heliopolis.Eng.Sun.COM; mobile-ip@sunroof.eng.sun.com;
> rohc@cdt.luth.se; seamoby@diameter.org
> Subject: RE: [seamoby] RE: [rohc] RE: Restarting Compressor
> on Mobile IPv6
> Handover
>
>
>
> Many real time context synchronization problems can be solved
> through "bi-casting", which is, I believe, the essence of what you
> describe.
>
> Gary
>
> > -----Original Message-----
> > From: khiem.le@nokia.com [ mailto:khiem.le@nokia.com
> <mailto:khiem.le@nokia.com> ]
> > Sent: Wednesday, April 04, 2001 12:16 AM
> > To: tmima@cisco.com; rajeev.koodli@nokia.com;
> > mccap@research.bell-labs.com; rajeev.koodli@nokia.com
> > Cc: kempf@heliopolis.Eng.Sun.COM; mobile-ip@sunroof.eng.sun.com;
> > rohc@cdt.luth.se; seamoby@diameter.org
> > Subject: RE: [seamoby] RE: [rohc] RE: Restarting Compressor
> on Mobile
> > IPv6 Handover
> >
> >
> > Hello Tmima,
> >
> > Your idea is very similar to the one I had some time ago (refer to
> > http://www.cdt.luth.se/robhc/msg01274.html
> <http://www.cdt.luth.se/robhc/msg01274.html> ).
> >
> > Essentially the idea is to relax the timing constraints and
> > allow some time
> > to establish the context at the new compressor/decompressor.
> > During that
> > context establishment time, the packets transit through the new
> > compressor/decompressor, but also transit through the old
> > which continues to
> > do compression/decompression. Once the context is
> > established, the new can
> > take over the compression/decompression process.
> >
> > The old compressor/decompressor helps the new
> compressor/decompressor
> > establish its context by sending some context information.
> > One way (as you
> > described, correct me if I am wrong) is to take a snapshot of
> > the context
> > and send it. To maintain context synchronization between the
> > old and new,
> > the new may do some update of the received context snapshot
> > to account for
> > the fact that the context may have been updated by the old
> > after it took the
> > snapshot. However, the problem is that packets may be lost
> > when sent from
> > the old to the new. So the new may do a context update based
> > on packet j,
> > but that update was not done by the old, since packet j was
> > never received
> > by the old. One way to solve this problem is to modify the
> > mechanism to send
> > the context information from old to new. Instead of sending
> a context
> > snapshot, the old sends the context-related information in
> > pieces, so the
> > new can gradually build up its context. This corresponds to the
> > Relocation-deferred-after-Link-Switching (RDLS)scheme in
> > http://www.cdt.luth.se/robhc/msg01274.html
> <http://www.cdt.luth.se/robhc/msg01274.html> . You can look at
> > it for details.
> >
> > The case where the old takes a snapshot of its context and
> > sends to the new
> > for immediate transfer of compression/decompression role
> > corresponds to
> > Relocation-concurrent-with-Link-Switching (RCLS).
> >
> > RDLS addresses the timing problem in a very reliable manner,
> > but is more
> > complex than RCLS. It also requires a higher capacity
> > connection between the
> > old and new. So each approach has its pros and cons.
> >
> > In any case, I believe the context transfer (whether RCLS
> or RDLS) is
> > doable, and the advantages over brute force
> reinitialization over the
> > wireless link outweigh the costs.
> >
> > Khiem
> >
> > > -----Original Message-----
> > > From: ext Tmima Koren [ mailto:tmima@cisco.com
> <mailto:tmima@cisco.com>
> ]
> > > Sent: Tuesday, April 03, 2001 8:19 PM
> > > To: rajeev.koodli@nokia.com; mccap@research.bell-labs.com;
> > > rajeev.koodli@nokia.com
> > > Cc: kempf@heliopolis.Eng.Sun.COM; mobile-ip@sunroof.eng.sun.com;
> > > rohc@cdt.luth.se; seamoby@diameter.org
> > > Subject: RE: [seamoby] RE: [rohc] RE: Restarting Compressor
> > on Mobile
> > > IPv6 Handover
> > >
> > >
> > > I wonder if it's possible to do both:
> > > The new router sends a request for context transfer, but
> > continues to
> > > forward the compressed packets to the old router, AND queues
> > > a copy of the
> > > packets he forwarded. Once he receives the context, the new
> > > router applies
> > > the necessary changes to the context from the queued
> > packets. Now his
> > > context is good and he can continue decompressing.
> > > Tmima
> > >
> > > At 07:58 PM 4/3/2001 -0500, rajeev.koodli@nokia.com wrote:
> > > > > -----Original Message-----
> > > > > From: ext Pete McCann [ mailto:mccap@research.bell-labs.com
> <mailto:mccap@research.bell-labs.com> ]
> > > > > Sent: Tuesday, April 03, 2001 5:30 PM
> > > > > To: rajeev.koodli@nokia.com
> > > > > Cc: kempf@heliopolis.Eng.Sun.COM;
> mobile-ip@sunroof.eng.sun.com;
> > > > > rohc@cdt.luth.se; seamoby@diameter.org
> > > > > Subject: RE: [seamoby] RE: [rohc] RE: Restarting
> > > Compressor on Mobile
> > > > > IPv6 Handover
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > Yes, you would need to re-initialize the context over the
> > > air, but I
> > > > > don't think the bandwidth usage is high enough to
> matter.  In a
> > > > > wide-area cellular environment IP handoffs will be relatively
> > > > > infrequent.  The important consideration is the "glitch"
> > > experienced
> > > > > in voice traffic at handoff time, and this can be
> minimized by
> > > > > temporarily anchoring the compressor.
> > > > >
> > > >
> > > >I don't agree with you comments that you could ignore
> > > bandwidth usage and
> > > >assume infrequent handovers.
> > > >
> > > >a> 84 bytes of IPv6/UDP/RTP headers with Mobile-IPv6 Home
> > > Address option for
> > > >a voice payload of 20 - 30 bytes. Several such packets sent
> > > per each stream.
> > > >
> > > >b> With fast user mobility, each BTS/AP being a router, I
> > can imagine
> > > >frequent handovers.
> > > >
> > > >In any case, context relocation addresses a>, does not
> > > assume infrequent
> > > >handovers, as well as attempts to provide "glitch-free"
> > > voice. When the
> > > >context is already present at the target router before the
> > > MN starts sending
> > > >compressed packets, the application should not see the glitch.
> > > >I know there is work to be done here, so let's try to
> > focus on that!
> > > >
> > > >Regards,
> > > >
> > > >-Rajeev
> > > >
> > > >
> > > > > -Pete
> > > > >
> > > > > rajeev.koodli@nokia.com (rk) writes:
> > > > >
> > > > > rk> Hi,
> > > > >
> > > > > rk> How does this avoid the core problem of context
> > > > > rk> _re-initialization_ ? You would still need to send IR
> > > packets (to
> > > > > rk> new access router over the air interface) subsequent
> > > to handover
> > > > > rk> in order to start a new context..  Anchoring it at
> > > the previous
> > > > > rk> router may buy you some time, but not the bits.  I reckon
> > > > > rk> anchoring will bring its own set of problems.
> > > > >
> > > > > rk> Regards,
> > > > >
> > > > > rk> -Rajeev
> > > > >
> > > > >
> > > > > >> -----Original Message-----
> > > > > >> From: ext Pete McCann [ mailto:mccap@research.bell-labs.com
> <mailto:mccap@research.bell-labs.com> ]
> > > > > >> Sent: Tuesday, April 03, 2001 11:32 AM
> > > > > >> To: kempf@heliopolis.Eng.Sun.COM
> > > > > >> Cc: mobile-ip@sunroof.eng.sun.com; rohc@cdt.luth.se;
> > > > > >> seamoby@diameter.org
> > > > > >> Subject: RE: [seamoby] RE: [rohc] RE: Restarting
> > > > > Compressor on Mobile
> > > > > >> IPv6 Handover
> > > > > >>
> > > > > >>
> > > > > >>
> > > > > >> Hi,
> > > > > >>
> > > > > >> I think there is a simpler solution to this problem that
> > > > > most people
> > > > > >> are overlooking.
> > > > > >>
> > > > > >> It should be possible to keep the compressor/decompressor
> > > > > state at the
> > > > > >> old access router and to tunnel the already-compressed
> > > > > packets to and
> > > > > >> from the new access router.  Then the MN and new
> > > access router can
> > > > > >> renegotiate header compression state from scratch and take
> > > > > as long as
> > > > > >> they want to do so, because the MN is still getting
> > > service in the
> > > > > >> meantime.
> > > > > >>
> > > > > >> Someone earlier asked about support for ROHC on IP tunnels
> > > > > and I think
> > > > > >> this would be a good application for that.
> > > > > >>
> > > > > >> We are trying to move the mountain to Mohammed and I don't
> > > > > see why we
> > > > > >> can't do the reverse instead.
> > > > > >>
> > > > > >> -Pete
> > > > > >>
> > > > > >>
> > > > > >> ---
> > > > > >> Mailing list for Robust Header Compression WG
> > > > > >> Archive: http://www.cdt.luth.se/rohc/
> <http://www.cdt.luth.se/rohc/> 
> > > > > >>
> > > > > rk> ---
> > > > > rk> Mailing list for Robust Header Compression WG
> > > > > rk> Archive: http://www.cdt.luth.se/rohc/
> <http://www.cdt.luth.se/rohc/> 
> > > > >
> > >
> > > ---
> > > Mailing list for Robust Header Compression WG
> > > Archive: http://www.cdt.luth.se/rohc/
<http://www.cdt.luth.se/rohc/> 
> >
>

------_=_NextPart_001_01C0BEC7.86C264F0-- From owner-seamoby@diameter.org Fri Apr 6 16:21:49 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA19448 for ; Fri, 6 Apr 2001 16:21:48 -0400 (EDT) Received: (qmail 7965 invoked by alias); 6 Apr 2001 21:10:59 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 7959 invoked by uid 200); 6 Apr 2001 21:10:59 -0000 Received: (qmail 7954 invoked from network); 6 Apr 2001 21:10:57 -0000 Received: from sj-msg-core-3.cisco.com (171.70.157.152) by c900656-a.plstn1.sfba.home.com with SMTP; 6 Apr 2001 21:10:57 -0000 Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-3.cisco.com (8.9.3/8.9.1) with ESMTP id NAA03814; Fri, 6 Apr 2001 13:18:12 -0700 (PDT) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id ADQ12759; Fri, 6 Apr 2001 13:19:29 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id NAA05928; Fri, 6 Apr 2001 13:19:29 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15054.9424.968727.865645@thomasm-u1.cisco.com> Date: Fri, 6 Apr 2001 13:19:28 -0700 (PDT) To: mobile-ip@sunroof.eng.sun.com Cc: mat@cisco.com, rajeev.koodli@nokia.com, khiem.le@nokia.com, gkenward@nortelnetworks.com, tmima@cisco.com, mccap@research.bell-labs.com, kempf@heliopolis.eng.sun.com, rohc@cdt.luth.se, seamoby@diameter.org Subject: [mobile-ip] RE: [seamoby] RE: [rohc] RE: Restarting Compressor on Mobile IPv6 Handover In-Reply-To: References: X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-seamoby@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit rajeev.koodli@nokia.com writes: > > > > From: ext Michael Thomas [mailto:mat@cisco.com] > > > If there is no compression state at the old router, why > > would you try to > > > relocate it ? > > > > There's compression state there, but not the > > compression state that matters: when I'm > > receiving packets from the old AR during the > > FMIP transition time, there will be a *new* > > IP header appended toward the MN. This is > > because those packets will have to be tunneled to the > > MN. This means that it is a *new* compression > > context, not an old existing one. > > > I don't have sufficient details to comment.. and then this: > You can't justify your claims. So, before you raise issues > (related/unrelated), try to make an effort to understand the work done by > others. I don't know what you would like me to do. I've brought up an issue, and you've brushed it aside assumedly as irrelevant. I've been paying attention to this thread, and as far I can tell, nobody has answered my question. Also: you are also telling me that I have to prove negatives of the form "tell me why we _shouldn't_ do XYZ." That is a logical fallacy. You may not like my message, but it does not give you free reign to ignore reality. It is in nobody's interest to design a protocol that does not work in the areas where it would be most useful. Mike From owner-seamoby@diameter.org Fri Apr 6 16:28:02 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA19577 for ; Fri, 6 Apr 2001 16:28:01 -0400 (EDT) Received: (qmail 7965 invoked by alias); 6 Apr 2001 21:10:59 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 7959 invoked by uid 200); 6 Apr 2001 21:10:59 -0000 Received: (qmail 7954 invoked from network); 6 Apr 2001 21:10:57 -0000 Received: from sj-msg-core-3.cisco.com (171.70.157.152) by c900656-a.plstn1.sfba.home.com with SMTP; 6 Apr 2001 21:10:57 -0000 Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-3.cisco.com (8.9.3/8.9.1) with ESMTP id NAA03814; Fri, 6 Apr 2001 13:18:12 -0700 (PDT) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id ADQ12759; Fri, 6 Apr 2001 13:19:29 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id NAA05928; Fri, 6 Apr 2001 13:19:29 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15054.9424.968727.865645@thomasm-u1.cisco.com> Date: Fri, 6 Apr 2001 13:19:28 -0700 (PDT) To: mobile-ip@sunroof.eng.sun.com Cc: mat@cisco.com, rajeev.koodli@nokia.com, khiem.le@nokia.com, gkenward@nortelnetworks.com, tmima@cisco.com, mccap@research.bell-labs.com, kempf@heliopolis.eng.sun.com, rohc@cdt.luth.se, seamoby@diameter.org Subject: [mobile-ip] RE: [seamoby] RE: [rohc] RE: Restarting Compressor on Mobile IPv6 Handover In-Reply-To: References: X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-seamoby@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit rajeev.koodli@nokia.com writes: > > > > From: ext Michael Thomas [mailto:mat@cisco.com] > > > If there is no compression state at the old router, why > > would you try to > > > relocate it ? > > > > There's compression state there, but not the > > compression state that matters: when I'm > > receiving packets from the old AR during the > > FMIP transition time, there will be a *new* > > IP header appended toward the MN. This is > > because those packets will have to be tunneled to the > > MN. This means that it is a *new* compression > > context, not an old existing one. > > > I don't have sufficient details to comment.. and then this: > You can't justify your claims. So, before you raise issues > (related/unrelated), try to make an effort to understand the work done by > others. I don't know what you would like me to do. I've brought up an issue, and you've brushed it aside assumedly as irrelevant. I've been paying attention to this thread, and as far I can tell, nobody has answered my question. Also: you are also telling me that I have to prove negatives of the form "tell me why we _shouldn't_ do XYZ." That is a logical fallacy. You may not like my message, but it does not give you free reign to ignore reality. It is in nobody's interest to design a protocol that does not work in the areas where it would be most useful. Mike From owner-seamoby@diameter.org Fri Apr 6 16:51:43 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA19968 for ; Fri, 6 Apr 2001 16:51:42 -0400 (EDT) Received: (qmail 8663 invoked by alias); 6 Apr 2001 21:35:19 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 8657 invoked by uid 200); 6 Apr 2001 21:35:18 -0000 Received: (qmail 8652 invoked from network); 6 Apr 2001 21:35:16 -0000 Received: from mgw-dax1.ext.nokia.com (63.78.179.216) by c900656-a.plstn1.sfba.home.com with SMTP; 6 Apr 2001 21:35:16 -0000 Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax1.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f36Kj1g14117 for ; Fri, 6 Apr 2001 15:45:01 -0500 (CDT) Received: from daebh01nok.americas.nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Fri, 6 Apr 2001 15:44:26 -0500 Received: by daebh01nok with Internet Mail Service (5.5.2652.78) id ; Fri, 6 Apr 2001 15:44:26 -0500 Message-ID: <8572CF1E2A95D211A1190008C7EAA24602720924@daeis05nok> From: khiem.le@nokia.com To: rajeev.koodli@nokia.com, mat@cisco.com Cc: gkenward@nortelnetworks.com, tmima@cisco.com, mccap@research.bell-labs.com, kempf@heliopolis.Eng.Sun.COM, mobile-ip@sunroof.eng.sun.com, rohc@cdt.luth.se, seamoby@diameter.org Subject: RE: [seamoby] RE: [rohc] RE: Restarting Compressor on Mobile IPv6 Handover Date: Fri, 6 Apr 2001 15:44:25 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-seamoby@diameter.org Precedence: bulk Hi, I have been too busy to comment on all these mails, but I just want to say a couple of things. I'm afraid that it > is your place to prove that context transfer > of header compression state in the face of all > of these extenuating circumstances is still > worthwhile. There have been many mails pointing out the merit of doing header compression context transfer. To repeat them: continued, seamless compression/decompression, higher compression efficiency, and minimization of degradation on the user media. This last point is the most important in my mind. At this stage, the link technologies where header compression is going to be used are primarily cellular links. In the cellular environment, handoffs (or handovers) are events that happen in normal operation, and therefore a very significant design effort is spent to minimize the impact of HO on performance. In particular, one wants to minimize the duration of the break. If brute force header compression reinitialization is done, one would have to send a certain number of 40-60 byte or more IR headers, instead of the usual 1 byte header. This big bandwidth demand surge will put a strain on the link. Some links will cope with it by blanking out the user data to make room to carry the IR headers. When such blanking takes place, the user media (voice, etc.) will be unavoidably affected. The impairment caused by the handoff is thus extended, compared to the case where header compression is not present. In the current and 3G cellular technologies, the break is about 100-150 msec, without header compression. This already translates into the loss of 5-6 20 msec packets. If some IR headers have to be sent by blanking out the user data, the break will be significantly longer. For example, if 3 (an optimistic value) IR headers are sent, the resulting break is increased to 8-9 packets worth. I also want to point out that minimization of the break will help in futureproofness. Applications that will be introduced in the future may be even more sensitive to the break (or the threshold for user perceived degradation may be lower) than the currently known ones. For example, if a packet is generated every 10 msec, the number of packets affected will be doubled. The only way to minimize the break is to do header compression context transfer. Khiem > -----Original Message----- > From: Koodli Rajeev (NRC/MtView) > Sent: Friday, April 06, 2001 1:13 PM > To: 'ext Michael Thomas'; Koodli Rajeev (NRC/MtView) > Cc: Le Khiem (NRC/Dallas); gkenward@nortelnetworks.com; > tmima@cisco.com; > mccap@research.bell-labs.com; kempf@heliopolis.Eng.Sun.COM; > mobile-ip@sunroof.eng.sun.com; rohc@cdt.luth.se; seamoby@diameter.org > Subject: RE: [seamoby] RE: [rohc] RE: Restarting Compressor on Mobile > IPv6 Handover > > > > > > > > rajeev.koodli@nokia.com writes: > > > > From: ext Michael Thomas [mailto:mat@cisco.com] > > > > > > Can somebody explain to me how this has any > > > > possible applicability if you are using FMIP > > > > during the transition? FMIP requires a new tunnel > > > > for which there will be no compression state in > > > > the old access router. > > > > > > > > > > If there is no compression state at the old router, why > > would you try to > > > relocate it ? > > > > There's compression state there, but not the > > compression state that matters: when I'm > > receiving packets from the old AR during the > > FMIP transition time, there will be a *new* > > IP header appended toward the MN. This is > > because those packets will have to be tunneled to the > > MN. This means that it is a *new* compression > > context, not an old existing one. > > > I don't have sufficient details to comment.. > > > > > All of these interactions with MIP, FMIP, HMIP > > > > etc, etc make it look to me like this is a losing > > > > situation. It may be the better part of valor to > > > > say that fast/smooth handoffs are inherently more > > > > bandwidth consumptive and that one of the > > > > casualties is header compression state in the mean > > > > time. > > > > > > Can you justify your claim above ? > > > > I can't prove negatives. I'm afraid that it > > is your place to prove that context transfer > > of header compression state in the face of all > > of these extenuating circumstances is still > > worthwhile. > > > > You can't justify your claims. So, before you raise issues > (related/unrelated), try to make an effort to understand the > work done by others. > > As far as I am concerned, how about all the e-mail discussion > during the last two weeks ? Please take a look! > > > > >Trying to extend a point to point L2 > > > > compression mechanism across an arbitrary internet > > > > is just *bizzare*. L2TP is bad enough. > > > > > > > > > > You are compressing IP and transport headers! This should > > work on ANY link. > > > That's why you try to CT header compression state. Get it ? > > > > Oh sure, I get it... I "get" VoMPLS too, but > > that doesn't make it any less bizarre. > > > > If you got it, you would probably re-think! If you were to > re-think and understand the issues, you would probably > question yourself what's bizarre, and then write. > > -Rajeev > > > Mike > > > From owner-seamoby@diameter.org Fri Apr 6 17:05:38 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA20246 for ; Fri, 6 Apr 2001 17:05:37 -0400 (EDT) Received: (qmail 9244 invoked by alias); 6 Apr 2001 21:54:33 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 9238 invoked by uid 200); 6 Apr 2001 21:54:33 -0000 Received: (qmail 9233 invoked from network); 6 Apr 2001 21:54:31 -0000 Received: from c007-h012.c007.snv.cp.net (HELO c007.snv.cp.net) (209.228.33.219) by c900656-a.plstn1.sfba.home.com with SMTP; 6 Apr 2001 21:54:31 -0000 Received: (cpmta 15962 invoked from network); 6 Apr 2001 14:03:41 -0700 Received: from dsl-64-193-0-129.telocity.com (HELO philneum) (64.193.0.129) by smtp.telocity.com (209.228.33.219) with SMTP; 6 Apr 2001 14:03:41 -0700 X-Sent: 6 Apr 2001 21:03:41 GMT Message-ID: <001c01c0bedc$eedfc9a0$6501a8c0@philneum> Reply-To: "Phil Neumiller" From: "Phil Neumiller" To: , , Cc: , , , , , , References: <8572CF1E2A95D211A1190008C7EAA24602720924@daeis05nok> Subject: Re: [seamoby] RE: [rohc] RE: Restarting Compressor on Mobile IPv6 Handover Date: Fri, 6 Apr 2001 16:02:45 -0500 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-seamoby@diameter.org Precedence: bulk This arguments seems completely bogus to me or I am missing something really fundamental here. Are not both 3GPP and 3GPP2 CDMA? This whole discussion falls apart and dies on the floor than. ----- Original Message ----- From: > There have been many mails pointing out the merit of doing header > compression context transfer. To repeat them: > continued, seamless compression/decompression, higher compression > efficiency, and minimization of degradation on the user media. This last > point is the most important in my mind. At this stage, the link technologies > where header compression is going to be used are primarily cellular links. 1). Based on what evidence? So far we have WAP, iMode, and iDen. Are you ignoring other possible edge and infrastructure technologies like wirelesss PANs, WLANs, ad hoc networks for any particular reason? > In the cellular environment, handoffs (or handovers) are events that happen > in normal operation, and therefore a very significant design effort is spent > to minimize the impact of HO on performance. In particular, one wants to > minimize the duration of the break. In post-modern cellular systems there is no break! Wake up! Qualcomm won the war a long time ago, I just can't get it why you guys are still in this "break" mind set. 3GPP and 3GPP2 use CDMA!!!! ITS MAKE BEFORE BREAK. THE SOONER PEOPLE START LEARNING HOW TO DEAL WITH IP PACKETS OVER CDMA w/ soft handover THE SOONER the MIP list will finally mature to where it needs to be (i.e. like OBAST :-)!!! > if brute force header compression reinitialization is done, one would have to send > certain number of 40-60 > byte or more IR headers, instead of the usual 1 byte header. This big > bandwidth demand surge will put a strain on the link. Please quantify this purported bandwidth demand surge and it origination. > Some links will cope > with it by blanking out the user data to make room to carry the IR headers. > When such blanking takes place, the user media (voice, etc.) will be > unavoidably affected. Yes but why would we use MIPv6 over TDMA systems? I just don't get this argument at all???? >The impairment caused by the handoff is thus extended, > compared to the case where header compression is not present. What it impairment, its a SOFT handoff? > > In the current and 3G cellular technologies, the break is about 100-150 > msec, without header compression. The break will be 0 ms in 3G systems (only when a hard handover is forced) is that what you are designing for the error leg cases? Again this argument seems rediculously TDMA. I feel like Rip Van Winkle, did I wake up and everything went back to TDMA? Why are we discussing this with reference to IPv6 handovers?? Regards, Phil From owner-seamoby@diameter.org Fri Apr 6 17:18:14 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA20593 for ; Fri, 6 Apr 2001 17:18:12 -0400 (EDT) Received: (qmail 9830 invoked by alias); 6 Apr 2001 22:06:13 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 9824 invoked by uid 200); 6 Apr 2001 22:06:13 -0000 Received: (qmail 9819 invoked from network); 6 Apr 2001 22:06:11 -0000 Received: from sj-msg-core-2.cisco.com (171.69.43.88) by c900656-a.plstn1.sfba.home.com with SMTP; 6 Apr 2001 22:06:11 -0000 Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id OAA22004; Fri, 6 Apr 2001 14:15:41 -0700 (PDT) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id ADQ14141; Fri, 6 Apr 2001 14:15:17 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id OAA05932; Fri, 6 Apr 2001 14:15:17 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15054.12773.346957.945689@thomasm-u1.cisco.com> Date: Fri, 6 Apr 2001 14:15:17 -0700 (PDT) To: Cc: rajeev.koodli@nokia.com, mat@cisco.com, gkenward@nortelnetworks.com, tmima@cisco.com, mccap@research.bell-labs.com, kempf@heliopolis.Eng.Sun.COM, mobile-ip@sunroof.eng.sun.com, rohc@cdt.luth.se, seamoby@diameter.org Subject: RE: [seamoby] RE: [rohc] RE: Restarting Compressor on Mobile IPv6 Handover In-Reply-To: <8572CF1E2A95D211A1190008C7EAA24602720924@daeis05nok> References: <8572CF1E2A95D211A1190008C7EAA24602720924@daeis05nok> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-seamoby@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit Kheim, I sorry to be so argumentative here, but I'm sure I could come up with a long laundry list of the benefits of quantum teleportation too. What obviously must be done beyond wanting such a thing is to see: o if it can be done at all o whether it would still be a benefit once we had done it. For example, if we could do quantum teleportation but the only way we could figure out how to teleport a person resulted in them dying, I'm sure you'd agree that we ought to reevaluate the benefits. All I'm asking here is how CT would interact with FMIP. I believe that FMIP is very likely to be a very important part of handoffs and as such, I would like to know whether CT for header compression state will help, hinder or be of no benefit at all. From what I can tell, there is indeed a problem and it is not clear whether there is a solution, or whether the solution would be worse than the original problem given the high likelihood of race conditions, etc. Mike khiem.le@nokia.com writes: > Hi, > > I have been too busy to comment on all these mails, but I just want to say a > couple of things. > > I'm afraid that it > > is your place to prove that context transfer > > of header compression state in the face of all > > of these extenuating circumstances is still > > worthwhile. > > There have been many mails pointing out the merit of doing header > compression context transfer. To repeat them: > continued, seamless compression/decompression, higher compression > efficiency, and minimization of degradation on the user media. This last > point is the most important in my mind. At this stage, the link technologies > where header compression is going to be used are primarily cellular links. > In the cellular environment, handoffs (or handovers) are events that happen > in normal operation, and therefore a very significant design effort is spent > to minimize the impact of HO on performance. In particular, one wants to > minimize the duration of the break. If brute force header compression > reinitialization is done, one would have to send a certain number of 40-60 > byte or more IR headers, instead of the usual 1 byte header. This big > bandwidth demand surge will put a strain on the link. Some links will cope > with it by blanking out the user data to make room to carry the IR headers. > When such blanking takes place, the user media (voice, etc.) will be > unavoidably affected. The impairment caused by the handoff is thus extended, > compared to the case where header compression is not present. > > In the current and 3G cellular technologies, the break is about 100-150 > msec, without header compression. This already translates into the loss of > 5-6 20 msec packets. If some IR headers have to be sent by blanking out the > user data, the break will be significantly longer. For example, if 3 (an > optimistic value) IR headers are sent, the resulting break is increased to > 8-9 packets worth. > > I also want to point out that minimization of the break will help in > futureproofness. Applications that will be introduced in the future may be > even more sensitive to the break (or the threshold for user perceived > degradation may be lower) than the currently known ones. For example, if a > packet is generated every 10 msec, the number of packets affected will be > doubled. > > The only way to minimize the break is to do header compression context > transfer. > > > Khiem > > -----Original Message----- > > From: Koodli Rajeev (NRC/MtView) > > Sent: Friday, April 06, 2001 1:13 PM > > To: 'ext Michael Thomas'; Koodli Rajeev (NRC/MtView) > > Cc: Le Khiem (NRC/Dallas); gkenward@nortelnetworks.com; > > tmima@cisco.com; > > mccap@research.bell-labs.com; kempf@heliopolis.Eng.Sun.COM; > > mobile-ip@sunroof.eng.sun.com; rohc@cdt.luth.se; seamoby@diameter.org > > Subject: RE: [seamoby] RE: [rohc] RE: Restarting Compressor on Mobile > > IPv6 Handover > > > > > > > > > > > > > rajeev.koodli@nokia.com writes: > > > > > From: ext Michael Thomas [mailto:mat@cisco.com] > > > > > > > > Can somebody explain to me how this has any > > > > > possible applicability if you are using FMIP > > > > > during the transition? FMIP requires a new tunnel > > > > > for which there will be no compression state in > > > > > the old access router. > > > > > > > > > > > > > If there is no compression state at the old router, why > > > would you try to > > > > relocate it ? > > > > > > There's compression state there, but not the > > > compression state that matters: when I'm > > > receiving packets from the old AR during the > > > FMIP transition time, there will be a *new* > > > IP header appended toward the MN. This is > > > because those packets will have to be tunneled to the > > > MN. This means that it is a *new* compression > > > context, not an old existing one. > > > > > I don't have sufficient details to comment.. > > > > > > > All of these interactions with MIP, FMIP, HMIP > > > > > etc, etc make it look to me like this is a losing > > > > > situation. It may be the better part of valor to > > > > > say that fast/smooth handoffs are inherently more > > > > > bandwidth consumptive and that one of the > > > > > casualties is header compression state in the mean > > > > > time. > > > > > > > > Can you justify your claim above ? > > > > > > I can't prove negatives. I'm afraid that it > > > is your place to prove that context transfer > > > of header compression state in the face of all > > > of these extenuating circumstances is still > > > worthwhile. > > > > > > > You can't justify your claims. So, before you raise issues > > (related/unrelated), try to make an effort to understand the > > work done by others. > > > > As far as I am concerned, how about all the e-mail discussion > > during the last two weeks ? Please take a look! > > > > > > >Trying to extend a point to point L2 > > > > > compression mechanism across an arbitrary internet > > > > > is just *bizzare*. L2TP is bad enough. > > > > > > > > > > > > > You are compressing IP and transport headers! This should > > > work on ANY link. > > > > That's why you try to CT header compression state. Get it ? > > > > > > Oh sure, I get it... I "get" VoMPLS too, but > > > that doesn't make it any less bizarre. > > > > > > > If you got it, you would probably re-think! If you were to > > re-think and understand the issues, you would probably > > question yourself what's bizarre, and then write. > > > > -Rajeev > > > > > Mike > > > > > From owner-seamoby@diameter.org Fri Apr 6 17:31:41 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA20897 for ; Fri, 6 Apr 2001 17:31:30 -0400 (EDT) Received: (qmail 10393 invoked by alias); 6 Apr 2001 22:19:49 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 10387 invoked by uid 200); 6 Apr 2001 22:19:48 -0000 Received: (qmail 10382 invoked from network); 6 Apr 2001 22:19:47 -0000 Received: from mgw-dax1.ext.nokia.com (63.78.179.216) by c900656-a.plstn1.sfba.home.com with SMTP; 6 Apr 2001 22:19:47 -0000 Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax1.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f36LTVg18681 for ; Fri, 6 Apr 2001 16:29:31 -0500 (CDT) Received: from daebh01nok.americas.nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Fri, 6 Apr 2001 16:29:14 -0500 Received: by daebh01nok with Internet Mail Service (5.5.2652.78) id ; Fri, 6 Apr 2001 16:29:14 -0500 Message-ID: <8572CF1E2A95D211A1190008C7EAA24602720927@daeis05nok> From: khiem.le@nokia.com To: neumiller@telocity.com, khiem.le@nokia.com, rajeev.koodli@nokia.com, mat@cisco.com Cc: gkenward@nortelnetworks.com, tmima@cisco.com, mccap@research.bell-labs.com, kempf@heliopolis.Eng.Sun.COM, mobile-ip@sunroof.eng.sun.com, rohc@cdt.luth.se, seamoby@diameter.org Subject: RE: [seamoby] RE: [rohc] RE: Restarting Compressor on Mobile IPv6 Handover Date: Fri, 6 Apr 2001 16:29:13 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-seamoby@diameter.org Precedence: bulk Hi, Please see my comments below. Khiem > -----Original Message----- > From: ext Phil Neumiller [mailto:neumiller@telocity.com] > Sent: Friday, April 06, 2001 4:03 PM > To: khiem.le@nokia.com; rajeev.koodli@nokia.com; mat@cisco.com > Cc: gkenward@nortelnetworks.com; tmima@cisco.com; > mccap@research.bell-labs.com; kempf@heliopolis.Eng.Sun.COM; > mobile-ip@sunroof.eng.sun.com; rohc@cdt.luth.se; seamoby@diameter.org > Subject: Re: [seamoby] RE: [rohc] RE: Restarting Compressor on Mobile > IPv6 Handover > > > This arguments seems completely bogus to me or I am missing something > really fundamental here. Are not both 3GPP and 3GPP2 CDMA? This > whole discussion falls apart and dies on the floor than. KL: I would appreciate it if you could give specific arguments rather than qualifying other people's arguments as "bogus". It is easy to do that, and I can do that too, if I wanted to. Yes, you are missing something fundamental. All this discussion is about HARD Handoff, not soft handoff. Hard handoff exists in both CDMA and TDMA. Your issue with TDMA/CDMA is irrelevant. Evidently you have not read (http://www.cdt.luth.se/robhc/msg01274.html) referenced in one of my earlier mails. In that material, I clearly stated the problem is hard HO, not soft HO. If you could at least read and try to understand before commenting, we can have a more productive discussion. > > ----- Original Message ----- > From: > > > > There have been many mails pointing out the merit of doing header > > compression context transfer. To repeat them: > > continued, seamless compression/decompression, higher compression > > efficiency, and minimization of degradation on the user > media. This last > > point is the most important in my mind. At this stage, the > link technologies > > where header compression is going to be used are primarily > cellular links. > > 1). Based on what evidence? So far we have WAP, iMode, and iDen. KL: What do WAP, iMODE and iDEN have to do with RTP header compression? > Are you ignoring other possible edge and infrastructure > technologies like > wirelesss PANs, WLANs, ad hoc networks for any particular reason? KL: I am not ignoring them. I am just saying that the 3GPP and 3GPP2 technologies will be the first major cases of ROHC utilization. In fact the ROHC work was driven by the 3GPP needs. > > > In the cellular environment, handoffs (or handovers) are > events that happen > > in normal operation, and therefore a very significant > design effort is spent > > to minimize the impact of HO on performance. In particular, > one wants to > > minimize the duration of the break. > > In post-modern cellular systems there is no break! Wake up! Qualcomm > won the war a long time ago, I just can't get it why you guys > are still in > this "break" mind set. 3GPP and 3GPP2 use CDMA!!!! ITS MAKE BEFORE > BREAK. THE SOONER PEOPLE START LEARNING HOW TO DEAL > WITH IP PACKETS OVER CDMA w/ soft handover THE SOONER the > MIP list will finally mature to where it needs to be (i.e. > like OBAST :-)!!! KL: Hard handoff has a break, whether in CDMA or TDMA. Wakeup! > > > if brute force header compression reinitialization is done, > one would have to send > > certain number of 40-60 > > byte or more IR headers, instead of the usual 1 byte > header. This big > > bandwidth demand surge will put a strain on the link. > > Please quantify this purported bandwidth demand surge and it > origination. KL: Please refer to the ROHC specs for the size of the IR headers vs, the minimal size compressed header. > > > Some links will cope > > with it by blanking out the user data to make room to carry > the IR headers. > > When such blanking takes place, the user media (voice, etc.) will be > > unavoidably affected. > > Yes but why would we use MIPv6 over TDMA systems? I just don't get > this argument at all???? KL: There may be a confusion here. The issue of MIPv6 is orthogonal to the issue "what is the impact/benefits/costs of doing vs not doing header compression?" There are cases where ROHC header compression is used and header compression context transfer is beneficial, and yet there is no MIPv6 involved. Refer to the upcoming 3GPP release. > > >The impairment caused by the handoff is thus extended, > > compared to the case where header compression is not present. > > What it impairment, its a SOFT handoff? > > > > > In the current and 3G cellular technologies, the break is > about 100-150 > > msec, without header compression. > > The break will be 0 ms in 3G systems (only when a hard > handover is forced) > is that what you are designing for the error leg cases? KL: Why is the hard handoff an error leg case? Hard handoff is part of the normal operation. > Again this argument > seems rediculously TDMA. > > I feel like Rip Van Winkle, did I wake up and everything went back to > TDMA? Why are we discussing this with reference to IPv6 handovers?? KL: I was discussing the issue "what is the impact/benefits/costs of doing vs not doing header compression?" > > Regards, > > Phil > > From owner-seamoby@diameter.org Fri Apr 6 17:44:20 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA21054 for ; Fri, 6 Apr 2001 17:44:20 -0400 (EDT) Received: (qmail 10993 invoked by alias); 6 Apr 2001 22:33:55 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 10987 invoked by uid 200); 6 Apr 2001 22:33:54 -0000 Received: (qmail 10982 invoked from network); 6 Apr 2001 22:33:53 -0000 Received: from c007-h008.c007.snv.cp.net (HELO c007.snv.cp.net) (209.228.33.214) by c900656-a.plstn1.sfba.home.com with SMTP; 6 Apr 2001 22:33:53 -0000 Received: (cpmta 6975 invoked from network); 6 Apr 2001 14:43:03 -0700 Received: from dsl-64-193-0-129.telocity.com (HELO philneum) (64.193.0.129) by smtp.telocity.com (209.228.33.214) with SMTP; 6 Apr 2001 14:43:03 -0700 X-Sent: 6 Apr 2001 21:43:03 GMT Message-ID: <004601c0bee2$6ea57f40$6501a8c0@philneum> Reply-To: "Phil Neumiller" From: "Phil Neumiller" To: , , Cc: , , , , , , References: <8572CF1E2A95D211A1190008C7EAA24602720927@daeis05nok> Subject: Re: [seamoby] RE: [rohc] RE: Restarting Compressor on Mobile IPv6 Handover Date: Fri, 6 Apr 2001 16:42:07 -0500 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-seamoby@diameter.org Precedence: bulk OK, now I am really confused. Typically (in my previous experience) with some very large cariers like Sprint, Verizon, etc, Hard handoffs were about 5-10% of ALL handoffs. Why is there no interest/concern about the soft case WHICH HAS NOT YET BEEN RESOLVED (i.e. the other 90%)?????????? Regards, Phil From owner-seamoby@diameter.org Fri Apr 6 17:46:51 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA21097 for ; Fri, 6 Apr 2001 17:46:51 -0400 (EDT) Received: (qmail 11448 invoked by alias); 6 Apr 2001 22:36:17 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 11442 invoked by uid 200); 6 Apr 2001 22:36:17 -0000 Received: (qmail 11437 invoked from network); 6 Apr 2001 22:36:16 -0000 Received: from c007-h015.c007.snv.cp.net (HELO c007.snv.cp.net) (209.228.33.222) by c900656-a.plstn1.sfba.home.com with SMTP; 6 Apr 2001 22:36:16 -0000 Received: (cpmta 17856 invoked from network); 6 Apr 2001 14:45:26 -0700 Received: from dsl-64-193-0-129.telocity.com (HELO philneum) (64.193.0.129) by smtp.telocity.com (209.228.33.222) with SMTP; 6 Apr 2001 14:45:26 -0700 X-Sent: 6 Apr 2001 21:45:26 GMT Message-ID: <004e01c0bee2$c3edc5c0$6501a8c0@philneum> Reply-To: "Phil Neumiller" From: "Phil Neumiller" To: , , Cc: , , , , , , References: <8572CF1E2A95D211A1190008C7EAA24602720927@daeis05nok> Subject: Re: [seamoby] RE: [rohc] RE: Restarting Compressor on Mobile IPv6 Handover Date: Fri, 6 Apr 2001 16:44:30 -0500 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-seamoby@diameter.org Precedence: bulk The problem is this is crossposted across MIP, SeaMoby, and ROCH. Drop the crossposting its confusing the issues. I missed the hard handoff specific context, but I was just reading SeaMoby and did not see that part. -Phil From owner-seamoby@diameter.org Fri Apr 6 17:51:40 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA21277 for ; Fri, 6 Apr 2001 17:51:34 -0400 (EDT) Received: (qmail 11885 invoked by alias); 6 Apr 2001 22:39:20 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 11880 invoked by uid 200); 6 Apr 2001 22:39:19 -0000 Received: (qmail 11875 invoked from network); 6 Apr 2001 22:39:18 -0000 Received: from mgw-dax2.ext.nokia.com (63.78.179.217) by c900656-a.plstn1.sfba.home.com with SMTP; 6 Apr 2001 22:39:18 -0000 Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84]) by mgw-dax2.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f36Lp8w04827 for ; Fri, 6 Apr 2001 16:51:08 -0500 (CDT) Received: from daebh02nok.americas.nokia.com (unverified) by davir01nok.americas.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Fri, 6 Apr 2001 16:48:15 -0500 Received: by daebh02nok with Internet Mail Service (5.5.2652.78) id ; Fri, 6 Apr 2001 16:48:15 -0500 Message-ID: <8572CF1E2A95D211A1190008C7EAA24602720928@daeis05nok> From: khiem.le@nokia.com To: mat@cisco.com, khiem.le@nokia.com Cc: rajeev.koodli@nokia.com, gkenward@nortelnetworks.com, tmima@cisco.com, mccap@research.bell-labs.com, kempf@heliopolis.Eng.Sun.COM, mobile-ip@sunroof.eng.sun.com, rohc@cdt.luth.se, seamoby@diameter.org Subject: RE: [seamoby] RE: [rohc] RE: Restarting Compressor on Mobile IPv6 Handover Date: Fri, 6 Apr 2001 16:48:14 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-seamoby@diameter.org Precedence: bulk Hi Mike, > -----Original Message----- > From: ext Michael Thomas [mailto:mat@cisco.com] > Sent: Friday, April 06, 2001 4:15 PM > To: khiem.le@nokia.com > Cc: rajeev.koodli@nokia.com; mat@cisco.com; > gkenward@nortelnetworks.com; > tmima@cisco.com; mccap@research.bell-labs.com; > kempf@heliopolis.Eng.Sun.COM; mobile-ip@sunroof.eng.sun.com; > rohc@cdt.luth.se; seamoby@diameter.org > Subject: RE: [seamoby] RE: [rohc] RE: Restarting Compressor on Mobile > IPv6 Handover > > > > Kheim, > > I sorry to be so argumentative here, but I'm sure I > could come up with a long laundry list of the benefits > of quantum teleportation too. What obviously must be > done beyond wanting such a thing is to see: > > o if it can be done at all > o whether it would still be a benefit once we > had done it. > > For example, if we could do quantum teleportation > but the only way we could figure out how to > teleport a person resulted in them dying, I'm sure > you'd agree that we ought to reevaluate the > benefits. > > All I'm asking here is how CT would interact with > FMIP. I believe that FMIP is very likely to be a > very important part of handoffs and as such, I > would like to know whether CT for header > compression state will help, hinder or be of no > benefit at all. From what I can tell, there is > indeed a problem and it is not clear whether there > is a solution, or whether the solution would be > worse than the original problem given the high > likelihood of race conditions, etc. KL: At the least, and correct me if I am wrong, what you are saying is, at this stage, we should at least consider and investigate context transfer, before jumping to any conclusions that it should not be done. I agree. > > Mike > > khiem.le@nokia.com writes: > > Hi, > > > > I have been too busy to comment on all these mails, but I > just want to say a > > couple of things. > > > > I'm afraid that it > > > is your place to prove that context transfer > > > of header compression state in the face of all > > > of these extenuating circumstances is still > > > worthwhile. > > > > There have been many mails pointing out the merit of doing header > > compression context transfer. To repeat them: > > continued, seamless compression/decompression, higher compression > > efficiency, and minimization of degradation on the user > media. This last > > point is the most important in my mind. At this stage, the > link technologies > > where header compression is going to be used are primarily > cellular links. > > In the cellular environment, handoffs (or handovers) are > events that happen > > in normal operation, and therefore a very significant > design effort is spent > > to minimize the impact of HO on performance. In > particular, one wants to > > minimize the duration of the break. If brute force header > compression > > reinitialization is done, one would have to send a certain > number of 40-60 > > byte or more IR headers, instead of the usual 1 byte > header. This big > > bandwidth demand surge will put a strain on the link. Some > links will cope > > with it by blanking out the user data to make room to > carry the IR headers. > > When such blanking takes place, the user media (voice, > etc.) will be > > unavoidably affected. The impairment caused by the handoff > is thus extended, > > compared to the case where header compression is not present. > > > > In the current and 3G cellular technologies, the break is > about 100-150 > > msec, without header compression. This already translates > into the loss of > > 5-6 20 msec packets. If some IR headers have to be sent by > blanking out the > > user data, the break will be significantly longer. For > example, if 3 (an > > optimistic value) IR headers are sent, the resulting break > is increased to > > 8-9 packets worth. > > > > I also want to point out that minimization of the break > will help in > > futureproofness. Applications that will be introduced in > the future may be > > even more sensitive to the break (or the threshold for > user perceived > > degradation may be lower) than the currently known ones. > For example, if a > > packet is generated every 10 msec, the number of packets > affected will be > > doubled. > > > > The only way to minimize the break is to do header > compression context > > transfer. > > > > > > Khiem > > > -----Original Message----- > > > From: Koodli Rajeev (NRC/MtView) > > > Sent: Friday, April 06, 2001 1:13 PM > > > To: 'ext Michael Thomas'; Koodli Rajeev (NRC/MtView) > > > Cc: Le Khiem (NRC/Dallas); gkenward@nortelnetworks.com; > > > tmima@cisco.com; > > > mccap@research.bell-labs.com; kempf@heliopolis.Eng.Sun.COM; > > > mobile-ip@sunroof.eng.sun.com; rohc@cdt.luth.se; > seamoby@diameter.org > > > Subject: RE: [seamoby] RE: [rohc] RE: Restarting > Compressor on Mobile > > > IPv6 Handover > > > > > > > > > > > > > > > > > > rajeev.koodli@nokia.com writes: > > > > > > From: ext Michael Thomas [mailto:mat@cisco.com] > > > > > > > > > > Can somebody explain to me how this has any > > > > > > possible applicability if you are using FMIP > > > > > > during the transition? FMIP requires a new tunnel > > > > > > for which there will be no compression state in > > > > > > the old access router. > > > > > > > > > > > > > > > > If there is no compression state at the old router, why > > > > would you try to > > > > > relocate it ? > > > > > > > > There's compression state there, but not the > > > > compression state that matters: when I'm > > > > receiving packets from the old AR during the > > > > FMIP transition time, there will be a *new* > > > > IP header appended toward the MN. This is > > > > because those packets will have to be tunneled to the > > > > MN. This means that it is a *new* compression > > > > context, not an old existing one. > > > > > > > I don't have sufficient details to comment.. > > > > > > > > > All of these interactions with MIP, FMIP, HMIP > > > > > > etc, etc make it look to me like this is a losing > > > > > > situation. It may be the better part of valor to > > > > > > say that fast/smooth handoffs are inherently more > > > > > > bandwidth consumptive and that one of the > > > > > > casualties is header compression state in the mean > > > > > > time. > > > > > > > > > > Can you justify your claim above ? > > > > > > > > I can't prove negatives. I'm afraid that it > > > > is your place to prove that context transfer > > > > of header compression state in the face of all > > > > of these extenuating circumstances is still > > > > worthwhile. > > > > > > > > > > You can't justify your claims. So, before you raise issues > > > (related/unrelated), try to make an effort to understand the > > > work done by others. > > > > > > As far as I am concerned, how about all the e-mail discussion > > > during the last two weeks ? Please take a look! > > > > > > > > >Trying to extend a point to point L2 > > > > > > compression mechanism across an arbitrary internet > > > > > > is just *bizzare*. L2TP is bad enough. > > > > > > > > > > > > > > > > You are compressing IP and transport headers! This should > > > > work on ANY link. > > > > > That's why you try to CT header compression state. Get it ? > > > > > > > > Oh sure, I get it... I "get" VoMPLS too, but > > > > that doesn't make it any less bizarre. > > > > > > > > > > If you got it, you would probably re-think! If you were to > > > re-think and understand the issues, you would probably > > > question yourself what's bizarre, and then write. > > > > > > -Rajeev > > > > > > > Mike > > > > > > > > From owner-seamoby@diameter.org Fri Apr 6 17:55:11 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA21340 for ; Fri, 6 Apr 2001 17:55:08 -0400 (EDT) Received: (qmail 12044 invoked by alias); 6 Apr 2001 22:40:42 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 12037 invoked by uid 200); 6 Apr 2001 22:40:41 -0000 Received: (qmail 12029 invoked from network); 6 Apr 2001 22:40:38 -0000 Received: from mail-blue.research.att.com (135.207.30.102) by c900656-a.plstn1.sfba.home.com with SMTP; 6 Apr 2001 22:40:38 -0000 Received: from surfcity.research.att.com (surfcity.research.att.com [135.207.128.5]) by mail-blue.research.att.com (Postfix) with ESMTP id 9D42F4CE58; Fri, 6 Apr 2001 17:50:11 -0400 (EDT) Received: from research.att.com (ltkostic [135.207.133.7]) by surfcity.research.att.com (8.8.7/8.8.7) with ESMTP id RAA08408; Fri, 6 Apr 2001 17:49:42 -0400 (EDT) Message-ID: <3ACE3A82.6321EF2D@research.att.com> Date: Fri, 06 Apr 2001 17:52:02 -0400 From: Zoran Kostic X-Mailer: Mozilla 4.75 [en] (Win98; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: Phil Neumiller Cc: khiem.le@nokia.com, rajeev.koodli@nokia.com, mat@cisco.com, gkenward@nortelnetworks.com, tmima@cisco.com, mccap@research.bell-labs.com, kempf@heliopolis.Eng.Sun.COM, mobile-ip@sunroof.eng.sun.com, rohc@cdt.luth.se, seamoby@diameter.org Subject: Re: [seamoby] RE: [rohc] RE: Restarting Compressor on Mobile IPv6 Handover References: <8572CF1E2A95D211A1190008C7EAA24602720924@daeis05nok> <001c01c0bedc$eedfc9a0$6501a8c0@philneum> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-seamoby@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit In response to the assumptions about soft-handoff by Phil Neumiller. * Soft-handoff is used and works well for VOICE in CDMA systems * All versions of data-carrying CDMA systems get away from soft-handoff - that includes Qualcomm's HDR, 3GPP Downlink shared channel, 3GPP High-speed downlink shared channel... Phil Neumiller wrote: > This arguments seems completely bogus to me or I am missing something > really fundamental here. Are not both 3GPP and 3GPP2 CDMA? This > whole discussion falls apart and dies on the floor than. > > ----- Original Message ----- > From: > > > There have been many mails pointing out the merit of doing header > > compression context transfer. To repeat them: > > continued, seamless compression/decompression, higher compression > > efficiency, and minimization of degradation on the user media. This last > > point is the most important in my mind. At this stage, the link technologies > > where header compression is going to be used are primarily cellular links. > > 1). Based on what evidence? So far we have WAP, iMode, and iDen. > Are you ignoring other possible edge and infrastructure technologies like > wirelesss PANs, WLANs, ad hoc networks for any particular reason? > > > In the cellular environment, handoffs (or handovers) are events that happen > > in normal operation, and therefore a very significant design effort is spent > > to minimize the impact of HO on performance. In particular, one wants to > > minimize the duration of the break. > > In post-modern cellular systems there is no break! Wake up! Qualcomm > won the war a long time ago, I just can't get it why you guys are still in > this "break" mind set. 3GPP and 3GPP2 use CDMA!!!! ITS MAKE BEFORE > BREAK. THE SOONER PEOPLE START LEARNING HOW TO DEAL > WITH IP PACKETS OVER CDMA w/ soft handover THE SOONER the > MIP list will finally mature to where it needs to be (i.e. like OBAST :-)!!! > > > if brute force header compression reinitialization is done, one would have to send > > certain number of 40-60 > > byte or more IR headers, instead of the usual 1 byte header. This big > > bandwidth demand surge will put a strain on the link. > > Please quantify this purported bandwidth demand surge and it origination. > > > Some links will cope > > with it by blanking out the user data to make room to carry the IR headers. > > When such blanking takes place, the user media (voice, etc.) will be > > unavoidably affected. > > Yes but why would we use MIPv6 over TDMA systems? I just don't get > this argument at all???? > > >The impairment caused by the handoff is thus extended, > > compared to the case where header compression is not present. > > What it impairment, its a SOFT handoff? > > > > > In the current and 3G cellular technologies, the break is about 100-150 > > msec, without header compression. > > The break will be 0 ms in 3G systems (only when a hard handover is forced) > is that what you are designing for the error leg cases? Again this argument > seems rediculously TDMA. > > I feel like Rip Van Winkle, did I wake up and everything went back to > TDMA? Why are we discussing this with reference to IPv6 handovers?? > > Regards, > > Phil > > --- > Mailing list for Robust Header Compression WG > Archive: http://www.cdt.luth.se/rohc/ From owner-seamoby@diameter.org Fri Apr 6 18:00:35 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA21467 for ; Fri, 6 Apr 2001 18:00:34 -0400 (EDT) Received: (qmail 12545 invoked by alias); 6 Apr 2001 22:44:54 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 12539 invoked by uid 200); 6 Apr 2001 22:44:53 -0000 Received: (qmail 12526 invoked from network); 6 Apr 2001 22:44:50 -0000 Received: from mgw-dax1.ext.nokia.com (63.78.179.216) by c900656-a.plstn1.sfba.home.com with SMTP; 6 Apr 2001 22:44:50 -0000 Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax1.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f36LsZg21470 for ; Fri, 6 Apr 2001 16:54:35 -0500 (CDT) Received: from daebh01nok.americas.nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Fri, 6 Apr 2001 16:54:10 -0500 Received: by daebh01nok with Internet Mail Service (5.5.2652.78) id ; Fri, 6 Apr 2001 16:54:10 -0500 Message-ID: From: rajeev.koodli@nokia.com To: neumiller@telocity.com, khiem.le@nokia.com, rajeev.koodli@nokia.com, mat@cisco.com Cc: gkenward@nortelnetworks.com, tmima@cisco.com, mccap@research.bell-labs.com, kempf@heliopolis.Eng.Sun.COM, mobile-ip@sunroof.eng.sun.com, rohc@cdt.luth.se, seamoby@diameter.org Subject: RE: [seamoby] RE: [rohc] RE: Restarting Compressor on Mobile IPv6 Handover Date: Fri, 6 Apr 2001 16:54:08 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-seamoby@diameter.org Precedence: bulk Hello Phil, > > > OK, now I am really confused. Typically (in my previous experience) > with some very large cariers like Sprint, Verizon, etc, Hard handoffs > were about 5-10% of ALL handoffs. > > Why is there no interest/concern about the soft case WHICH HAS > NOT YET BEEN RESOLVED (i.e. the other 90%)?????????? > I am no CDMA/TDMA expert, but, it appears to me that even with soft handover, you still have the issue with context initialization, which I believe is the crux here. When you have soft handover, would you re-initialize context on the new BTS/AR, or would you relocate it from old BTS/AR to the new one ? Regards, -Rajeev > Regards, > > Phil > > From owner-seamoby@diameter.org Fri Apr 6 18:04:25 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA21552 for ; Fri, 6 Apr 2001 18:04:25 -0400 (EDT) Received: (qmail 13138 invoked by alias); 6 Apr 2001 22:50:50 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 13131 invoked by uid 200); 6 Apr 2001 22:50:50 -0000 Received: (qmail 13113 invoked from network); 6 Apr 2001 22:50:46 -0000 Received: from c007-h000.c007.snv.cp.net (HELO c007.snv.cp.net) (209.228.33.206) by c900656-a.plstn1.sfba.home.com with SMTP; 6 Apr 2001 22:50:46 -0000 Received: (cpmta 7511 invoked from network); 6 Apr 2001 15:00:23 -0700 Received: from dsl-64-193-0-129.telocity.com (HELO philneum) (64.193.0.129) by smtp.telocity.com (209.228.33.206) with SMTP; 6 Apr 2001 15:00:23 -0700 X-Sent: 6 Apr 2001 22:00:23 GMT Message-ID: <007801c0bee4$da79a500$6501a8c0@philneum> Reply-To: "Phil Neumiller" From: "Phil Neumiller" To: , , Cc: , , , , , , References: Subject: Re: [seamoby] RE: [rohc] RE: Restarting Compressor on Mobile IPv6 Handover Date: Fri, 6 Apr 2001 16:59:27 -0500 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-seamoby@diameter.org Precedence: bulk Thanks for understanding Rajeev. This is the appropriate question to focus on (i.e. the lion share of the handoffs for VOICE) will be soft and I think we can all agree to that. > > I am no CDMA/TDMA expert, but, it appears to me that even with soft > handover, you still have the issue with context initialization, which I > believe is the crux here. When you have soft handover, would you > re-initialize context on the new BTS/AR, or would you relocate it from old > BTS/AR to the new one ? This is absolutely the correct question to ask. Now here is where things get ugly. This context has to be done post selection (i.e. after all macro-diversity legs have been compbined with maximal ratio combining in a CDMA system). THIS MEANS THE CONTEXT CAN NOT RESIDE ON THE BTS/AR AT ALL UNLESS YOU PUT THE SDU in the BTS/AR like OBAST!!! NOTE TO SELF: [I think I am either winning this argument or flipping my wig or both at the same time..] Again, thanks for understanding Rajeev, Phil From owner-seamoby@diameter.org Fri Apr 6 18:35:09 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA22268 for ; Fri, 6 Apr 2001 18:35:07 -0400 (EDT) Received: (qmail 14239 invoked by alias); 6 Apr 2001 23:23:55 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 14233 invoked by uid 200); 6 Apr 2001 23:23:55 -0000 Received: (qmail 14228 invoked from network); 6 Apr 2001 23:23:53 -0000 Received: from mgw-dax1.ext.nokia.com (63.78.179.216) by c900656-a.plstn1.sfba.home.com with SMTP; 6 Apr 2001 23:23:53 -0000 Received: from davir03nok.americas.nokia.com (davir03nok.americas.nokia.com [172.18.242.86]) by mgw-dax1.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f36MXbg24466 for ; Fri, 6 Apr 2001 17:33:37 -0500 (CDT) Received: from daebh02nok.americas.nokia.com (unverified) by davir03nok.americas.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Fri, 6 Apr 2001 17:32:46 -0500 Received: by daebh02nok with Internet Mail Service (5.5.2652.78) id ; Fri, 6 Apr 2001 17:32:46 -0500 Message-ID: From: rajeev.koodli@nokia.com To: mat@cisco.com, mobile-ip@sunroof.eng.sun.com Cc: rajeev.koodli@nokia.com, khiem.le@nokia.com, gkenward@nortelnetworks.com, tmima@cisco.com, mccap@research.bell-labs.com, kempf@heliopolis.eng.sun.com, rohc@cdt.luth.se, seamoby@diameter.org Subject: RE: [mobile-ip] RE: [seamoby] RE: [rohc] RE: Restarting Compresso r on Mobile IPv6 Handover Date: Fri, 6 Apr 2001 17:32:45 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-seamoby@diameter.org Precedence: bulk Hi, > > > rajeev.koodli@nokia.com writes: > > > > > From: ext Michael Thomas [mailto:mat@cisco.com] > > > > If there is no compression state at the old router, why > > > would you try to > > > > relocate it ? > > > > > > There's compression state there, but not the > > > compression state that matters: when I'm > > > receiving packets from the old AR during the > > > FMIP transition time, there will be a *new* > > > IP header appended toward the MN. This is > > > because those packets will have to be tunneled to the > > > MN. This means that it is a *new* compression > > > context, not an old existing one. > > > > > I don't have sufficient details to comment.. > > and then this: > > > You can't justify your claims. So, before you raise issues > > (related/unrelated), try to make an effort to understand > the work done by > > others. > > I don't know what you would like me to do. I've > brought up an issue, and you've brushed it > aside assumedly as irrelevant. I've been paying > attention to this thread, and as far I can > tell, nobody has answered my question. > I was not meaning to brush aside your issue, I was simply saying I didn't have sufficient details in your e-mail. Let me try to address your issue based on my understanding of your point above. Let's assume that context has been relocated from old AR to the new AR. The new AR receives a packet tunneled to the MN. The new AR can now compress the inner packet. What you do with the outer IP packet ? You could only send required fields, e.g., you can compress src and dst addresses (32 bytes in IPv6). What you need is an rohc packet format that indicates that this is a packet belonging to an old context with *some* new information (such as the Next Header field being IPv6). This *indication* bit should provide the logic to demultiplex into the correct (existing) context. This is solution space, and needs work. I hope we can focus on requirements. BTW, what is FMIP ? :-) > Also: you are also telling me that I have to > prove negatives of the form "tell me why we > _shouldn't_ do XYZ." That is a logical fallacy. > You may not like my message, but it does not > give you free reign to ignore reality. It is > in nobody's interest to design a protocol > that does not work in the areas where it would > be most useful. > > I don't wish to work on a protocol knowing that it is not going to be useful. At this point however, my apprehensions, if any, are unnecessary. -Rajeev Mike > From owner-seamoby@diameter.org Fri Apr 6 20:47:54 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA23850 for ; Fri, 6 Apr 2001 20:47:52 -0400 (EDT) Received: (qmail 16150 invoked by alias); 7 Apr 2001 01:36:13 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 16143 invoked by uid 200); 7 Apr 2001 01:36:12 -0000 Received: (qmail 16134 invoked from network); 7 Apr 2001 01:36:10 -0000 Received: from patan.sun.com (192.18.98.43) by c900656-a.plstn1.sfba.home.com with SMTP; 7 Apr 2001 01:36:10 -0000 Received: from centralmail1.Central.Sun.COM ([129.147.62.10]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA14722; Fri, 6 Apr 2001 17:45:20 -0700 (PDT) Received: from esun1as-mm. (esun1as-mm.Central.Sun.COM [129.147.34.144]) by centralmail1.Central.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id SAA24044; Fri, 6 Apr 2001 18:45:20 -0600 (MDT) Received: from sunyata.sun.com by esun1as-mm. (SMI-8.6/SMI-SVR4) id SAA06062; Fri, 6 Apr 2001 18:49:09 -0600 Message-Id: <5.0.0.25.1.20010407090947.00a24eb0@localhost> X-Sender: kempf@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Sat, 07 Apr 2001 09:21:48 +0900 To: "Gary Kenward" , seamoby@diameter.org From: James Kempf Subject: RE: [seamoby] Response of Mobile Operator to Request for Info on Realistic Paging Cc: makin@isi.edu In-Reply-To: <9FBD322B7824D511B36900508BF93C9C125764@zcard031.ca.nortel. com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-seamoby@diameter.org Precedence: bulk Hi Gary, They don't like HLR/VLR because these things are basically databases and they are required to lay out millions when they upgrade because they have to buy a new MSC (with the VLR in particular). If they were AAA servers and MIP home agents, the cost would be much less, to say nothing of the wider expertese, management tools, etc. available for IP networks. If you want to know more about this, let's take it off line. jak At 10:03 AM 4/6/01 -0400, Gary Kenward wrote: >Interesting James, but was it this anonymous persons opinion that the >really significant >flaw in 3GPP was HLR/VLRs? Or did he have other issues, like the many >problems >with the packet transport? the access model? > >I am not defending 3GPP. It is simply that there is sooooo much more to >wireless IP access then mobile IP and AAA. > >Gary > > > -----Original Message----- > > From: James Kempf [mailto:james.kempf@sun.com] > > Sent: Thursday, April 05, 2001 10:21 AM > > To: seamoby@diameter.org > > Cc: makin@isi.edu > > Subject: [seamoby] Response of Mobile Operator to Request for Info on > > Realistic Paging > > > > > > Okay, folks, I spoke with a mobile operator here at MWIF in Korea. > > Alessio, I'm really sorry they can't post themselves, but > > they generally > > don't hang out on specific IETF working group lists. One of > > them will be > > at IETF 51, and hopefully involved in a requirements discussion via > > email beforehand (as soon as we can set up the list), so you > > can ask him there > > if you think I'm making this up. > > > > Some background on the operator. The operator I talked with > > has had over 10 > > years of experience deploying GSM networks in Asia, and is a major > > technical contributor to a leading European cellular > > provider. He is very > > critical of the direction being taken > > by 3GPP, sees IETF as a promising possiblity to make the > > mobile Internet > > happen the way most IETFer's would like to see it happen. His > > view is therefore > > likely to be different from someone who thinks 3GPP is the > > bees knees, however, > > technically, this guy is at the top of the pack. He knows cellular. > > > > Anyway, I explained to him the problem statement, and that we > > were designing > > for a target network in which the HLR and VLR were replaced by mobile > > IP and AAA. That is to say, we are not just desiging for GPRS or 3GPP2 > > IOS because they already have solutions to this problem, > > however imperfect. > > > > His response was that it is important and necessary that no a > > priori connection > > be assumed between subnets and paging areas. Another example, not > > cited in the draft which came out in our conversation, > > involves overlapping > > paging areas. It is sometimes necessary to configure a paging > > area entirely > > within another paging area, due to hotspots where there are > > lots of mobile > > nodes in dormant mode. There absolutely cannot be any > > constraint as to > > subnet in this case, because the inner, donut hole may have > > an arbitrary > > relation to the subnets. > > > > BTW, I also asked him about the case where wCDMA allows a mobile node > > to have more than one paging identifier, and he said this was because > > the mobile node could be in soft handoff between two RNCs that were in > > two different location areas. It would therefore require a > > paging identifier > > for both. > > > > I suppose it is possible to spin this however you want if you > > do or don't > > believe > > the problem statement, but, to me, it seems a pretty clear > > endorsement of > > the problem statement. > > > > jak > > > > From owner-seamoby@diameter.org Fri Apr 6 21:35:59 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA25027 for ; Fri, 6 Apr 2001 21:35:57 -0400 (EDT) Received: (qmail 16980 invoked by alias); 7 Apr 2001 02:25:00 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 16974 invoked by uid 200); 7 Apr 2001 02:25:00 -0000 Received: (qmail 16969 invoked from network); 7 Apr 2001 02:24:58 -0000 Received: from mercury.sun.com (192.9.25.1) by c900656-a.plstn1.sfba.home.com with SMTP; 7 Apr 2001 02:24:58 -0000 Received: from centralmail1.Central.Sun.COM ([129.147.62.10]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id SAA27571; Fri, 6 Apr 2001 18:33:58 -0700 (PDT) Received: from esun1as-mm. (esun1as-mm.Central.Sun.COM [129.147.34.144]) by centralmail1.Central.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id TAA00851; Fri, 6 Apr 2001 19:33:57 -0600 (MDT) Received: from sunyata.sun.com by esun1as-mm. (SMI-8.6/SMI-SVR4) id TAA06911; Fri, 6 Apr 2001 19:37:45 -0600 Message-Id: <5.0.0.25.1.20010407101802.00a149a0@localhost> X-Sender: kempf@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Sat, 07 Apr 2001 10:28:59 +0900 To: "Phil Neumiller" , , , From: James Kempf Subject: Re: [seamoby] RE: [rohc] RE: Restarting Compressor on Mobile IPv6 Handover Cc: , , , , , In-Reply-To: <004601c0bee2$6ea57f40$6501a8c0@philneum> References: <8572CF1E2A95D211A1190008C7EAA24602720927@daeis05nok> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-seamoby@diameter.org Precedence: bulk Phil, I think this discussion may be a case of misunderstanding about what is done where. Header compression seems of most value on what in 3GPP speak is called the nonaccess stratum. This is the packets that applications at the top of the mobile's stack sees, and these are the bits that go out over the air. These packets never see soft handoff, because they are segmented into radio frames by the time soft handoff occurs. The compression must be done before the packets are stuffed into radio frames. In the so-called access stratum, header compression may be used to remove header overhead on slow links so that the real time requirements of CDMA radio access can be met. There isn't an issue with moving context because the SDU is at a centrallly located point so when a soft handoff leg needs to be added, the SDU can take care of it. The only time there may be an issue is when the SDU itself gets relocated (called SRNS relocation in 3GPP speak). This is a fairly rare event, but would need to be handled in an IP RAN design. Or maybe you had something different in mind? jak At 04:42 PM 4/6/01 -0500, Phil Neumiller wrote: >OK, now I am really confused. Typically (in my previous experience) >with some very large cariers like Sprint, Verizon, etc, Hard handoffs >were about 5-10% of ALL handoffs. > >Why is there no interest/concern about the soft case WHICH HAS >NOT YET BEEN RESOLVED (i.e. the other 90%)?????????? > >Regards, > >Phil From owner-seamoby@diameter.org Fri Apr 6 21:47:21 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA25222 for ; Fri, 6 Apr 2001 21:47:20 -0400 (EDT) Received: (qmail 17510 invoked by alias); 7 Apr 2001 02:35:29 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 17504 invoked by uid 200); 7 Apr 2001 02:35:28 -0000 Received: (qmail 17499 invoked from network); 7 Apr 2001 02:35:26 -0000 Received: from c007-h000.c007.snv.cp.net (HELO c007.snv.cp.net) (209.228.33.206) by c900656-a.plstn1.sfba.home.com with SMTP; 7 Apr 2001 02:35:26 -0000 Received: (cpmta 17780 invoked from network); 6 Apr 2001 18:44:37 -0700 Received: from unknown (HELO philneum) (64.193.0.129) by smtp.telocity.com (209.228.33.206) with SMTP; 6 Apr 2001 18:44:37 -0700 X-Sent: 7 Apr 2001 01:44:37 GMT Message-ID: <005601c0bf04$2e81b240$6501a8c0@philneum> Reply-To: "Phil Neumiller" From: "Phil Neumiller" To: , , , "James Kempf" Cc: , , , , , References: <8572CF1E2A95D211A1190008C7EAA24602720927@daeis05nok> <5.0.0.25.1.20010407101802.00a149a0@localhost> Subject: Re: [seamoby] RE: [rohc] RE: Restarting Compressor on Mobile IPv6 Handover Date: Fri, 6 Apr 2001 20:43:43 -0500 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-seamoby@diameter.org Precedence: bulk Jim, and (really long threaders) These are clearly excellent details James, but I would be willing to bet $2.00 that none of what you state below is in an I-D of any sort, and this has probably lead to an incredible amount of confusion and wasted bandwidth on the MIP list. I have not kept up with these standards as you know, I was familiar with them at one time. I made some additional comments below on your 3GPP update which I really appreciated. ----- Original Message ----- From: "James Kempf" To: "Phil Neumiller" ; ; ; Cc: ; ; ; ; ; Sent: Friday, April 06, 2001 8:28 PM Subject: Re: [seamoby] RE: [rohc] RE: Restarting Compressor on Mobile IPv6 Handover > Phil, > > I think this discussion may be a case of misunderstanding about what is > done where. > > Header compression seems of most value on what in 3GPP speak is called > the nonaccess stratum. This is the packets that applications at the top of > the mobile's stack sees, and these are the bits that go out over the air. > These packets never see soft handoff, because they are segmented into > radio frames by the time soft handoff occurs. The compression must > be done before the packets are stuffed into radio frames. > OK this is the mobile side and I believe we were talking about the BTS/AR side in this thread. > In the so-called access stratum, header compression may be used to > remove header overhead on slow links so that the real time requirements > of CDMA radio access can be met. There isn't an issue with moving context > because the SDU is at a centrallly located point so when a soft handoff > leg needs to be added, the SDU can take care of it. The only time > there may be an issue is when the SDU itself gets relocated (called > SRNS relocation in 3GPP speak). This is a fairly rare event, but > would need to be handled in an IP RAN design. Oh, I see, very interesting. The difference here with OBAST is that the so called SRNS is a bit more frequent since the "virtual" SDU is following the mobile throgh the "sea" of moby (I mean BTSs). I guess that even between what 3GPP dis and what OBAST did the original thread was still bogus, and that was my point. Seems that the arguments were being based strictly on hard HO and no description of the soft case. One question is the SRNS operation "soft" in the 3GPP design (because it was in OBAST of course!). Thanks, Phil From owner-seamoby@diameter.org Fri Apr 6 21:50:58 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA25309 for ; Fri, 6 Apr 2001 21:50:57 -0400 (EDT) Received: (qmail 17872 invoked by alias); 7 Apr 2001 02:38:40 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 17866 invoked by uid 200); 7 Apr 2001 02:38:40 -0000 Received: (qmail 17858 invoked from network); 7 Apr 2001 02:38:38 -0000 Received: from patan.sun.com (192.18.98.43) by c900656-a.plstn1.sfba.home.com with SMTP; 7 Apr 2001 02:38:38 -0000 Received: from centralmail1.Central.Sun.COM ([129.147.62.10]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA01652; Fri, 6 Apr 2001 18:47:40 -0700 (PDT) Received: from esun1as-mm. (esun1as-mm.Central.Sun.COM [129.147.34.144]) by centralmail1.Central.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id TAA02017; Fri, 6 Apr 2001 19:47:39 -0600 (MDT) Received: from sunyata.sun.com by esun1as-mm. (SMI-8.6/SMI-SVR4) id TAA07096; Fri, 6 Apr 2001 19:51:28 -0600 Message-Id: <5.0.0.25.1.20010407104123.00a23d10@localhost> X-Sender: kempf@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Sat, 07 Apr 2001 10:42:42 +0900 To: "Phil Neumiller" , , , From: James Kempf Subject: Re: [seamoby] RE: [rohc] RE: Restarting Compressor on Mobile IPv6 Handover Cc: , , , , , In-Reply-To: <005601c0bf04$2e81b240$6501a8c0@philneum> References: <8572CF1E2A95D211A1190008C7EAA24602720927@daeis05nok> <5.0.0.25.1.20010407101802.00a149a0@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-seamoby@diameter.org Precedence: bulk Hi Phil, At 08:43 PM 4/6/01 -0500, Phil Neumiller wrote: >One question is the SRNS operation "soft" in the 3GPP design (because it >was in OBAST of course!). I think it is but it is not between BTSs (Node B) as I presume it was in OBAST. It is between RNCs (serving RNC to drift RNC, at which point, drift RNC becomes serving). jak From owner-seamoby@diameter.org Sat Apr 7 08:32:25 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA13865 for ; Sat, 7 Apr 2001 08:32:25 -0400 (EDT) Received: (qmail 21025 invoked by alias); 7 Apr 2001 13:20:28 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 21019 invoked by uid 200); 7 Apr 2001 13:20:27 -0000 Received: (qmail 21014 invoked from network); 7 Apr 2001 13:20:25 -0000 Received: from ihemail1.lucent.com (HELO ihemail1.firewall.lucent.com) (192.11.222.161) by c900656-a.plstn1.sfba.home.com with SMTP; 7 Apr 2001 13:20:25 -0000 Received: from ihemail1.firewall.lucent.com (localhost [127.0.0.1]) by ihemail1.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id IAA04473 for ; Sat, 7 Apr 2001 08:30:07 -0400 (EDT) Received: from uk0006exch001h.wins.lucent.com (h135-86-160-150.lucent.com [135.86.160.150]) by ihemail1.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id IAA04453 for ; Sat, 7 Apr 2001 08:30:06 -0400 (EDT) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2650.21) id ; Sat, 7 Apr 2001 13:30:06 +0100 Message-ID: <976F7C55E3B2D111A0720008C728549C097CC31F@en0060exch001u.uk.lucent.com> From: "Casati, Alessio \(Alessio\)" To: "'James Kempf'" , Gary Kenward , seamoby@diameter.org Subject: RE: [seamoby] Response of Mobile Operator to Request for Info on Realistic Paging Date: Sat, 7 Apr 2001 13:30:04 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: owner-seamoby@diameter.org Precedence: bulk * *Hi Gary, * *They don't like HLR/VLR because these things are basically *databases and they *are required to lay out millions when they upgrade because they have to *buy a new MSC (with the VLR in particular). If they were AAA *servers and *MIP home agents, the cost would be much less, to say nothing *of the wider *expertese, management tools, etc. available for IP networks. * And this is evolving technologies/implementation according to changed industry conditions, not exactly removing the HLR and VLR functionality which will still be there (although implemented in a different way, and baptized differently in this new life, for instance HSS in 3GPP). So, I guess everybody on this last part of this dead thread (to be killed as per WG chair request) share the same understanding, only the terminology was making opinions apparently diverge. alessio From owner-seamoby@diameter.org Sat Apr 7 16:46:34 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA17823 for ; Sat, 7 Apr 2001 16:45:51 -0400 (EDT) Received: (qmail 23178 invoked by alias); 7 Apr 2001 21:31:14 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 23172 invoked by uid 200); 7 Apr 2001 21:31:13 -0000 Received: (qmail 23167 invoked from network); 7 Apr 2001 21:31:11 -0000 Received: from zcars04f.nortelnetworks.com (HELO zcars04f.ca.nortel.com) (47.129.242.57) by c900656-a.plstn1.sfba.home.com with SMTP; 7 Apr 2001 21:31:11 -0000 Received: from zcard015.ca.nortel.com by zcars04f.ca.nortel.com; Sat, 7 Apr 2001 16:11:40 -0400 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Sat, 7 Apr 2001 16:11:41 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C125776@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'James Kempf'" , seamoby@diameter.org Cc: makin@isi.edu Subject: RE: [seamoby] Response of Mobile Operator to Request for Info on Realistic Paging Date: Sat, 7 Apr 2001 16:11:43 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0BF9E.F6E8BE00" X-Orig: Sender: owner-seamoby@diameter.org Precedence: bulk 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_01C0BF9E.F6E8BE00 Content-Type: text/plain; charset="iso-8859-1" Don't get me wrong, I see advantages with IP networking. I guess I'll have to take your word that AAA/MIP HA servers have smaller databases. I suspect that if you looked at all the services provided for cellular, and all the corresponding IP servers required (such as Policy, DNS), it probably comes closer to the same $$$. There is still an advantage, but more in terms of scalability and competition between vendors. Cellular operators are always keen on getting rid of boxes, but they seldom want to relinquish control of the service (can you say "WAP", I knew you could ;^} ). In terms of reducing cost and complexity, I suspect that such cellular specific beasts such as the RNC, SGSN, GGSN, PDSN are more obvious opportunities. Gary > -----Original Message----- > From: James Kempf [mailto:james.kempf@sun.com] > Sent: Friday, April 06, 2001 8:22 PM > To: Kenward, Gary [WDLN2:AN10:EXCH]; seamoby@diameter.org > Cc: makin@isi.edu > Subject: RE: [seamoby] Response of Mobile Operator to Request for Info > on Realistic Paging > > > Hi Gary, > > They don't like HLR/VLR because these things are basically > databases and they > are required to lay out millions when they upgrade because > they have to > buy a new MSC (with the VLR in particular). If they were AAA > servers and > MIP home agents, the cost would be much less, to say nothing > of the wider > expertese, management tools, etc. available for IP networks. > > If you want to know more about this, let's take it off line. > > jak > > > At 10:03 AM 4/6/01 -0400, Gary Kenward wrote: > > >Interesting James, but was it this anonymous persons opinion > that the > >really significant > >flaw in 3GPP was HLR/VLRs? Or did he have other issues, like > the many > >problems > >with the packet transport? the access model? > > > >I am not defending 3GPP. It is simply that there is sooooo > much more to > >wireless IP access then mobile IP and AAA. > > > >Gary > > > > > -----Original Message----- > > > From: James Kempf > [mailto:james.kempf@sun.com] > > > Sent: Thursday, April 05, 2001 10:21 AM > > > To: seamoby@diameter.org > > > Cc: makin@isi.edu > > > Subject: [seamoby] Response of Mobile Operator to Request > for Info on > > > Realistic Paging > > > > > > > > > Okay, folks, I spoke with a mobile operator here at MWIF in Korea. > > > Alessio, I'm really sorry they can't post themselves, but > > > they generally > > > don't hang out on specific IETF working group lists. One of > > > them will be > > > at IETF 51, and hopefully involved in a requirements > discussion via > > > email beforehand (as soon as we can set up the list), so you > > > can ask him there > > > if you think I'm making this up. > > > > > > Some background on the operator. The operator I talked with > > > has had over 10 > > > years of experience deploying GSM networks in Asia, and is a major > > > technical contributor to a leading European cellular > > > provider. He is very > > > critical of the direction being taken > > > by 3GPP, sees IETF as a promising possiblity to make the > > > mobile Internet > > > happen the way most IETFer's would like to see it happen. His > > > view is therefore > > > likely to be different from someone who thinks 3GPP is the > > > bees knees, however, > > > technically, this guy is at the top of the pack. He knows > cellular. > > > > > > Anyway, I explained to him the problem statement, and that we > > > were designing > > > for a target network in which the HLR and VLR were > replaced by mobile > > > IP and AAA. That is to say, we are not just desiging for > GPRS or 3GPP2 > > > IOS because they already have solutions to this problem, > > > however imperfect. > > > > > > His response was that it is important and necessary that no a > > > priori connection > > > be assumed between subnets and paging areas. Another example, not > > > cited in the draft which came out in our conversation, > > > involves overlapping > > > paging areas. It is sometimes necessary to configure a paging > > > area entirely > > > within another paging area, due to hotspots where there are > > > lots of mobile > > > nodes in dormant mode. There absolutely cannot be any > > > constraint as to > > > subnet in this case, because the inner, donut hole may have > > > an arbitrary > > > relation to the subnets. > > > > > > BTW, I also asked him about the case where wCDMA allows a > mobile node > > > to have more than one paging identifier, and he said this > was because > > > the mobile node could be in soft handoff between two RNCs > that were in > > > two different location areas. It would therefore require a > > > paging identifier > > > for both. > > > > > > I suppose it is possible to spin this however you want if you > > > do or don't > > > believe > > > the problem statement, but, to me, it seems a pretty clear > > > endorsement of > > > the problem statement. > > > > > > jak > > > > > > > > ------_=_NextPart_001_01C0BF9E.F6E8BE00 Content-Type: text/html; charset="iso-8859-1" RE: [seamoby] Response of Mobile Operator to Request for Info on Realistic Paging

Don't get me wrong, I see advantages with IP networking.
I guess I'll have to take your word that AAA/MIP HA servers
have smaller databases. I suspect that if you looked at all the
services provided for cellular, and all the corresponding IP
servers required (such as Policy, DNS), it probably comes closer
to the same $$$. There is still an advantage, but more in terms
of scalability and competition between vendors.

Cellular operators are always keen on getting rid of boxes, but
they seldom want to relinquish control of the service (can you
say "WAP", I knew you could ;^} ).  In terms of reducing cost and
complexity, I suspect that such cellular specific beasts such as the
RNC, SGSN, GGSN, PDSN are more obvious opportunities.

Gary

> -----Original Message-----
> From: James Kempf [mailto:james.kempf@sun.com]
> Sent: Friday, April 06, 2001 8:22 PM
> To: Kenward, Gary [WDLN2:AN10:EXCH]; seamoby@diameter.org
> Cc: makin@isi.edu
> Subject: RE: [seamoby] Response of Mobile Operator to Request for Info
> on Realistic Paging
>
>
> Hi Gary,
>
> They don't like HLR/VLR because these things are basically
> databases and they
> are required to lay out millions when they upgrade because
> they have to
> buy a new MSC (with the VLR in particular). If they were AAA
> servers and
> MIP home agents, the cost would be much less, to say nothing
> of the wider
> expertese, management tools, etc. available for IP networks.
>
> If you want to know more about this, let's take it off line.
>
>                  jak
>
>
> At 10:03 AM 4/6/01 -0400, Gary Kenward wrote:
>
> >Interesting James, but was it this anonymous persons opinion
> that the
> >really significant
> >flaw in 3GPP was HLR/VLRs? Or did he have other issues, like
> the many
> >problems
> >with the packet transport? the access model?
> >
> >I am not defending 3GPP. It is simply that there is sooooo
> much more to
> >wireless IP access then mobile IP and AAA.
> >
> >Gary
> >
> > > -----Original Message-----
> > > From: James Kempf
> [<mailto:james.kempf@sun.com>mailto:james.kempf@sun.com]
> > > Sent: Thursday, April 05, 2001 10:21 AM
> > > To: seamoby@diameter.org
> > > Cc: makin@isi.edu
> > > Subject: [seamoby] Response of Mobile Operator to Request
> for Info on
> > > Realistic Paging
> > >
> > >
> > > Okay, folks, I spoke with a mobile operator here at MWIF in Korea.
> > > Alessio, I'm really sorry they can't post themselves, but
> > > they generally
> > > don't hang out on specific IETF working group lists. One of
> > > them will be
> > > at IETF 51, and hopefully involved in a requirements
> discussion via
> > > email beforehand (as soon as we can set up the list), so you
> > > can ask him there
> > > if you think I'm making this up.
> > >
> > > Some background on the operator. The operator I talked with
> > > has had over 10
> > > years of experience deploying GSM networks in Asia, and is a major
> > > technical contributor to a leading European cellular
> > > provider. He is very
> > > critical of the direction being taken
> > > by 3GPP, sees IETF as a promising possiblity to make the
> > > mobile Internet
> > > happen the way most IETFer's would like to see it happen. His
> > > view is therefore
> > > likely to be different from someone who thinks 3GPP is the
> > > bees knees, however,
> > > technically, this guy is at the top of the pack. He knows
> cellular.
> > >
> > > Anyway, I explained to him the problem statement, and that we
> > > were designing
> > > for a target network in which the HLR and VLR were
> replaced by mobile
> > > IP and AAA. That is to say, we are not just desiging for
> GPRS or 3GPP2
> > > IOS because they already have solutions to this problem,
> > > however imperfect.
> > >
> > > His response was that it is important and necessary that no a
> > > priori connection
> > > be assumed between subnets and paging areas. Another example, not
> > > cited in the draft which came out in our conversation,
> > > involves overlapping
> > > paging areas. It is sometimes necessary to configure a paging
> > > area entirely
> > > within another paging area, due to hotspots where there are
> > > lots of mobile
> > > nodes in dormant mode. There absolutely cannot be any
> > > constraint as to
> > > subnet in this case, because the inner, donut hole may have
> > > an arbitrary
> > > relation to the subnets.
> > >
> > > BTW, I also asked him about the case where wCDMA allows a
> mobile node
> > > to have more than one paging identifier, and he said this
> was because
> > > the mobile node could be in soft handoff between two RNCs
> that were in
> > > two different location areas. It would therefore require a
> > > paging identifier
> > > for both.
> > >
> > > I suppose it is possible to spin this however you want if you
> > > do or don't
> > > believe
> > > the problem statement, but, to me, it seems a pretty clear
> > > endorsement of
> > > the problem statement.
> > >
> > >               jak
> > >
> > >
>
>

------_=_NextPart_001_01C0BF9E.F6E8BE00-- From owner-seamoby@diameter.org Sun Apr 8 14:17:01 2001 Received: from charizard.diameter.org ([24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA11627 for ; Sun, 8 Apr 2001 14:17:00 -0400 (EDT) Received: (qmail 520 invoked by alias); 8 Apr 2001 19:06:03 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 514 invoked by uid 200); 8 Apr 2001 19:06:02 -0000 Received: (qmail 509 invoked from network); 8 Apr 2001 19:06:00 -0000 Received: from mailhost.iprg.nokia.com (205.226.5.12) by c900656-a.plstn1.sfba.home.com with SMTP; 8 Apr 2001 19:06:00 -0000 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 LAA14693 for ; Sun, 8 Apr 2001 11:15:03 -0700 (PDT) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f38HbMb15199; Sun, 8 Apr 2001 10:37:22 -0700 X-mProtect: Sun, 8 Apr 2001 10:37:22 -0700 Nokia Silicon Valley Messaging Protection Received: from Icharliep-1.iprg.nokia.com (205.226.22.18, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(WTS.12.69) smtpdAlqG2Z; Sun, 08 Apr 2001 10:36:58 PDT Message-ID: <3AD0A200.A1B972C3@iprg.nokia.com> Date: Sun, 08 Apr 2001 10:38:08 -0700 From: Charlie Perkins Organization: Nokia X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Gary Kenward CC: seamoby@diameter.org Subject: Re: [seamoby] Response of Mobile Operator to Request for Info on Realistic Paging References: <9FBD322B7824D511B36900508BF93C9C125764@zcard031.ca.nortel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-seamoby@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit Hello Gary, > I am not defending 3GPP. It is simply that there is sooooo much more > to wireless IP access then mobile IP and AAA. I agree with you 100% that Mobile IP and AAA are only part of the story. However, it seems that the overall story is one of systems engineering. The important question here is to find out what new protocols are needed to enable systems integrators to develop useful systems for wireless IP access. I don't think we can ever solve the whole problem with protocols, and protocols at the IP layer can help with the solution of only a restricted part of the problem. Regards, Charlie P. From owner-seamoby@diameter.org Sun Apr 8 16:02:20 2001 Received: from charizard.diameter.org ([24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA12082 for ; Sun, 8 Apr 2001 16:02:18 -0400 (EDT) Received: (qmail 1310 invoked by alias); 8 Apr 2001 20:50:34 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 1304 invoked by uid 200); 8 Apr 2001 20:50:34 -0000 Received: (qmail 1299 invoked from network); 8 Apr 2001 20:50:32 -0000 Received: from zcars04f.nortelnetworks.com (HELO zcars04f.ca.nortel.com) (47.129.242.57) by c900656-a.plstn1.sfba.home.com with SMTP; 8 Apr 2001 20:50:32 -0000 Received: from zcard015.ca.nortel.com by zcars04f.ca.nortel.com; Sun, 8 Apr 2001 15:30:01 -0400 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Sun, 8 Apr 2001 15:30:03 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C125777@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'Charlie Perkins'" Cc: seamoby@diameter.org Subject: RE: [seamoby] Response of Mobile Operator to Request for Info on Realistic Paging Date: Sun, 8 Apr 2001 15:30:08 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0C062.5217E6C0" X-Orig: Sender: owner-seamoby@diameter.org Precedence: bulk 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_01C0C062.5217E6C0 Content-Type: text/plain; charset="iso-8859-1" Too true Charlie. > -----Original Message----- > From: Charlie Perkins [mailto:charliep@IPRG.nokia.com] > Sent: Sunday, April 08, 2001 1:38 PM > To: Kenward, Gary [WDLN2:AN10:EXCH] > Cc: seamoby@diameter.org > Subject: Re: [seamoby] Response of Mobile Operator to Request for Info > on Realistic Paging > > > > Hello Gary, > > > I am not defending 3GPP. It is simply that there is sooooo much more > > to wireless IP access then mobile IP and AAA. > > I agree with you 100% that Mobile IP and AAA are only part of > the story. > > However, it seems that the overall story is one of systems > engineering. > The important question here is to find out what new protocols > are needed > > to enable systems integrators to develop useful systems for > wireless IP > access. I don't think we can ever solve the whole problem with > protocols, > and protocols at the IP layer can help with the solution of only a > restricted > part of the problem. > > Regards, > Charlie P. > > > > ------_=_NextPart_001_01C0C062.5217E6C0 Content-Type: text/html; charset="iso-8859-1" RE: [seamoby] Response of Mobile Operator to Request for Info on Realistic Paging

Too true Charlie.


> -----Original Message-----
> From: Charlie Perkins [mailto:charliep@IPRG.nokia.com]
> Sent: Sunday, April 08, 2001 1:38 PM
> To: Kenward, Gary [WDLN2:AN10:EXCH]
> Cc: seamoby@diameter.org
> Subject: Re: [seamoby] Response of Mobile Operator to Request for Info
> on Realistic Paging
>
>
>
> Hello Gary,
>
> > I am not defending 3GPP. It is simply that there is sooooo much more
> > to wireless IP access then mobile IP and AAA.
>
> I agree with you 100% that Mobile IP and AAA are only part of
> the story.
>
> However, it seems that the overall story is one of systems
> engineering.
> The important question here is to find out what new protocols
> are needed
>
> to enable systems integrators to develop useful systems for
> wireless IP
> access.  I don't think we can ever solve the whole problem with
> protocols,
> and protocols at the IP layer can help with the solution of only a
> restricted
> part of the problem.
>
> Regards,
> Charlie P.
>
>
>
>

------_=_NextPart_001_01C0C062.5217E6C0-- From owner-seamoby@diameter.org Sun Apr 8 18:10:43 2001 Received: from charizard.diameter.org ([24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA12669 for ; Sun, 8 Apr 2001 18:10:42 -0400 (EDT) Received: (qmail 2126 invoked by alias); 8 Apr 2001 22:59:10 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 2120 invoked by uid 200); 8 Apr 2001 22:59:10 -0000 Received: (qmail 2114 invoked from network); 8 Apr 2001 22:59:06 -0000 Received: from albatross-ext.wise.edt.ericsson.se (194.237.142.116) by c900656-a.plstn1.sfba.home.com with SMTP; 8 Apr 2001 22:59:06 -0000 Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id f38M8qI00256 for ; Mon, 9 Apr 2001 00:08:52 +0200 (MEST) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Mon Apr 09 00:08:48 2001 +0200 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Mon, 9 Apr 2001 00:04:24 +0200 Message-ID: <034BEFD03799D411A59F00508BDF7546013DBD67@esealnt448.al.sw.ericsson.se> From: "Hesham Soliman \(ERA\)" To: "'Patrice Calhoun'" , "Casati, Alessio \(Alessio\)" Cc: "Seamoby \(E-mail\)" Subject: RE: [seamoby] Response of Mobile Operator to Request for Info on Re alistic Paging Date: Mon, 9 Apr 2001 00:08:46 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-seamoby@diameter.org Precedence: bulk Pat, Sorry for the short disobedience to your recommendtion to kill the thread. But for the record, I think Alessio is making a lot of sense. Others also raised similar issues in Minneapolis. Regards, Hesham > -----Original Message----- > From: Patrice Calhoun [SMTP:pcalhoun@nasnfs.Eng.Sun.COM] > Sent: Saturday, 7 April 2001 12:41 > To: Casati, Alessio (Alessio) > Cc: Seamoby (E-mail) > Subject: Re: [seamoby] Response of Mobile Operator to Request for Info on Re alistic Paging > > I have been trying to sit by the sidelines, and allow everyone to express > their opinion, but it is apparent to me that there is no possible compromise > here. Alessio is insistent that this is useless, and others do not think so. > They find this work useful, and have stated their opinions as well. > > So, in the spirit of cooperation, perhaps we can put this thread aside, and > start working on the requirements. > > Please kill this thread. If the market does in fact not find this work useful, > then like many other things from the IETF, it will not have much deployment. > > As for HLR/VLR, I know that there is significant work going on to eliminate > them in *some* of the SDOs. Again, whether or not carriers will use the new > standards is nothing more than a guess any one of us could do. > > So, let's get to work! > > PatC > > > > > > > Your opinion is not shared by either the working group chair > > nor by the AD. > > When the AD reports back to us, we will see whether it is shared by > > the > > IESG. We are not talking about GPRS nor 3GPP2, we are talking > > about a future network where there is no HLR or VLR. > > > > So, this should be written in the problem statement. > > However this does not change the validity of > > what I wrote. By the way there are > > a few operators out there that are happy to use HLR > > and VLR. Those concepts I wrote will remain valid, although technology > > and naming of for the same functionality will evolve. So, something > > meaningless today (such as a wireless net without HLR and VLR > > functionality, > > will be meaningless in the future). Need of L3 paging is > > meaningless today > > as it will be tomorrow (unless what you are doing is what the GTP > > PDU notification does today, in which case you are doing really nothing > > new, since this was done years ago in ETSI - if you are doing that > > then I can point you to where you could look this up not to > > reinvent the wheel > > too much) > > > > My observation is that you keep bringing up the same points, > > which I keep > > answering. To that extent, Mike's comment that you seem to be > > disruptive > > is appropriate. > > > > The same points are brought insofar as no response is given to > > them. I wonder why I get no answer other than " we work by > > rough consensus". > > It is depressing :). > > > > > > alessio > From owner-seamoby@diameter.org Mon Apr 9 10:41:04 2001 Received: from charizard.diameter.org ([24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA07935 for ; Mon, 9 Apr 2001 10:41:03 -0400 (EDT) Received: (qmail 7011 invoked by alias); 9 Apr 2001 15:07:14 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 7005 invoked by uid 200); 9 Apr 2001 15:07:14 -0000 Received: (qmail 7000 invoked from network); 9 Apr 2001 15:07:12 -0000 Received: from atlsnmx1.nextel.com (167.20.198.200) by c900656-a.plstn1.sfba.home.com with SMTP; 9 Apr 2001 15:07:12 -0000 Received: from atlntgw02.nextel.com (atlntgw02.nextel.com [10.8.79.186]) by atlsnmx1.nextel.com (8.8.8+Sun/8.8.6) with ESMTP id TAA05540; Sun, 8 Apr 2001 19:43:04 -0400 (EDT) Received: by atlntgw02.nextel.com with Internet Mail Service (5.5.2650.21) id <2GY2RANZ>; Sun, 8 Apr 2001 19:43:34 -0400 Message-ID: <020A5EC56F3FD411B5230008C716D0858685DC@nhqntex01.nextel.com> From: "Martin, David P" To: "'Gary Kenward'" , "'James Kempf'" , seamoby@diameter.org Cc: makin@isi.edu Subject: RE: [seamoby] Response of Mobile Operator to Request for Info on Realistic Paging Date: Sun, 8 Apr 2001 19:38:07 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-seamoby@diameter.org Precedence: bulk As a representative of a wireless operator, and having seriously looked into IP services vs traditional telephony services, I can tell you that the $$$ savings are not there today. However, if you think of all the people that know how to code to AAA and MIP, and that the IP solutions typically follow open interfaces rather than closed proprietary interfaces, and that IETF standards stress interoperability, other advantages of the IP servers become apparent than just $$$. However, having said that, the general feeling is that the cost curves of the IP solutions have a large ability to decrease, while it will be tough for many of the traditional telephony systems to follow the IP cost curves. The future will tell... -----Original Message----- From: Gary Kenward [mailto:gkenward@nortelnetworks.com] Sent: Saturday, April 07, 2001 4:12 PM To: 'James Kempf'; seamoby@diameter.org Cc: makin@isi.edu Subject: RE: [seamoby] Response of Mobile Operator to Request for Info on Realistic Paging Don't get me wrong, I see advantages with IP networking. I guess I'll have to take your word that AAA/MIP HA servers have smaller databases. I suspect that if you looked at all the services provided for cellular, and all the corresponding IP servers required (such as Policy, DNS), it probably comes closer to the same $$$. There is still an advantage, but more in terms of scalability and competition between vendors. Cellular operators are always keen on getting rid of boxes, but they seldom want to relinquish control of the service (can you say "WAP", I knew you could ;^} ). In terms of reducing cost and complexity, I suspect that such cellular specific beasts such as the RNC, SGSN, GGSN, PDSN are more obvious opportunities. Gary > -----Original Message----- > From: James Kempf [ mailto:james.kempf@sun.com ] > Sent: Friday, April 06, 2001 8:22 PM > To: Kenward, Gary [WDLN2:AN10:EXCH]; seamoby@diameter.org > Cc: makin@isi.edu > Subject: RE: [seamoby] Response of Mobile Operator to Request for Info > on Realistic Paging > > > Hi Gary, > > They don't like HLR/VLR because these things are basically > databases and they > are required to lay out millions when they upgrade because > they have to > buy a new MSC (with the VLR in particular). If they were AAA > servers and > MIP home agents, the cost would be much less, to say nothing > of the wider > expertese, management tools, etc. available for IP networks. > > If you want to know more about this, let's take it off line. > > jak > > > At 10:03 AM 4/6/01 -0400, Gary Kenward wrote: > > >Interesting James, but was it this anonymous persons opinion > that the > >really significant > >flaw in 3GPP was HLR/VLRs? Or did he have other issues, like > the many > >problems > >with the packet transport? the access model? > > > >I am not defending 3GPP. It is simply that there is sooooo > much more to > >wireless IP access then mobile IP and AAA. > > > >Gary > > > > > -----Original Message----- > > > From: James Kempf > [< mailto:james.kempf@sun.com > mailto:james.kempf@sun.com ] > > > Sent: Thursday, April 05, 2001 10:21 AM > > > To: seamoby@diameter.org > > > Cc: makin@isi.edu > > > Subject: [seamoby] Response of Mobile Operator to Request > for Info on > > > Realistic Paging > > > > > > > > > Okay, folks, I spoke with a mobile operator here at MWIF in Korea. > > > Alessio, I'm really sorry they can't post themselves, but > > > they generally > > > don't hang out on specific IETF working group lists. One of > > > them will be > > > at IETF 51, and hopefully involved in a requirements > discussion via > > > email beforehand (as soon as we can set up the list), so you > > > can ask him there > > > if you think I'm making this up. > > > > > > Some background on the operator. The operator I talked with > > > has had over 10 > > > years of experience deploying GSM networks in Asia, and is a major > > > technical contributor to a leading European cellular > > > provider. He is very > > > critical of the direction being taken > > > by 3GPP, sees IETF as a promising possiblity to make the > > > mobile Internet > > > happen the way most IETFer's would like to see it happen. His > > > view is therefore > > > likely to be different from someone who thinks 3GPP is the > > > bees knees, however, > > > technically, this guy is at the top of the pack. He knows > cellular. > > > > > > Anyway, I explained to him the problem statement, and that we > > > were designing > > > for a target network in which the HLR and VLR were > replaced by mobile > > > IP and AAA. That is to say, we are not just desiging for > GPRS or 3GPP2 > > > IOS because they already have solutions to this problem, > > > however imperfect. > > > > > > His response was that it is important and necessary that no a > > > priori connection > > > be assumed between subnets and paging areas. Another example, not > > > cited in the draft which came out in our conversation, > > > involves overlapping > > > paging areas. It is sometimes necessary to configure a paging > > > area entirely > > > within another paging area, due to hotspots where there are > > > lots of mobile > > > nodes in dormant mode. There absolutely cannot be any > > > constraint as to > > > subnet in this case, because the inner, donut hole may have > > > an arbitrary > > > relation to the subnets. > > > > > > BTW, I also asked him about the case where wCDMA allows a > mobile node > > > to have more than one paging identifier, and he said this > was because > > > the mobile node could be in soft handoff between two RNCs > that were in > > > two different location areas. It would therefore require a > > > paging identifier > > > for both. > > > > > > I suppose it is possible to spin this however you want if you > > > do or don't > > > believe > > > the problem statement, but, to me, it seems a pretty clear > > > endorsement of > > > the problem statement. > > > > > > jak > > > > > > > > From owner-seamoby@diameter.org Mon Apr 9 11:38:09 2001 Received: from charizard.diameter.org ([24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA09571 for ; Mon, 9 Apr 2001 11:38:08 -0400 (EDT) Received: (qmail 8114 invoked by alias); 9 Apr 2001 16:26:56 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 8108 invoked by uid 200); 9 Apr 2001 16:26:56 -0000 Received: (qmail 8103 invoked from network); 9 Apr 2001 16:26:52 -0000 Received: from sj-msg-core-3.cisco.com (171.70.157.152) by c900656-a.plstn1.sfba.home.com with SMTP; 9 Apr 2001 16:26:52 -0000 Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-3.cisco.com (8.9.3/8.9.1) with ESMTP id IAA25861; Mon, 9 Apr 2001 08:34:48 -0700 (PDT) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id ADR17305; Mon, 9 Apr 2001 08:36:05 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id IAA06722; Mon, 9 Apr 2001 08:36:05 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15057.55013.595163.77860@thomasm-u1.cisco.com> Date: Mon, 9 Apr 2001 08:36:05 -0700 (PDT) To: "Casati, Alessio \(Alessio\)" Cc: "'James Kempf'" , Gary Kenward , seamoby@diameter.org Subject: RE: [seamoby] Response of Mobile Operator to Request for Info on Realistic Paging In-Reply-To: <976F7C55E3B2D111A0720008C728549C097CC31F@en0060exch001u.uk.lucent.com> References: <976F7C55E3B2D111A0720008C728549C097CC31F@en0060exch001u.uk.lucent.com> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-seamoby@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit It's not at all clear that things will mimic the current PSTN at all on the HLR/VLR database issues. This was pretty well necessitated given the existing PSTN when cellular was initially deployed, but there is no fundamental requirement that you have to have a distributed database with IP: you can just as easily go back to your home servers too. In fact, the requirement of a homogeneous, cross provider database is a weakness rather than a strength; for all the bad things you can say about M$ and their poor track record of incompatible word processor formats, if they had to not only be backward compatible with their selves, but compatiable with the rest of the world too, I don't think we'd have seen much innovation in the 80's on this front. Agreements for cross provider database schema's are incredibly hard to come by (and is why I think that XML is largely hype with some core utility). ObCT: we do not want to be in a position that would imply that CT for things other than routers is needed. That might be implied by an HLR/VLR sort of architecture. Mike Casati, Alessio \(Alessio\) writes: > * > *Hi Gary, > * > *They don't like HLR/VLR because these things are basically > *databases and they > *are required to lay out millions when they upgrade because they have to > *buy a new MSC (with the VLR in particular). If they were AAA > *servers and > *MIP home agents, the cost would be much less, to say nothing > *of the wider > *expertese, management tools, etc. available for IP networks. > * > > And this is evolving technologies/implementation according to changed > industry > conditions, not exactly removing the HLR and VLR functionality which will > still > be there (although implemented in a different way, and baptized differently > in this new life, for instance HSS in 3GPP). > > So, I guess everybody on this last part of this dead thread (to be killed as > per > WG chair request) share the same understanding, only the terminology was > making > opinions apparently diverge. > > alessio > From owner-seamoby@diameter.org Mon Apr 9 12:19:48 2001 Received: from charizard.diameter.org ([24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA10635 for ; Mon, 9 Apr 2001 12:19:46 -0400 (EDT) Received: (qmail 8759 invoked by alias); 9 Apr 2001 17:09:02 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 8753 invoked by uid 200); 9 Apr 2001 17:09:02 -0000 Received: (qmail 8748 invoked from network); 9 Apr 2001 17:09:00 -0000 Received: from hoemail1.lucent.com (HELO hoemlsrv.firewall.lucent.com) (192.11.226.161) by c900656-a.plstn1.sfba.home.com with SMTP; 9 Apr 2001 17:09:00 -0000 Received: from hoemlsrv.firewall.lucent.com (localhost [127.0.0.1]) by hoemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id MAA10630 for ; Mon, 9 Apr 2001 12:18:46 -0400 (EDT) Received: from uk0006exch001h.wins.lucent.com (h135-86-160-150.lucent.com [135.86.160.150]) by hoemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id MAA09811 for ; Mon, 9 Apr 2001 12:18:10 -0400 (EDT) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2650.21) id ; Mon, 9 Apr 2001 17:17:32 +0100 Message-ID: <976F7C55E3B2D111A0720008C728549C097CC33C@en0060exch001u.uk.lucent.com> From: "Casati, Alessio \(Alessio\)" To: "'Michael Thomas'" , "Casati, Alessio \(Alessio\)" Cc: "'James Kempf'" , Gary Kenward , seamoby@diameter.org Subject: [seamoby] Context transfer and VLR Date: Mon, 9 Apr 2001 17:16:11 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: owner-seamoby@diameter.org Precedence: bulk *ObCT: we do not want to be in a position that *would imply that CT for things other than routers *is needed. That might be implied by an HLR/VLR *sort of architecture. So, do you mean that anything that one access point had learned and negotiated with the home would be lost upon transfer from it to another. That is really a bad design. By the way, GPRS terminology does not include VLR. Only subscriber data is stored in the SGSN and transferred to the next access point when the MS moves. So, the SGSN actually acts as a VLR, but you don't know that since they don't tell you. And the unwary believe that the VLR's gone. Probably you'd end up just removing a name, rather than the VLR's role ;). Bottom line, if you want to be in the wireless access business, you need to be prepared to store locally some subscriber data, and not retrieve this from the home every time. If I were you I would not restrict the context transfer design to a well defined minimal set of "router" specific data - missing out Wireless access AKA and subscriber data aspects. alessio From owner-seamoby@diameter.org Mon Apr 9 13:20:04 2001 Received: from charizard.diameter.org ([24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA12190 for ; Mon, 9 Apr 2001 13:20:00 -0400 (EDT) Received: (qmail 9839 invoked by alias); 9 Apr 2001 18:08:26 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 9833 invoked by uid 200); 9 Apr 2001 18:08:26 -0000 Received: (qmail 9828 invoked from network); 9 Apr 2001 18:08:23 -0000 Received: from unknown (HELO NEPTUNE.zucotto.com) (216.95.209.154) by c900656-a.plstn1.sfba.home.com with SMTP; 9 Apr 2001 18:08:23 -0000 Received: by NEPTUNE.zucotto.com with Internet Mail Service (5.5.2653.19) id ; Sun, 8 Apr 2001 23:29:41 -0400 Message-ID: <6833D86F1B05CA4FBAB3C73DD98BD8B90D2AEF@NEPTUNE.zucotto.com> From: Kulwinder Atwal To: "'Hesham Soliman \(ERA\)'" , "'Patrice Calhoun'" , "Casati, Alessio \(Alessio\)" Cc: "Seamoby \(E-mail\)" Subject: RE: [seamoby] Response of Mobile Operator to Request for Info on Re alistic Paging Date: Sun, 8 Apr 2001 23:29:41 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-seamoby@diameter.org Precedence: bulk > -----Original Message----- > From: Hesham Soliman (ERA) [mailto:Hesham.Soliman@era.ericsson.se] > Sent: Sunday, April 08, 2001 6:09 PM > To: 'Patrice Calhoun'; Casati, Alessio (Alessio) > Cc: Seamoby (E-mail) > Subject: RE: [seamoby] Response of Mobile Operator to Request for Info > on Re alistic Paging > > > Pat, > > Sorry for the short disobedience to your recommendtion to kill > the thread. But for the record, I think Alessio is making a lot > of sense. Others also raised similar issues in Minneapolis. > I agree. Some of the points that have been raised are valid ones. - why can't this annonyous operator speak? Why can't the operator be more specific in requirements? - A paging protocol is more about enabling paging optimized vs routing optimized networks. - Low power design is better handled in hardware, than a new protocol for routing optimized networks. - 3GPP2,3GPP do not need an IP paging protocol. - If 3GPP2 does not need a paging protocol then it is inappropriate for anyone to state: "MIP needs IP paging" Is the IP Paging protocol really about "some network in the future", or about paging in a city wide network infrastructure composed of AMPS,GSM,PCS,3GPP, and 3GPP2? If so, then the only real requirements that I can see are: - timeliness of the incoming phone call (i.e. send call out on all network types at the same time: IP Multi-cast). - Legacy compabitility. - Kulwinder. > > Regards, > Hesham > > > -----Original Message----- > > From: Patrice Calhoun [SMTP:pcalhoun@nasnfs.Eng.Sun.COM] > > Sent: Saturday, 7 April 2001 12:41 > > To: Casati, Alessio (Alessio) > > Cc: Seamoby (E-mail) > > Subject: Re: [seamoby] Response of Mobile Operator to > Request for Info on Re alistic Paging > > > > I have been trying to sit by the sidelines, and allow > everyone to express > > their opinion, but it is apparent to me that there is no > possible compromise > > here. Alessio is insistent that this is useless, and others > do not think so. > > They find this work useful, and have stated their opinions as well. > > > > So, in the spirit of cooperation, perhaps we can put this > thread aside, and > > start working on the requirements. > > > > Please kill this thread. If the market does in fact not > find this work useful, > > then like many other things from the IETF, it will not have > much deployment. > > > > As for HLR/VLR, I know that there is significant work going > on to eliminate > > them in *some* of the SDOs. Again, whether or not carriers > will use the new > > standards is nothing more than a guess any one of us could do. > > > > So, let's get to work! > > > > PatC > > > > > > > > > > > Your opinion is not shared by either the working group chair > > > nor by the AD. > > > When the AD reports back to us, we will see whether it > is shared by > > > the > > > IESG. We are not talking about GPRS nor 3GPP2, we are talking > > > about a future network where there is no HLR or VLR. > > > > > > So, this should be written in the problem statement. > > > However this does not change the validity of > > > what I wrote. By the way there are > > > a few operators out there that are happy to use HLR > > > and VLR. Those concepts I wrote will remain valid, > although technology > > > and naming of for the same functionality will evolve. So, > something > > > meaningless today (such as a wireless net without HLR and VLR > > > functionality, > > > will be meaningless in the future). Need of L3 paging is > > > meaningless today > > > as it will be tomorrow (unless what you are doing is what the GTP > > > PDU notification does today, in which case you are doing > really nothing > > > new, since this was done years ago in ETSI - if you are doing that > > > then I can point you to where you could look this up not to > > > reinvent the wheel > > > too much) > > > > > > My observation is that you keep bringing up the same points, > > > which I keep > > > answering. To that extent, Mike's comment that you seem to be > > > disruptive > > > is appropriate. > > > > > > The same points are brought insofar as no response is given to > > > them. I wonder why I get no answer other than " we work by > > > rough consensus". > > > It is depressing :). > > > > > > > > > alessio > > > From owner-seamoby@diameter.org Mon Apr 9 22:07:21 2001 Received: from charizard.diameter.org ([24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA22181 for ; Mon, 9 Apr 2001 22:07:18 -0400 (EDT) Received: (qmail 17281 invoked by alias); 10 Apr 2001 02:54:43 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 17275 invoked by uid 200); 10 Apr 2001 02:54:43 -0000 Received: (qmail 17270 invoked from network); 10 Apr 2001 02:54:42 -0000 Received: from unknown (HELO NEPTUNE.zucotto.com) (216.95.209.154) by c900656-a.plstn1.sfba.home.com with SMTP; 10 Apr 2001 02:54:42 -0000 Received: by NEPTUNE.zucotto.com with Internet Mail Service (5.5.2653.19) id ; Mon, 9 Apr 2001 22:04:32 -0400 Message-ID: <6833D86F1B05CA4FBAB3C73DD98BD8B90D2AFF@NEPTUNE.zucotto.com> From: Kulwinder Atwal To: "'Michael Thomas'" , khiem.le@nokia.com Cc: rajeev.koodli@nokia.com, gkenward@nortelnetworks.com, tmima@cisco.com, mccap@research.bell-labs.com, kempf@heliopolis.Eng.Sun.COM, mobile-ip@sunroof.eng.sun.com, rohc@cdt.luth.se, seamoby@diameter.org Subject: RE: [seamoby] RE: [rohc] RE: Restarting Compressor on Mobile IPv6 Handover Date: Mon, 9 Apr 2001 22:04:32 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-seamoby@diameter.org Precedence: bulk > -----Original Message----- > From: Michael Thomas [mailto:mat@cisco.com] > Sent: Friday, April 06, 2001 5:15 PM > To: khiem.le@nokia.com > Cc: rajeev.koodli@nokia.com; mat@cisco.com; > gkenward@nortelnetworks.com; > tmima@cisco.com; mccap@research.bell-labs.com; > kempf@heliopolis.Eng.Sun.COM; mobile-ip@sunroof.eng.sun.com; > rohc@cdt.luth.se; seamoby@diameter.org > Subject: RE: [seamoby] RE: [rohc] RE: Restarting Compressor on Mobile > IPv6 Handover > > > > Kheim, > > I sorry to be so argumentative here, but I'm sure I > could come up with a long laundry list of the benefits > of quantum teleportation too. What obviously must be > done beyond wanting such a thing is to see: > > o if it can be done at all > o whether it would still be a benefit once we > had done it. > > For example, if we could do quantum teleportation > but the only way we could figure out how to > teleport a person resulted in them dying, I'm sure > you'd agree that we ought to reevaluate the > benefits. > > All I'm asking here is how CT would interact with > FMIP. I believe that FMIP is very likely to be a > very important part of handoffs and as such, I > would like to know whether CT for header > compression state will help, hinder or be of no > benefit at all. From what I can tell, there is > indeed a problem and it is not clear whether there > is a solution, or whether the solution would be > worse than the original problem given the high > likelihood of race conditions, etc. Just becuase it doesn't work for FMIP does not mean we should stop. If it doesn't work for FMIP then change FMIP. - Kulwinder. > > Mike > > khiem.le@nokia.com writes: > > Hi, > > > > I have been too busy to comment on all these mails, but I > just want to say a > > couple of things. > > > > I'm afraid that it > > > is your place to prove that context transfer > > > of header compression state in the face of all > > > of these extenuating circumstances is still > > > worthwhile. > > > > There have been many mails pointing out the merit of doing header > > compression context transfer. To repeat them: > > continued, seamless compression/decompression, higher compression > > efficiency, and minimization of degradation on the user > media. This last > > point is the most important in my mind. At this stage, the > link technologies > > where header compression is going to be used are primarily > cellular links. > > In the cellular environment, handoffs (or handovers) are > events that happen > > in normal operation, and therefore a very significant > design effort is spent > > to minimize the impact of HO on performance. In > particular, one wants to > > minimize the duration of the break. If brute force header > compression > > reinitialization is done, one would have to send a certain > number of 40-60 > > byte or more IR headers, instead of the usual 1 byte > header. This big > > bandwidth demand surge will put a strain on the link. Some > links will cope > > with it by blanking out the user data to make room to > carry the IR headers. > > When such blanking takes place, the user media (voice, > etc.) will be > > unavoidably affected. The impairment caused by the handoff > is thus extended, > > compared to the case where header compression is not present. > > > > In the current and 3G cellular technologies, the break is > about 100-150 > > msec, without header compression. This already translates > into the loss of > > 5-6 20 msec packets. If some IR headers have to be sent by > blanking out the > > user data, the break will be significantly longer. For > example, if 3 (an > > optimistic value) IR headers are sent, the resulting break > is increased to > > 8-9 packets worth. > > > > I also want to point out that minimization of the break > will help in > > futureproofness. Applications that will be introduced in > the future may be > > even more sensitive to the break (or the threshold for > user perceived > > degradation may be lower) than the currently known ones. > For example, if a > > packet is generated every 10 msec, the number of packets > affected will be > > doubled. > > > > The only way to minimize the break is to do header > compression context > > transfer. > > > > > > Khiem > > > -----Original Message----- > > > From: Koodli Rajeev (NRC/MtView) > > > Sent: Friday, April 06, 2001 1:13 PM > > > To: 'ext Michael Thomas'; Koodli Rajeev (NRC/MtView) > > > Cc: Le Khiem (NRC/Dallas); gkenward@nortelnetworks.com; > > > tmima@cisco.com; > > > mccap@research.bell-labs.com; kempf@heliopolis.Eng.Sun.COM; > > > mobile-ip@sunroof.eng.sun.com; rohc@cdt.luth.se; > seamoby@diameter.org > > > Subject: RE: [seamoby] RE: [rohc] RE: Restarting > Compressor on Mobile > > > IPv6 Handover > > > > > > > > > > > > > > > > > > rajeev.koodli@nokia.com writes: > > > > > > From: ext Michael Thomas [mailto:mat@cisco.com] > > > > > > > > > > Can somebody explain to me how this has any > > > > > > possible applicability if you are using FMIP > > > > > > during the transition? FMIP requires a new tunnel > > > > > > for which there will be no compression state in > > > > > > the old access router. > > > > > > > > > > > > > > > > If there is no compression state at the old router, why > > > > would you try to > > > > > relocate it ? > > > > > > > > There's compression state there, but not the > > > > compression state that matters: when I'm > > > > receiving packets from the old AR during the > > > > FMIP transition time, there will be a *new* > > > > IP header appended toward the MN. This is > > > > because those packets will have to be tunneled to the > > > > MN. This means that it is a *new* compression > > > > context, not an old existing one. > > > > > > > I don't have sufficient details to comment.. > > > > > > > > > All of these interactions with MIP, FMIP, HMIP > > > > > > etc, etc make it look to me like this is a losing > > > > > > situation. It may be the better part of valor to > > > > > > say that fast/smooth handoffs are inherently more > > > > > > bandwidth consumptive and that one of the > > > > > > casualties is header compression state in the mean > > > > > > time. > > > > > > > > > > Can you justify your claim above ? > > > > > > > > I can't prove negatives. I'm afraid that it > > > > is your place to prove that context transfer > > > > of header compression state in the face of all > > > > of these extenuating circumstances is still > > > > worthwhile. > > > > > > > > > > You can't justify your claims. So, before you raise issues > > > (related/unrelated), try to make an effort to understand the > > > work done by others. > > > > > > As far as I am concerned, how about all the e-mail discussion > > > during the last two weeks ? Please take a look! > > > > > > > > >Trying to extend a point to point L2 > > > > > > compression mechanism across an arbitrary internet > > > > > > is just *bizzare*. L2TP is bad enough. > > > > > > > > > > > > > > > > You are compressing IP and transport headers! This should > > > > work on ANY link. > > > > > That's why you try to CT header compression state. Get it ? > > > > > > > > Oh sure, I get it... I "get" VoMPLS too, but > > > > that doesn't make it any less bizarre. > > > > > > > > > > If you got it, you would probably re-think! If you were to > > > re-think and understand the issues, you would probably > > > question yourself what's bizarre, and then write. > > > > > > -Rajeev > > > > > > > Mike > > > > > > > > From owner-seamoby@diameter.org Tue Apr 10 10:36:13 2001 Received: from charizard.diameter.org ([24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA16650 for ; Tue, 10 Apr 2001 10:36:07 -0400 (EDT) Received: (qmail 23396 invoked by alias); 10 Apr 2001 15:23:59 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 23390 invoked by uid 200); 10 Apr 2001 15:23:59 -0000 Received: (qmail 23385 invoked from network); 10 Apr 2001 15:23:57 -0000 Received: from h52s48a140n47.user.nortelnetworks.com (HELO zrtps06u.us.nortel.com) (47.140.48.52) by c900656-a.plstn1.sfba.home.com with SMTP; 10 Apr 2001 15:23:57 -0000 Received: from zcars04f.ca.nortel.com (zcars04f.ca.nortel.com [47.129.242.57]) by zrtps06u.us.nortel.com (8.11.0/8.11.0) with ESMTP id f3AEVvJ13517 for ; Tue, 10 Apr 2001 10:31:57 -0400 (EDT) Received: from zcard015.ca.nortel.com by zcars04f.ca.nortel.com; Tue, 10 Apr 2001 10:32:55 -0400 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 10 Apr 2001 10:32:56 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C12578D@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'Michael Thomas'" , "rajeev.koodli" Cc: khiem.le@nokia.com, tmima@cisco.com, mccap@research.bell-labs.com, kempf@heliopolis.Eng.Sun.COM, mobile-ip@sunroof.eng.sun.com, rohc@cdt.luth.se, seamoby@diameter.org Subject: RE: [seamoby] RE: [rohc] RE: Restarting Compressor on Mobile IPv6 Handover Date: Tue, 10 Apr 2001 10:32:48 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0C1CB.1D54C330" X-Orig: Sender: owner-seamoby@diameter.org Precedence: bulk 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_01C0C1CB.1D54C330 Content-Type: text/plain; charset="iso-8859-1" > -----Original Message----- > From: Michael Thomas [mailto:mat@cisco.com] > Sent: Friday, April 06, 2001 1:46 PM > To: rajeev.koodli > Cc: mat@cisco.com; khiem.le@nokia.com; Kenward, Gary > [WDLN2:AN10:EXCH]; > tmima@cisco.com; mccap@research.bell-labs.com; > kempf@heliopolis.Eng.Sun.COM; mobile-ip@sunroof.eng.sun.com; > rohc@cdt.luth.se; seamoby@diameter.org > Subject: RE: [seamoby] RE: [rohc] RE: Restarting Compressor on Mobile > IPv6 Handover > > > rajeev.koodli@nokia.com writes: > > > From: ext Michael Thomas [mailto:mat@cisco.com] > > > > Can somebody explain to me how this has any > > > possible applicability if you are using FMIP > > > during the transition? FMIP requires a new tunnel > > > for which there will be no compression state in > > > the old access router. > > > > > > > If there is no compression state at the old router, why > would you try to > > relocate it ? > > There's compression state there, but not the > compression state that matters: when I'm > receiving packets from the old AR during the > FMIP transition time, there will be a *new* > IP header appended toward the MN. This is > because those packets will have to be tunneled to the > MN. This means that it is a *new* compression > context, not an old existing one. Sounds like a problem with FMIP to me. Gary > ------_=_NextPart_001_01C0C1CB.1D54C330 Content-Type: text/html; charset="iso-8859-1" RE: [seamoby] RE: [rohc] RE: Restarting Compressor on Mobile IPv6 Handover

> -----Original Message-----
> From: Michael Thomas [mailto:mat@cisco.com]
> Sent: Friday, April 06, 2001 1:46 PM
> To: rajeev.koodli
> Cc: mat@cisco.com; khiem.le@nokia.com; Kenward, Gary
> [WDLN2:AN10:EXCH];
> tmima@cisco.com; mccap@research.bell-labs.com;
> kempf@heliopolis.Eng.Sun.COM; mobile-ip@sunroof.eng.sun.com;
> rohc@cdt.luth.se; seamoby@diameter.org
> Subject: RE: [seamoby] RE: [rohc] RE: Restarting Compressor on Mobile
> IPv6 Handover
>
>
> rajeev.koodli@nokia.com writes:
>  > > From: ext Michael Thomas [mailto:mat@cisco.com]
>
>  > > Can somebody explain to me how this has any
>  > > possible applicability if you are using FMIP
>  > > during the transition? FMIP requires a new tunnel
>  > > for which there will be no compression state in
>  > > the old access router.
>  > >
>  >
>  > If there is no compression state at the old router, why
> would you try to
>  > relocate it ?
>
>    There's compression state there, but not the
>    compression state that matters: when I'm
>    receiving packets from the old AR during the
>    FMIP transition time, there will be a *new*
>    IP header appended toward the MN. This is
>    because those packets will have to be tunneled to the
>    MN. This means that it is a *new* compression
>    context, not an old existing one.

Sounds like a problem with FMIP to me.

Gary

>

------_=_NextPart_001_01C0C1CB.1D54C330-- From owner-seamoby@diameter.org Tue Apr 10 10:43:35 2001 Received: from charizard.diameter.org ([24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA16835 for ; Tue, 10 Apr 2001 10:43:17 -0400 (EDT) Received: (qmail 23791 invoked by alias); 10 Apr 2001 15:27:13 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 23785 invoked by uid 200); 10 Apr 2001 15:27:13 -0000 Received: (qmail 23776 invoked from network); 10 Apr 2001 15:27:10 -0000 Received: from h52s48a140n47.user.nortelnetworks.com (HELO zrtps06u.us.nortel.com) (47.140.48.52) by c900656-a.plstn1.sfba.home.com with SMTP; 10 Apr 2001 15:27:10 -0000 Received: from zcars04f.ca.nortel.com (zcars04f.ca.nortel.com [47.129.242.57]) by zrtps06u.us.nortel.com (8.11.0/8.11.0) with ESMTP id f3AEZ8J14451 for ; Tue, 10 Apr 2001 10:35:08 -0400 (EDT) Received: from zcard015.ca.nortel.com by zcars04f.ca.nortel.com; Tue, 10 Apr 2001 10:36:08 -0400 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 10 Apr 2001 10:36:09 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C12578E@zcard031.ca.nortel.com> From: "Gary Kenward" To: rajeev.koodli@nokia.com Cc: seamoby@diameter.org Subject: RE: [mobile-ip] RE: [seamoby] RE: [rohc] RE: Restarting Compresso r on Mobile IPv6 Handover Date: Tue, 10 Apr 2001 10:36:07 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0C1CB.94346F00" X-Orig: Sender: owner-seamoby@diameter.org Precedence: bulk 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_01C0C1CB.94346F00 Content-Type: text/plain; charset="iso-8859-1" Well put! > -----Original Message----- > From: khiem.le@nokia.com [mailto:khiem.le@nokia.com] > Sent: Friday, April 06, 2001 4:44 PM > To: rajeev.koodli@nokia.com; mat@cisco.com > Cc: Kenward, Gary [WDLN2:AN10:EXCH]; tmima@cisco.com; > mccap@research.bell-labs.com; kempf@heliopolis.Eng.Sun.COM; > mobile-ip@sunroof.eng.sun.com; rohc@cdt.luth.se; seamoby@diameter.org > Subject: [mobile-ip] RE: [seamoby] RE: [rohc] RE: Restarting > Compressor > on Mobile IPv6 Handover > > > Hi, > > I have been too busy to comment on all these mails, but I > just want to say a > couple of things. > > I'm afraid that it > > is your place to prove that context transfer > > of header compression state in the face of all > > of these extenuating circumstances is still > > worthwhile. > > There have been many mails pointing out the merit of doing header > compression context transfer. To repeat them: > continued, seamless compression/decompression, higher compression > efficiency, and minimization of degradation on the user > media. This last > point is the most important in my mind. At this stage, the > link technologies > where header compression is going to be used are primarily > cellular links. > In the cellular environment, handoffs (or handovers) are > events that happen > in normal operation, and therefore a very significant design > effort is spent > to minimize the impact of HO on performance. In particular, > one wants to > minimize the duration of the break. If brute force header compression > reinitialization is done, one would have to send a certain > number of 40-60 > byte or more IR headers, instead of the usual 1 byte header. This big > bandwidth demand surge will put a strain on the link. Some > links will cope > with it by blanking out the user data to make room to carry > the IR headers. > When such blanking takes place, the user media (voice, etc.) will be > unavoidably affected. The impairment caused by the handoff is > thus extended, > compared to the case where header compression is not present. > > In the current and 3G cellular technologies, the break is > about 100-150 > msec, without header compression. This already translates > into the loss of > 5-6 20 msec packets. If some IR headers have to be sent by > blanking out the > user data, the break will be significantly longer. For > example, if 3 (an > optimistic value) IR headers are sent, the resulting break is > increased to > 8-9 packets worth. > > I also want to point out that minimization of the break will help in > futureproofness. Applications that will be introduced in the > future may be > even more sensitive to the break (or the threshold for user perceived > degradation may be lower) than the currently known ones. For > example, if a > packet is generated every 10 msec, the number of packets > affected will be > doubled. > > The only way to minimize the break is to do header compression context > transfer. > > > Khiem > > -----Original Message----- > > From: Koodli Rajeev (NRC/MtView) > > Sent: Friday, April 06, 2001 1:13 PM > > To: 'ext Michael Thomas'; Koodli Rajeev (NRC/MtView) > > Cc: Le Khiem (NRC/Dallas); gkenward@nortelnetworks.com; > > tmima@cisco.com; > > mccap@research.bell-labs.com; kempf@heliopolis.Eng.Sun.COM; > > mobile-ip@sunroof.eng.sun.com; rohc@cdt.luth.se; > seamoby@diameter.org > > Subject: RE: [seamoby] RE: [rohc] RE: Restarting Compressor > on Mobile > > IPv6 Handover > > > > > > > > > > > > > rajeev.koodli@nokia.com writes: > > > > > From: ext Michael Thomas [mailto:mat@cisco.com] > > > > > > > > Can somebody explain to me how this has any > > > > > possible applicability if you are using FMIP > > > > > during the transition? FMIP requires a new tunnel > > > > > for which there will be no compression state in > > > > > the old access router. > > > > > > > > > > > > > If there is no compression state at the old router, why > > > would you try to > > > > relocate it ? > > > > > > There's compression state there, but not the > > > compression state that matters: when I'm > > > receiving packets from the old AR during the > > > FMIP transition time, there will be a *new* > > > IP header appended toward the MN. This is > > > because those packets will have to be tunneled to the > > > MN. This means that it is a *new* compression > > > context, not an old existing one. > > > > > I don't have sufficient details to comment.. > > > > > > > All of these interactions with MIP, FMIP, HMIP > > > > > etc, etc make it look to me like this is a losing > > > > > situation. It may be the better part of valor to > > > > > say that fast/smooth handoffs are inherently more > > > > > bandwidth consumptive and that one of the > > > > > casualties is header compression state in the mean > > > > > time. > > > > > > > > Can you justify your claim above ? > > > > > > I can't prove negatives. I'm afraid that it > > > is your place to prove that context transfer > > > of header compression state in the face of all > > > of these extenuating circumstances is still > > > worthwhile. > > > > > > > You can't justify your claims. So, before you raise issues > > (related/unrelated), try to make an effort to understand the > > work done by others. > > > > As far as I am concerned, how about all the e-mail discussion > > during the last two weeks ? Please take a look! > > > > > > >Trying to extend a point to point L2 > > > > > compression mechanism across an arbitrary internet > > > > > is just *bizzare*. L2TP is bad enough. > > > > > > > > > > > > > You are compressing IP and transport headers! This should > > > work on ANY link. > > > > That's why you try to CT header compression state. Get it ? > > > > > > Oh sure, I get it... I "get" VoMPLS too, but > > > that doesn't make it any less bizarre. > > > > > > > If you got it, you would probably re-think! If you were to > > re-think and understand the issues, you would probably > > question yourself what's bizarre, and then write. > > > > -Rajeev > > > > > Mike > > > > > > ------_=_NextPart_001_01C0C1CB.94346F00 Content-Type: text/html; charset="iso-8859-1" RE: [mobile-ip] RE: [seamoby] RE: [rohc] RE: Restarting Compressor on Mobile IPv6 Handover

Well put!

> -----Original Message-----
> From: khiem.le@nokia.com [mailto:khiem.le@nokia.com]
> Sent: Friday, April 06, 2001 4:44 PM
> To: rajeev.koodli@nokia.com; mat@cisco.com
> Cc: Kenward, Gary [WDLN2:AN10:EXCH]; tmima@cisco.com;
> mccap@research.bell-labs.com; kempf@heliopolis.Eng.Sun.COM;
> mobile-ip@sunroof.eng.sun.com; rohc@cdt.luth.se; seamoby@diameter.org
> Subject: [mobile-ip] RE: [seamoby] RE: [rohc] RE: Restarting
> Compressor
> on Mobile IPv6 Handover
>
>
> Hi,
>
> I have been too busy to comment on all these mails, but I
> just want to say a
> couple of things.
>
> I'm afraid that it
> >    is your place to prove that context transfer
> >    of header compression state in the face of all
> >    of these extenuating circumstances is still
> >    worthwhile.
>
> There have been many mails pointing out the merit of doing header
> compression context transfer. To repeat them:
> continued, seamless compression/decompression, higher compression
> efficiency, and minimization of degradation on the user
> media. This last
> point is the most important in my mind. At this stage, the
> link technologies
> where header compression is going to be used are primarily
> cellular links.
> In the cellular environment, handoffs (or handovers) are
> events that happen
> in normal operation, and therefore a very significant design
> effort is spent
> to minimize the impact of HO on performance. In particular,
> one wants to
> minimize the duration of the break. If brute force header compression
> reinitialization is done, one would have to send a certain
> number of 40-60
> byte or more IR headers, instead of the usual 1 byte header. This big
> bandwidth demand surge will put a strain on the link. Some
> links will cope
> with it by blanking out the user data to make room to carry
> the IR headers.
> When such blanking takes place, the user media (voice, etc.) will be
> unavoidably affected. The impairment caused by the handoff is
> thus extended,
> compared to the case where header compression is not present. 
>
> In the current and 3G cellular technologies, the break is
> about 100-150
> msec, without header compression. This already translates
> into the loss of
> 5-6 20 msec packets. If some IR headers have to be sent by
> blanking out the
> user data, the break will be significantly longer. For
> example, if 3 (an
> optimistic value) IR headers are sent, the resulting break is
> increased to
> 8-9 packets worth.
>
> I also want to point out that minimization of the break will help in
> futureproofness.  Applications that will be introduced in the
> future may be
> even more sensitive to the break (or the threshold for user perceived
> degradation may be lower) than the currently known ones. For
> example, if a
> packet is generated every 10 msec, the number of packets
> affected will be
> doubled.
>   
> The only way to minimize the break is to do header compression context
> transfer. 
>
>
> Khiem
> > -----Original Message-----
> > From: Koodli Rajeev (NRC/MtView)
> > Sent: Friday, April 06, 2001 1:13 PM
> > To: 'ext Michael Thomas'; Koodli Rajeev (NRC/MtView)
> > Cc: Le Khiem (NRC/Dallas); gkenward@nortelnetworks.com;
> > tmima@cisco.com;
> > mccap@research.bell-labs.com; kempf@heliopolis.Eng.Sun.COM;
> > mobile-ip@sunroof.eng.sun.com; rohc@cdt.luth.se;
> seamoby@diameter.org
> > Subject: RE: [seamoby] RE: [rohc] RE: Restarting Compressor
> on Mobile
> > IPv6 Handover
> >
> >
> > >
> > >
> > > rajeev.koodli@nokia.com writes:
> > >  > > From: ext Michael Thomas [mailto:mat@cisco.com]
> > >
> > >  > > Can somebody explain to me how this has any
> > >  > > possible applicability if you are using FMIP
> > >  > > during the transition? FMIP requires a new tunnel
> > >  > > for which there will be no compression state in
> > >  > > the old access router.
> > >  > >
> > >  >
> > >  > If there is no compression state at the old router, why
> > > would you try to
> > >  > relocate it ?
> > >
> > >    There's compression state there, but not the
> > >    compression state that matters: when I'm
> > >    receiving packets from the old AR during the
> > >    FMIP transition time, there will be a *new*
> > >    IP header appended toward the MN. This is
> > >    because those packets will have to be tunneled to the
> > >    MN. This means that it is a *new* compression
> > >    context, not an old existing one.
> > > 
> > I don't have sufficient details to comment..
> >
> > >  > > All of these interactions with MIP, FMIP, HMIP
> > >  > > etc, etc make it look to me like this is a losing
> > >  > > situation. It may be the better part of valor to
> > >  > > say that fast/smooth handoffs are inherently more
> > >  > > bandwidth consumptive and that one of the
> > >  > > casualties is header compression state in the mean
> > >  > > time.
> > >  >
> > >  > Can you justify your claim above ?
> > >
> > >    I can't prove negatives. I'm afraid that it
> > >    is your place to prove that context transfer
> > >    of header compression state in the face of all
> > >    of these extenuating circumstances is still
> > >    worthwhile.
> > >
> >
> > You can't justify your claims. So, before you raise issues
> > (related/unrelated), try to make an effort to understand the
> > work done by others.
> >
> > As far as I am concerned, how about all the e-mail discussion
> > during the last two weeks ? Please take a look!
> >
> > >  > >Trying to extend a point to point L2
> > >  > > compression mechanism across an arbitrary internet
> > >  > > is just *bizzare*. L2TP is bad enough.
> > >  > >
> > >  >
> > >  > You are compressing IP and transport headers! This should
> > > work on ANY link.
> > >  > That's why you try to CT header compression state. Get it ?
> > >
> > >    Oh sure, I get it... I "get" VoMPLS too, but
> > >    that doesn't make it any less bizarre.
> > >
> >
> > If you got it, you would probably re-think! If you were to
> > re-think and understand the issues, you would probably
> > question yourself what's bizarre, and then write.
> >
> > -Rajeev
> >
> > >       Mike
> > >
> >
>

------_=_NextPart_001_01C0C1CB.94346F00-- From owner-seamoby@diameter.org Tue Apr 10 10:50:34 2001 Received: from charizard.diameter.org ([24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA17146 for ; Tue, 10 Apr 2001 10:50:33 -0400 (EDT) Received: (qmail 24076 invoked by alias); 10 Apr 2001 15:31:55 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 24069 invoked by uid 200); 10 Apr 2001 15:31:54 -0000 Received: (qmail 24059 invoked from network); 10 Apr 2001 15:31:51 -0000 Received: from h52s48a140n47.user.nortelnetworks.com (HELO zrtps06u.us.nortel.com) (47.140.48.52) by c900656-a.plstn1.sfba.home.com with SMTP; 10 Apr 2001 15:31:51 -0000 Received: from zcars04f.ca.nortel.com (zcars04f.ca.nortel.com [47.129.242.57]) by zrtps06u.us.nortel.com (8.11.0/8.11.0) with ESMTP id f3AEdfJ16251 for ; Tue, 10 Apr 2001 10:39:42 -0400 (EDT) Received: from zcard015.ca.nortel.com by zcars04f.ca.nortel.com; Tue, 10 Apr 2001 10:41:00 -0400 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 10 Apr 2001 10:41:01 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C12578F@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'seamoby'" Cc: "'mobile-ip@sunroof.eng.sun.com'" , mat@cisco.com, tmima@cisco.com, mccap@research.bell-labs.com, kempf@heliopolis.eng.sun.com, rohc@cdt.luth.se Subject: RE: [mobile-ip] RE: [seamoby] RE: [rohc] RE: Restarting Compresso r on Mobile IPv6 Handover Date: Tue, 10 Apr 2001 10:40:59 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Orig: Sender: owner-seamoby@diameter.org Precedence: bulk Michael: It *may* be the case here that FMIP is deficient in supporting context transfer for header compression state. FMIP does not define the problem space. Kheim has done a fairly eloquent job of describing a real world issue with wireless handover. To say that FMIP won't support it is to say that FMIP is broken, not that the problem should not be solved. So let's get on with solving the problem. If there is a requirement to change FMIP, I'm sure the MIP group would be interested in our input. After all, that is one of the reasons Seamoby was chartered. Gary "When your only tool is a hammer, all your problems tend to look like nails" > -----Original Message----- > From: Michael Thomas [mailto:mat@cisco.com] > Sent: Friday, April 06, 2001 5:15 PM > To: khiem.le > Cc: rajeev.koodli@nokia.com; mat@cisco.com; Kenward, Gary > [WDLN2:AN10:EXCH]; tmima@cisco.com; mccap@research.bell-labs.com; > kempf@heliopolis.eng.sun.com; mobile-ip@sunroof.eng.sun.com; > rohc@cdt.luth.se; seamoby@diameter.org > Subject: [mobile-ip] RE: [seamoby] RE: [rohc] RE: Restarting > Compressor > on Mobile IPv6 Handover > > > Kheim, > > I sorry to be so argumentative here, but I'm sure I > could come up with a long laundry list of the benefits > of quantum teleportation too. What obviously must be > done beyond wanting such a thing is to see: > > o if it can be done at all > o whether it would still be a benefit once we > had done it. > > For example, if we could do quantum teleportation > but the only way we could figure out how to > teleport a person resulted in them dying, I'm sure > you'd agree that we ought to reevaluate the > benefits. > > All I'm asking here is how CT would interact with > FMIP. I believe that FMIP is very likely to be a > very important part of handoffs and as such, I > would like to know whether CT for header > compression state will help, hinder or be of no > benefit at all. From what I can tell, there is > indeed a problem and it is not clear whether there > is a solution, or whether the solution would be > worse than the original problem given the high > likelihood of race conditions, etc. > > Mike > > khiem.le@nokia.com writes: > > Hi, > > > > I have been too busy to comment on all these mails, but I > just want to say a > > couple of things. > > > > I'm afraid that it > > > is your place to prove that context transfer > > > of header compression state in the face of all > > > of these extenuating circumstances is still > > > worthwhile. > > > > There have been many mails pointing out the merit of doing header > > compression context transfer. To repeat them: > > continued, seamless compression/decompression, higher compression > > efficiency, and minimization of degradation on the user > media. This last > > point is the most important in my mind. At this stage, the > link technologies > > where header compression is going to be used are primarily > cellular links. > > In the cellular environment, handoffs (or handovers) are > events that happen > > in normal operation, and therefore a very significant > design effort is spent > > to minimize the impact of HO on performance. In > particular, one wants to > > minimize the duration of the break. If brute force header > compression > > reinitialization is done, one would have to send a certain > number of 40-60 > > byte or more IR headers, instead of the usual 1 byte > header. This big > > bandwidth demand surge will put a strain on the link. Some > links will cope > > with it by blanking out the user data to make room to > carry the IR headers. > > When such blanking takes place, the user media (voice, > etc.) will be > > unavoidably affected. The impairment caused by the handoff > is thus extended, > > compared to the case where header compression is not present. > > > > In the current and 3G cellular technologies, the break is > about 100-150 > > msec, without header compression. This already translates > into the loss of > > 5-6 20 msec packets. If some IR headers have to be sent by > blanking out the > > user data, the break will be significantly longer. For > example, if 3 (an > > optimistic value) IR headers are sent, the resulting break > is increased to > > 8-9 packets worth. > > > > I also want to point out that minimization of the break > will help in > > futureproofness. Applications that will be introduced in > the future may be > > even more sensitive to the break (or the threshold for > user perceived > > degradation may be lower) than the currently known ones. > For example, if a > > packet is generated every 10 msec, the number of packets > affected will be > > doubled. > > > > The only way to minimize the break is to do header > compression context > > transfer. > > > > > > Khiem > > > -----Original Message----- > > > From: Koodli Rajeev (NRC/MtView) > > > Sent: Friday, April 06, 2001 1:13 PM > > > To: 'ext Michael Thomas'; Koodli Rajeev (NRC/MtView) > > > Cc: Le Khiem (NRC/Dallas); gkenward@nortelnetworks.com; > > > tmima@cisco.com; > > > mccap@research.bell-labs.com; kempf@heliopolis.Eng.Sun.COM; > > > mobile-ip@sunroof.eng.sun.com; rohc@cdt.luth.se; > seamoby@diameter.org > > > Subject: RE: [seamoby] RE: [rohc] RE: Restarting > Compressor on Mobile > > > IPv6 Handover > > > > > > > > > > > > > > > > > > rajeev.koodli@nokia.com writes: > > > > > > From: ext Michael Thomas [mailto:mat@cisco.com] > > > > > > > > > > Can somebody explain to me how this has any > > > > > > possible applicability if you are using FMIP > > > > > > during the transition? FMIP requires a new tunnel > > > > > > for which there will be no compression state in > > > > > > the old access router. > > > > > > > > > > > > > > > > If there is no compression state at the old router, why > > > > would you try to > > > > > relocate it ? > > > > > > > > There's compression state there, but not the > > > > compression state that matters: when I'm > > > > receiving packets from the old AR during the > > > > FMIP transition time, there will be a *new* > > > > IP header appended toward the MN. This is > > > > because those packets will have to be tunneled to the > > > > MN. This means that it is a *new* compression > > > > context, not an old existing one. > > > > > > > I don't have sufficient details to comment.. > > > > > > > > > All of these interactions with MIP, FMIP, HMIP > > > > > > etc, etc make it look to me like this is a losing > > > > > > situation. It may be the better part of valor to > > > > > > say that fast/smooth handoffs are inherently more > > > > > > bandwidth consumptive and that one of the > > > > > > casualties is header compression state in the mean > > > > > > time. > > > > > > > > > > Can you justify your claim above ? > > > > > > > > I can't prove negatives. I'm afraid that it > > > > is your place to prove that context transfer > > > > of header compression state in the face of all > > > > of these extenuating circumstances is still > > > > worthwhile. > > > > > > > > > > You can't justify your claims. So, before you raise issues > > > (related/unrelated), try to make an effort to understand the > > > work done by others. > > > > > > As far as I am concerned, how about all the e-mail discussion > > > during the last two weeks ? Please take a look! > > > > > > > > >Trying to extend a point to point L2 > > > > > > compression mechanism across an arbitrary internet > > > > > > is just *bizzare*. L2TP is bad enough. > > > > > > > > > > > > > > > > You are compressing IP and transport headers! This should > > > > work on ANY link. > > > > > That's why you try to CT header compression state. Get it ? > > > > > > > > Oh sure, I get it... I "get" VoMPLS too, but > > > > that doesn't make it any less bizarre. > > > > > > > > > > If you got it, you would probably re-think! If you were to > > > re-think and understand the issues, you would probably > > > question yourself what's bizarre, and then write. > > > > > > -Rajeev > > > > > > > Mike > > > > > > > > From owner-seamoby@diameter.org Tue Apr 10 11:52:48 2001 Received: from charizard.diameter.org ([24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA19076 for ; Tue, 10 Apr 2001 11:52:47 -0400 (EDT) Received: (qmail 25494 invoked by alias); 10 Apr 2001 16:41:34 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 25488 invoked by uid 200); 10 Apr 2001 16:41:33 -0000 Received: (qmail 25483 invoked from network); 10 Apr 2001 16:41:32 -0000 Received: from sj-msg-core-1.cisco.com (171.71.163.11) by c900656-a.plstn1.sfba.home.com with SMTP; 10 Apr 2001 16:41:32 -0000 Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id IAA12833; Tue, 10 Apr 2001 08:36:40 -0700 (PDT) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id ADV01344; Tue, 10 Apr 2001 08:36:38 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id IAA07084; Tue, 10 Apr 2001 08:36:38 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15059.10374.495321.664907@thomasm-u1.cisco.com> Date: Tue, 10 Apr 2001 08:36:38 -0700 (PDT) To: "Gary Kenward" Cc: "'seamoby'" , mat@cisco.com, tmima@cisco.com, mccap@research.bell-labs.com, kempf@heliopolis.eng.sun.com Subject: RE: [mobile-ip] RE: [seamoby] RE: [rohc] RE: Restarting Compresso r on Mobile IPv6 Handover In-Reply-To: <9FBD322B7824D511B36900508BF93C9C12578F@zcard031.ca.nortel.com> References: <9FBD322B7824D511B36900508BF93C9C12578F@zcard031.ca.nortel.com> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-seamoby@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit Gary Kenward writes: > Michael: > > It *may* be the case here that FMIP is deficient in supporting context > transfer for header compression state. FMIP does not define the problem > space. Kheim has done a fairly eloquent job of describing a real world issue > with wireless handover. To say that FMIP won't support it is to say that > FMIP > is broken, not that the problem should not be solved. I find it hard to fault FMIP here; it's just setting up a tunnel between the old AR and the MN. There's nothing "broken" about that. The alternative is not exactly very pretty either and could lead to some bizarre and unforseen side effects (though MIPv4 may have a handle on them). There's a lot to be said about preserving transparency when ARnew and ARold have no relationship with one another. > So let's get on with solving the problem. If there is a requirement to > change > FMIP, I'm sure the MIP group would be interested in our input. After all, > that is one of the reasons Seamoby was chartered. The requirement belongs on CT, not FMIP. It may also be a bogus thing to do given the way that ROHC/CRTP works. Mike From owner-seamoby@diameter.org Tue Apr 10 14:15:54 2001 Received: from charizard.diameter.org ([24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA22674 for ; Tue, 10 Apr 2001 14:15:48 -0400 (EDT) Received: (qmail 26921 invoked by alias); 10 Apr 2001 19:03:33 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 26915 invoked by uid 200); 10 Apr 2001 19:03:33 -0000 Received: (qmail 26910 invoked from network); 10 Apr 2001 19:03:31 -0000 Received: from zcars04e.nortelnetworks.com (47.129.242.56) by c900656-a.plstn1.sfba.home.com with SMTP; 10 Apr 2001 19:03:31 -0000 Received: from zcard015.ca.nortel.com (actually zcard015) by zcars04e.nortelnetworks.com; Tue, 10 Apr 2001 14:10:58 -0400 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 10 Apr 2001 14:11:00 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C125792@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'Michael Thomas'" Cc: "'seamoby'" , tmima@cisco.com, mccap@research.bell-labs.com, kempf@heliopolis.eng.sun.com Subject: RE: [mobile-ip] RE: [seamoby] RE: [rohc] RE: Restarting Compresso r on Mobile IPv6 Handover Date: Tue, 10 Apr 2001 14:10:42 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0C1E9.8E7FBA10" X-Orig: Sender: owner-seamoby@diameter.org Precedence: bulk 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_01C0C1E9.8E7FBA10 Content-Type: text/plain; charset="iso-8859-1" Michael: You were the one who stated that FMIP would not support context tranfer for header compression. Jumping over all the usual diabtribe, my point was that we need to find a solution, wherever the changes may be required, not just find fault with the approach. End of thread as far as I am concerned. Gary > -----Original Message----- > From: Michael Thomas [mailto:mat@cisco.com] > Sent: Tuesday, April 10, 2001 11:37 AM > To: Kenward, Gary [WDLN2:AN10:EXCH] > Cc: 'seamoby'; mat@cisco.com; tmima@cisco.com; > mccap@research.bell-labs.com; kempf@heliopolis.eng.sun.com > Subject: RE: [mobile-ip] RE: [seamoby] RE: [rohc] RE: Restarting > Compresso r on Mobile IPv6 Handover > > > Gary Kenward writes: > > Michael: > > > > It *may* be the case here that FMIP is deficient in > supporting context > > transfer for header compression state. FMIP does not > define the problem > > space. Kheim has done a fairly eloquent job of describing > a real world issue > > with wireless handover. To say that FMIP won't support it > is to say that > > FMIP > > is broken, not that the problem should not be solved. > > I find it hard to fault FMIP here; it's just setting up > a tunnel between the old AR and the MN. There's nothing > "broken" about that. The alternative is not > exactly very pretty either and could lead to > some bizarre and unforseen side effects (though MIPv4 > may have a handle on them). There's a lot to be > said about preserving transparency when ARnew > and ARold have no relationship with one another. > > > So let's get on with solving the problem. If there is a > requirement to > > change > > FMIP, I'm sure the MIP group would be interested in our > input. After all, > > that is one of the reasons Seamoby was chartered. > > The requirement belongs on CT, not FMIP. It may > also be a bogus thing to do given the way that > ROHC/CRTP works. > > Mike > ------_=_NextPart_001_01C0C1E9.8E7FBA10 Content-Type: text/html; charset="iso-8859-1" RE: [mobile-ip] RE: [seamoby] RE: [rohc] RE: Restarting Compresso r on Mobile IPv6 Handover

Michael:

   You were the one who stated that FMIP would not support context
tranfer for header compression.

    Jumping over all the usual diabtribe, my point was that we need to
find a solution, wherever the changes may be required, not just find
fault with the approach.

    End of thread as far as I am concerned.

Gary

> -----Original Message-----
> From: Michael Thomas [mailto:mat@cisco.com]
> Sent: Tuesday, April 10, 2001 11:37 AM
> To: Kenward, Gary [WDLN2:AN10:EXCH]
> Cc: 'seamoby'; mat@cisco.com; tmima@cisco.com;
> mccap@research.bell-labs.com; kempf@heliopolis.eng.sun.com
> Subject: RE: [mobile-ip] RE: [seamoby] RE: [rohc] RE: Restarting
> Compresso r on Mobile IPv6 Handover
>
>
> Gary Kenward writes:
>  > Michael:
>  >
>  >    It *may* be the case here that FMIP is deficient in
> supporting context
>  > transfer for header compression state. FMIP does not
> define the problem
>  > space. Kheim has done a fairly eloquent job of describing
> a real world issue
>  > with wireless handover. To say that FMIP won't support it
> is to say that
>  > FMIP
>  > is broken, not that the problem should not be solved.
>
>    I find it hard to fault FMIP here; it's just setting up
>    a tunnel between the old AR and the MN. There's nothing
>    "broken" about that. The alternative is not
>    exactly very pretty either and could lead to
>    some bizarre and unforseen side effects (though MIPv4
>    may have a handle on them). There's a lot to be
>    said about preserving transparency when ARnew
>    and ARold have no relationship with one another.
>
>  >   So let's get on with solving the problem. If there is a
> requirement to
>  > change
>  > FMIP, I'm sure the MIP group would be interested in our
> input. After all,
>  > that is one of the reasons Seamoby was chartered.
>
>    The requirement belongs on CT, not FMIP. It may
>    also be a bogus thing to do given the way that
>    ROHC/CRTP works.
>
>               Mike
>

------_=_NextPart_001_01C0C1E9.8E7FBA10-- From owner-seamoby@diameter.org Tue Apr 10 14:44:02 2001 Received: from charizard.diameter.org ([24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA23365 for ; Tue, 10 Apr 2001 14:44:00 -0400 (EDT) Received: (qmail 27651 invoked by alias); 10 Apr 2001 19:33:18 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 27645 invoked by uid 200); 10 Apr 2001 19:33:17 -0000 Received: (qmail 27640 invoked from network); 10 Apr 2001 19:33:16 -0000 Received: from sj-msg-core-3.cisco.com (171.70.157.152) by c900656-a.plstn1.sfba.home.com with SMTP; 10 Apr 2001 19:33:16 -0000 Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-3.cisco.com (8.9.3/8.9.1) with ESMTP id LAA11969; Tue, 10 Apr 2001 11:21:34 -0700 (PDT) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id ADV05891; Tue, 10 Apr 2001 11:22:51 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id LAA07115; Tue, 10 Apr 2001 11:22:50 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15059.20346.415938.311723@thomasm-u1.cisco.com> Date: Tue, 10 Apr 2001 11:22:50 -0700 (PDT) To: "Gary Kenward" Cc: "'Michael Thomas'" , "'seamoby'" , tmima@cisco.com, mccap@research.bell-labs.com, kempf@heliopolis.eng.sun.com Subject: RE: [mobile-ip] RE: [seamoby] RE: [rohc] RE: Restarting Compresso r on Mobile IPv6 Handover In-Reply-To: <9FBD322B7824D511B36900508BF93C9C125792@zcard031.ca.nortel.com> References: <9FBD322B7824D511B36900508BF93C9C125792@zcard031.ca.nortel.com> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-seamoby@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit Gary Kenward writes: > Michael: > > You were the one who stated that FMIP would not support context > tranfer for header compression. That's *one* way to spin it. The way I wrote it is that header compression CT will have trouble with FMIP. I'm not interested in assigning blame to FMIP here because I don't think FMIP is the root of the problem. Mike From owner-seamoby@diameter.org Tue Apr 10 16:23:53 2001 Received: from charizard.diameter.org ([24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA25483 for ; Tue, 10 Apr 2001 16:23:52 -0400 (EDT) Received: (qmail 29015 invoked by alias); 10 Apr 2001 21:12:15 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 29009 invoked by uid 200); 10 Apr 2001 21:12:15 -0000 Received: (qmail 29004 invoked from network); 10 Apr 2001 21:12:13 -0000 Received: from h52s48a140n47.user.nortelnetworks.com (HELO zrtps06u.us.nortel.com) (47.140.48.52) by c900656-a.plstn1.sfba.home.com with SMTP; 10 Apr 2001 21:12:13 -0000 Received: from zcars04f.ca.nortel.com (zcars04f.ca.nortel.com [47.129.242.57]) by zrtps06u.us.nortel.com (8.11.0/8.11.0) with ESMTP id f3AKKEJ17371 for ; Tue, 10 Apr 2001 16:20:14 -0400 (EDT) Received: from zcard015.ca.nortel.com by zcars04f.ca.nortel.com; Tue, 10 Apr 2001 16:21:20 -0400 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 10 Apr 2001 16:21:22 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C125798@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'Michael Thomas'" Cc: "'seamoby'" , tmima@cisco.com, mccap@research.bell-labs.com, kempf@heliopolis.eng.sun.com Subject: RE: [mobile-ip] RE: [seamoby] RE: [rohc] RE: Restarting Compresso r on Mobile IPv6 Handover Date: Tue, 10 Apr 2001 16:21:23 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0C1FB.CFABAAA0" X-Orig: Sender: owner-seamoby@diameter.org Precedence: bulk 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_01C0C1FB.CFABAAA0 Content-Type: text/plain; charset="iso-8859-1" Sheesh. It's not about blame. It is *all* about determining where the most appropriate place to fix a problem. That's what distinguishes engineering from hacking. > -----Original Message----- > From: Michael Thomas [mailto:mat@cisco.com] > Sent: Tuesday, April 10, 2001 2:23 PM > To: Kenward, Gary [WDLN2:AN10:EXCH] > Cc: 'Michael Thomas'; 'seamoby'; tmima@cisco.com; > mccap@research.bell-labs.com; kempf@heliopolis.eng.sun.com > Subject: RE: [mobile-ip] RE: [seamoby] RE: [rohc] RE: Restarting > Compresso r on Mobile IPv6 Handover > > > Gary Kenward writes: > > Michael: > > > > You were the one who stated that FMIP would not support context > > tranfer for header compression. > > That's *one* way to spin it. The way I wrote it is > that header compression CT will have trouble with > FMIP. I'm not interested in assigning blame to FMIP > here because I don't think FMIP is the root of the > problem. > > Mike > ------_=_NextPart_001_01C0C1FB.CFABAAA0 Content-Type: text/html; charset="iso-8859-1" RE: [mobile-ip] RE: [seamoby] RE: [rohc] RE: Restarting Compresso r on Mobile IPv6 Handover

Sheesh. It's not about blame.

It is *all* about determining where the most appropriate place to fix a problem.
That's what distinguishes engineering from hacking.

> -----Original Message-----
> From: Michael Thomas [mailto:mat@cisco.com]
> Sent: Tuesday, April 10, 2001 2:23 PM
> To: Kenward, Gary [WDLN2:AN10:EXCH]
> Cc: 'Michael Thomas'; 'seamoby'; tmima@cisco.com;
> mccap@research.bell-labs.com; kempf@heliopolis.eng.sun.com
> Subject: RE: [mobile-ip] RE: [seamoby] RE: [rohc] RE: Restarting
> Compresso r on Mobile IPv6 Handover
>
>
> Gary Kenward writes:
>  > Michael:
>  >
>  >    You were the one who stated that FMIP would not support context
>  > tranfer for header compression.
>
>    That's *one* way to spin it. The way I wrote it is
>    that header compression CT will have trouble with
>    FMIP. I'm not interested in assigning blame to FMIP
>    here because I don't think FMIP is the root of the
>    problem.
>
>               Mike
>

------_=_NextPart_001_01C0C1FB.CFABAAA0-- From owner-seamoby@diameter.org Tue Apr 10 16:54:28 2001 Received: from charizard.diameter.org ([24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA25967 for ; Tue, 10 Apr 2001 16:54:27 -0400 (EDT) Received: (qmail 29757 invoked by alias); 10 Apr 2001 21:42:47 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 29751 invoked by uid 200); 10 Apr 2001 21:42:47 -0000 Received: (qmail 29746 invoked from network); 10 Apr 2001 21:42:45 -0000 Received: from sj-msg-core-4.cisco.com (171.71.163.10) by c900656-a.plstn1.sfba.home.com with SMTP; 10 Apr 2001 21:42:45 -0000 Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-4.cisco.com (8.9.3/8.9.1) with ESMTP id NAA11411; Tue, 10 Apr 2001 13:32:24 -0700 (PDT) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id ADV09343; Tue, 10 Apr 2001 13:32:18 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id NAA07144; Tue, 10 Apr 2001 13:32:18 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15059.28114.544690.190970@thomasm-u1.cisco.com> Date: Tue, 10 Apr 2001 13:32:18 -0700 (PDT) To: "Gary Kenward" Cc: "'Michael Thomas'" , "'seamoby'" , tmima@cisco.com, mccap@research.bell-labs.com, kempf@heliopolis.eng.sun.com Subject: RE: [mobile-ip] RE: [seamoby] RE: [rohc] RE: Restarting Compresso r on Mobile IPv6 Handover In-Reply-To: <9FBD322B7824D511B36900508BF93C9C125798@zcard031.ca.nortel.com> References: <9FBD322B7824D511B36900508BF93C9C125798@zcard031.ca.nortel.com> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-seamoby@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit Gary Kenward writes: > Sheesh. It's not about blame. > > It is *all* about determining where the most appropriate place to fix a > problem. > That's what distinguishes engineering from hacking. Fine. You said that it looked like a problem with FMIP and it should be fixed there. What leads you to that conclusion and what would you have them do? Mike > > > -----Original Message----- > > From: Michael Thomas [mailto:mat@cisco.com] > > Sent: Tuesday, April 10, 2001 2:23 PM > > To: Kenward, Gary [WDLN2:AN10:EXCH] > > Cc: 'Michael Thomas'; 'seamoby'; tmima@cisco.com; > > mccap@research.bell-labs.com; kempf@heliopolis.eng.sun.com > > Subject: RE: [mobile-ip] RE: [seamoby] RE: [rohc] RE: Restarting > > Compresso r on Mobile IPv6 Handover > > > > > > Gary Kenward writes: > > > Michael: > > > > > > You were the one who stated that FMIP would not support context > > > tranfer for header compression. > > > > That's *one* way to spin it. The way I wrote it is > > that header compression CT will have trouble with > > FMIP. I'm not interested in assigning blame to FMIP > > here because I don't think FMIP is the root of the > > problem. > > > > Mike > > > > > > > > RE: [mobile-ip] RE: [seamoby] RE: [rohc] RE: Restarting Compresso r on Mobile IPv6 Handover > > > >

Sheesh. It's not about blame. >

> >

It is *all* about determining where the most appropriate place to fix a problem. >
That's what distinguishes engineering from hacking. >

> >

> -----Original Message----- >
> From: Michael Thomas [mailto:mat@cisco.com] >
> Sent: Tuesday, April 10, 2001 2:23 PM >
> To: Kenward, Gary [WDLN2:AN10:EXCH] >
> Cc: 'Michael Thomas'; 'seamoby'; tmima@cisco.com; >
> mccap@research.bell-labs.com; kempf@heliopolis.eng.sun.com >
> Subject: RE: [mobile-ip] RE: [seamoby] RE: [rohc] RE: Restarting >
> Compresso r on Mobile IPv6 Handover >
> >
> >
> Gary Kenward writes: >
>  > Michael: >
>  > >
>  >    You were the one who stated that FMIP would not support context >
>  > tranfer for header compression. >
> >
>    That's *one* way to spin it. The way I wrote it is >
>    that header compression CT will have trouble with >
>    FMIP. I'm not interested in assigning blame to FMIP >
>    here because I don't think FMIP is the root of the >
>    problem. >
> >
>               Mike >
> >

> > > From owner-seamoby@diameter.org Tue Apr 10 20:19:01 2001 Received: from charizard.diameter.org ([24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA28773 for ; Tue, 10 Apr 2001 20:18:58 -0400 (EDT) Received: (qmail 32305 invoked by alias); 11 Apr 2001 01:07:06 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 32299 invoked by uid 200); 11 Apr 2001 01:07:05 -0000 Received: (qmail 32294 invoked from network); 11 Apr 2001 01:07:04 -0000 Received: from unknown (HELO NEPTUNE.zucotto.com) (216.95.209.154) by c900656-a.plstn1.sfba.home.com with SMTP; 11 Apr 2001 01:07:04 -0000 Received: by NEPTUNE.zucotto.com with Internet Mail Service (5.5.2653.19) id ; Tue, 10 Apr 2001 20:16:57 -0400 Message-ID: <6833D86F1B05CA4FBAB3C73DD98BD8B90D2B15@NEPTUNE.zucotto.com> From: Kulwinder Atwal To: "'Michael Thomas'" , Gary Kenward Cc: "'seamoby'" , tmima@cisco.com, mccap@research.bell-labs.com, kempf@heliopolis.eng.sun.com Subject: RE: [mobile-ip] RE: [seamoby] RE: [rohc] RE: Restarting Compresso r on Mobile IPv6 Handover Date: Tue, 10 Apr 2001 20:16:53 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-seamoby@diameter.org Precedence: bulk > -----Original Message----- > From: Michael Thomas [mailto:mat@cisco.com] > Sent: Tuesday, April 10, 2001 4:32 PM > To: Gary Kenward > Cc: 'Michael Thomas'; 'seamoby'; tmima@cisco.com; > mccap@research.bell-labs.com; kempf@heliopolis.eng.sun.com > Subject: RE: [mobile-ip] RE: [seamoby] RE: [rohc] RE: Restarting > Compresso r on Mobile IPv6 Handover > > > Gary Kenward writes: > > Sheesh. It's not about blame. > > > > It is *all* about determining where the most appropriate > place to fix a > > problem. > > That's what distinguishes engineering from hacking. > > Fine. You said that it looked like a problem with > FMIP and it should be fixed there. What leads you > to that conclusion and what would you have them do? What lead some of us to that conclusion are two things: 1. Your statement below in a previous emial: > All I'm asking here is how CT would interact with > FMIP. I believe that FMIP is very likely to be a > very important part of handoffs and as such, I > would like to know whether CT for header > compression state will help, hinder or be of no > benefit at all. From what I can tell, there is > indeed a problem and it is not clear whether there > is a solution, or whether the solution would be > worse than the original problem given the high > likelihood of race conditions, etc. 2. The Bluetooth Special Interest Group, Personal Area Networking Working Group, plans to use the output of CT in a mobility protocol other than FMIP, HMIP, MIPv4, MIPv6 or anything else with MIP in the title. Therefore, tying CT to your favorite flavor of MIP is NOT a requirement. More importantly, requesting CT to change to accommodate FMIP is NOT a requirement. If there are problems with FMIP there is an IETF working group established to deal with them. It is called the: MIP WG Here is a link. Check it out: http://www.ietf.org/html.charters/mobileip-charter.html - Kulwinder. > > Mike > > > > > > -----Original Message----- > > > From: Michael Thomas [mailto:mat@cisco.com] > > > Sent: Tuesday, April 10, 2001 2:23 PM > > > To: Kenward, Gary [WDLN2:AN10:EXCH] > > > Cc: 'Michael Thomas'; 'seamoby'; tmima@cisco.com; > > > mccap@research.bell-labs.com; kempf@heliopolis.eng.sun.com > > > Subject: RE: [mobile-ip] RE: [seamoby] RE: [rohc] RE: Restarting > > > Compresso r on Mobile IPv6 Handover > > > > > > > > > Gary Kenward writes: > > > > Michael: > > > > > > > > You were the one who stated that FMIP would not > support context > > > > tranfer for header compression. > > > > > > That's *one* way to spin it. The way I wrote it is > > > that header compression CT will have trouble with > > > FMIP. I'm not interested in assigning blame to FMIP > > > here because I don't think FMIP is the root of the > > > problem. > > > > > > Mike > > > > > > > > > > > > > > > RE: [mobile-ip] RE: [seamoby] RE: [rohc] RE: > Restarting Compresso r on Mobile IPv6 Handover > > > > > > > >

Sheesh. It's not about blame. > >

> > > >

It is *all* about determining where the > most appropriate place to fix a problem. > >
That's what distinguishes engineering > from hacking. > >

> > > >

> -----Original Message----- > >
> From: Michael Thomas [ HREF="mailto:mat@cisco.com">mailto:mat@cisco.com] > >
> Sent: Tuesday, April 10, 2001 2:23 PM > >
> To: Kenward, Gary [WDLN2:AN10:EXCH] > >
> Cc: 'Michael Thomas'; 'seamoby'; > tmima@cisco.com; > >
> mccap@research.bell-labs.com; > kempf@heliopolis.eng.sun.com > >
> Subject: RE: [mobile-ip] RE: > [seamoby] RE: [rohc] RE: Restarting > >
> Compresso r on Mobile IPv6 Handover > >
> > >
> > >
> Gary Kenward writes: > >
>  > Michael: > >
>  > > >
>  >    You > were the one who stated that FMIP would not support context > >
>  > tranfer for header > compression. > >
> > >
>    That's *one* way > to spin it. The way I wrote it is > >
>    that header > compression CT will have trouble with > >
>    FMIP. I'm not > interested in assigning blame to FMIP > >
>    here because I > don't think FMIP is the root of the > >
>    problem. > >
> > >
>       >         Mike > >
> > >

> > > > > > > From owner-seamoby@diameter.org Tue Apr 10 20:36:42 2001 Received: from charizard.diameter.org ([24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA28921 for ; Tue, 10 Apr 2001 20:36:40 -0400 (EDT) Received: (qmail 417 invoked by alias); 11 Apr 2001 01:25:31 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 411 invoked by uid 200); 11 Apr 2001 01:25:30 -0000 Received: (qmail 406 invoked from network); 11 Apr 2001 01:25:29 -0000 Received: from sj-msg-core-4.cisco.com (171.71.163.10) by c900656-a.plstn1.sfba.home.com with SMTP; 11 Apr 2001 01:25:29 -0000 Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-4.cisco.com (8.9.3/8.9.1) with ESMTP id RAA19195; Tue, 10 Apr 2001 17:34:53 -0700 (PDT) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id ADV16313; Tue, 10 Apr 2001 17:34:48 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id RAA07178; Tue, 10 Apr 2001 17:34:48 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15059.42664.318875.533333@thomasm-u1.cisco.com> Date: Tue, 10 Apr 2001 17:34:48 -0700 (PDT) To: Kulwinder Atwal Cc: "'Michael Thomas'" , Gary Kenward , "'seamoby'" , tmima@cisco.com, mccap@research.bell-labs.com, kempf@heliopolis.eng.sun.com Subject: RE: [mobile-ip] RE: [seamoby] RE: [rohc] RE: Restarting Compresso r on Mobile IPv6 Handover In-Reply-To: <6833D86F1B05CA4FBAB3C73DD98BD8B90D2B15@NEPTUNE.zucotto.com> References: <6833D86F1B05CA4FBAB3C73DD98BD8B90D2B15@NEPTUNE.zucotto.com> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-seamoby@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit Kulwinder Atwal writes: > > Fine. You said that it looked like a problem with > > FMIP and it should be fixed there. What leads you > > to that conclusion and what would you have them do? > > What lead some of us to that conclusion are two things: > > 1. Your statement below in a previous emial: > > All I'm asking here is how CT would interact with > > FMIP. I believe that FMIP is very likely to be a > > very important part of handoffs and as such, I > > would like to know whether CT for header > > compression state will help, hinder or be of no > > benefit at all. From what I can tell, there is > > indeed a problem and it is not clear whether there > > is a solution, or whether the solution would be > > worse than the original problem given the high > > likelihood of race conditions, etc. I fail to see how this supports your argument. You can't run ROHC end to end either. That doesn't imply that IP is broken. > 2. The Bluetooth Special Interest Group, Personal Area Networking Working > Group, plans to use the output of CT in a mobility protocol other than FMIP, > HMIP, MIPv4, MIPv6 or anything else with MIP in the title. And this has what, exactly. to do with the interaction of FMIP and header compression CT? > Therefore, tying CT to your favorite flavor of MIP is NOT a > requirement. Nobody said it was. CT does have a requirement to support MIP though. > More importantly, requesting CT to change to accommodate FMIP is NOT a > requirement. If there are problems with FMIP there is an IETF working group > established to deal with them. It is called the: MIP WG Considering that there is a FMIP protocol defined and no CT protocol whatsoever, I don't know what it is that you think we should be telling the mobile IP working group. Is mind reading in their charter too? Mike From owner-seamoby@diameter.org Tue Apr 10 21:01:08 2001 Received: from charizard.diameter.org ([24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA29465 for ; Tue, 10 Apr 2001 21:01:08 -0400 (EDT) Received: (qmail 1080 invoked by alias); 11 Apr 2001 01:50:06 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 1074 invoked by uid 200); 11 Apr 2001 01:50:05 -0000 Received: (qmail 1067 invoked from network); 11 Apr 2001 01:50:04 -0000 Received: from unknown (HELO NEPTUNE.zucotto.com) (216.95.209.154) by c900656-a.plstn1.sfba.home.com with SMTP; 11 Apr 2001 01:50:04 -0000 Received: by NEPTUNE.zucotto.com with Internet Mail Service (5.5.2653.19) id ; Tue, 10 Apr 2001 20:59:58 -0400 Message-ID: <6833D86F1B05CA4FBAB3C73DD98BD8B90D2B16@NEPTUNE.zucotto.com> From: Kulwinder Atwal To: "'Michael Thomas'" , Kulwinder Atwal Cc: Gary Kenward , "'seamoby'" , tmima@cisco.com, mccap@research.bell-labs.com, kempf@heliopolis.eng.sun.com Subject: RE: [mobile-ip] RE: [seamoby] RE: [rohc] RE: Restarting Compresso r on Mobile IPv6 Handover Date: Tue, 10 Apr 2001 20:59:50 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-seamoby@diameter.org Precedence: bulk > -----Original Message----- > From: Michael Thomas [mailto:mat@cisco.com] > Sent: Tuesday, April 10, 2001 8:35 PM > To: Kulwinder Atwal > Cc: 'Michael Thomas'; Gary Kenward; 'seamoby'; tmima@cisco.com; > mccap@research.bell-labs.com; kempf@heliopolis.eng.sun.com > Subject: RE: [mobile-ip] RE: [seamoby] RE: [rohc] RE: Restarting > Compresso r on Mobile IPv6 Handover > > > Kulwinder Atwal writes: > > > Fine. You said that it looked like a problem with > > > FMIP and it should be fixed there. What leads you > > > to that conclusion and what would you have them do? > > > > What lead some of us to that conclusion are two things: > > > > 1. Your statement below in a previous emial: > > > All I'm asking here is how CT would interact with > > > FMIP. I believe that FMIP is very likely to be a > > > very important part of handoffs and as such, I > > > would like to know whether CT for header > > > compression state will help, hinder or be of no > > > benefit at all. From what I can tell, there is > > > indeed a problem and it is not clear whether there > > > is a solution, or whether the solution would be > > > worse than the original problem given the high > > > likelihood of race conditions, etc. > > I fail to see how this supports your argument. > You can't run ROHC end to end either. That > doesn't imply that IP is broken. > Rather than me just repeating what Gary K said in his emails today, please re-read his emails. Ditto. Before responding, please read Rajeev's enlightenment on how to do ROHC CT for FMIP. - Kulwinder. From owner-seamoby@diameter.org Wed Apr 11 09:25:16 2001 Received: from charizard.diameter.org ([24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA23613 for ; Wed, 11 Apr 2001 09:25:14 -0400 (EDT) Received: (qmail 7137 invoked by alias); 11 Apr 2001 14:13:35 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 7131 invoked by uid 200); 11 Apr 2001 14:13:34 -0000 Received: (qmail 7126 invoked from network); 11 Apr 2001 14:13:32 -0000 Received: from patan.sun.com (192.18.98.43) by c900656-a.plstn1.sfba.home.com with SMTP; 11 Apr 2001 14:13:32 -0000 Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA29260; Wed, 11 Apr 2001 06:23:21 -0700 (PDT) Received: from nasnfs.Eng.Sun.COM (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA13421; Wed, 11 Apr 2001 06:23:21 -0700 (PDT) Received: from nasnfs.Eng.Sun.COM (eastapp2.East.Sun.COM [129.148.162.99]) by nasnfs.Eng.Sun.COM (8.9.3+Sun/8.9.1) with ESMTP id GAA12610; Wed, 11 Apr 2001 06:22:47 -0700 (PDT) From: Patrice Calhoun Message-Id: <200104111322.GAA12610@nasnfs.Eng.Sun.COM> Date: Wed, 11 Apr 2001 09:18:40 -0700 To: "Hesham Soliman \(ERA\)" , "Casati, Alessio \(Alessio\)" , "'Patrice Calhoun'" Cc: "Seamoby \(E-mail\)" Reply-To: Subject: RE: [seamoby] Response of Mobile Operator to Request for Info on Re alistic Paging X-Mailer: Sun NetMail 2.3 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Sender: owner-seamoby@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit Then it is up to these people to either state: 1. proposed changes to the problem statement 2. Claim that this is not a problem to be solved, or 3. point to specific text that needs to be clarified What I don't want is simple e-mails that bash the work without any justification. Alessio tried to kill it and failed, because he was alone, and concensus rules. I don't have issues if other people want to do one of the above, but I wanted to kill Alessio's bashing thread because his position was well known. PatC >Pat, > >Sorry for the short disobedience to your recommendtion to kill >the thread. But for the record, I think Alessio is making a lot >of sense. Others also raised similar issues in Minneapolis. > > >Regards, >Hesham > >> -----Original Message----- >> From: Patrice Calhoun [SMTP:pcalhoun@nasnfs.Eng.Sun.COM] >> Sent: Saturday, 7 April 2001 12:41 >> To: Casati, Alessio (Alessio) >> Cc: Seamoby (E-mail) >> Subject: Re: [seamoby] Response of Mobile Operator to Request for Info on Re >alistic Paging >> >> I have been trying to sit by the sidelines, and allow everyone to express >> their opinion, but it is apparent to me that there is no possible compromise >> here. Alessio is insistent that this is useless, and others do not think so. >> They find this work useful, and have stated their opinions as well. >> >> So, in the spirit of cooperation, perhaps we can put this thread aside, and >> start working on the requirements. >> >> Please kill this thread. If the market does in fact not find this work >useful, >> then like many other things from the IETF, it will not have much deployment. >> >> As for HLR/VLR, I know that there is significant work going on to eliminate >> them in *some* of the SDOs. Again, whether or not carriers will use the new >> standards is nothing more than a guess any one of us could do. >> >> So, let's get to work! >> >> PatC >> >> > >> > >> > Your opinion is not shared by either the working group chair >> > nor by the AD. >> > When the AD reports back to us, we will see whether it is shared by >> > the >> > IESG. We are not talking about GPRS nor 3GPP2, we are talking >> > about a future network where there is no HLR or VLR. >> > >> > So, this should be written in the problem statement. >> > However this does not change the validity of >> > what I wrote. By the way there are >> > a few operators out there that are happy to use HLR >> > and VLR. Those concepts I wrote will remain valid, although technology >> > and naming of for the same functionality will evolve. So, something >> > meaningless today (such as a wireless net without HLR and VLR >> > functionality, >> > will be meaningless in the future). Need of L3 paging is >> > meaningless today >> > as it will be tomorrow (unless what you are doing is what the GTP >> > PDU notification does today, in which case you are doing really nothing >> > new, since this was done years ago in ETSI - if you are doing that >> > then I can point you to where you could look this up not to >> > reinvent the wheel >> > too much) >> > >> > My observation is that you keep bringing up the same points, >> > which I keep >> > answering. To that extent, Mike's comment that you seem to be >> > disruptive >> > is appropriate. >> > >> > The same points are brought insofar as no response is given to >> > them. I wonder why I get no answer other than " we work by >> > rough consensus". >> > It is depressing :). >> > >> > >> > alessio >> From owner-seamoby@diameter.org Wed Apr 11 09:28:57 2001 Received: from charizard.diameter.org ([24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA23743 for ; Wed, 11 Apr 2001 09:28:56 -0400 (EDT) Received: (qmail 7667 invoked by alias); 11 Apr 2001 14:17:20 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 7661 invoked by uid 200); 11 Apr 2001 14:17:19 -0000 Received: (qmail 7656 invoked from network); 11 Apr 2001 14:17:18 -0000 Received: from patan.sun.com (192.18.98.43) by c900656-a.plstn1.sfba.home.com with SMTP; 11 Apr 2001 14:17:18 -0000 Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA02121; Wed, 11 Apr 2001 06:27:10 -0700 (PDT) Received: from nasnfs.Eng.Sun.COM (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA13743; Wed, 11 Apr 2001 06:27:09 -0700 (PDT) Received: from nasnfs.Eng.Sun.COM (eastapp2.East.Sun.COM [129.148.162.99]) by nasnfs.Eng.Sun.COM (8.9.3+Sun/8.9.1) with ESMTP id GAA12657; Wed, 11 Apr 2001 06:26:35 -0700 (PDT) From: Patrice Calhoun Message-Id: <200104111326.GAA12657@nasnfs.Eng.Sun.COM> Date: Wed, 11 Apr 2001 09:22:28 -0700 To: "'Patrice Calhoun'" , "Casati, Alessio \(Alessio\)" , "Hesham Soliman \(ERA\)" Cc: "Seamoby \(E-mail\)" Reply-To: Subject: RE: [seamoby] Response of Mobile Operator to Request for Info on Re alistic Paging X-Mailer: Sun NetMail 2.3 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Sender: owner-seamoby@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit Sorry, I think I was a little harsh with my use of "bashing thread". I understand that he wasn't "bashing" the work, but trying to make his position known, and what I was really trying to state was that we understood his position, so it was time to move on. (it'll teach me better to write e-mails when in a different time zone while my internal clock still thinks it's middle of the night) PatC >Then it is up to these people to either state: > >1. proposed changes to the problem statement >2. Claim that this is not a problem to be solved, or >3. point to specific text that needs to be clarified > >What I don't want is simple e-mails that bash the work without any >justification. >Alessio tried to kill it and failed, because he was alone, and concensus rules. >I don't have issues if other people want to do one of the above, but I wanted >to kill Alessio's bashing thread because his position was well known. > >PatC > >>Pat, >> >>Sorry for the short disobedience to your recommendtion to kill >>the thread. But for the record, I think Alessio is making a lot >>of sense. Others also raised similar issues in Minneapolis. >> >> >>Regards, >>Hesham >> >>> -----Original Message----- >>> From: Patrice Calhoun [SMTP:pcalhoun@nasnfs.Eng.Sun.COM] >>> Sent: Saturday, 7 April 2001 12:41 >>> To: Casati, Alessio (Alessio) >>> Cc: Seamoby (E-mail) >>> Subject: Re: [seamoby] Response of Mobile Operator to Request for Info on >Re >>alistic Paging >>> >>> I have been trying to sit by the sidelines, and allow everyone to express >>> their opinion, but it is apparent to me that there is no possible compromise >>> here. Alessio is insistent that this is useless, and others do not think so. >>> They find this work useful, and have stated their opinions as well. >>> >>> So, in the spirit of cooperation, perhaps we can put this thread aside, and >>> start working on the requirements. >>> >>> Please kill this thread. If the market does in fact not find this work >>useful, >>> then like many other things from the IETF, it will not have much deployment. >>> >>> As for HLR/VLR, I know that there is significant work going on to eliminate >>> them in *some* of the SDOs. Again, whether or not carriers will use the new >>> standards is nothing more than a guess any one of us could do. >>> >>> So, let's get to work! >>> >>> PatC >>> >>> > >>> > >>> > Your opinion is not shared by either the working group chair >>> > nor by the AD. >>> > When the AD reports back to us, we will see whether it is shared by >>> > the >>> > IESG. We are not talking about GPRS nor 3GPP2, we are talking >>> > about a future network where there is no HLR or VLR. >>> > >>> > So, this should be written in the problem statement. >>> > However this does not change the validity of >>> > what I wrote. By the way there are >>> > a few operators out there that are happy to use HLR >>> > and VLR. Those concepts I wrote will remain valid, although technology >>> > and naming of for the same functionality will evolve. So, something >>> > meaningless today (such as a wireless net without HLR and VLR >>> > functionality, >>> > will be meaningless in the future). Need of L3 paging is >>> > meaningless today >>> > as it will be tomorrow (unless what you are doing is what the GTP >>> > PDU notification does today, in which case you are doing really nothing >>> > new, since this was done years ago in ETSI - if you are doing that >>> > then I can point you to where you could look this up not to >>> > reinvent the wheel >>> > too much) >>> > >>> > My observation is that you keep bringing up the same points, >>> > which I keep >>> > answering. To that extent, Mike's comment that you seem to be >>> > disruptive >>> > is appropriate. >>> > >>> > The same points are brought insofar as no response is given to >>> > them. I wonder why I get no answer other than " we work by >>> > rough consensus". >>> > It is depressing :). >>> > >>> > >>> > alessio >>> > > From owner-seamoby@diameter.org Wed Apr 11 10:06:35 2001 Received: from charizard.diameter.org ([24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA24402 for ; Wed, 11 Apr 2001 10:06:33 -0400 (EDT) Received: (qmail 8919 invoked by alias); 11 Apr 2001 14:54:44 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 8913 invoked by uid 200); 11 Apr 2001 14:54:44 -0000 Received: (qmail 8908 invoked from network); 11 Apr 2001 14:54:36 -0000 Received: from www.bit-net.com (HELO mail.users.bit-net.com) (208.146.132.4) by c900656-a.plstn1.sfba.home.com with SMTP; 11 Apr 2001 14:54:36 -0000 Received: from localhost by mail.users.bit-net.com; (5.65v3.2/1.1.8.2/30Jul96-0143PM) id AA18891; Wed, 11 Apr 2001 10:04:10 -0400 Date: Wed, 11 Apr 2001 10:04:10 -0400 (EDT) From: Jim Bound To: Patrice Calhoun Cc: "Hesham Soliman \(ERA\)" , "Casati, Alessio \(Alessio\)" , "Seamoby \(E-mail\)" Subject: RE: [seamoby] Response of Mobile Operator to Request for Info on Re alistic Paging In-Reply-To: <200104111322.GAA12610@nasnfs.Eng.Sun.COM> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-seamoby@diameter.org Precedence: bulk Pat, Not sure how to do this constructively yet. But I do think the HLR/VLR for 3GPP2 and 3GPP are in fact in the way of IP PDN and not the right models to assume for context xfr, complete handoff (even if done at layer 2) for a "FULL IP Network" (seems ALL-IP has beome a marketing term that is at best confusing to the public when looking at what it means). Likewise for HSS too. So one thing to suggest might be adding that the objective is to get to FULL IP Network and what are the resultant problems from going there. And I will stop there to see if my statements are constructive? /jim On Wed, 11 Apr 2001, Patrice Calhoun wrote: > Then it is up to these people to either state: > > 1. proposed changes to the problem statement > 2. Claim that this is not a problem to be solved, or > 3. point to specific text that needs to be clarified > > What I don't want is simple e-mails that bash the work without any justification. > Alessio tried to kill it and failed, because he was alone, and concensus rules. > I don't have issues if other people want to do one of the above, but I wanted > to kill Alessio's bashing thread because his position was well known. > > PatC > > >Pat, > > > >Sorry for the short disobedience to your recommendtion to kill > >the thread. But for the record, I think Alessio is making a lot > >of sense. Others also raised similar issues in Minneapolis. > > > > > >Regards, > >Hesham > > > >> -----Original Message----- > >> From: Patrice Calhoun [SMTP:pcalhoun@nasnfs.Eng.Sun.COM] > >> Sent: Saturday, 7 April 2001 12:41 > >> To: Casati, Alessio (Alessio) > >> Cc: Seamoby (E-mail) > >> Subject: Re: [seamoby] Response of Mobile Operator to Request for Info on Re > >alistic Paging > >> > >> I have been trying to sit by the sidelines, and allow everyone to express > >> their opinion, but it is apparent to me that there is no possible compromise > >> here. Alessio is insistent that this is useless, and others do not think so. > >> They find this work useful, and have stated their opinions as well. > >> > >> So, in the spirit of cooperation, perhaps we can put this thread aside, and > >> start working on the requirements. > >> > >> Please kill this thread. If the market does in fact not find this work > >useful, > >> then like many other things from the IETF, it will not have much deployment. > >> > >> As for HLR/VLR, I know that there is significant work going on to eliminate > >> them in *some* of the SDOs. Again, whether or not carriers will use the new > >> standards is nothing more than a guess any one of us could do. > >> > >> So, let's get to work! > >> > >> PatC > >> > >> > > >> > > >> > Your opinion is not shared by either the working group chair > >> > nor by the AD. > >> > When the AD reports back to us, we will see whether it is shared by > >> > the > >> > IESG. We are not talking about GPRS nor 3GPP2, we are talking > >> > about a future network where there is no HLR or VLR. > >> > > >> > So, this should be written in the problem statement. > >> > However this does not change the validity of > >> > what I wrote. By the way there are > >> > a few operators out there that are happy to use HLR > >> > and VLR. Those concepts I wrote will remain valid, although technology > >> > and naming of for the same functionality will evolve. So, something > >> > meaningless today (such as a wireless net without HLR and VLR > >> > functionality, > >> > will be meaningless in the future). Need of L3 paging is > >> > meaningless today > >> > as it will be tomorrow (unless what you are doing is what the GTP > >> > PDU notification does today, in which case you are doing really nothing > >> > new, since this was done years ago in ETSI - if you are doing that > >> > then I can point you to where you could look this up not to > >> > reinvent the wheel > >> > too much) > >> > > >> > My observation is that you keep bringing up the same points, > >> > which I keep > >> > answering. To that extent, Mike's comment that you seem to be > >> > disruptive > >> > is appropriate. > >> > > >> > The same points are brought insofar as no response is given to > >> > them. I wonder why I get no answer other than " we work by > >> > rough consensus". > >> > It is depressing :). > >> > > >> > > >> > alessio > >> > > From owner-seamoby@diameter.org Wed Apr 11 10:31:46 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA24906 for ; Wed, 11 Apr 2001 10:31:45 -0400 (EDT) Received: (qmail 9647 invoked by alias); 11 Apr 2001 15:20:43 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 9641 invoked by uid 200); 11 Apr 2001 15:20:43 -0000 Received: (qmail 9636 invoked from network); 11 Apr 2001 15:20:41 -0000 Received: from c007-h014.c007.snv.cp.net (HELO c007.snv.cp.net) (209.228.33.221) by c900656-a.plstn1.sfba.home.com with SMTP; 11 Apr 2001 15:20:41 -0000 Received: (cpmta 3341 invoked from network); 11 Apr 2001 07:30:06 -0700 Received: from unknown (HELO philneum) (64.193.0.129) by smtp.telocity.com (209.228.33.221) with SMTP; 11 Apr 2001 07:30:06 -0700 X-Sent: 11 Apr 2001 14:30:06 GMT Message-ID: <002401c0c293$c3e63940$6501a8c0@philneum> Reply-To: "Phil Neumiller" From: "Phil Neumiller" To: "Jim Bound" , "Patrice Calhoun" Cc: "Hesham Soliman \(ERA\)" , "Casati, Alessio \(Alessio\)" , "Seamoby \(E-mail\)" References: Subject: Re: [seamoby] Response of Mobile Operator to Request for Info on Re alistic Paging Date: Wed, 11 Apr 2001 09:28:59 -0500 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-seamoby@diameter.org Precedence: bulk What a breath of fresh air! Could not agree more. Also, many of the threads on MIP, SeaMoby, and ROHC seem to be ignoring that WE WILL HAVE TO DEAL with architecture here. We in SeaMoby have created our own reference model which is nice, but other SDO's have their own "reference" models (aka architectures) and the stuff we are doing will probably not work properly for them if these things are ignored as they seem to be. I don't get it? I am not the world's biggest 3G supporter but even I see a train wreck for these poor 3G guys that MAY want to use this stuff eventually. -Phil ----- Original Message ----- From: "Jim Bound" To: "Patrice Calhoun" Cc: "Hesham Soliman (ERA)" ; "Casati, Alessio (Alessio)" ; "Seamoby (E-mail)" Sent: Wednesday, April 11, 2001 9:04 AM Subject: RE: [seamoby] Response of Mobile Operator to Request for Info on Re alistic Paging > Pat, > > Not sure how to do this constructively yet. But I do think the HLR/VLR > for 3GPP2 and 3GPP are in fact in the way of IP PDN and not the right > models to assume for context xfr, complete handoff (even if done at layer > 2) for a "FULL IP Network" (seems ALL-IP has beome a marketing term that > is at best confusing to the public when looking at what it means). > Likewise for HSS too. > > So one thing to suggest might be adding that the objective is to get to > FULL IP Network and what are the resultant problems from going there. > > And I will stop there to see if my statements are constructive? > > /jim From owner-seamoby@diameter.org Wed Apr 11 10:47:02 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA25206 for ; Wed, 11 Apr 2001 10:47:01 -0400 (EDT) Received: (qmail 10228 invoked by alias); 11 Apr 2001 15:36:12 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 10222 invoked by uid 200); 11 Apr 2001 15:36:12 -0000 Received: (qmail 10217 invoked from network); 11 Apr 2001 15:36:11 -0000 Received: from auemail2.lucent.com (HELO auemail2.firewall.lucent.com) (192.11.223.163) by c900656-a.plstn1.sfba.home.com with SMTP; 11 Apr 2001 15:36:11 -0000 Received: from auemail2.firewall.lucent.com (localhost [127.0.0.1]) by auemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id KAA11862 for ; Wed, 11 Apr 2001 10:46:06 -0400 (EDT) Received: from uk0006exch001h.wins.lucent.com (h135-86-160-150.lucent.com [135.86.160.150]) by auemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id KAA11831 for ; Wed, 11 Apr 2001 10:46:06 -0400 (EDT) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2650.21) id ; Wed, 11 Apr 2001 15:02:16 +0100 Message-ID: <976F7C55E3B2D111A0720008C728549C097CC372@en0060exch001u.uk.lucent.com> From: "Casati, Alessio \(Alessio\)" To: "'pcalhoun@eng.sun.com'" , "Casati, Alessio \(Alessio\)" , "Hesham Soliman \(ERA\)" Cc: "Seamoby \(E-mail\)" Subject: RE: [seamoby] Response of Mobile Operator to Request for Info on Re alistic Paging Date: Wed, 11 Apr 2001 14:57:52 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: owner-seamoby@diameter.org Precedence: bulk * * *Sorry, I think I was a little harsh with my use of "bashing *thread". I understand *that he wasn't "bashing" the work, but trying to make his *position known, and *what I was really trying to state was that we understood his *position, so it was *time to move on. * *(it'll teach me better to write e-mails when in a different *time zone while my *internal clock still thinks it's middle of the night) * You should not send IP packets while you are dormant ;). alessio From owner-seamoby@diameter.org Wed Apr 11 10:49:13 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA25252 for ; Wed, 11 Apr 2001 10:49:11 -0400 (EDT) Received: (qmail 10292 invoked by alias); 11 Apr 2001 15:36:20 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 10284 invoked by uid 200); 11 Apr 2001 15:36:20 -0000 Received: (qmail 10256 invoked from network); 11 Apr 2001 15:36:15 -0000 Received: from auemail2.lucent.com (HELO auemail2.firewall.lucent.com) (192.11.223.163) by c900656-a.plstn1.sfba.home.com with SMTP; 11 Apr 2001 15:36:15 -0000 Received: from auemail2.firewall.lucent.com (localhost [127.0.0.1]) by auemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id KAA11796 for ; Wed, 11 Apr 2001 10:46:05 -0400 (EDT) Received: from uk0006exch001h.wins.lucent.com (h135-86-160-150.lucent.com [135.86.160.150]) by auemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id KAA11762 for ; Wed, 11 Apr 2001 10:46:04 -0400 (EDT) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2650.21) id ; Wed, 11 Apr 2001 15:00:48 +0100 Message-ID: <976F7C55E3B2D111A0720008C728549C097CC371@en0060exch001u.uk.lucent.com> From: "Casati, Alessio \(Alessio\)" To: "'pcalhoun@eng.sun.com'" , "Hesham Soliman \(ERA\)" Cc: "Seamoby \(E-mail\)" , "'mankin@isi.edu'" Subject: RE: [seamoby] Response of Mobile Operator to Request for Info on Re alistic Paging Date: Wed, 11 Apr 2001 14:54:24 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: owner-seamoby@diameter.org Precedence: bulk *Then it is up to these people to either state: * *1. proposed changes to the problem statement *2. Claim that this is not a problem to be solved, or *3. point to specific text that needs to be clarified * *What I don't want is simple e-mails that bash the work without *any justification. *Alessio tried to kill it and failed, because he was alone, and *concensus rules. My attempt was not to kill it (I'm not in the draft murder business as yet). I also don't think I was alone (at least 3 people on the list show some agreement on my position). I think I'm the only one that persisted in pointing out some weak technical foundations upon which the work is based. I also believed I indicated parts of the probelem statement that need fixing, and parts that are (sorry for crude statement) bogus. I understand the only answers were escaping via the well Known IETF rule of rough consensus. But the only endorsement we have so far is the author's and the anonymous' (Based on his presumed (?) and not justified operational aspects - rather than answers to my technical comments). I also don't want to interfere with the rest of the paging work, since, who knows, it may be that something useful could come out from the brain trust working at it. If not, we'll just add this work to the pile of the failures in research history, as Pat stated. *I don't have issues if other people want to do one of the *above, but I wanted *to kill Alessio's bashing thread because his position was well known. Yet unanswered... But, Till some not correct messages like the one you sent now will show up (or till the discussion on the problem statement can continue on a technical basis) I'll go dormant. Perhaps I'm experimenting L8 paging... PS. By the way, a reminder for the AD: you promised you would have reported on the IESG telechat. How did it go? Can you summarize what the discussion on this was (if at all it was discussed). It is interesting to have a statement from the IESG on this. peace alessio From owner-seamoby@diameter.org Wed Apr 11 11:27:47 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA26135 for ; Wed, 11 Apr 2001 11:27:46 -0400 (EDT) Received: (qmail 11669 invoked by alias); 11 Apr 2001 16:16:43 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 11662 invoked by uid 200); 11 Apr 2001 16:16:43 -0000 Received: (qmail 11657 invoked from network); 11 Apr 2001 16:16:41 -0000 Received: from auemail2.lucent.com (HELO auemail2.firewall.lucent.com) (192.11.223.163) by c900656-a.plstn1.sfba.home.com with SMTP; 11 Apr 2001 16:16:41 -0000 Received: from auemail2.firewall.lucent.com (localhost [127.0.0.1]) by auemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id LAA02924 for ; Wed, 11 Apr 2001 11:26:37 -0400 (EDT) Received: from uk0006exch001h.wins.lucent.com (h135-86-160-150.lucent.com [135.86.160.150]) by auemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id LAA02895 for ; Wed, 11 Apr 2001 11:26:36 -0400 (EDT) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2650.21) id ; Wed, 11 Apr 2001 16:26:35 +0100 Message-ID: <976F7C55E3B2D111A0720008C728549C097CC377@en0060exch001u.uk.lucent.com> From: "Casati, Alessio \(Alessio\)" To: "'pcalhoun@eng.sun.com'" , "Hesham Soliman \(ERA\)" Cc: "Seamoby \(E-mail\)" , "'mankin@isi.edu'" Subject: RE: [seamoby] Response of Mobile Operator to Request for Info on Re alistic Paging Date: Wed, 11 Apr 2001 16:26:16 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C0C29B.C05F14B0" Sender: owner-seamoby@diameter.org Precedence: bulk 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_000_01C0C29B.C05F14B0 Content-Type: text/plain * * **Then it is up to these people to either state: ** **1. proposed changes to the problem statement **2. Claim that this is not a problem to be solved, or **3. point to specific text that needs to be clarified ** by the way, I think the attached e-mail contradicts your previous message. alessio ------_=_NextPart_000_01C0C29B.C05F14B0 Content-Type: message/rfc822 Content-Description: Re: [seamoby-paging] Paging Requirements Draft and Teleconference Message-ID: <200104111331.GAA12704@nasnfs.Eng.Sun.COM> From: Patrice Calhoun Reply-To: pcalhoun@eng.sun.com To: James Kempf , seamoby-paging@diameter.org Subject: Re: [seamoby-paging] Paging Requirements Draft and Teleconference Date: Wed, 11 Apr 2001 17:27:12 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain >1) If you don't believe there is a problem to be solved for paging, >please go to the IESG and talk to them. Or me, and I will concatenate the comments and bring them to the IESG. > If you don't believe paging >applies to your favorite radio protocol, please don't bother to >show up at the teleconference. But do write me e-mail so I can understand your position. So far I have been collecting comments from people that do not believe this works is needed. PatC ------_=_NextPart_000_01C0C29B.C05F14B0-- From owner-seamoby@diameter.org Wed Apr 11 16:18:45 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA02382 for ; Wed, 11 Apr 2001 16:18:44 -0400 (EDT) Received: (qmail 17868 invoked by alias); 11 Apr 2001 21:07:20 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 17862 invoked by uid 200); 11 Apr 2001 21:07:20 -0000 Received: (qmail 17855 invoked from network); 11 Apr 2001 21:07:16 -0000 Received: from c007-h014.c007.snv.cp.net (HELO c007.snv.cp.net) (209.228.33.221) by c900656-a.plstn1.sfba.home.com with SMTP; 11 Apr 2001 21:07:16 -0000 Received: (cpmta 1848 invoked from network); 11 Apr 2001 13:16:43 -0700 Received: from unknown (HELO philneum) (64.193.0.129) by smtp.telocity.com (209.228.33.221) with SMTP; 11 Apr 2001 13:16:43 -0700 X-Sent: 11 Apr 2001 20:16:43 GMT Message-ID: <001d01c0c2c4$3029d3c0$6501a8c0@philneum> Reply-To: "Phil Neumiller" From: "Phil Neumiller" To: "Michael Thomas" , "James Kempf" Cc: , References: <200104111823.LAA12747@heliopolis.eng.sun.com> <15060.43262.631464.956252@thomasm-u1.cisco.com> Subject: [seamoby] IETF Architecture Work (RANT) Date: Wed, 11 Apr 2001 15:15:36 -0500 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-seamoby@diameter.org Precedence: bulk // BEGIN RANT I am sending this rant to SeaMoby since I think its important to the whole WG. I am basing this off some threads I have seen go astray due to a lack of a common set of terminology and assumptions (i.e. stuff that can often be provided by an architecture). I think when the IETF was young it was probably like working for a startup. You can't tolerate people that aren't good so they are immediately gotten moved off the critical path and you keep the top talent that buys into a common vision going. In these situations, architecture is done implicitly, its almost a Zen thing. Today, we have a different IETF with lots of different visions, interests, and time frames. There are only a few people that can catch the "gestalt" of an entire WG let alone multiple WGs and other SDOs that are coming into the IETF to "influence" it. If there was EVER a time for the IETF to sincerely start documentings is architecture work (which it is doing a lot of these days under the covers) it is now. More comments below: ----- Original Message ----- > > > The IETF has been well served by steering clear > of architectures. That isn't to say that lots > of people don't have architectures in mind when > they do protocol design; I'm sure most do. > However, I think there's a lot of merit to > leaving the architecture ambiguous because: I think there is a subtle difference between ambiguity and generality. I think most people want to strive for work that is the most general purpose and handles the most cases, by its very nature this type of design is very flexible and can transcend the boundaries of many architectures. > 1) It postpones that debate till deployment > 2) IETF already incorporates deployment > experience as part of its process > 3) "Architectures" have a tendency to become > ossified when they are too narrow. > 4) Leaving the deployment architecture unspoken > is a feature, not a bug. There are many > reuses of existing protocols which probably > wouldn't have happened if they had to be > vetted against some architecture. > I would argue that there are probably just as many problems caused by existing protocols that may have been prevented with a bit more "architecture" work. In many cases it may boil down to the size of the WG. In the case of SeaMoby its a pretty big group and to handle the diverging opinions it would seem to me that architecture is a useful tool. If it were me and Peter coding it... wait a minute, we finished this stuff in 1998! Regards, -Phil // END RANT From owner-seamoby@diameter.org Wed Apr 11 16:51:29 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA03145 for ; Wed, 11 Apr 2001 16:51:28 -0400 (EDT) Received: (qmail 18807 invoked by alias); 11 Apr 2001 21:40:02 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 18801 invoked by uid 200); 11 Apr 2001 21:40:02 -0000 Received: (qmail 18790 invoked from network); 11 Apr 2001 21:39:59 -0000 Received: from mailhost.iprg.nokia.com (205.226.5.12) by c900656-a.plstn1.sfba.home.com with SMTP; 11 Apr 2001 21:39:59 -0000 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 NAA28830; Wed, 11 Apr 2001 13:49:26 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f3BKnPW21571; Wed, 11 Apr 2001 13:49:25 -0700 X-mProtect: Wed, 11 Apr 2001 13:49:25 -0700 Nokia Silicon Valley Messaging Protection Received: from charliep.iprg.nokia.com (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(WTS.12.69) smtpdxljEZn; Wed, 11 Apr 2001 13:49:17 PDT Message-ID: <3AD4C34E.53E4F6A5@iprg.nokia.com> Date: Wed, 11 Apr 2001 13:49:18 -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: Phil Neumiller CC: seamoby@cdma-2000.org Subject: Re: [seamoby] IETF Architecture Work (RANT) References: <200104111823.LAA12747@heliopolis.eng.sun.com> <15060.43262.631464.956252@thomasm-u1.cisco.com> <001d01c0c2c4$3029d3c0$6501a8c0@philneum> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-seamoby@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit Hello Phil, If you think there are architectural issues that need attention, can you say what they are? If you can say what they are, do you think there is value in bringing the list items to the attention of the IAB? > I am sending this rant to SeaMoby since I think its important to the > whole WG. I am basing this off some threads I have seen go astray > due to a lack of a common set of terminology and assumptions (i.e. > stuff that can often be provided by an architecture). It can also be provided by a terminology document and a requirements document. > I think when the IETF was young it was probably like working for a > startup. You can't tolerate people that aren't good so they are immediately > gotten moved off the critical path and you keep the top talent that buys into > a common vision going. In these situations, architecture is done implicitly, > its almost a Zen thing. But four out of five startups fail. We need to keep the failure average lower in the IETF, I reckon. > Today, we have a different IETF with lots of different visions, interests, > and time frames. There are only a few people that can catch the "gestalt" of > an entire WG let alone multiple WGs and other SDOs that are coming > into the IETF to "influence" it. If there was EVER a time for the IETF > to sincerely start documentings is architecture work (which it is doing a > lot of these days under the covers) it is now. That's because the Internet is huge enough to encompass a major diversity of applications and utilizations. I just hope we can avoid the tragedy of the commons. Sometimes it seems inevitable, as clever people make local optimizations that damage the overall good. Architecture with teeth could help in this regard. But the market can dump any solution it has not been groomed to prefer, architecture or not. Examples abound. Worse, if the architecture has teeth, and it's not great according to your definition, then you won't like the teeth marks. .......... > If it were me and Peter coding it... wait a minute, we > finished this stuff in 1998! But coding isn't architecture. And I know you didn't say it was. But your comment here would be more appropriate in a discussion about why the IETF should NOT DO architecture. I absolutely agree that architecture is needed. I just question whether it belongs in a working group like [seamoby]. It would seem to be more appropriate at the area directorate level, or probably better within a group like the IAB. I wonder if there should be an [iawg]. We'd need some wild-eyed masochists as chairs, I reckon. Regards, Charlie P. From owner-seamoby@diameter.org Wed Apr 11 17:28:44 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA03701 for ; Wed, 11 Apr 2001 17:28:42 -0400 (EDT) Received: (qmail 19868 invoked by alias); 11 Apr 2001 22:17:24 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 19861 invoked by uid 200); 11 Apr 2001 22:17:23 -0000 Received: (qmail 19856 invoked from network); 11 Apr 2001 22:17:18 -0000 Received: from mercury.sun.com (192.9.25.1) by c900656-a.plstn1.sfba.home.com with SMTP; 11 Apr 2001 22:17:18 -0000 Received: from heliopolis.eng.sun.com ([152.70.1.39]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA21777; Wed, 11 Apr 2001 14:25:48 -0700 (PDT) Received: from srmtv29a (srmtv29a [152.70.1.41]) by heliopolis.eng.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id OAA18296; Wed, 11 Apr 2001 14:27:13 -0700 (PDT) Message-Id: <200104112127.OAA18296@heliopolis.eng.sun.com> Date: Wed, 11 Apr 2001 14:27:14 -0700 (PDT) From: James Kempf Reply-To: James Kempf Subject: Re: [seamoby] IETF Architecture Work (RANT) To: neumiller@telocity.com, charliep@IPRG.nokia.com Cc: seamoby@cdma-2000.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: bAHYMFLZSe9alUbx8PRGag== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 sun4u sparc Sender: owner-seamoby@diameter.org Precedence: bulk Hi Charlie, Apologies for getting off on a rant here, but unfortunately this has hit a hot button. >I absolutely agree that architecture is needed. I just question >whether it belongs in a working group like [seamoby]. It would >seem to be more appropriate at the area directorate level, >or probably better within a group like the IAB. I wonder if >there should be an [iawg]. We'd need some wild-eyed masochists >as chairs, I reckon. > May I quote from http://www.ietf.org/overview.html? >The Internet Engineering Task Force (IETF) is a large open international >community of network designers, operators, vendors, and >researchers concerned with the evolution of the Internet architecture and the ^^^^^^^^^^^^ >smooth operation of the Internet. It is open to any >interested individual. Notice the word "architecture" in the above? Anybody coming into the IETF as a newbie who depended on this page to tell them what the IETF actually does would assume that IETF was already concerned about the Internet architecture. In fact, whether we (the IETF) like it or not, there are other groups outside the IETF that are taking IETF protocols and doing architecture with them. In many cases, this architecture will more likely than not cause a major change in the Internet as we know it, especially if the future looks like millions of IPv6 mobile nodes. The resulting Internet will probably not look anything like the Internet we know and love, because the people doing the architecture come from a background that does not value open systems and does not want to enable a proliferation of services. The IAB, IMHO, has completely and totally failed to recognize this challenge. Working groups/BOFs have been fumbling towards a solution (AAA WG, Middlebox BOF), but the IETF as a whole has, as yet, not recognized the threat to the Internet architecture by the *lack* of any serious consideration of architecture. That said, there is a need for balance, and going in the direction of rigid architectures ala a bell-shaped process that constrains protocol development is also not the right direction. And, working groups operate by concensus, so unless the working group members agree that architecture is important, it won't get done. As for seamoby, I think having some kind of architecture just so we know what we are talking about is important. Again, the issue is balance. I don't think the architecture has to be all-encompassing, though having some kind of global view of how complex networking systems work is important. jak From owner-seamoby@diameter.org Wed Apr 11 17:32:24 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA03777 for ; Wed, 11 Apr 2001 17:32:22 -0400 (EDT) Received: (qmail 20375 invoked by alias); 11 Apr 2001 22:21:10 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 20369 invoked by uid 200); 11 Apr 2001 22:21:09 -0000 Received: (qmail 20363 invoked from network); 11 Apr 2001 22:21:06 -0000 Received: from c007-h012.c007.snv.cp.net (HELO c007.snv.cp.net) (209.228.33.219) by c900656-a.plstn1.sfba.home.com with SMTP; 11 Apr 2001 22:21:06 -0000 Received: (cpmta 27837 invoked from network); 11 Apr 2001 14:30:29 -0700 Received: from dsl-64-193-0-129.telocity.com (HELO philneum) (64.193.0.129) by smtp.telocity.com (209.228.33.219) with SMTP; 11 Apr 2001 14:30:29 -0700 X-Sent: 11 Apr 2001 21:30:29 GMT Message-ID: <006d01c0c2ce$7e2b6ac0$6501a8c0@philneum> Reply-To: "Phil Neumiller" From: "Phil Neumiller" To: "Charles E. Perkins" Cc: References: <200104111823.LAA12747@heliopolis.eng.sun.com> <15060.43262.631464.956252@thomasm-u1.cisco.com> <001d01c0c2c4$3029d3c0$6501a8c0@philneum> <3AD4C34E.53E4F6A5@iprg.nokia.com> Subject: Re: [seamoby] IETF Architecture Work (RANT) Date: Wed, 11 Apr 2001 16:29:22 -0500 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-seamoby@diameter.org Precedence: bulk > If you think there are architectural issues that need attention, > can you say what they are? I really don't need rocket science to explain this and this will probably will offend some folks and maker others happy... I guess one big one is as follows: the IETF seems to be good at solving problems at the protocol scale, i.e. I need to transport data of type X between boxes of type Y with bearer characteristics Z and signalling characteristics Q. Which is fine for some things. It does not handle well at all, other SDO's coming into the IETF with their own stove-pipe architectures and expecting the IETF to work really hard to preserve or build towards those transient architectures. The IETF should be in a good position to influence others to adopt the architecture of the global Interent rather than be pandering to the voices of whichever group can send the most bodies to a WG list or microphone (one way to gain consensus is to outnumber your adversaries - Cisco comes to mind!!). The global internet is hierarchical in the DNS systems and the way prefixes are aggragated, peer-to-peer with respect to IP transport, and client server with respect to DNS and the interior / exterior gateway protocol relationships of edge versus core. It would seem that this particular way of arranging routers has proven itself a viable architecture with planetary scalability, albeit with some very serious growing pains that it is still battling daily. At one time it was fashionable to say "Apple won" with respect to the way Microsoft kept stealing (I mean succesfully marketing) everything the Mac did. Is it not time to say the same about the Internet architecture? CONCLUSION of RANT (we can only hope!) The INTERNET WON! Now, if you build a system, you probably want to take a close look at the arrangement of its constituent boxes and sort of make sure they are arranged in a manner consistent with the IP routers that constitute the global Internet (and I am sure that Cisco, Redback, etc) would tend to agree with this view! -pdn (Then again... I could be dead wrong!) From owner-seamoby@diameter.org Wed Apr 11 19:16:40 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA04842 for ; Wed, 11 Apr 2001 19:16:40 -0400 (EDT) Received: (qmail 23466 invoked by alias); 12 Apr 2001 00:05:11 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 23460 invoked by uid 200); 12 Apr 2001 00:05:10 -0000 Received: (qmail 23455 invoked from network); 12 Apr 2001 00:05:09 -0000 Received: from out1.prserv.net (HELO prserv.net) (32.97.166.31) by c900656-a.plstn1.sfba.home.com with SMTP; 12 Apr 2001 00:05:09 -0000 Received: from [32.101.227.75] (slip-32-101-227-75.ca.us.prserv.net[32.101.227.75]) by prserv.net (out1) with ESMTP id <2001041123150320100jcq6he>; Wed, 11 Apr 2001 23:15:04 +0000 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Sender: ahmrphd@pop3.attglobal.net Message-Id: In-Reply-To: <006d01c0c2ce$7e2b6ac0$6501a8c0@philneum> References: <200104111823.LAA12747@heliopolis.eng.sun.com> <15060.43262.631464.956252@thomasm-u1.cisco.com> <001d01c0c2c4$3029d3c0$6501a8c0@philneum> <3AD4C34E.53E4F6A5@iprg.nokia.com> Date: Wed, 11 Apr 2001 16:11:21 -0700 To: "Phil Neumiller" , "Charles E. Perkins" From: Arthur Ross Subject: Re: [seamoby] IETF Architecture Work (RANT) Cc: Sender: owner-seamoby@diameter.org Precedence: bulk At 14:29 -0700 04/11/2001, Phil Neumiller wrote: > >The INTERNET WON! Now, if you build a system, you probably >want to take a close look at the arrangement of its constituent boxes >and sort of make sure they are arranged in a manner consistent with >the IP routers that constitute the global Internet (and I am sure that >Cisco, Redback, etc) would tend to agree with this view! > >-pdn (Then again... I could be dead wrong!) Au contraire Phil ... I think you are dead right. Echoing what I said in my letter to the WSJ last week ("Readers Respond" to the Journal's "Capital" column on March 29 re spectrum auctions), I am DELIGHTED that this discussion is being floated in a public, deliberative forum that is well-known for thouroughly thrashing out the technical issues. The notion of overlaying IP somehow on the 3GPPx PSTN-centric (Bell-shaped?) architectures (SS7, HLR, VLR, etc.) has always seemed to me obviously inappropriate, bordering on insane. One can only conclude that the potentially lucrative, vertically-integrated services envisioned by the auction winners motivate the obviously inappropriate architectural models. These discussions of paging, context transfer, etc, have been suffering from big-time disconnect of the implicit models brought by the participants from their various disjoint universes. This debate on requirements has, I think, been very healthy in that it has been uncovering & airing these implicit, inconsistent world views. As you say, the underlying conceptual model (note my careful choice of words - not necessarily an "architecture") needs to be confronted. I wholeheartedly support the notion of formal definition. This might entail only identification of the functional entities, and a minimal set of assumptions about their interconnection rules and properties. But it is needed. The obvious, stunning, global success of IP stems, in large part, from the EXTREMELY SIMPLE underlying conceptual model. That model needs to be mobile-ized, while retaining that underlying minimalist philosophy. I probably don't need to tell anyone that the outcome of this will have ENORMOUS consequences for the business of wireless telecom. WW-III(G, that is) was not really the trans-atlantic chip rate, modulation & coding skirmish, which ended in a stalemate; the real WW-III will be this - the IP-centric world view versus the PSTN-centric world view. -- Regards, -- Arthur From owner-seamoby@diameter.org Thu Apr 12 02:22:39 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA23806 for ; Thu, 12 Apr 2001 02:22:38 -0400 (EDT) Received: (qmail 28406 invoked by alias); 12 Apr 2001 07:11:42 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 28400 invoked by uid 200); 12 Apr 2001 07:11:42 -0000 Received: (qmail 28395 invoked from network); 12 Apr 2001 07:11:40 -0000 Received: from mgw-x2.nokia.com (131.228.20.22) by c900656-a.plstn1.sfba.home.com with SMTP; 12 Apr 2001 07:11:40 -0000 Received: from esvir02nok.nokia.com (esvir02nokt.ntc.nokia.com [172.21.143.34]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f3C6LhS22882 for ; Thu, 12 Apr 2001 09:21:43 +0300 (EET DST) Received: from esebh24nok.ntc.nokia.com (unverified) by esvir02nok.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Thu, 12 Apr 2001 09:21:36 +0300 Received: by esebh24nok with Internet Mail Service (5.5.2652.78) id ; Thu, 12 Apr 2001 09:21:02 +0300 Message-ID: <01D91AFB08B6D211BFD00008C7EABAE10680AD13@eseis04nok> From: john.loughney@nokia.com To: neumiller@telocity.com Cc: seamoby@cdma-2000.org Subject: RE: [seamoby] IETF Architecture Work (RANT) Date: Thu, 12 Apr 2001 09:21:00 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-seamoby@diameter.org Precedence: bulk Phil, > If there was EVER a time for the IETF > to sincerely start documentings is architecture work (which > it is doing a lot of these days under the covers) it is now. I'd definately vote against this. I think that other SDOs become fixed into their architectural view and stagnate. Also, it also implies that there is a correct way to do things. IP technologies have been very successful because they have focused on the interoperability of the protocols, not on the architecture. The IETF does provide architecure pieces for certain protocol sets, but anything larger, I fear would be doomed to failure. br, John From owner-seamoby@diameter.org Thu Apr 12 06:56:52 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA25804 for ; Thu, 12 Apr 2001 06:56:51 -0400 (EDT) Received: (qmail 31613 invoked by alias); 12 Apr 2001 11:45:35 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 31607 invoked by uid 200); 12 Apr 2001 11:45:34 -0000 Received: (qmail 31602 invoked from network); 12 Apr 2001 11:45:32 -0000 Received: from mgw-x3.nokia.com (131.228.20.26) by c900656-a.plstn1.sfba.home.com with SMTP; 12 Apr 2001 11:45:32 -0000 Received: from esvir07nok.ntc.nokia.com (esvir07nokt.ntc.nokia.com [172.21.143.39]) by mgw-x3.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f3CAtpH07478 for ; Thu, 12 Apr 2001 13:55:51 +0300 (EET DST) Received: from esebh24nok.ntc.nokia.com (unverified) by esvir07nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Thu, 12 Apr 2001 13:55:29 +0300 Received: by esebh24nok with Internet Mail Service (5.5.2652.78) id ; Thu, 12 Apr 2001 13:53:49 +0300 Message-ID: <01D91AFB08B6D211BFD00008C7EABAE10680AD1F@eseis04nok> From: john.loughney@nokia.com To: seamus@bit-net.com Cc: seamoby@diameter.org Subject: RE: [seamoby] Response of Mobile Operator to Request for Info on Re alistic Paging Date: Thu, 12 Apr 2001 13:52:53 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-seamoby@diameter.org Precedence: bulk Hi Jim, > Not sure how to do this constructively yet. But I do think > the HLR/VLR for 3GPP2 and 3GPP are in fact in the way of IP > PDN and not the right models to assume for context xfr, > complete handoff (even if done at layer 2) for a "FULL IP Network" > (seems ALL-IP has beome a marketing term that is at best confusing > to the public when looking at what it means). Likewise for HSS too. Thinking about the 3GPP case, if one were to implement a 'pure' or full IP RAN, you would have to have a connection to the HSS (HLR) / AAA server. The HLR/HSS is essentially a subscriber database, which is using MAP & DIAMETER currently for different function. On inter-RAN handovers, the HSS doesn't need to be contacted & the SGSN is handling the billing. Looking towards the future, I think that we will see most (if not all) the HSS interfaces moving to DIAMETER. I'm not going to hazard a guess at this, as this will be up to the Operators, who are sometimes fickle ... but I don't think that it is unreasonable to plan for this already. Anyhow, I don't think that there will be such a thing as 'full context transfer' because different radio technologies and different service providers will support different things. I'm thinking that CT will be a framework to transport blobs of data around. In 3G networks, header compression, qos & security might be the first interesting parameters to transport around, but that doesn't mean that there isn't more than that. best regards, John From owner-seamoby@diameter.org Thu Apr 12 07:09:07 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA26294 for ; Thu, 12 Apr 2001 07:09:07 -0400 (EDT) Received: (qmail 32156 invoked by alias); 12 Apr 2001 11:57:40 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 32151 invoked by uid 200); 12 Apr 2001 11:57:40 -0000 Received: (qmail 32146 invoked from network); 12 Apr 2001 11:57:38 -0000 Received: from hoemail1.lucent.com (HELO hoemlsrv.firewall.lucent.com) (192.11.226.161) by c900656-a.plstn1.sfba.home.com with SMTP; 12 Apr 2001 11:57:38 -0000 Received: from hoemlsrv.firewall.lucent.com (localhost [127.0.0.1]) by hoemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id HAA04149 for ; Thu, 12 Apr 2001 07:07:36 -0400 (EDT) Received: from uk0006exch001h.wins.lucent.com (h135-86-160-150.lucent.com [135.86.160.150]) by hoemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id HAA04119 for ; Thu, 12 Apr 2001 07:07:36 -0400 (EDT) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2650.21) id ; Thu, 12 Apr 2001 12:07:35 +0100 Message-ID: <976F7C55E3B2D111A0720008C728549C097CC38B@en0060exch001u.uk.lucent.com> From: "Casati, Alessio \(Alessio\)" To: "'john.loughney@nokia.com'" , seamus@bit-net.com Cc: seamoby@diameter.org Subject: RE: [seamoby] Response of Mobile Operator to Request for Info on Re alistic Paging Date: Thu, 12 Apr 2001 12:07:25 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-seamoby@diameter.org Precedence: bulk * I'm *thinking that CT will be a framework to transport blobs of data *around. * I would agree. A framework to do that fast and safely Inter- and intra-domain. From owner-seamoby@diameter.org Thu Apr 12 07:17:16 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA26425 for ; Thu, 12 Apr 2001 07:17:16 -0400 (EDT) Received: (qmail 32724 invoked by alias); 12 Apr 2001 12:06:15 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 32718 invoked by uid 200); 12 Apr 2001 12:06:15 -0000 Received: (qmail 32713 invoked from network); 12 Apr 2001 12:06:13 -0000 Received: from c007-h014.c007.snv.cp.net (HELO c007.snv.cp.net) (209.228.33.221) by c900656-a.plstn1.sfba.home.com with SMTP; 12 Apr 2001 12:06:13 -0000 Received: (cpmta 22404 invoked from network); 12 Apr 2001 04:15:42 -0700 Received: from unknown (HELO philneum) (64.193.0.129) by smtp.telocity.com (209.228.33.221) with SMTP; 12 Apr 2001 04:15:42 -0700 X-Sent: 12 Apr 2001 11:15:42 GMT Message-ID: <00d001c0c341$c7f84100$6501a8c0@philneum> Reply-To: "Phil Neumiller" From: "Phil Neumiller" To: "Casati, Alessio \(Alessio\)" , , Cc: References: <976F7C55E3B2D111A0720008C728549C097CC38B@en0060exch001u.uk.lucent.com> Subject: Re: [seamoby] Response of Mobile Operator to Request for Info on Re alistic Paging Date: Thu, 12 Apr 2001 06:14:38 -0500 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-seamoby@diameter.org Precedence: bulk Ok then, allow me to play devil's advocate. Its done. Why not use TCP, UDP, or SCTP depending on your application and transport lumps of Type, Length, Value (TLV) fields (and just for giggles give the user a choice of parseable ASCII (Unicode) or binary. Q.E.D. End of CT work, we can all go home? Is this all there is it to it? ----- Original Message ----- From: "Casati, Alessio (Alessio)" To: ; Cc: Sent: Thursday, April 12, 2001 6:07 AM Subject: RE: [seamoby] Response of Mobile Operator to Request for Info on Re alistic Paging > * I'm > *thinking that CT will be a framework to transport blobs of data > *around. > * > > > I would agree. A framework to do that fast and safely > Inter- and intra-domain. > From owner-seamoby@diameter.org Thu Apr 12 07:23:48 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA26508 for ; Thu, 12 Apr 2001 07:23:47 -0400 (EDT) Received: (qmail 842 invoked by alias); 12 Apr 2001 12:12:28 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 836 invoked by uid 200); 12 Apr 2001 12:12:28 -0000 Received: (qmail 830 invoked from network); 12 Apr 2001 12:12:24 -0000 Received: from mgw-x3.nokia.com (131.228.20.26) by c900656-a.plstn1.sfba.home.com with SMTP; 12 Apr 2001 12:12:24 -0000 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x3.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f3CBMiH21830 for ; Thu, 12 Apr 2001 14:22:44 +0300 (EET DST) Received: from esebh24nok.ntc.nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Thu, 12 Apr 2001 14:22:20 +0300 Received: by esebh24nok with Internet Mail Service (5.5.2652.78) id ; Thu, 12 Apr 2001 14:21:53 +0300 Message-ID: <01D91AFB08B6D211BFD00008C7EABAE10680AD24@eseis04nok> From: john.loughney@nokia.com To: neumiller@telocity.com Cc: seamoby@diameter.org Subject: RE: [seamoby] Response of Mobile Operator to Request for Info on Re alistic Paging Date: Thu, 12 Apr 2001 14:21:50 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-seamoby@diameter.org Precedence: bulk Hi Phil, > Ok then, allow me to play devil's advocate. Its done. Why not use > TCP, UDP, or SCTP depending on your application and transport > lumps of Type, Length, Value (TLV) fields (and just for giggles give > the user a choice of parseable ASCII (Unicode) or binary. Q.E.D. > End of CT work, we can all go home? Is this all there is it to it? If we are having a protocol running on top of a transport protocol, we need to define the blobs. I think that we may want to define different modes (proactive transfer, reactive trasfer); error messages & error situations, ability to 'broadcast' the blobs (to more than one AR); security requirements. Some questions: o Will we ever have to do a hop-by-hop operation? o Do we want to build some inteligence into the system, some sort of discovery protocol? o Should we define some sort of extensibility mechanism? o How to handle situations when one node only understands one type of QoS (for example) but the destination node only understands another type? Lots more as well. John From owner-seamoby@diameter.org Thu Apr 12 10:45:14 2001 Received: from charizard.diameter.org ([24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA01790 for ; Thu, 12 Apr 2001 10:45:13 -0400 (EDT) Received: (qmail 3771 invoked by alias); 12 Apr 2001 15:33:45 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 3765 invoked by uid 200); 12 Apr 2001 15:33:45 -0000 Received: (qmail 3760 invoked from network); 12 Apr 2001 15:33:44 -0000 Received: from www.bit-net.com (HELO mail.users.bit-net.com) (208.146.132.4) by c900656-a.plstn1.sfba.home.com with SMTP; 12 Apr 2001 15:33:44 -0000 Received: from localhost by mail.users.bit-net.com; (5.65v3.2/1.1.8.2/30Jul96-0143PM) id AA22094; Thu, 12 Apr 2001 10:43:20 -0400 Date: Thu, 12 Apr 2001 10:43:20 -0400 (EDT) From: Jim Bound To: "Charles E. Perkins" Cc: Phil Neumiller , seamoby@cdma-2000.org Subject: Re: [seamoby] IETF Architecture Work (RANT) In-Reply-To: <3AD4C34E.53E4F6A5@iprg.nokia.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-seamoby@diameter.org Precedence: bulk Charlie, I strongly disagree that the architecture belongs in the Area Director or IAB. That is a very bad idea. Direction statements are fine. But good architecture is a very serious process to accomplish what Phil stated so that multiple solutions can be attained. It also may permit a more laizzes-faire approach to implementation with interoperability the only goal from our specs in this and other working groups in the IETF. If an architecture draft or picture will help us declare and put on the table all our assumptions then its worth its weight in gold to this working group. One reason for failure and drafts numbers greater than lets xxxxx-05.txt is precisely what Phil stated and I would add to that the working group members were operating on different assumptions which is death to a clear consensus solution. /jim On Wed, 11 Apr 2001, Charles E. Perkins wrote: > > Hello Phil, > > If you think there are architectural issues that need attention, > can you say what they are? > > If you can say what they are, do you think there is value in > bringing the list items to the attention of the IAB? > > > I am sending this rant to SeaMoby since I think its important to the > > whole WG. I am basing this off some threads I have seen go astray > > due to a lack of a common set of terminology and assumptions (i.e. > > stuff that can often be provided by an architecture). > > It can also be provided by a terminology document and a requirements > document. > > > I think when the IETF was young it was probably like working for a > > startup. You can't tolerate people that aren't good so they are immediately > > gotten moved off the critical path and you keep the top talent that buys into > > a common vision going. In these situations, architecture is done implicitly, > > its almost a Zen thing. > > But four out of five startups fail. We need to keep the failure average > lower in the IETF, I reckon. > > > Today, we have a different IETF with lots of different visions, interests, > > and time frames. There are only a few people that can catch the "gestalt" of > > an entire WG let alone multiple WGs and other SDOs that are coming > > into the IETF to "influence" it. If there was EVER a time for the IETF > > to sincerely start documentings is architecture work (which it is doing a > > lot of these days under the covers) it is now. > > That's because the Internet is huge enough to encompass a > major diversity of applications and utilizations. I just hope > we can avoid the tragedy of the commons. Sometimes it seems > inevitable, as clever people make local optimizations that > damage the overall good. Architecture with teeth could help > in this regard. But the market can dump any solution it > has not been groomed to prefer, architecture or not. Examples > abound. Worse, if the architecture has teeth, and it's not > great according to your definition, then you won't like the > teeth marks. > > .......... > > > If it were me and Peter coding it... wait a minute, we > > finished this stuff in 1998! > > But coding isn't architecture. And I know you didn't say > it was. But your comment here would be more appropriate in > a discussion about why the IETF should NOT DO architecture. > > I absolutely agree that architecture is needed. I just question > whether it belongs in a working group like [seamoby]. It would > seem to be more appropriate at the area directorate level, > or probably better within a group like the IAB. I wonder if > there should be an [iawg]. We'd need some wild-eyed masochists > as chairs, I reckon. > > Regards, > Charlie P. > From owner-seamoby@diameter.org Thu Apr 12 10:55:24 2001 Received: from charizard.diameter.org ([24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA02017 for ; Thu, 12 Apr 2001 10:55:23 -0400 (EDT) Received: (qmail 4284 invoked by alias); 12 Apr 2001 15:44:14 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 4278 invoked by uid 200); 12 Apr 2001 15:44:14 -0000 Received: (qmail 4273 invoked from network); 12 Apr 2001 15:44:13 -0000 Received: from www.bit-net.com (HELO mail.users.bit-net.com) (208.146.132.4) by c900656-a.plstn1.sfba.home.com with SMTP; 12 Apr 2001 15:44:13 -0000 Received: from localhost by mail.users.bit-net.com; (5.65v3.2/1.1.8.2/30Jul96-0143PM) id AA02204; Thu, 12 Apr 2001 10:54:05 -0400 Date: Thu, 12 Apr 2001 10:54:04 -0400 (EDT) From: Jim Bound To: john.loughney@nokia.com Cc: seamoby@diameter.org Subject: RE: [seamoby] Response of Mobile Operator to Request for Info on Re alistic Paging In-Reply-To: <01D91AFB08B6D211BFD00008C7EABAE10680AD1F@eseis04nok> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-seamoby@diameter.org Precedence: bulk Hi John, I agree and full context may not be operationally possible. My issues is the req of SS7 gunk to speak with HSS and GTP in 3G. I want them dead. Sorry. Of course the functions are needed. I believe the function HSS provides is almost all but elimnated with UMTS evolution too and I think our seamoby thinking process should eliminate them in our resultant to get to real running code and message to the public and telcos. /jim On Thu, 12 Apr 2001 john.loughney@nokia.com wrote: > Hi Jim, > > > Not sure how to do this constructively yet. But I do think > > the HLR/VLR for 3GPP2 and 3GPP are in fact in the way of IP > > PDN and not the right models to assume for context xfr, > > complete handoff (even if done at layer 2) for a "FULL IP Network" > > (seems ALL-IP has beome a marketing term that is at best confusing > > to the public when looking at what it means). Likewise for HSS too. > > Thinking about the 3GPP case, if one were to implement a 'pure' or > full IP RAN, you would have to have a connection to the HSS (HLR) / > AAA server. The HLR/HSS is essentially a subscriber database, > which is using MAP & DIAMETER currently for different function. > On inter-RAN handovers, the HSS doesn't need to be contacted & > the SGSN is handling the billing. > > Looking towards the future, I think that we will see most (if not all) > the HSS interfaces moving to DIAMETER. I'm not going to hazard > a guess at this, as this will be up to the Operators, who are > sometimes fickle ... but I don't think that it is unreasonable to > plan for this already. > > Anyhow, I don't think that there will be such a thing as > 'full context transfer' because different radio technologies and > different service providers will support different things. I'm > thinking that CT will be a framework to transport blobs of data > around. > > In 3G networks, header compression, qos & security might be the first > interesting parameters to transport around, but that doesn't > mean that there isn't more than that. > > best regards, > John > From owner-seamoby@diameter.org Thu Apr 12 11:27:09 2001 Received: from charizard.diameter.org ([24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA02721 for ; Thu, 12 Apr 2001 11:26:43 -0400 (EDT) Received: (qmail 5320 invoked by alias); 12 Apr 2001 16:15:14 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 5314 invoked by uid 200); 12 Apr 2001 16:15:13 -0000 Received: (qmail 5309 invoked from network); 12 Apr 2001 16:15:07 -0000 Received: from sj-msg-core-3.cisco.com (171.70.157.152) by c900656-a.plstn1.sfba.home.com with SMTP; 12 Apr 2001 16:15:07 -0000 Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-3.cisco.com (8.9.3/8.9.1) with ESMTP id IAA14650; Thu, 12 Apr 2001 08:23:11 -0700 (PDT) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id ADY03314; Thu, 12 Apr 2001 08:24:29 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id IAA07783; Thu, 12 Apr 2001 08:24:29 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15061.51373.148675.574019@thomasm-u1.cisco.com> Date: Thu, 12 Apr 2001 08:24:29 -0700 (PDT) To: john.loughney@nokia.com Cc: seamus@bit-net.com, seamoby@diameter.org Subject: RE: [seamoby] Response of Mobile Operator to Request for Info on Re alistic Paging In-Reply-To: <01D91AFB08B6D211BFD00008C7EABAE10680AD1F@eseis04nok> References: <01D91AFB08B6D211BFD00008C7EABAE10680AD1F@eseis04nok> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-seamoby@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit The main problem with faithfully reproducing an HLR-like thing in IP is that the PSTN does not make a distinction between data access and call control. In fact, they are one and the same along with all of the baggage that implies. The most harmful implication of this architecture is that call control is a pretty complicated beast, and at its heart there is the requirement for very complex user information in the form of some sort of database. Generally speaking, defining and transporting a complex database schema is an extremely difficult thing to do and leads to ossification of applications because it violates the localization principal. In the wireless PSTN that was pretty unavoidable given the way that MSC's are connected together. IP, on the other hand, is far more flexible: there is no reason whatsover why I can't localize most of the processing (user preferences, etc) and only export the few bits and pieces as is absolutely necessary (like, say, data access admission control, QoS limits, etc). What I sincerely hope we are not headed for -- and I am afraid some people think we are -- is the misuse of AAA as a database transport protocol for *call control*, and CT as a means of transfering call control information (HLR records) between SIP proxies and/or UA's. That way leads to Global Database Standards and service stagnation. It would be far simpler to keep those sort of relationships local between my UA and my home proxies which already have a vested interest to work with each other that the visited network does not. ObSEAMOBYRequirements: o The protocol will only focus on transfering context that pertains to the reestablishment of equivalent data access on the CT peer. Mike john.loughney@nokia.com writes: > Thinking about the 3GPP case, if one were to implement a 'pure' or > full IP RAN, you would have to have a connection to the HSS (HLR) / > AAA server. The HLR/HSS is essentially a subscriber database, > which is using MAP & DIAMETER currently for different function. > On inter-RAN handovers, the HSS doesn't need to be contacted & > the SGSN is handling the billing. > > Looking towards the future, I think that we will see most (if not all) > the HSS interfaces moving to DIAMETER. I'm not going to hazard > a guess at this, as this will be up to the Operators, who are > sometimes fickle ... but I don't think that it is unreasonable to > plan for this already. > > Anyhow, I don't think that there will be such a thing as > 'full context transfer' because different radio technologies and > different service providers will support different things. I'm > thinking that CT will be a framework to transport blobs of data > around. > > In 3G networks, header compression, qos & security might be the first > interesting parameters to transport around, but that doesn't > mean that there isn't more than that. > > best regards, > John From owner-seamoby@diameter.org Thu Apr 12 11:44:13 2001 Received: from charizard.diameter.org ([24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA03065 for ; Thu, 12 Apr 2001 11:44:10 -0400 (EDT) Received: (qmail 6189 invoked by alias); 12 Apr 2001 16:33:10 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 6183 invoked by uid 200); 12 Apr 2001 16:33:09 -0000 Received: (qmail 6176 invoked from network); 12 Apr 2001 16:33:08 -0000 Received: from mercury.sun.com (192.9.25.1) by c900656-a.plstn1.sfba.home.com with SMTP; 12 Apr 2001 16:33:08 -0000 Received: from heliopolis.eng.sun.com ([152.70.1.39]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA18862; Thu, 12 Apr 2001 08:38:40 -0700 (PDT) Received: from srmtv29a (srmtv29a [152.70.1.41]) by heliopolis.eng.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id IAA03609; Thu, 12 Apr 2001 08:39:50 -0700 (PDT) Message-Id: <200104121539.IAA03609@heliopolis.eng.sun.com> Date: Thu, 12 Apr 2001 08:39:50 -0700 (PDT) From: James Kempf Reply-To: James Kempf Subject: RE: [seamoby] IETF Architecture Work (RANT) To: neumiller@telocity.com, john.loughney@nokia.com Cc: seamoby@cdma-2000.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: E5VxjpK2F/4UMxvPQ8VCBA== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 sun4u sparc Sender: owner-seamoby@diameter.org Precedence: bulk John, I suggest you look at http://www.ietf.org/overview.html. This page is what the IETF says it does. Architecture is in the first sentence. According to this, IETF *already* does architecture. So it is not a matter of whether we should start doing it or not. The problem is, we are doing a lousy job of it. And, as I tried to point out in my posting several days ago, other groups are taking IETF protocols and doing architecture with them that is directly contrary to the Internet architecture as it currently stands. So, we are by default letting other SDOs do architecture with our protocols that will end up screwing the Internet in the end. jak >Delivered-To: seamoby-list@charizard.diameter.org >From: john.loughney@nokia.com >To: neumiller@telocity.com >Cc: seamoby@cdma-2000.org >Subject: RE: [seamoby] IETF Architecture Work (RANT) >Date: Thu, 12 Apr 2001 09:21:00 +0300 > >Phil, > >> If there was EVER a time for the IETF >> to sincerely start documentings is architecture work (which >> it is doing a lot of these days under the covers) it is now. > >I'd definately vote against this. I think that other SDOs >become fixed into their architectural view and stagnate. > >Also, it also implies that there is a correct way to do >things. IP technologies have been very successful because >they have focused on the interoperability of the protocols, >not on the architecture. > >The IETF does provide architecure pieces for certain >protocol sets, but anything larger, I fear would be >doomed to failure. > >br, >John From owner-seamoby@diameter.org Thu Apr 12 11:57:52 2001 Received: from charizard.diameter.org ([24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA03335 for ; Thu, 12 Apr 2001 11:57:51 -0400 (EDT) Received: (qmail 6844 invoked by alias); 12 Apr 2001 16:46:45 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 6838 invoked by uid 200); 12 Apr 2001 16:46:44 -0000 Received: (qmail 6833 invoked from network); 12 Apr 2001 16:46:43 -0000 Received: from c007-h015.c007.snv.cp.net (HELO c007.snv.cp.net) (209.228.33.222) by c900656-a.plstn1.sfba.home.com with SMTP; 12 Apr 2001 16:46:43 -0000 Received: (cpmta 5848 invoked from network); 12 Apr 2001 08:56:12 -0700 Received: from unknown (HELO philneum) (64.193.0.129) by smtp.telocity.com (209.228.33.222) with SMTP; 12 Apr 2001 08:56:12 -0700 X-Sent: 12 Apr 2001 15:56:12 GMT Message-ID: <017f01c0c368$f7daca60$6501a8c0@philneum> Reply-To: "Phil Neumiller" From: "Phil Neumiller" To: "James Kempf" , Cc: References: <200104121539.IAA03609@heliopolis.eng.sun.com> Subject: Re: [seamoby] IETF Architecture Work (RANT) Date: Thu, 12 Apr 2001 10:55:09 -0500 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-seamoby@diameter.org Precedence: bulk // EVEN MORE RANTING Even if we don't call it architecture, what the WGs should be doing is improving the global Internet for mobility and not reacting to other SDOs that show up in numbers at WG meetings and demand that the IETF do things for them. I don't get why the IETF has been so responsive to these other SDOs. Clearly, this has been a huge distraction for the MIP WG over the last few years. Let's EXTEND the global Internet to support the best wireless mobility on the planet and let other SDOs worry about supporting their legacy systems. WHY is the MIP charter so dominated with work from the 3GXXrs I must ask? They are not the only customer, in fact with the advent of "cheap" wireless, which most people are starting to see the advantages of (I can only hope), cellular architectures as built today and the business models that support them will be deconstructed. It seems much safer to bet on the Internet than to bet on any air interface technology or set of standards that will be obsolete in a few years. The Internet has much more momentum and evolution and we need to continue to improve the beast and not get side tracked by fast talking TIA, ETSI, IMT, ISO, IEEE, or SIG de jours representation. // END rant ----- Original Message ----- From: "James Kempf" > I suggest you look at http://www.ietf.org/overview.html. This > page is what the IETF says it does. Architecture is in the first sentence. > According to this, IETF *already* does architecture. So it is not > a matter of whether we should start doing it or not. > > The problem is, we are doing a lousy job of it. And, as I tried > to point out in my posting several days ago, other groups are taking > IETF protocols and doing architecture with them that is directly > contrary to the Internet architecture as it currently stands. From owner-seamoby@diameter.org Thu Apr 12 13:07:38 2001 Received: from charizard.diameter.org ([24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA05036 for ; Thu, 12 Apr 2001 13:07:37 -0400 (EDT) Received: (qmail 8997 invoked by alias); 12 Apr 2001 17:56:43 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 8992 invoked by uid 200); 12 Apr 2001 17:56:43 -0000 Received: (qmail 8987 invoked from network); 12 Apr 2001 17:56:41 -0000 Received: from unknown (HELO megisto-sql1.megisto.com) (63.113.114.132) by c900656-a.plstn1.sfba.home.com with SMTP; 12 Apr 2001 17:56:41 -0000 Received: by mail.megisto.com with Internet Mail Service (5.5.2650.21) id ; Thu, 12 Apr 2001 13:00:35 -0400 Message-ID: From: Phil Roberts To: "'Phil Neumiller'" Cc: seamoby@cdma-2000.org Subject: RE: [seamoby] IETF Architecture Work (RANT) Date: Thu, 12 Apr 2001 13:00:35 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-seamoby@diameter.org Precedence: bulk > Even if we don't call it architecture, what the WGs should be doing > is improving the global Internet for mobility and not > reacting to other SDOs > that show up in numbers at WG meetings and demand that the IETF > do things for them. I don't get why the IETF has been so responsive > to these other SDOs. Clearly, this has been a huge > distraction for the > MIP WG over the last few years. > The IETF is open to anyone who wants to participate. Surely you're not proposing the IETF register the affiliation of the folks showing up and count the opinions of those who also participate in other SDOs as of less value. What are you proposing? I'm not sure what you see as a distraction for the MIP WG over the last few years. The WG has produced a number of new proposed standard that facilitate deployment in cdma2000 networks. Do you view this as a bad thing? It seems to me they add valuable functionality around MIP that could be used in a number of different settings. From owner-seamoby@diameter.org Thu Apr 12 13:17:02 2001 Received: from charizard.diameter.org ([24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA05238 for ; Thu, 12 Apr 2001 13:17:00 -0400 (EDT) Received: (qmail 8461 invoked by alias); 12 Apr 2001 17:46:52 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 8454 invoked by uid 200); 12 Apr 2001 17:46:52 -0000 Received: (qmail 8449 invoked from network); 12 Apr 2001 17:46:50 -0000 Received: from mailhost.iprg.nokia.com (205.226.5.12) by c900656-a.plstn1.sfba.home.com with SMTP; 12 Apr 2001 17:46:50 -0000 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 JAA29422; Thu, 12 Apr 2001 09:56:20 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f3CGuHt17510; Thu, 12 Apr 2001 09:56:17 -0700 X-mProtect: Thu, 12 Apr 2001 09:56:17 -0700 Nokia Silicon Valley Messaging Protection Received: from charliep.iprg.nokia.com (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(WTS.12.69) smtpdOyHp0W; Thu, 12 Apr 2001 09:56:02 PDT Message-ID: <3AD5DE24.BBA1E334@iprg.nokia.com> Date: Thu, 12 Apr 2001 09:56:04 -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: Phil Neumiller CC: seamoby@cdma-2000.org Subject: Re: [seamoby] IETF Architecture Work (RANT) References: <200104121539.IAA03609@heliopolis.eng.sun.com> <017f01c0c368$f7daca60$6501a8c0@philneum> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-seamoby@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit Hello Phil, Phil Neumiller wrote: > > // EVEN MORE RANTING > > Even if we don't call it architecture, what the WGs should be doing > is improving the global Internet for mobility and not reacting to other SDOs > that show up in numbers at WG meetings and demand that the IETF > do things for them. I don't get why the IETF has been so responsive > to these other SDOs. Clearly, this has been a huge distraction for the > MIP WG over the last few years. Try looking at it the other way. I have something to say about this, since I tried to be very encouraging to get engineeers from the other SDOs involved. Mobile IP has been moderately, but not hugely successful. That is, there have been millions of units deployed, not tens of millions like there should have been. One place where it _could_ be more widely deployed is with new wireless networks, and 3GPP* certainly qualify as standard bodies for new wireless networks. They are IETF customers. Customers are allowed to express their requirements, and technology providers are allowed (in fact, wise) to pay attention to those requirements. Sometimes, the requirements need to be reshaped as the technology providers supply missing technical details to the customers' views of their requirements. I think this is exactly what has been happening in the Mobile IP working group. In fact, instead of characterizing it as a distraction, I should characterize it as a healthy and almost inevitable evolution. The challenge, as always, is to stay involved with the evolutionary process so that we don't get gross mutants that crowd out the more beautiful and desirable species. > Let's EXTEND the global Internet to support the best wireless mobility > on the planet and let other SDOs worry about supporting their legacy > systems. WHY is the MIP charter so dominated with work from the > 3GXXrs I must ask? They are not the only customer, in fact with > the advent of "cheap" wireless, which most people are starting to see > the advantages of (I can only hope), cellular architectures as built today > and the business models that support them will be deconstructed. Seems unlikely to me. A better chance is to get protocols that maintain freedom of choice. If we do that, then operators that make restrictions may lose out to operators that offer services for cheap, and freedom to pick other services according to the desirable Internet end-to-end application model. If we don't make the protocols available, then we won't expedite the development of the networks that offer the freedom. A lot of the recent work engendering [seamoby] and fast handovers in Mobile IPv6 was motivated, at least in part, by inputs from other SDOs. I think we will see a major push towards QoS for some of the same reasons. [digression: anyone see the nasty claims on the cover of the new Wired magazine? -- I guess it means we have more work to do.] > It seems much safer to bet on the Internet than to bet on any air > interface technology or set of standards that will be obsolete in a few > years. The Internet has much more momentum and evolution and > we need to continue to improve the beast and not get side tracked > by fast talking TIA, ETSI, IMT, ISO, IEEE, or SIG de jours > representation. I don't see this as reflecting any reality that I have observed within the IETF recently. And which "SIG" are you referring to? If it's SIGMOBILE, then I have to respectfully but assertively disagree with your characterization. About IEEE, they're not trying to derail our efforts. I might wish they'd leave ad-hoc networking out of their charter, but I don't think that causes them to deserve such a characterization. Regards, Charlie P. From owner-seamoby@diameter.org Thu Apr 12 13:25:25 2001 Received: from charizard.diameter.org ([24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA05450 for ; Thu, 12 Apr 2001 13:25:25 -0400 (EDT) Received: (qmail 9744 invoked by alias); 12 Apr 2001 18:14:25 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 9738 invoked by uid 200); 12 Apr 2001 18:14:25 -0000 Received: (qmail 9733 invoked from network); 12 Apr 2001 18:14:23 -0000 Received: from www.bit-net.com (HELO mail.users.bit-net.com) (208.146.132.4) by c900656-a.plstn1.sfba.home.com with SMTP; 12 Apr 2001 18:14:23 -0000 Received: from localhost by mail.users.bit-net.com; (5.65v3.2/1.1.8.2/30Jul96-0143PM) id AA01211; Thu, 12 Apr 2001 13:24:08 -0400 Date: Thu, 12 Apr 2001 13:24:08 -0400 (EDT) From: Jim Bound To: James Kempf Cc: neumiller@telocity.com, john.loughney@nokia.com, seamoby@cdma-2000.org Subject: RE: [seamoby] IETF Architecture Work (RANT) In-Reply-To: <200104121539.IAA03609@heliopolis.eng.sun.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-seamoby@diameter.org Precedence: bulk > The problem is, we are doing a lousy job of it. And, as I tried > to point out in my posting several days ago, other groups are taking > IETF protocols and doing architecture with them that is directly > contrary to the Internet architecture as it currently stands. I agree and contrary architecture to the Internet will also increase cost of its use and the products built. It will also cause transitions from Catanet principles I for one believe should not be changed without much caution. /jim From owner-seamoby@diameter.org Thu Apr 12 13:38:41 2001 Received: from charizard.diameter.org ([24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA05745 for ; Thu, 12 Apr 2001 13:38:39 -0400 (EDT) Received: (qmail 10588 invoked by alias); 12 Apr 2001 18:25:04 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 10579 invoked by uid 200); 12 Apr 2001 18:25:03 -0000 Received: (qmail 10561 invoked from network); 12 Apr 2001 18:24:55 -0000 Received: from www.bit-net.com (HELO mail.users.bit-net.com) (208.146.132.4) by c900656-a.plstn1.sfba.home.com with SMTP; 12 Apr 2001 18:24:55 -0000 Received: from localhost by mail.users.bit-net.com; (5.65v3.2/1.1.8.2/30Jul96-0143PM) id AA15880; Thu, 12 Apr 2001 13:34:40 -0400 Date: Thu, 12 Apr 2001 13:34:40 -0400 (EDT) From: Jim Bound To: Phil Neumiller Cc: James Kempf , john.loughney@nokia.com, seamoby@cdma-2000.org Subject: Re: [seamoby] IETF Architecture Work (RANT) In-Reply-To: <017f01c0c368$f7daca60$6501a8c0@philneum> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-seamoby@diameter.org Precedence: bulk Phil, I think we are off topic for our goal and my last response to non tech stuff we won't fix the IETF here (but would love to if folks want offline and I am thinking about starting an Internet Warriors private mail list). But I don't agree that we can ignore 3Gxxx the target market for 3G is in the trillion of revenue streams. There is a business and technical case to make sure MIPv6 works very well with 3G and micromobility for MIPv6 (Seamoby anyone ???). I also believe we need to make sure the wireless solutions work with the wireline Internet (why we must do architecture) so when I am roaming with my PDA on the streets paying 30cents per/min when I walk in my house to my wireless access point I can jump on my wireline 8cents per/min charge with "seamless handoff". So I view the reason to treat 3G very important is because its our wireless pragmatic input, instead of wireless papers on theory or the existing wireless debaucle in the U.S. and North America. It will also be the first significant IPv6 deployed base and I admit my biases there for those who don't know me. /jim On Thu, 12 Apr 2001, Phil Neumiller wrote: > // EVEN MORE RANTING > > Even if we don't call it architecture, what the WGs should be doing > is improving the global Internet for mobility and not reacting to other SDOs > that show up in numbers at WG meetings and demand that the IETF > do things for them. I don't get why the IETF has been so responsive > to these other SDOs. Clearly, this has been a huge distraction for the > MIP WG over the last few years. > > Let's EXTEND the global Internet to support the best wireless mobility > on the planet and let other SDOs worry about supporting their legacy > systems. WHY is the MIP charter so dominated with work from the > 3GXXrs I must ask? They are not the only customer, in fact with > the advent of "cheap" wireless, which most people are starting to see > the advantages of (I can only hope), cellular architectures as built today > and the business models that support them will be deconstructed. > > It seems much safer to bet on the Internet than to bet on any air > interface technology or set of standards that will be obsolete in a few > years. The Internet has much more momentum and evolution and > we need to continue to improve the beast and not get side tracked > by fast talking TIA, ETSI, IMT, ISO, IEEE, or SIG de jours > representation. > > // END rant > > ----- Original Message ----- > From: "James Kempf" > > > > I suggest you look at http://www.ietf.org/overview.html. This > > page is what the IETF says it does. Architecture is in the first sentence. > > According to this, IETF *already* does architecture. So it is not > > a matter of whether we should start doing it or not. > > > > The problem is, we are doing a lousy job of it. And, as I tried > > to point out in my posting several days ago, other groups are taking > > IETF protocols and doing architecture with them that is directly > > contrary to the Internet architecture as it currently stands. > > > From owner-seamoby@diameter.org Thu Apr 12 13:42:32 2001 Received: from charizard.diameter.org ([24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA05812 for ; Thu, 12 Apr 2001 13:42:31 -0400 (EDT) Received: (qmail 10797 invoked by alias); 12 Apr 2001 18:26:38 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 10790 invoked by uid 200); 12 Apr 2001 18:26:38 -0000 Received: (qmail 10776 invoked from network); 12 Apr 2001 18:26:34 -0000 Received: from sj-msg-core-3.cisco.com (171.70.157.152) by c900656-a.plstn1.sfba.home.com with SMTP; 12 Apr 2001 18:26:34 -0000 Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-3.cisco.com (8.9.3/8.9.1) with ESMTP id KAA27103; Thu, 12 Apr 2001 10:35:07 -0700 (PDT) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id ADZ02835; Thu, 12 Apr 2001 10:36:25 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id KAA07801; Thu, 12 Apr 2001 10:36:25 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15061.59289.4630.420030@thomasm-u1.cisco.com> Date: Thu, 12 Apr 2001 10:36:25 -0700 (PDT) To: James Kempf Cc: neumiller@telocity.com, john.loughney@nokia.com, seamoby@cdma-2000.org Subject: RE: [seamoby] IETF Architecture Work (RANT) In-Reply-To: <200104121539.IAA03609@heliopolis.eng.sun.com> References: <200104121539.IAA03609@heliopolis.eng.sun.com> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-seamoby@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit James Kempf writes: > John, > > I suggest you look at http://www.ietf.org/overview.html. This > page is what the IETF says it does. Architecture is in the first sentence. > According to this, IETF *already* does architecture. So it is not > a matter of whether we should start doing it or not. > > The problem is, we are doing a lousy job of it. And, as I tried > to point out in my posting several days ago, other groups are taking > IETF protocols and doing architecture with them that is directly > contrary to the Internet architecture as it currently stands. > > So, we are by default letting other SDOs do architecture with our > protocols that will end up screwing the Internet in the end. "Death of the net, film at 11:00" Oh, I don't think that it's quite that bad. However, the thing I find somewhat disturbing is the underlying assumption that we'd get the architecture *right*. We may, but there a lot of downside if we didn't but was rubber stamped as "The IETF Architecture." Ultimately, there's still a significant amount of room for competing architectures where the market sorts the dead ends out. If we were in monopoly situation I might feel somewhat different, but we aren't. Can I also point out that we might be using the term architecture in different ways? I generally think of "architecture" in the analogous way as to what an architect does when she puts lines on a drawing to build a house. 3GPP, Packetcable, etc, are all in the business of producing those sorts of architectures. Under that definition, the IETF has never done architectures per se. It does have a base level model, set of assumptions, and guiding principles which facilitate protocol development but this isn't really the same; it's more like a guidelines which instruct architects the do's and don't on the net. Sort of like "don't build houses with the roof on the foundation". Mike From owner-seamoby@diameter.org Thu Apr 12 13:45:12 2001 Received: from charizard.diameter.org ([24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA05866 for ; Thu, 12 Apr 2001 13:45:09 -0400 (EDT) Received: (qmail 10860 invoked by alias); 12 Apr 2001 18:27:06 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 10854 invoked by uid 200); 12 Apr 2001 18:27:05 -0000 Received: (qmail 10848 invoked from network); 12 Apr 2001 18:27:03 -0000 Received: from out4.prserv.net (HELO prserv.net) (32.97.166.34) by c900656-a.plstn1.sfba.home.com with SMTP; 12 Apr 2001 18:27:03 -0000 Received: from [32.101.185.160] (slip129-37-43-218.il.us.prserv.net[129.37.43.218]) by prserv.net (out4) with ESMTP id <2001041217365820400puenpe>; Thu, 12 Apr 2001 17:36:59 +0000 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Sender: ahmrphd@pop3.attglobal.net Message-Id: In-Reply-To: <017f01c0c368$f7daca60$6501a8c0@philneum> References: <200104121539.IAA03609@heliopolis.eng.sun.com> Date: Thu, 12 Apr 2001 10:37:08 -0700 To: "Phil Neumiller" , "James Kempf" , From: Arthur Ross Subject: Re: [seamoby] IETF Architecture Work (RANT) Cc: Sender: owner-seamoby@diameter.org Precedence: bulk At 8:55 -0700 04/12/2001, Phil Neumiller wrote: >It seems much safer to bet on the Internet than to bet on any air >interface technology or set of standards that will be obsolete in a few >years. The Internet has much more momentum and evolution and >we need to continue to improve the beast and not get side tracked >by fast talking TIA, ETSI, IMT, ISO, IEEE, or SIG de jours >representation. > Again, right on Phil. To some degree, this argument is short-term versus long-term view. All those folks who have over-sold the "Mobile Internet" to their investors now have to ante-up, and they want at least the appearance of an IETF imprimateur. They will figure out some way of cobbling together something that works ... sortof. They have to, after spending, stupidly, upwards of 110 dB$ on spectrum (and that's only in western Europe). They tried to promote this universal, do-everything service in the wired world: ISDN. It has failed in the retail marketplace, where it makes much more sense. Why anyone thinks it will succeed wireLESS continues to mystify me. We are, I like to think, on the cusp of a golden opportunity, brought about by this collective insanity of the corporate world. For a long time now, I have thought that what we should be having is a very basic discussion on the NATURE of network communication - not so much of the architecture of it, but rather of "What problem(s) are we solving?", or, perhaps more accurately, "What problems CAN be solved?" and "What are the conceptual abstractions of that communication universe?" There is an opportunity to at least try to get this right, while "big telecom" goes off on its ill-advised course. This might include such seemingly childish, naive questions as "What are the entities doing the communicating?" The current mindset is "Handsets/subscriber loops" in the telephonic universe, and "Hosts" in the IP universe. What might they be in Voltaire's "best of all possible worlds"? I have long thought that the real, underlying endpoint entities are neither "handsets" nor "hosts", but something that more nearly resembles a record in a distributed database. The physical embodiment of it could take many forms, but the essential abstraction would be the CONTENT, not the physical realization. It would be logically separate from the embodiment of any communication device. The association of the two would occur as a result of network interactions (the SIM/UIM is a step in this direction). A variety of information could reside in this identity record. Addressing would resemble a distributed database query rather than a wireless-like wide-area page. While this is, in the context of the current internet, a sort of "DNS on steroids" concept, it should be quite easily doable, given the current state-of-the-art in storage technology. Seems to me that the endpoint of the communication should be this "identity record", which, hopefully, could be plugged into, or associated somehow, with whatever network access point is conventient - a wireLINE terminal, a wireLESS terminal, a mobile subnet such as in an airplane or ship, etc. The network would, by some means, update the routing as that endpoint record thingy moves its attachment point. The record is a network proxy for the real source/sink of the communication, be it a particular human, the human in a particular business role, or some mechanical entity, such as a business' database. I see this kind of thing as the ultimate evolution of ALL public telecom ... somehow. I once heard the fixed telephone network described as a "special case of a mobile network with very low mobility." Right on bro. -- Regards, -- A PS: Recommended reading, for those of you who missed it in the original: "Extraordinary Popular Delusions and the Madness of Crowds," by Charles Mackay, originally published in 1841 London. While his central topic is a series of investment manias that ran through Europe in the 18th century, alchemy, and the vogue for witch burning in the 16th & 17th century Europe, the human behaviors are VERY CLEARLY RECOGNIZABLE in recent events, both financial and telecom. It's available in a Barnes & Noble paperback reprint. From owner-seamoby@diameter.org Thu Apr 12 13:55:45 2001 Received: from charizard.diameter.org ([24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA06095 for ; Thu, 12 Apr 2001 13:55:43 -0400 (EDT) Received: (qmail 12481 invoked by alias); 12 Apr 2001 18:44:09 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 12475 invoked by uid 200); 12 Apr 2001 18:44:09 -0000 Received: (qmail 12470 invoked from network); 12 Apr 2001 18:44:07 -0000 Received: from patan.sun.com (192.18.98.43) by c900656-a.plstn1.sfba.home.com with SMTP; 12 Apr 2001 18:44:07 -0000 Received: from heliopolis.eng.sun.com ([152.70.1.39]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA29405; Thu, 12 Apr 2001 10:54:06 -0700 (PDT) Received: from srmtv29a (srmtv29a [152.70.1.41]) by heliopolis.eng.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id KAA10647; Thu, 12 Apr 2001 10:54:05 -0700 (PDT) Message-Id: <200104121754.KAA10647@heliopolis.eng.sun.com> Date: Thu, 12 Apr 2001 10:54:05 -0700 (PDT) From: James Kempf Reply-To: James Kempf Subject: RE: [seamoby] IETF Architecture Work (RANT) To: mat@cisco.com, seamus@bit-net.com Cc: James.Kempf@Sun.COM, neumiller@telocity.com, john.loughney@nokia.com, seamoby@cdma-2000.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: x554+HgH3CrUi2zkWQQD5A== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 sun4u sparc Sender: owner-seamoby@diameter.org Precedence: bulk If I might remind everyone again, please take a look at http://www.ietf.org/overview.html. This tells the world what IETF is about. The very first sentence says IETF is about doing architecture. If you don't think that should be the case, send email to Harald and tell him to remove that. jak >Date: Thu, 12 Apr 2001 13:50:45 -0400 (EDT) >From: Jim Bound >To: Michael Thomas >Cc: James Kempf , neumiller@telocity.com, john.loughney@nokia.com, seamoby@cdma-2000.org >Subject: RE: [seamoby] IETF Architecture Work (RANT) > > >Mike, > >At a minimum we need to do good Requirements Definition and Analysis >phase. That has been missing in many working groups for a few years. >That helps with sorting assumptions and guiding light out. > >/jim > >On Thu, 12 Apr 2001, Michael Thomas wrote: > >> James Kempf writes: >> > John, >> > >> > I suggest you look at http://www.ietf.org/overview.html. This >> > page is what the IETF says it does. Architecture is in the first sentence. >> > According to this, IETF *already* does architecture. So it is not >> > a matter of whether we should start doing it or not. >> > >> > The problem is, we are doing a lousy job of it. And, as I tried >> > to point out in my posting several days ago, other groups are taking >> > IETF protocols and doing architecture with them that is directly >> > contrary to the Internet architecture as it currently stands. >> > >> > So, we are by default letting other SDOs do architecture with our >> > protocols that will end up screwing the Internet in the end. >> >> "Death of the net, film at 11:00" >> >> Oh, I don't think that it's quite that bad. >> However, the thing I find somewhat disturbing >> is the underlying assumption that we'd get the >> architecture *right*. We may, but there a lot >> of downside if we didn't but was rubber stamped >> as "The IETF Architecture." >> >> Ultimately, there's still a significant amount >> of room for competing architectures where the >> market sorts the dead ends out. If we were in >> monopoly situation I might feel somewhat >> different, but we aren't. >> >> Can I also point out that we might be using >> the term architecture in different ways? I >> generally think of "architecture" in the >> analogous way as to what an architect does when >> she puts lines on a drawing to build a house. >> 3GPP, Packetcable, etc, are all in the business >> of producing those sorts of architectures. >> Under that definition, the IETF has never done >> architectures per se. It does have a base level >> model, set of assumptions, and guiding >> principles which facilitate protocol >> development but this isn't really the same; >> it's more like a guidelines which instruct >> architects the do's and don't on the net. Sort >> of like "don't build houses with the roof on >> the foundation". >> >> Mike >> > From owner-seamoby@diameter.org Thu Apr 12 13:56:50 2001 Received: from charizard.diameter.org ([24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA06114 for ; Thu, 12 Apr 2001 13:56:48 -0400 (EDT) Received: (qmail 10381 invoked by alias); 12 Apr 2001 18:23:33 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 10375 invoked by uid 200); 12 Apr 2001 18:23:32 -0000 Received: (qmail 10370 invoked from network); 12 Apr 2001 18:23:31 -0000 Received: from c007-h000.c007.snv.cp.net (HELO c007.snv.cp.net) (209.228.33.206) by c900656-a.plstn1.sfba.home.com with SMTP; 12 Apr 2001 18:23:31 -0000 Received: (cpmta 815 invoked from network); 12 Apr 2001 10:33:01 -0700 Received: from unknown (HELO philneum) (64.193.0.129) by smtp.telocity.com (209.228.33.206) with SMTP; 12 Apr 2001 10:33:01 -0700 X-Sent: 12 Apr 2001 17:33:01 GMT Message-ID: <01a801c0c376$7e4e6cc0$6501a8c0@philneum> Reply-To: "Phil Neumiller" From: "Phil Neumiller" To: "Charles E. Perkins" Cc: References: <200104121539.IAA03609@heliopolis.eng.sun.com> <017f01c0c368$f7daca60$6501a8c0@philneum> <3AD5DE24.BBA1E334@iprg.nokia.com> Subject: Re: [seamoby] IETF Architecture Work (RANT) Date: Thu, 12 Apr 2001 12:31:59 -0500 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-seamoby@diameter.org Precedence: bulk Hello Charlie, OK so I probably over-reacted a tad (maybe even a bullfrog), however I do want to address some of your points since I think some things were mis-understood or mis-interpreted comments below. ----- Original Message ----- From: "Charles E. Perkins" To: "Phil Neumiller" Cc: Sent: Thursday, April 12, 2001 11:56 AM Subject: Re: [seamoby] IETF Architecture Work (RANT) > > > > > Even if we don't call it architecture, what the WGs should be doing > > is improving the global Internet for mobility and not reacting to other SDOs > > that show up in numbers at WG meetings and demand that the IETF > > do things for them. I don't get why the IETF has been so responsive > > to these other SDOs. Clearly, this has been a huge distraction for the > > MIP WG over the last few years. > > Try looking at it the other way. I have something to say about > this, since I tried to be very encouraging to get engineeers from > the other SDOs involved. OK, I guess the problem I see, is that we don't build hardware in the IETF. :-) It seems to me, that wireless Internet could be there in massive ways now, by avoiding all the leaps and bounds we are forced to go through to support the cellular guys. This is just my opinion and it should be viewed as such. For example: The original wired Internet protocols didn't have to worry about AAA or security or QoS to get massively deployed. I am quite positive that wireless Internet (not WAP or iMode) could have been deployed in the router sense on cheap wireless for quite some time now had the "normal" Internet exponential explosion occured. It seems to me that somehow this progress was shut down by large monopolistic carriers (and this is where Phil's wacko conspiracy theories start to show (don't get me started on FCC auctions)) . I am convinced that the economy of scales would have been there to drive Bluetooth, 802.11b and other WLAN and WPAN technologies prices down if "growing the Internet" over wireless was the IETF's goal rather than placating commercial cellular operators concerns. I realize this sounds sort of idealistic. Who pays the bill? Well its going to be us paying for that spectrum because it will be passed on to us and its taxation without representation as far as I'm concerned. > Mobile IP has been moderately, but not hugely successful. > That is, there have been millions of units deployed, not tens > of millions like there should have been. One place where it > _could_ be more widely deployed is with new wireless networks, > and 3GPP* certainly qualify as standard bodies for new wireless > networks. They are IETF customers. I am going to respectfully disagree Charlie. It *COULD* have been already deployed massively over WPAN and WLAN technology had we ignored the cellular concerns of AAA and QoS and minutes of use carrier class requirements and gone rapidly with a data only model. > Customers are allowed to express their requirements, and technology > providers are allowed (in fact, wise) to pay attention to those > requirements. Sometimes, the requirements need to be reshaped > as the technology providers supply missing technical details to > the customers' views of their requirements. I do agree with this, however, I also believe that the electoral system taught us a lesson in the last US election, that a popular vote is not necessarly best for the entire constituency. > I think this is exactly what has been happening in the Mobile IP > working group. In fact, instead of characterizing it as a > distraction, I should characterize it as a healthy and almost > inevitable evolution. The challenge, as always, is to stay > involved with the evolutionary process so that we don't get > gross mutants that crowd out the more beautiful and desirable > species. The global Internet is a unique creature, more like a diety than one of these creatures you are talking to. The 1st law of the Internet is to have no other Internet (sounds sort of familiar). In the end, these creatures are mortal, and the Internet will go on. > Seems unlikely to me. A better chance is to get protocols that > maintain freedom of choice. If we do that, then operators that > make restrictions may lose out to operators that offer services > for cheap, and freedom to pick other services according to the > desirable Internet end-to-end application model. If we don't make > the protocols available, then we won't expedite the development of > the networks that offer the freedom. [Apologizing ahead of time, here I go again, inserting foot into mouth] Right now, "we have only one choice, Mobile IP." > > It seems much safer to bet on the Internet than to bet on any air > > interface technology or set of standards that will be obsolete in a few > > years. The Internet has much more momentum and evolution and > > we need to continue to improve the beast and not get side tracked > > by fast talking TIA, ETSI, IMT, ISO, IEEE, or SIG de jours > > representation. > > I don't see this as reflecting any reality that I have observed > within the IETF recently. And which "SIG" are you referring to? > If it's SIGMOBILE, then I have to respectfully but assertively > disagree with your characterization. About IEEE, they're not trying > to derail our efforts. I might wish they'd leave ad-hoc networking > out of their charter, but I don't think that causes them to deserve > such a characterization. No, not SIGMOBILE, I was thinking of the Bluetooth SIG and some others. The IEEE is working on there own context transfer right now in 802.11 TG 17. Regards, Phil From owner-seamoby@diameter.org Thu Apr 12 13:58:13 2001 Received: from charizard.diameter.org ([24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA06158 for ; Thu, 12 Apr 2001 13:58:11 -0400 (EDT) Received: (qmail 12831 invoked by alias); 12 Apr 2001 18:46:05 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 12825 invoked by uid 200); 12 Apr 2001 18:46:05 -0000 Received: (qmail 12807 invoked from network); 12 Apr 2001 18:45:59 -0000 Received: from www.bit-net.com (HELO mail.users.bit-net.com) (208.146.132.4) by c900656-a.plstn1.sfba.home.com with SMTP; 12 Apr 2001 18:45:59 -0000 Received: from localhost by mail.users.bit-net.com; (5.65v3.2/1.1.8.2/30Jul96-0143PM) id AA11282; Thu, 12 Apr 2001 13:50:45 -0400 Date: Thu, 12 Apr 2001 13:50:45 -0400 (EDT) From: Jim Bound To: Michael Thomas Cc: James Kempf , neumiller@telocity.com, john.loughney@nokia.com, seamoby@cdma-2000.org Subject: RE: [seamoby] IETF Architecture Work (RANT) In-Reply-To: <15061.59289.4630.420030@thomasm-u1.cisco.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-seamoby@diameter.org Precedence: bulk Mike, At a minimum we need to do good Requirements Definition and Analysis phase. That has been missing in many working groups for a few years. That helps with sorting assumptions and guiding light out. /jim On Thu, 12 Apr 2001, Michael Thomas wrote: > James Kempf writes: > > John, > > > > I suggest you look at http://www.ietf.org/overview.html. This > > page is what the IETF says it does. Architecture is in the first sentence. > > According to this, IETF *already* does architecture. So it is not > > a matter of whether we should start doing it or not. > > > > The problem is, we are doing a lousy job of it. And, as I tried > > to point out in my posting several days ago, other groups are taking > > IETF protocols and doing architecture with them that is directly > > contrary to the Internet architecture as it currently stands. > > > > So, we are by default letting other SDOs do architecture with our > > protocols that will end up screwing the Internet in the end. > > "Death of the net, film at 11:00" > > Oh, I don't think that it's quite that bad. > However, the thing I find somewhat disturbing > is the underlying assumption that we'd get the > architecture *right*. We may, but there a lot > of downside if we didn't but was rubber stamped > as "The IETF Architecture." > > Ultimately, there's still a significant amount > of room for competing architectures where the > market sorts the dead ends out. If we were in > monopoly situation I might feel somewhat > different, but we aren't. > > Can I also point out that we might be using > the term architecture in different ways? I > generally think of "architecture" in the > analogous way as to what an architect does when > she puts lines on a drawing to build a house. > 3GPP, Packetcable, etc, are all in the business > of producing those sorts of architectures. > Under that definition, the IETF has never done > architectures per se. It does have a base level > model, set of assumptions, and guiding > principles which facilitate protocol > development but this isn't really the same; > it's more like a guidelines which instruct > architects the do's and don't on the net. Sort > of like "don't build houses with the roof on > the foundation". > > Mike > From owner-seamoby@diameter.org Thu Apr 12 14:06:21 2001 Received: from charizard.diameter.org ([24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA06330 for ; Thu, 12 Apr 2001 14:06:19 -0400 (EDT) Received: (qmail 13561 invoked by alias); 12 Apr 2001 18:54:28 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 13554 invoked by uid 200); 12 Apr 2001 18:54:27 -0000 Received: (qmail 13549 invoked from network); 12 Apr 2001 18:54:25 -0000 Received: from mailhost.iprg.nokia.com (205.226.5.12) by c900656-a.plstn1.sfba.home.com with SMTP; 12 Apr 2001 18:54:25 -0000 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 LAA05975; Thu, 12 Apr 2001 11:03:55 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f3CI3r110676; Thu, 12 Apr 2001 11:03:53 -0700 X-mProtect: Thu, 12 Apr 2001 11:03:53 -0700 Nokia Silicon Valley Messaging Protection Received: from charliep.iprg.nokia.com (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(WTS.12.69) smtpdZdEdou; Thu, 12 Apr 2001 11:03:39 PDT Message-ID: <3AD5EDFC.2767A3E4@iprg.nokia.com> Date: Thu, 12 Apr 2001 11:03:40 -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: Phil Neumiller CC: seamoby@cdma-2000.org Subject: Re: [seamoby] IETF Architecture Work (RANT) References: <200104121539.IAA03609@heliopolis.eng.sun.com> <017f01c0c368$f7daca60$6501a8c0@philneum> <3AD5DE24.BBA1E334@iprg.nokia.com> <01a801c0c376$7e4e6cc0$6501a8c0@philneum> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-seamoby@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit Hello Phil, We're not so far apart, and yet we get to such different answers... Phil Neumiller wrote: > The original wired Internet protocols didn't have to worry about AAA or > security or QoS to get massively deployed. I am quite positive that wireless > Internet (not WAP or iMode) could have been deployed in the router sense on > cheap wireless for quite some time now had the "normal" Internet exponential > explosion occured. The WLAN cards were there. The protocols were there. Why didn't it happen? The spectrum was even there, in the ISM band, right? I think the reason it didn't happen yet was because the market wasn't ready. Now the market for WLAN seems to be happening, and maybe we'll get a lot more WLAN. That will be great. AAA won't be needed, although perhaps it will find some use. > It seems to me that somehow this progress was shut down > by large monopolistic carriers (and this is where Phil's wacko conspiracy theories > start to show (don't get me started on FCC auctions)) . I am convinced that the > economy of scales would have been there to drive Bluetooth, 802.11b and other > WLAN and WPAN technologies prices down if "growing the Internet" over > wireless was the IETF's goal rather than placating commercial cellular operators > concerns. Again, what did the IETF fail to do? It's more accurate, I think, to say that the IETF did what seemed necessary, and new customers brought in new requirements. That's a lot different than vectoring into a distractive swamp. > I realize this sounds sort of idealistic. Who pays the bill? Well its > going to be us paying for that spectrum because it will be passed on to us > and its taxation without representation as far as I'm concerned. This is a different issue, but since you brought it up I wish we could somehow get it into the popular consciousness that the spectrum is a _public resource_, not a purchasable commodity. Most people seem all too willing to cede control of it to large corporations and the military. Sigh. >> Mobile IP has been moderately, but not hugely successful. >> That is, there have been millions of units deployed, not tens >> of millions like there should have been. One place where it >> _could_ be more widely deployed is with new wireless networks, >> and 3GPP* certainly qualify as standard bodies for new wireless >> networks. They are IETF customers. > > I am going to respectfully disagree Charlie. It *COULD* have been > already deployed massively over WPAN and WLAN technology > had we ignored the cellular concerns of AAA and QoS and minutes > of use carrier class requirements and gone rapidly with a data only > model. I just don't get it, Phil. No one stopped Motorola or IBM or any other startup, small company, or large company from deploying Mobile IP. They just didn't do it in huge numbers. My guess is because they couldn't figure out a profitable business model. How would ignoring the concerns of some customers work to encourage other customers to use the existing protocols? >> Customers are allowed to express their requirements, and technology >> providers are allowed (in fact, wise) to pay attention to those >> requirements. Sometimes, the requirements need to be reshaped >> as the technology providers supply missing technical details to >> the customers' views of their requirements. > > I do agree with this, however, I also believe that the electoral system > taught us a lesson in the last US election, that a popular vote is not > necessarly best for the entire constituency. More people voted for Gore, and it took massive and expensive rigging to contravene the democratically mandated result. But that's not wireless networking, eh? ........ >> If we don't make >> the protocols available, then we won't expedite the development of >> the networks that offer the freedom. > > [Apologizing ahead of time, here I go again, inserting foot into mouth] > Right now, "we have only one choice, Mobile IP." Foot or not, I am not getting a clear idea from what's coming out of your mouth. How should the situation have been improved? > No, not SIGMOBILE, I was thinking of the Bluetooth SIG and some > others. The IEEE is working on there own context transfer right now > in 802.11 TG 17. Hmmm, that seems like a waste of time to me, I'll admit. Regards, Charlie P. From owner-seamoby@diameter.org Thu Apr 12 14:09:30 2001 Received: from charizard.diameter.org ([24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA06476 for ; Thu, 12 Apr 2001 14:09:30 -0400 (EDT) Received: (qmail 14021 invoked by alias); 12 Apr 2001 18:58:28 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 14015 invoked by uid 200); 12 Apr 2001 18:58:27 -0000 Received: (qmail 14010 invoked from network); 12 Apr 2001 18:58:26 -0000 Received: from unknown (HELO megisto-sql1.megisto.com) (63.113.114.132) by c900656-a.plstn1.sfba.home.com with SMTP; 12 Apr 2001 18:58:26 -0000 Received: by mail.megisto.com with Internet Mail Service (5.5.2650.21) id ; Thu, 12 Apr 2001 14:02:24 -0400 Message-ID: From: Phil Roberts To: "'Phil Neumiller'" Cc: seamoby@cdma-2000.org Subject: RE: [seamoby] IETF Architecture Work (RANT) Date: Thu, 12 Apr 2001 14:02:24 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-seamoby@diameter.org Precedence: bulk > > Mobile IP has been moderately, but not hugely successful. > > That is, there have been millions of units deployed, not tens > > of millions like there should have been. One place where it > > _could_ be more widely deployed is with new wireless networks, > > and 3GPP* certainly qualify as standard bodies for new wireless > > networks. They are IETF customers. > > I am going to respectfully disagree Charlie. It *COULD* have been > already deployed massively over WPAN and WLAN technology > had we ignored the cellular concerns of AAA and QoS and minutes > of use carrier class requirements and gone rapidly with a data only > model. What exactly was missed that kept it from being massively deployed? I don't recall us turning down any request for work that would help enable that deployment, but perhaps you can point some out? From owner-seamoby@diameter.org Thu Apr 12 16:02:39 2001 Received: from charizard.diameter.org ([24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA09340 for ; Thu, 12 Apr 2001 16:02:37 -0400 (EDT) Received: (qmail 16315 invoked by alias); 12 Apr 2001 20:51:21 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 16309 invoked by uid 200); 12 Apr 2001 20:51:21 -0000 Received: (qmail 16304 invoked from network); 12 Apr 2001 20:51:19 -0000 Received: from c007-h015.c007.snv.cp.net (HELO c007.snv.cp.net) (209.228.33.222) by c900656-a.plstn1.sfba.home.com with SMTP; 12 Apr 2001 20:51:19 -0000 Received: (cpmta 9586 invoked from network); 12 Apr 2001 13:00:48 -0700 Received: from dsl-64-193-0-129.telocity.com (HELO philneum) (64.193.0.129) by smtp.telocity.com (209.228.33.222) with SMTP; 12 Apr 2001 13:00:48 -0700 X-Sent: 12 Apr 2001 20:00:48 GMT Message-ID: <020601c0c38b$242d6880$6501a8c0@philneum> Reply-To: "Phil Neumiller" From: "Phil Neumiller" To: "Phil Roberts" , References: Subject: Re: [seamoby] IETF Architecture Work (RANT) Date: Thu, 12 Apr 2001 14:59:45 -0500 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-seamoby@diameter.org Precedence: bulk Hi Phil R. I will take a stab at answering. I am officially off on a rant now so *try* not to respond unless of course you need to defend yourself. :-) > > What exactly was missed that kept it from being massively deployed? I don't > recall us turning down any request for work that would help enable that > deployment, but perhaps you can point some out? > 1). As James has pointed out repeatedly, it is the IETF's job to preserve, cherish, and extend the architecture of the global Internet. When did it become the IETF's job to work for other SDOs? IMO, the MIP WG has catered almost exclusively to cdma2000/3GPP2 and UMTS/3GPP for the last 1 1/2 years or better. I could be wrong but that is my opinion. In fact, some of the work that was not expedient for 3G was handed over to SeaMoby (and now the IRTF). 2). A real goal that SHOULD be on the MIP charter (again this is IMO) is to make itself go away, i.e. MIP should be once and for all absorbed into the router fabric of the global Internet since the work is routing work and should stay routing work decoupled from other issues that are related to mobility. Distance Vector approaches like BGP4 and RIP have clearly proven themselves in fixed routers and will probably make a strong showing in pre-commercial MANETs shortly. What does this mean to MIP? Apparently not much. Its quite possible that some BGP-like monster could really becomes the routing algorithm for all devices whether fixed or mobile and the utility of a home agent could be nullified. Is this a concern of the MIP group? It seems like maybe things like this SHOULD be on the charter to me since they are the things that have to do with the architecture of the global Internet itself. Improvements to the global Internet in its support of mobility help everybody on the planet not just the 3G fat cats. 3). I fail to see how continuing to tie security issues, QoS issues, AAA issues directly into the routing protocol implementation of MIP help to acheive the important goal of getting it universally deployed in the global Internet (not just a bunch of private cellular networks). (again this is IMO). Please take all this with an industrial sized canister of NaCl since it was a and still is a rant. Best regards, Phil N. From owner-seamoby@diameter.org Thu Apr 12 16:19:09 2001 Received: from charizard.diameter.org ([24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA09781 for ; Thu, 12 Apr 2001 16:19:07 -0400 (EDT) Received: (qmail 16937 invoked by alias); 12 Apr 2001 21:07:39 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 16931 invoked by uid 200); 12 Apr 2001 21:07:38 -0000 Received: (qmail 16926 invoked from network); 12 Apr 2001 21:07:37 -0000 Received: from unknown (HELO megisto-sql1.megisto.com) (63.113.114.132) by c900656-a.plstn1.sfba.home.com with SMTP; 12 Apr 2001 21:07:37 -0000 Received: by mail.megisto.com with Internet Mail Service (5.5.2650.21) id ; Thu, 12 Apr 2001 16:11:35 -0400 Message-ID: From: Phil Roberts To: "'Phil Neumiller'" , seamoby@cdma-2000.org Subject: RE: [seamoby] IETF Architecture Work (RANT) Date: Thu, 12 Apr 2001 16:11:35 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-seamoby@diameter.org Precedence: bulk Hi Phil N. I'm not sure I see an answer to my question. I was trying to figure out what we should have done to see MIP massively deployed now. Re: your points 1. I don't see how we could have kept from supporting the (what is now called 3gpp2) folks from doing the things they wanted to get done. They came, had work, contributed cycles, got working group consensus, and are now rolling stuff out. And I don't see why we would want not to support them. 2. Perhaps we should take this up on the MIP list? Now that I think about it, perhaps this whole thing should be on the MIP list. (Sorry, Pat). 3. Most of the add-ons are add-ons. One could just run vanilla mobile IP. Phil R. > -----Original Message----- > From: Phil Neumiller [mailto:neumiller@telocity.com] > Sent: Thursday, April 12, 2001 4:00 PM > To: Phil Roberts; seamoby@cdma-2000.org > Subject: Re: [seamoby] IETF Architecture Work (RANT) > > > Hi Phil R. > > I will take a stab at answering. I am officially off on a > rant now so *try* > not to respond unless of course you need to defend yourself. :-) > > > > > What exactly was missed that kept it from being massively > deployed? I don't > > recall us turning down any request for work that would help > enable that > > deployment, but perhaps you can point some out? > > > > 1). As James has pointed out repeatedly, it is the IETF's > job to preserve, > cherish, and extend the architecture of the global > Internet. When > did it become the IETF's job to work for other SDOs? IMO, the > MIP WG has catered almost exclusively to cdma2000/3GPP2 and > UMTS/3GPP for the last 1 1/2 years or better. I could be wrong > but that is my opinion. In fact, some of the work that > was not expedient > for 3G was handed over to SeaMoby (and now the IRTF). > > 2). A real goal that SHOULD be on the MIP charter (again this is IMO) > is to make itself go away, i.e. MIP should be once and > for all absorbed > into the router fabric of the global Internet since the > work is routing work > and should stay routing work decoupled from other > issues that are related > to mobility. > > Distance Vector approaches like BGP4 and RIP have clearly proven > themselves in fixed routers and will probably make a > strong showing in > pre-commercial MANETs shortly. What does this mean to MIP? > Apparently not much. Its quite possible that some > BGP-like monster > could really becomes the routing algorithm for all > devices whether fixed > or mobile and the utility of a home agent could be > nullified. Is this a > concern of the MIP group? It seems like maybe things > like this SHOULD > be on the charter to me since they are the things that > have to do with > the architecture of the global Internet itself. > Improvements to the global > Internet in its support of mobility help everybody on > the planet not just > the 3G fat cats. > > 3). I fail to see how continuing to tie security issues, QoS > issues, AAA > issues directly into the routing protocol > implementation of MIP help to > acheive the important goal of getting it universally > deployed in the > global Internet (not just a bunch of private cellular > networks). (again this is IMO). > > Please take all this with an industrial sized canister of > NaCl since it was a > and still is a rant. > > Best regards, > > Phil N. > > From owner-seamoby@diameter.org Thu Apr 12 19:13:13 2001 Received: from charizard.diameter.org ([24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA13274 for ; Thu, 12 Apr 2001 19:13:13 -0400 (EDT) Received: (qmail 20047 invoked by alias); 13 Apr 2001 00:01:33 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 20041 invoked by uid 200); 13 Apr 2001 00:01:33 -0000 Received: (qmail 20036 invoked from network); 13 Apr 2001 00:01:31 -0000 Received: from mgw-dax1.ext.nokia.com (63.78.179.216) by c900656-a.plstn1.sfba.home.com with SMTP; 13 Apr 2001 00:01:31 -0000 Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85]) by mgw-dax1.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f3CNBbg22055 for ; Thu, 12 Apr 2001 18:11:37 -0500 (CDT) Received: from daebh01nok.americas.nokia.com (unverified) by davir02nok.americas.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Thu, 12 Apr 2001 18:11:10 -0500 Received: by daebh01nok with Internet Mail Service (5.5.2652.78) id ; Thu, 12 Apr 2001 18:11:10 -0500 Message-ID: <7B5C0390ACE7D211BC9C0008C7EABA2B03213809@daeis07nok> From: Basavaraj.Patil@nokia.com To: neumiller@telocity.com, PRoberts@MEGISTO.com, seamoby@cdma-2000.org Subject: RE: [seamoby] IETF Architecture Work (RANT) Date: Thu, 12 Apr 2001 18:11:10 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-seamoby@diameter.org Precedence: bulk Phil N wrote: > > 1). As James has pointed out repeatedly, it is the IETF's > job to preserve, > cherish, and extend the architecture of the global > Internet. When > did it become the IETF's job to work for other SDOs? IMO, the > MIP WG has catered almost exclusively to cdma2000/3GPP2 and > UMTS/3GPP for the last 1 1/2 years or better. I could be wrong > but that is my opinion. In fact, some of the work that > was not expedient > for 3G was handed over to SeaMoby (and now the IRTF). > What specific work done in the MIP WG over the last year and a half has been done with 3GPP as a customer in mind? The MIP WG did undertake some work that was specific to PP2, but the people who did this work in the IETF were/are people who also play in the PP2 field. So what's wrong with that.... Let's not get into the philosophy of what the IETF's job is and should be and treat the global Internet as the holy grail So adding peripheral stuff to MIP allows it to be "Maybe" used in certain types of networks. But that does not change the basic MIP protocol itself. -Basavaraj From owner-seamoby@diameter.org Thu Apr 12 19:39:43 2001 Received: from charizard.diameter.org ([24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA13550 for ; Thu, 12 Apr 2001 19:39:43 -0400 (EDT) Received: (qmail 20751 invoked by alias); 13 Apr 2001 00:28:01 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 20745 invoked by uid 200); 13 Apr 2001 00:28:01 -0000 Received: (qmail 20739 invoked from network); 13 Apr 2001 00:27:59 -0000 Received: from unknown (HELO NEPTUNE.zucotto.com) (216.95.209.154) by c900656-a.plstn1.sfba.home.com with SMTP; 13 Apr 2001 00:27:59 -0000 Received: by NEPTUNE.zucotto.com with Internet Mail Service (5.5.2653.19) id ; Thu, 12 Apr 2001 19:37:59 -0400 Message-ID: <6833D86F1B05CA4FBAB3C73DD98BD8B90D2B33@NEPTUNE.zucotto.com> From: Kulwinder Atwal To: "'Phil Neumiller'" , "Charles E. Perkins" Cc: seamoby@cdma-2000.org Subject: RE: [seamoby] IETF Architecture Work (RANT) Date: Thu, 12 Apr 2001 19:37:58 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-seamoby@diameter.org Precedence: bulk > -----Original Message----- > From: Phil Neumiller [mailto:neumiller@telocity.com] > Sent: Thursday, April 12, 2001 1:32 PM > To: Charles E. Perkins > Cc: seamoby@cdma-2000.org > Subject: Re: [seamoby] IETF Architecture Work (RANT) > > > Hello Charlie, > > > > > > It seems much safer to bet on the Internet than to bet on any air > > > interface technology or set of standards that will be > obsolete in a few > > > years. The Internet has much more momentum and evolution and > > > we need to continue to improve the beast and not get side tracked > > > by fast talking TIA, ETSI, IMT, ISO, IEEE, or SIG de jours > > > representation. > > > > I don't see this as reflecting any reality that I have observed > > within the IETF recently. And which "SIG" are you referring to? > > If it's SIGMOBILE, then I have to respectfully but assertively > > disagree with your characterization. About IEEE, they're not trying > > to derail our efforts. I might wish they'd leave ad-hoc networking > > out of their charter, but I don't think that causes them to deserve > > such a characterization. > > No, not SIGMOBILE, I was thinking of the Bluetooth SIG and some > others. The IEEE is working on there own context transfer right now > in 802.11 TG 17. I would like to address this concern about the Bluetooth SIG and what changes have occurred in the last two months: The Bluetooth SIG: - encourages that all future Bluetooth Profiles be based on IP. - plans to work on the L2 portion of a mobile router protocol (Scatternets). The Bluetooth PAN WG wishes to use the output of at least: - IETF SLP - IETF ZeroConf WG - IETF ROHC WG - IETF Seamoby (Context Transfer) WG - some kind of IP based Ad Hoc Mobile Router Protocol most likely developed in IETF MANET. The only real debate that has occcured is finding the best way to do IP over Bluetooth. With the SIG releasing all relevant docs sometime next month this issue will be resolved on the IETF IP over Bluetooth list. Can you explain how you feel that the Internet is being 'side tracked' by the Bluetooth SIG? - Kulwinder. > > Regards, > > Phil > > > From owner-seamoby@diameter.org Thu Apr 12 19:46:56 2001 Received: from charizard.diameter.org ([24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA13673 for ; Thu, 12 Apr 2001 19:46:55 -0400 (EDT) Received: (qmail 21344 invoked by alias); 13 Apr 2001 00:35:46 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 21338 invoked by uid 200); 13 Apr 2001 00:35:45 -0000 Received: (qmail 21333 invoked from network); 13 Apr 2001 00:35:44 -0000 Received: from c007-h014.c007.snv.cp.net (HELO c007.snv.cp.net) (209.228.33.221) by c900656-a.plstn1.sfba.home.com with SMTP; 13 Apr 2001 00:35:44 -0000 Received: (cpmta 28541 invoked from network); 12 Apr 2001 16:45:14 -0700 Received: from dsl-64-193-0-129.telocity.com (HELO philneum) (64.193.0.129) by smtp.telocity.com (209.228.33.221) with SMTP; 12 Apr 2001 16:45:14 -0700 X-Sent: 12 Apr 2001 23:45:14 GMT Message-ID: <02ab01c0c3aa$7ea6ef60$6501a8c0@philneum> Reply-To: "Phil Neumiller" From: "Phil Neumiller" To: "Kulwinder Atwal" , References: <6833D86F1B05CA4FBAB3C73DD98BD8B90D2B33@NEPTUNE.zucotto.com> Subject: Re: [seamoby] IETF Architecture Work (RANT) Date: Thu, 12 Apr 2001 18:44:13 -0500 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-seamoby@diameter.org Precedence: bulk My only answer to this is finally! Yeah! Kulwinder I have been trying in the background for about 1 1/2 years to encourage these things to happen with Bluetooth. If you check the archives in the groups you enumerated you will find that I have been advocating exactly what is being done i.e. I think you will find that I am on "your side". Believe me, it was not always this way, and I applaud you for the huge amount of progress you have been making with the SIG. ----- Original Message ----- From: "Kulwinder Atwal" > I would like to address this concern about the Bluetooth SIG and what > changes have occurred in the last two months: > > The Bluetooth SIG: > - encourages that all future Bluetooth Profiles be based on IP. > - plans to work on the L2 portion of a mobile router protocol > (Scatternets). > > The Bluetooth PAN WG wishes to use the output of at least: > > - IETF SLP > - IETF ZeroConf WG > - IETF ROHC WG > - IETF Seamoby (Context Transfer) WG > - some kind of IP based Ad Hoc Mobile Router Protocol most likely > developed in IETF MANET. > > The only real debate that has occcured is finding the best way to do IP over > Bluetooth. With the SIG releasing all relevant docs sometime next month > this issue will be resolved on the IETF IP over Bluetooth list. > > Can you explain how you feel that the Internet is being 'side tracked' by > the Bluetooth SIG? > > - Kulwinder. > > > > > From owner-seamoby@diameter.org Fri Apr 13 02:05:29 2001 Received: from charizard.diameter.org ([24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA01753 for ; Fri, 13 Apr 2001 02:05:29 -0400 (EDT) Received: (qmail 26592 invoked by alias); 13 Apr 2001 06:53:24 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 26587 invoked by uid 200); 13 Apr 2001 06:53:22 -0000 Received: (qmail 26580 invoked from network); 13 Apr 2001 06:53:20 -0000 Received: from unknown (HELO NEPTUNE.zucotto.com) (216.95.209.154) by c900656-a.plstn1.sfba.home.com with SMTP; 13 Apr 2001 06:53:20 -0000 Received: by NEPTUNE.zucotto.com with Internet Mail Service (5.5.2653.19) id ; Fri, 13 Apr 2001 02:03:21 -0400 Message-ID: <6833D86F1B05CA4FBAB3C73DD98BD8B90D2B36@NEPTUNE.zucotto.com> From: Kulwinder Atwal To: "'Arthur Ross'" , Phil Neumiller , James Kempf , john.loughney@nokia.com Cc: seamoby@cdma-2000.org Subject: RE: [seamoby] IETF Architecture Work (RANT) Date: Fri, 13 Apr 2001 02:03:19 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-seamoby@diameter.org Precedence: bulk > -----Original Message----- > From: Arthur Ross [mailto:a.ross@ieee.org] > Sent: Thursday, April 12, 2001 1:37 PM > To: Phil Neumiller; James Kempf; john.loughney@nokia.com > Cc: seamoby@cdma-2000.org > Subject: Re: [seamoby] IETF Architecture Work (RANT) > > > I have long thought that the real, underlying endpoint > entities are neither > "handsets" nor "hosts", but something that more nearly > resembles a record > in a distributed database. The physical embodiment of it > could take many > forms, but the essential abstraction would be the CONTENT, > not the physical > realization. It would be logically separate from the embodiment of any > communication device. The association of the two would occur > as a result of > network interactions (the SIM/UIM is a step in this > direction). A variety > of information could reside in this identity record. Addressing would > resemble a distributed database query rather than a > wireless-like wide-area > page. While this is, in the context of the current internet, > a sort of "DNS > on steroids" concept, it should be quite easily doable, given > the current > state-of-the-art in storage technology. > > Seems to me that the endpoint of the communication should be > this "identity > record", which, hopefully, could be plugged into, or > associated somehow, > with whatever network access point is conventient - a > wireLINE terminal, a > wireLESS terminal, a mobile subnet such as in an airplane or > ship, etc. The > network would, by some means, update the routing as that > endpoint record > thingy moves its attachment point. The record is a network > proxy for the > real source/sink of the communication, be it a particular > human, the human > in a particular business role, or some mechanical entity, such as a > business' database. > > I see this kind of thing as the ultimate evolution of ALL > public telecom > ... somehow. I once heard the fixed telephone network described as a > "special case of a mobile network with very low mobility." > Right on bro. > > > > -- Regards, > -- A > > PS: Recommended reading, for those of you who missed it in > the original: > > "Extraordinary Popular Delusions and the Madness of Crowds," > by Charles > Mackay, originally published in 1841 London. While his > central topic is a > series of investment manias that ran through Europe in the > 18th century, > alchemy, and the vogue for witch burning in the 16th & 17th > century Europe, > the human behaviors are VERY CLEARLY RECOGNIZABLE in recent > events, both > financial and telecom. It's available in a Barnes & Noble > paperback reprint. > I see that someone other than myself really gets it. What we need to be working toward in the IETF is a: Mobile Real-Time Peer-To-Peer Globally Distributed Database With parts of the Freenet concept: http://news.cnet.com/news/0-1005-200-5578112.html Where we let the L2 deal with physical entities like Physical links: L3 Logical Link Layer (Triggers). L2 Physical Link Layer. (Physical Events) L1 Physical. Starting at the bottom, the first thing we need to get away from is routing and context transfer protocols for L3 and above that rely on timers. Timers are physical embodiments. For routing protocols to be based on timers in a mobile environment has no value. In the static internet is has been easy to pick a optimal frequency becuase we have had only ONE Usage Model: Static Internet Usage Model: Stationary Computer to Stationary Computer. And with cellular we have been adding only one more usage model. Cellular Usage Model: Mobile Phone to Cell Tower. But, it is impossible to predict the optimal frequency that route updates should occur. A user, or vehicle may remain stationary for hours at a time then move at a high rate. Should the router update occur once per 30 seconds, per hour, or per millisecond? What about Context Transfer? Is the endpoint record a fridge, ID Badge, stereo, person, car, ship or plane? This is why context transfer and route updates need to occur based on Physical Events propagated up the stack as Logical Triggers. NOT TIMERS. Becuase it is impossible to predict the Usage Model. The mapping of Physical Events to Logical Triggers may change depending on the technology, application, external event, or user preference. We need enable all current and future Usage Models. The Mobile Real-Time Peer-To-Peer Globally Distributed Database. -Kulwinder. From owner-seamoby@diameter.org Fri Apr 13 07:50:26 2001 Received: from charizard.diameter.org ([24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA05615 for ; Fri, 13 Apr 2001 07:50:26 -0400 (EDT) Received: (qmail 29939 invoked by alias); 13 Apr 2001 12:18:49 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 29933 invoked by uid 200); 13 Apr 2001 12:18:48 -0000 Received: (qmail 29928 invoked from network); 13 Apr 2001 12:18:47 -0000 Received: from c007-h000.c007.snv.cp.net (HELO c007.snv.cp.net) (209.228.33.206) by c900656-a.plstn1.sfba.home.com with SMTP; 13 Apr 2001 12:18:47 -0000 Received: (cpmta 26241 invoked from network); 13 Apr 2001 04:28:14 -0700 Received: from dsl-64-193-0-129.telocity.com (HELO philneum) (64.193.0.129) by smtp.telocity.com (209.228.33.206) with SMTP; 13 Apr 2001 04:28:14 -0700 X-Sent: 13 Apr 2001 11:28:14 GMT Message-ID: <032e01c0c40c$b4bb4f80$6501a8c0@philneum> Reply-To: "Phil Neumiller" From: "Phil Neumiller" To: "Kulwinder Atwal" , References: <6833D86F1B05CA4FBAB3C73DD98BD8B90D2B36@NEPTUNE.zucotto.com> Subject: Re: [seamoby] IETF Architecture Work (RANT) Date: Fri, 13 Apr 2001 06:27:06 -0500 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-seamoby@diameter.org Precedence: bulk Hi Kulwinder, BTW your direct Email in your from address is bouncing again so you may want to check it. ----- Original Message ----- From: "Kulwinder Atwal" > I see that someone other than myself really gets it. > What we need to be working toward in the IETF is a: > > Mobile Real-Time Peer-To-Peer Globally Distributed Database > > With parts of the Freenet concept: > > http://news.cnet.com/news/0-1005-200-5578112.html > I think you may not be giving the "real" Internet enough credit Kulwinder and since I strangely find myself defending it these days I will try and explain why. We need to face up to the fact that "real" global Internet is here now and it has proven itself to be remarkably robust and scalable. It has also brought a lot of wealth to a lot of companies (especially Cisco :-)). The term "peer-to-peer" is pure unaldulterated marketing hype! The global Internet has been peer-to-peer from day 0. It was founded on the end-to-end principle, i.e. my IP address speaks to your IP address. What we decide to put on top of that for window dressing is just fluff (which may enclude military grade privacy encryption between you and your co-horts in your version of the world). Nobody is stopping anybody from doing this now, except the big carriers while caving in to world governments that are attempting tax the spectrum and spy on their people. As far as the database portion goes, I would like you take a look at some work going on in Randy Katz's group at Berkley. They have something called OceanStore that is incredibly cool. In this model your secure data follows you around as you are mobile and sloshes around in something analogous to a service provider SANs (storage area network). You only need your privacy key and a secure pipe to carry your entire digital library around wherever you go. Here is the URL http://oceanstore.cs.berkeley.edu/ . > Where we let the L2 deal with physical entities like Physical links: > > L3 Logical Link Layer (Triggers). > L2 Physical Link Layer. (Physical Events) > L1 Physical. > > Starting at the bottom, the first thing we need to get away from is routing > and context transfer protocols for L3 and above that rely on timers. Timers > are physical embodiments. OK, and this is why, I have ranted and raved for years about a standardized triggering mechanism between layers. Some people like to call these things "shims". Back in the olden days of structured analysis we called them SAPs and SPPs, i.e. service access points and service provision points. Real time UML has actually adopted this model by bringing in Selic's ROOM actors (which has SAPs and SPPs), but that is besides the point. I, like you I believe, would rather see a hard core protocol definition of the trigger rather than a design abstraction for it, and hopefully the sub-IP area can get interested in this. > > For routing protocols to be based on timers in a mobile environment has no > value. Yes, and you would argue that MIP does just that right? Of course MANET protocols typically don't and they will replace MIP soon anyway! Fixed nodes have used distance vector based algorithms for many moons to reach other just fine and soon the planet will be covered with mobile routers doing somithing very anologous to this. Who needs timers and/or mobile IP in this coming world I might ask? In light of this, the home agent is silly because it is essentially burning up an IP address to use as key value into a location database. > > In the static internet is has been easy to pick a optimal frequency becuase > we have had only ONE Usage Model: > > Static Internet Usage Model: Stationary Computer to Stationary Computer. > > And with cellular we have been adding only one more usage model. > > Cellular Usage Model: Mobile Phone to Cell Tower. Well, um, ah, when I was at Motorola, we did expand this model in a few interesting way, Irridium comes to mind first but there were many other models. Please recall that the Internet was originally developed on a packet radio network! > > But, it is impossible to predict the optimal frequency that route updates > should occur. A user, or vehicle may remain stationary for hours at a time > then move at a high rate. Should the router update occur once per 30 > seconds, per hour, or per millisecond? What about Context Transfer? Yes we have your point, event driven systems are better in many ways, but I think they are only reliable if redundancy is added and many times timers are adding that redundancy (in the time domain) when the event triggers fail (in the frequency domain). > > Is the endpoint record a fridge, ID Badge, stereo, person, car, ship or > plane? > > This is why context transfer and route updates need to occur based on > Physical Events propagated up the stack as Logical Triggers. NOT TIMERS. > Becuase it is impossible to predict the Usage Model. If you study MANET algorithms Kulwinder you will see that this is exactly how they work (at least in the routing sense). > > The mapping of Physical Events to Logical Triggers may change depending on > the technology, application, external event, or user preference. > > We need enable all current and future Usage Models. A bit altruistic, but I'll try to help, I like generalized solutions! > > The Mobile Real-Time Peer-To-Peer Globally Distributed Database. > Could very well be a good MANET algorithm with something like OceanStore IMHO. > -Kulwinder. Best regards, Phil From owner-seamoby@diameter.org Fri Apr 13 11:57:02 2001 Received: from charizard.diameter.org ([24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA11068 for ; Fri, 13 Apr 2001 11:57:00 -0400 (EDT) Received: (qmail 528 invoked by alias); 13 Apr 2001 16:45:36 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 522 invoked by uid 200); 13 Apr 2001 16:45:36 -0000 Received: (qmail 517 invoked from network); 13 Apr 2001 16:45:34 -0000 Received: from mercury.sun.com (192.9.25.1) by c900656-a.plstn1.sfba.home.com with SMTP; 13 Apr 2001 16:45:34 -0000 Received: from heliopolis.eng.sun.com ([152.70.1.39]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA21580; Fri, 13 Apr 2001 08:52:56 -0700 (PDT) Received: from heliopolis.Eng.Sun.COM (esun1as-be.Central.Sun.COM [129.147.34.142]) by heliopolis.eng.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA05081; Fri, 13 Apr 2001 08:55:01 -0700 (PDT) From: Patrice Calhoun Message-Id: <200104131555.IAA05081@heliopolis.eng.sun.com> Date: Fri, 13 Apr 2001 11:50:27 -0700 To: "Phil Neumiller" , , "James Kempf" Cc: Reply-To: Subject: Re: [seamoby] IETF Architecture Work (RANT) X-Mailer: Sun NetMail 2.3 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Sender: owner-seamoby@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit >Even if we don't call it architecture, what the WGs should be doing >is improving the global Internet for mobility and not reacting to other SDOs >that show up in numbers at WG meetings and demand that the IETF >do things for them. I don't get why the IETF has been so responsive >to these other SDOs. Clearly, this has been a huge distraction for the >MIP WG over the last few years. Well, I suppose one could argue that the IETF is there to build protocols that will be used in the real world. So far 3GPP2 is the one big one that has come up and stated that they will deploy MIP in a large scale network. So, it sounds reasonable for the IETF to help out. >Let's EXTEND the global Internet to support the best wireless mobility >on the planet and let other SDOs worry about supporting their legacy >systems. WHY is the MIP charter so dominated with work from the >3GXXrs I must ask? They are not the only customer, in fact with >the advent of "cheap" wireless, which most people are starting to see >the advantages of (I can only hope), cellular architectures as built today >and the business models that support them will be deconstructed. Any "other" customer is free to come to the IETF and state they requirements. I can assure you that they would be heard, and cooperation is guaranteed. However, we cannot just build something and then shove it down their throats :( From owner-seamoby@diameter.org Fri Apr 13 12:01:37 2001 Received: from charizard.diameter.org ([24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA11162 for ; Fri, 13 Apr 2001 12:01:35 -0400 (EDT) Received: (qmail 1021 invoked by alias); 13 Apr 2001 16:50:00 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 1015 invoked by uid 200); 13 Apr 2001 16:49:59 -0000 Received: (qmail 1010 invoked from network); 13 Apr 2001 16:49:58 -0000 Received: from mailhost.iprg.nokia.com (205.226.5.12) by c900656-a.plstn1.sfba.home.com with SMTP; 13 Apr 2001 16:49:58 -0000 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 IAA10242; Fri, 13 Apr 2001 08:59:31 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f3DFxRH16625; Fri, 13 Apr 2001 08:59:27 -0700 X-mProtect: Fri, 13 Apr 2001 08:59:27 -0700 Nokia Silicon Valley Messaging Protection Received: from charliep.iprg.nokia.com (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(WTS.12.69) smtpdXeiWWU; Fri, 13 Apr 2001 08:59:16 PDT Message-ID: <3AD72257.F8F17D07@iprg.nokia.com> Date: Fri, 13 Apr 2001 08:59:19 -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: Phil Neumiller CC: seamoby@cdma-2000.org Subject: Re: [seamoby] IETF Architecture Work (RANT) References: <6833D86F1B05CA4FBAB3C73DD98BD8B90D2B36@NEPTUNE.zucotto.com> <032e01c0c40c$b4bb4f80$6501a8c0@philneum> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-seamoby@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit Hello Phil, I keep trying to stay out of the discussion, but haven't the strength to withstand... >> For routing protocols to be based on timers in a mobile environment has no >> value. Routing protocols depend on timing in many ways. I believe they will continue to do so until further research is done towards omniscience. The best result will be to minimize dependence on timers. Getting rid of them entirely, without replacement by mechanisms that are at least as good, is poor engineering. Don't you like screensavers and alarm clocks? > Yes, and you would argue that MIP does just that right? Of course MANET > protocols typically don't and they will replace MIP soon anyway! Even the most ardent supporter of a MANET cannot claim that it will scale to the size of the Internet. Right now, as far as I know, nobody has even tried 20,000 nodes under any MANET algorithm. Plus, it could be that there IS NOT any natural way to do aggregation, and I just don't think we can make a completely flat addressing model work for billions of network nodes, even with on-demand routing and superlatively clever engineering. MANET so far relies on flooding control packets at least every once in a while for route discovery or for route maintenance. You just can't do this in the global Internet. Plus, a lot of MANET plus a lot of Internet will lead to a lot of multi-path routing possibilities, with difficult decisions about which path to take. That just makes things "worse", from the point of view of making MANET work. How about this for a "better" model of the future: - Mobile IP to support hierarchical addressing for nodes (no longer any need to distinguish "mobile nodes" from other nodes, since they're practically all mobile) - Home agents as directory servers for routing information for mobile nodes - Manets for community and local connectivity. - Seamoby for temporary, local connectivity management while ... - Regional Registration diffuses any necessary routing updates. It could work... And it points out the opportunity for improvement if someone wishes to engineer a way for marrying bits of [seamoby-context] to manet... > Fixed nodes > have used distance vector based algorithms for many moons to reach other just > fine and soon the planet will be covered with mobile routers doing somithing > very anologous to this. Who needs timers and/or mobile IP in this coming world > I might ask? In light of this, the home agent is silly because it is essentially > burning up an IP address to use as key value into a location database. Since I'm in the IPv6 camp, this doesn't seem to be to be so unthinkably horrible. Even with IPv4, we do have a few addresses left for use. Regards, Charlie P. From owner-seamoby@diameter.org Fri Apr 13 12:14:51 2001 Received: from charizard.diameter.org ([24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA12017 for ; Fri, 13 Apr 2001 12:14:48 -0400 (EDT) Received: (qmail 1637 invoked by alias); 13 Apr 2001 17:03:10 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 1632 invoked by uid 200); 13 Apr 2001 17:03:10 -0000 Received: (qmail 1626 invoked from network); 13 Apr 2001 17:03:08 -0000 Received: from mercury.sun.com (192.9.25.1) by c900656-a.plstn1.sfba.home.com with SMTP; 13 Apr 2001 17:03:08 -0000 Received: from heliopolis.eng.sun.com ([152.70.1.39]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA28939; Fri, 13 Apr 2001 09:10:37 -0700 (PDT) Received: from heliopolis.Eng.Sun.COM (esun1as-be.Central.Sun.COM [129.147.34.142]) by heliopolis.eng.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA05607; Fri, 13 Apr 2001 09:13:01 -0700 (PDT) From: Patrice Calhoun Message-Id: <200104131613.JAA05607@heliopolis.eng.sun.com> Date: Fri, 13 Apr 2001 12:08:26 -0700 To: "Phil Neumiller" , "Charles E. Perkins" Cc: Reply-To: Subject: Re: [seamoby] IETF Architecture Work (RANT) X-Mailer: Sun NetMail 2.3 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Sender: owner-seamoby@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit >The original wired Internet protocols didn't have to worry about AAA or >security or QoS to get massively deployed. Really? RADIUS was specifically designed to allow for ISPs to provide Internet access to users in a more scalable way.... and this is back in 1992! >I am going to respectfully disagree Charlie. It *COULD* have been >already deployed massively over WPAN and WLAN technology >had we ignored the cellular concerns of AAA and QoS and minutes >of use carrier class requirements and gone rapidly with a data only >model. Phil, please help me a little. How could we ever have guessed how Mobile IP would run over WPAN and WLAN, and could the IETF have ensured that MIP was used over these wireless technologies? (as an aside, alot of WLAN work has been in progress to use RADIUS/AAA to authenticate 802.11 mobiles) >I do agree with this, however, I also believe that the electoral system >taught us a lesson in the last US election, that a popular vote is not >necessarly best for the entire constituency. No, I think it taught us that we all have different beliefs, but this is hardly an IETF problem, is it? :) PatC From owner-seamoby@diameter.org Fri Apr 13 12:21:47 2001 Received: from charizard.diameter.org ([24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA12438 for ; Fri, 13 Apr 2001 12:21:47 -0400 (EDT) Received: (qmail 2215 invoked by alias); 13 Apr 2001 17:10:45 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 2209 invoked by uid 200); 13 Apr 2001 17:10:44 -0000 Received: (qmail 2203 invoked from network); 13 Apr 2001 17:10:42 -0000 Received: from mercury.sun.com (192.9.25.1) by c900656-a.plstn1.sfba.home.com with SMTP; 13 Apr 2001 17:10:42 -0000 Received: from heliopolis.eng.sun.com ([152.70.1.39]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA02220; Fri, 13 Apr 2001 09:18:10 -0700 (PDT) Received: from heliopolis.Eng.Sun.COM (esun1as-be.Central.Sun.COM [129.147.34.142]) by heliopolis.eng.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA05807; Fri, 13 Apr 2001 09:20:37 -0700 (PDT) From: Patrice Calhoun Message-Id: <200104131620.JAA05807@heliopolis.eng.sun.com> Date: Fri, 13 Apr 2001 12:16:02 -0700 To: "Charles E. Perkins" , "Phil Neumiller" Cc: Reply-To: Subject: Re: [seamoby] IETF Architecture Work (RANT) X-Mailer: Sun NetMail 2.3 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Sender: owner-seamoby@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit >> No, not SIGMOBILE, I was thinking of the Bluetooth SIG and some >> others. The IEEE is working on there own context transfer right now >> in 802.11 TG 17. > >Hmmm, that seems like a waste of time to me, I'll admit. First, chances are they started before we did, and second, we aren't even close to being done yet. Are you proposing that they just sit on the sidelines waiting? It would be nice, but perhaps not realistic. PatC From owner-seamoby@diameter.org Fri Apr 13 12:28:36 2001 Received: from charizard.diameter.org ([24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA12907 for ; Fri, 13 Apr 2001 12:28:35 -0400 (EDT) Received: (qmail 2713 invoked by alias); 13 Apr 2001 17:17:38 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 2707 invoked by uid 200); 13 Apr 2001 17:17:38 -0000 Received: (qmail 2702 invoked from network); 13 Apr 2001 17:17:37 -0000 Received: from mercury.sun.com (192.9.25.1) by c900656-a.plstn1.sfba.home.com with SMTP; 13 Apr 2001 17:17:37 -0000 Received: from heliopolis.eng.sun.com ([152.70.1.39]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA05123; Fri, 13 Apr 2001 09:25:00 -0700 (PDT) Received: from heliopolis.Eng.Sun.COM (esun1as-be.Central.Sun.COM [129.147.34.142]) by heliopolis.eng.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA05974; Fri, 13 Apr 2001 09:27:27 -0700 (PDT) From: Patrice Calhoun Message-Id: <200104131627.JAA05974@heliopolis.eng.sun.com> Date: Fri, 13 Apr 2001 12:22:51 -0700 To: "Phil Roberts" , , "'Phil Neumiller'" Reply-To: Subject: RE: [seamoby] IETF Architecture Work (RANT) X-Mailer: Sun NetMail 2.3 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Sender: owner-seamoby@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit >2. Perhaps we should take this up on the MIP list? Now that I think about >it, >perhaps this whole thing should be on the MIP list. (Sorry, Pat). Oh, you can take this thread to your list. No objections on my side. I always dislike bashing other protocols on this list, but we seem to entertain plenty such threads :( PatC From owner-seamoby@diameter.org Fri Apr 13 14:19:04 2001 Received: from charizard.diameter.org ([24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA15636 for ; Fri, 13 Apr 2001 14:19:03 -0400 (EDT) Received: (qmail 1450 invoked by alias); 13 Apr 2001 18:06:54 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 1444 invoked by uid 200); 13 Apr 2001 18:06:53 -0000 Received: (qmail 1439 invoked from network); 13 Apr 2001 18:06:51 -0000 Received: from c007-h012.c007.snv.cp.net (HELO c007.snv.cp.net) (209.228.33.219) by c900656-a.plstn1.sfba.home.com with SMTP; 13 Apr 2001 18:06:51 -0000 Received: (cpmta 21027 invoked from network); 13 Apr 2001 11:15:11 -0700 Received: from unknown (HELO federalmobility.com) (64.193.0.129) by smtp.federalmobility.com (209.228.33.219) with SMTP; 13 Apr 2001 11:15:11 -0700 X-Sent: 13 Apr 2001 18:15:11 GMT Message-ID: <3AD741DF.6D571DCC@federalmobility.com> Date: Fri, 13 Apr 2001 13:13:51 -0500 From: Phil Neumiller Organization: Federal Mobility X-Mailer: Mozilla 4.77 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Pat.Calhoun@Sun.COM, seamoby@diameter.org Subject: [seamoby] MIP & SeaMoby are 3G biased References: <200104131644.JAA06399@heliopolis.eng.sun.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-seamoby@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit Pat, Gary, and ADs, Interesting you should mention the "Internet community" Pat because 3G networks are private and not part of "that" community as far as I can tell. We are not here to work with or for potential customers especially if they are another SDO building private networks. We are here to improve the global Internet. If that is what you and Gary are here for, I suggest you take your work elsewhere (perhaps 3GPP2) and leave SeaMoby to work on the global Internet as WGs in the IETF are supposed to do. The IETF is supposed to architect the global Internet and that is "its" priority not 3GPP or 3GPP2 "customers". I am going to raise hell about this Pat. It has become very clear to me that MIP (from what Raj and Phil R. have said) and SeaMoby are now completely biased towards 3G and I am taking this to the IESG. If my appeal goes nowhere, then I have lost, but at least I have stated my case and I have stood up for what I believe. I don't mind being called a "conspiracy wacko" since I will be in good company. Best regards, Phil Neumiller Patrice Calhoun wrote: > >> Pat, Gary, and Hamid, are we working for MIP/3G or not? We > >> need to know now to stop > >> a draft that could be completely pointless IMHO. > > > >Frankly, you have lost me. I either don't get your point, or your > >arguing both sides of a solution issue. > > Ditto. > > Perhaps we could stop the conspiracy theories, and start working on requirements > gathering for a protocol that will be useful for the Internet Community. If the > 3Gs are a potential customer, then so be it, but we are focusing on a protocol > that has wider applicability. > > PatC From owner-seamoby@diameter.org Fri Apr 13 14:29:30 2001 Received: from charizard.diameter.org ([24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA15766 for ; Fri, 13 Apr 2001 14:29:28 -0400 (EDT) Received: (qmail 2022 invoked by alias); 13 Apr 2001 18:18:25 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 2016 invoked by uid 200); 13 Apr 2001 18:18:24 -0000 Received: (qmail 2011 invoked from network); 13 Apr 2001 18:18:22 -0000 Received: from mercury.sun.com (192.9.25.1) by c900656-a.plstn1.sfba.home.com with SMTP; 13 Apr 2001 18:18:22 -0000 Received: from heliopolis.eng.sun.com ([152.70.1.39]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA24571; Fri, 13 Apr 2001 11:24:52 -0700 (PDT) Received: from heliopolis.Eng.Sun.COM (esun1as-be.Central.Sun.COM [129.147.34.142]) by heliopolis.eng.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA09569; Fri, 13 Apr 2001 11:27:21 -0700 (PDT) From: Patrice Calhoun Message-Id: <200104131827.LAA09569@heliopolis.eng.sun.com> Date: Fri, 13 Apr 2001 14:22:46 -0700 To: "Phil Neumiller" , , Reply-To: Subject: [seamoby] Re: MIP & SeaMoby are 3G biased X-Mailer: Sun NetMail 2.3 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Sender: owner-seamoby@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit >Interesting you should mention the "Internet community" Pat because >3G networks are private and not part of "that" community as far as I can >tell. If you persist... I'll play. As far as I can tell, if no one ever did anything with IETF protocols, there wouldn't be an Internet Community. So I don't see the 3G folks being any different from cable modem, DSL or even the modem folks that really need lots of PPP features. It's just another IP delivery service, for the community. > We are not here to work with or for potential customers especially if >they are another SDO building private networks. We are here to improve >the global Internet. Correct, and if some of the SDOs end up building private networks, then that would be a shame. Of course, we cannot prevent them from doing so, but I am not convinced that P2 is intending to build private networks either. > >If that is what you and Gary are here for, I suggest you take your work >elsewhere (perhaps 3GPP2) and leave SeaMoby to work on the global >Internet as WGs in the IETF are supposed to do. The IETF is supposed >to architect the global Internet and that is "its" priority not 3GPP or >3GPP2 "customers". hmm.... I haven't actually started any work here. I am just the chair. I have never, as far as I can tell, stated that we are custom building protocols for P2. In fact, even in the MIP WG, we made damn sure that it was generic enough to be used by *any* wireless technology. In fact, look at the R-P interface, which ended up in the MIP WG. I worked on an alternative that was NOT cdma2000 specific, and could be used by *any* network. My goal is to make sure that IP protocols are not built for a particular link layer. Of course, I cannot prevent people from using such protocols, and that's what P2 is doing. So, I am a little confused by your statements. oh, and by the way, if some 3GPP2 folks want to bring in their requirements, and no one else from any other SDO does, then are you stating that we should ignore 3GPP2 for wanting to collaborate with the IETF?? > I am going to raise hell about this Pat. mailto://iesg@ietf.org > It has become >very clear to me that MIP (from what Raj and Phil R. have said) and >SeaMoby are now completely biased towards 3G and I am taking this >to the IESG. ok, free country. (of course, keep in mind that seamoby has *never* come up as a topic in *any* of the 3GPP2 TSG-P meeting I've been at...) >If my appeal goes nowhere, then I have lost, but at least >I have stated my case and I have stood up for what I believe. I don't >mind being called a "conspiracy wacko" since I will be in good company. please feel free to completely misrepresent what we've been striving for the past two years. I will be there to defend myself. Now, these accusations really have nothing to do with *any* seamoby work, so I propose you take this thread, and send it to me, anyone else you think would care, and cc the IESG (if you think that is appropriate). PatC From owner-seamoby@diameter.org Fri Apr 13 14:33:58 2001 Received: from charizard.diameter.org ([24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA15845 for ; Fri, 13 Apr 2001 14:33:57 -0400 (EDT) Received: (qmail 2523 invoked by alias); 13 Apr 2001 18:23:33 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 2517 invoked by uid 200); 13 Apr 2001 18:23:33 -0000 Received: (qmail 2512 invoked from network); 13 Apr 2001 18:23:31 -0000 Received: from unknown (HELO NEPTUNE.zucotto.com) (216.95.209.154) by c900656-a.plstn1.sfba.home.com with SMTP; 13 Apr 2001 18:23:31 -0000 Received: by NEPTUNE.zucotto.com with Internet Mail Service (5.5.2653.19) id ; Fri, 13 Apr 2001 14:32:36 -0400 Message-ID: <6833D86F1B05CA4FBAB3C73DD98BD8B90D2B37@NEPTUNE.zucotto.com> From: Kulwinder Atwal To: "'Phil Neumiller'" , Kulwinder Atwal , seamoby@cdma-2000.org Subject: RE: [seamoby] IETF Architecture Work (RANT) Date: Fri, 13 Apr 2001 14:32:35 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-seamoby@diameter.org Precedence: bulk > -----Original Message----- > From: Phil Neumiller [mailto:neumiller@telocity.com] > Sent: Friday, April 13, 2001 7:27 AM > To: Kulwinder Atwal; seamoby@cdma-2000.org > Subject: Re: [seamoby] IETF Architecture Work (RANT) > > But, it is impossible to predict the optimal frequency that > route updates > > should occur. A user, or vehicle may remain stationary for > hours at a time > > then move at a high rate. Should the router update occur > once per 30 > > seconds, per hour, or per millisecond? What about Context Transfer? > > Yes we have your point, event driven systems are better in many ways, > but I think they are only reliable if redundancy is added and > many times > timers are adding that redundancy (in the time domain) when the event > triggers fail (in the frequency domain). Timers are an L2 issue. They are necessary, but at the L2 level. A Timer is a physical embodiment. It belongs at L2. Link reliability (redundancy) is an L2 issue. Logical Trigger: Route Lost Physical Event: Timer times out, or other side terminates link. > > > > > Is the endpoint record a fridge, ID Badge, stereo, person, > car, ship or > > plane? > > > > This is why context transfer and route updates need to > occur based on > > Physical Events propagated up the stack as Logical > Triggers. NOT TIMERS. > > Becuase it is impossible to predict the Usage Model. > > If you study MANET algorithms Kulwinder you will see that > this is exactly > how they work (at least in the routing sense). I attended the MANET WG meeting. All of the proposals had timers. I discussed this with the Co-Chair, Joe Macker. It appears as if most of the work seems to be taylored to 802.11. Since 802.11 is primarily a PHY, with no link reliability mechanisms (no MAC), the solutions presented introduced timers to compensate for a full MAC. > > > > > The mapping of Physical Events to Logical Triggers may > change depending on > > the technology, application, external event, or user preference. > > > > We need enable all current and future Usage Models. > > A bit altruistic, but I'll try to help, I like generalized solutions! Not as altruistic as you think. This is primarily an IETF-centric view. The SIG has many Usage Models currently and in development. Since the SIG encourages future profiles to be IP based, future Usage Models will be IP based as well. - Kulwinder. From owner-seamoby@diameter.org Fri Apr 13 14:39:28 2001 Received: from charizard.diameter.org ([24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA15944 for ; Fri, 13 Apr 2001 14:39:27 -0400 (EDT) Received: (qmail 3050 invoked by alias); 13 Apr 2001 18:29:18 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 3044 invoked by uid 200); 13 Apr 2001 18:29:18 -0000 Received: (qmail 3038 invoked from network); 13 Apr 2001 18:29:15 -0000 Received: from unknown (HELO NEPTUNE.zucotto.com) (216.95.209.154) by c900656-a.plstn1.sfba.home.com with SMTP; 13 Apr 2001 18:29:15 -0000 Received: by NEPTUNE.zucotto.com with Internet Mail Service (5.5.2653.19) id ; Fri, 13 Apr 2001 14:38:21 -0400 Message-ID: <6833D86F1B05CA4FBAB3C73DD98BD8B90D2B38@NEPTUNE.zucotto.com> From: Kulwinder Atwal To: "'Pat.Calhoun@Sun.COM'" , Phil Neumiller , john.loughney@nokia.com, James Kempf Cc: seamoby@cdma-2000.org Subject: RE: [seamoby] IETF Architecture Work (RANT) Date: Fri, 13 Apr 2001 14:38:21 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-seamoby@diameter.org Precedence: bulk > -----Original Message----- > From: Patrice Calhoun [mailto:Pat.Calhoun@Sun.COM] > Sent: Friday, April 13, 2001 2:50 PM > To: Phil Neumiller; john.loughney@nokia.com; James Kempf > Cc: seamoby@cdma-2000.org > Subject: Re: [seamoby] IETF Architecture Work (RANT) > > Well, I suppose one could argue that the IETF is there to > build protocols > that will be used in the real world. So far 3GPP2 is the one > big one that > has come up and stated that they will deploy MIP in a large > scale network. > > > Any "other" customer is free to come to the IETF and state > they requirements. > I can assure you that they would be heard, and cooperation is > guaranteed. > However, we cannot just build something and then shove it > down their throats :( The SIG did come and state its requirements to the IESG. You were invited. You missed that meeting, becuase you thought we were meeting in the bar downstairs. The SIG is composed of 2481 companies is that big enough for you? - Kulwinder. > > From owner-seamoby@diameter.org Fri Apr 13 15:25:29 2001 Received: from charizard.diameter.org ([24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA16588 for ; Fri, 13 Apr 2001 15:25:28 -0400 (EDT) Received: (qmail 3752 invoked by alias); 13 Apr 2001 18:55:17 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 3746 invoked by uid 200); 13 Apr 2001 18:55:17 -0000 Received: (qmail 3741 invoked from network); 13 Apr 2001 18:55:15 -0000 Received: from mercury.sun.com (192.9.25.1) by c900656-a.plstn1.sfba.home.com with SMTP; 13 Apr 2001 18:55:15 -0000 Received: from heliopolis.eng.sun.com ([152.70.1.39]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA12191; Fri, 13 Apr 2001 12:01:36 -0700 (PDT) Received: from heliopolis.Eng.Sun.COM (esun1as-be.Central.Sun.COM [129.147.34.142]) by heliopolis.eng.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA10485; Fri, 13 Apr 2001 12:04:04 -0700 (PDT) From: Patrice Calhoun Message-Id: <200104131904.MAA10485@heliopolis.eng.sun.com> Date: Fri, 13 Apr 2001 14:59:33 -0700 To: "Kulwinder Atwal" , "James Kempf" , , "Phil Neumiller" , "'Pat.Calhoun@Sun.COM'" Cc: Reply-To: Subject: RE: [seamoby] IETF Architecture Work (RANT) X-Mailer: Sun NetMail 2.3 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Sender: owner-seamoby@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit >> Any "other" customer is free to come to the IETF and state >> they requirements. >> I can assure you that they would be heard, and cooperation is >> guaranteed. >> However, we cannot just build something and then shove it >> down their throats :( > >The SIG did come and state its requirements to the IESG. You were invited. >You missed that meeting, becuase you thought we were meeting in the bar >downstairs. The SIG is composed of 2481 companies is that big enough for >you? (assuming that you are criticizing my note) Yes, and I am sorry that I was not able to find you guys. I realize that this was a first attempt, and I applaud the effort. Of course, in the future, it would be nice for bluetooth to take their requirements and make them known in the individual WGs where the work occurs, since that's the way the IETF works. I am quite certain this is the intended direction, so no response is necessary (unless I am wrong). btw, I was not in any way shape or form, stating that bluetooth, or any other SDO doesn't want to collaborate. This is a response to why MIP has been listening to 3GPP2. Bluetooth, up to now, has never been putting requirments in the Mobile IP WG. However, look at the following for a great example of how some external SDOs can get their requirements heard in the IETF (note that the document is not "authored" by an SDO, but by IETF folks that have an interest in the particular SDO. ftp://ftp.isi.edu/internet-drafts/draft-hiller-cdma2000-aaa-02.txt Oh and for what it's worth, AAA was not custom designed for 3GPP2. However, their requirements were fulfilled in the protocol design phase. Hope this helps, PatC From owner-seamoby@diameter.org Fri Apr 13 15:28:21 2001 Received: from charizard.diameter.org ([24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA16615 for ; Fri, 13 Apr 2001 15:28:20 -0400 (EDT) Received: (qmail 4474 invoked by alias); 13 Apr 2001 19:18:15 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 4468 invoked by uid 200); 13 Apr 2001 19:18:15 -0000 Received: (qmail 4463 invoked from network); 13 Apr 2001 19:18:14 -0000 Received: from unknown (HELO NEPTUNE.zucotto.com) (216.95.209.154) by c900656-a.plstn1.sfba.home.com with SMTP; 13 Apr 2001 19:18:14 -0000 Received: by NEPTUNE.zucotto.com with Internet Mail Service (5.5.2653.19) id ; Fri, 13 Apr 2001 15:27:19 -0400 Message-ID: <6833D86F1B05CA4FBAB3C73DD98BD8B90D2B3A@NEPTUNE.zucotto.com> From: Kulwinder Atwal To: "'Phil Neumiller'" , Kulwinder Atwal , seamoby@cdma-2000.org Subject: RE: [seamoby] IETF Architecture Work (RANT) Date: Fri, 13 Apr 2001 15:27:19 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-seamoby@diameter.org Precedence: bulk > -----Original Message----- > From: Phil Neumiller [mailto:neumiller@telocity.com] > Sent: Friday, April 13, 2001 7:27 AM > To: Kulwinder Atwal; seamoby@cdma-2000.org > Subject: Re: [seamoby] IETF Architecture Work (RANT) > > > > As far as the database portion goes, I would like you take a look at > some work going on in Randy Katz's group at Berkley. They have > something called OceanStore that is incredibly cool. In this model > your secure data follows you around as you are mobile and sloshes > around in something analogous to a service provider SANs (storage > area network). You only need your privacy key and a secure pipe > to carry your entire digital library around wherever you go. Here is > the URL http://oceanstore.cs.berkeley.edu/ . > This is closer to what I was thinking. Although, maybe not the entire digital library, just the part that is most used. -Kulwinder. From owner-seamoby@diameter.org Fri Apr 13 16:07:59 2001 Received: from charizard.diameter.org ([24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA17101 for ; Fri, 13 Apr 2001 16:07:57 -0400 (EDT) Received: (qmail 5254 invoked by alias); 13 Apr 2001 19:57:00 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 5249 invoked by uid 200); 13 Apr 2001 19:57:00 -0000 Received: (qmail 5243 invoked from network); 13 Apr 2001 19:56:58 -0000 Received: from out4.prserv.net (HELO prserv.net) (32.97.166.34) by c900656-a.plstn1.sfba.home.com with SMTP; 13 Apr 2001 19:56:58 -0000 Received: from [32.101.185.42] (slip-32-101-185-42.ca.us.prserv.net[32.101.185.42]) by prserv.net (out4) with ESMTP id <2001041320055720400gc2eke>; Fri, 13 Apr 2001 20:05:57 +0000 Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Sender: ahmrphd@pop3.attglobal.net Message-Id: In-Reply-To: <3AD741DF.6D571DCC@federalmobility.com> References: <200104131644.JAA06399@heliopolis.eng.sun.com> Date: Fri, 13 Apr 2001 12:57:02 -0700 To: Phil Neumiller , Pat.Calhoun@Sun.COM, seamoby@diameter.org From: Arthur Ross Subject: Re: [seamoby] MIP & SeaMoby are 3G biased Sender: owner-seamoby@diameter.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id QAA17101 At 11:13 -0700 04/13/2001, Phil Neumiller wrote: >Pat, Gary, and ADs, > >Interesting you should mention the "Internet community" Pat because >3G networks are private and not part of "that" community as far as I can >tell. We are not here to work with or for potential customers especially if >they are another SDO building private networks. We are here to improve >the global Internet. > >If that is what you and Gary are here for, I suggest you take your work >elsewhere (perhaps 3GPP2) and leave SeaMoby to work on the global >Internet as WGs in the IETF are supposed to do. The IETF is supposed >to architect the global Internet and that is "its" priority not 3GPP or >3GPP2 "customers". I am going to raise hell about this Pat. It has become >very clear to me that MIP (from what Raj and Phil R. have said) and >SeaMoby are now completely biased towards 3G and I am taking this >to the IESG. If my appeal goes nowhere, then I have lost, but at least >I have stated my case and I have stood up for what I believe. I don't >mind being called a "conspiracy wacko" since I will be in good company. > As usual, I have to echo Phil's view. What we have here is a fundamental clash. A clash both of culture, and of structure/charter. There are very fundamental difference between the IETF and the SDOs. The formal SDOs (the members of the 3GPPs), such as TIA and ETSI, are industry consortia of for-profit companies. They have membership fees (usually quite large). They have dedicated offices, full-time paid employees, attorneys, formal charters, formal rules of procedure, and formal governing bodies. They exist, to a large degree, as a sort of insurance against accusations of unfair collusion that undoubtedly would ensue if there were to be privately cooked up standards. A long-time rep of one of the telecom giants once told me that those open meetings are "what keeps us all out of jail", a view that my personal experience with them reinforces. They do indeed have a very strong mutual self-interest in producing well thought out standards that work (not always achieved, as we all know), and they do it with great formality and rigorous process. The IETF is a totally different animal. It is, as I understand it, all volunteer, uncompensated, with facilities, such as they are, provided pro bono by various educational, government, and corporate entities. Its organization is loose and informal, depending on a spirit of mutual cooperation and good will, rather than bureacracies, legalistic procedures, and attorneys, to accomplish its work. This is a sure-fire recipe for conflict, given the fact of the Internet explosion as a global business platform. The notion of supporting "customers" for the IETF work product has no formal basis; rather, it is only a vague notion of openess and reasonableness, with diverse opinions as to what that means, in the minds of the participants. The closest thing I have found to a guiding principle relevant to this argument seems to be RFC2026, §1.1: The Internet, a loosely-organized international collaboration of autonomous, interconnected networks, supports host-to-host communication through voluntary adherence to open protocols and procedures defined by Internet Standards. There are also many isolated interconnected networks, which are not connected to the global Internet but use the Internet Standards. The Internet Standards Process described in this document is concerned with all protocols, procedures, and conventions that are used in or by the Internet, whether or not they are part of the TCP/IP protocol suite. In the case of protocols developed and/or standardized by non-Internet organizations, however, the Internet Standards Process normally applies to the application of the protocol or procedure in the Internet context, not to the specification of the protocol itself. It does seem that Phil's right, given this current framework. The IETF exists for the good of the global Internet, not necessarily as a service organization to the business world, except where the business interest coincides with the good-of-the-Internet criterion. This seems like a very fundamental question of philosophy, scope, & charter. Is it perhaps time to think about creating a formal charter for the IETF? I personally tend to oppose that, but the fact of the well-funded 800 pound gorilla that is "3G" may make this attitude difficult to sustain in practice. Is the "good-of-the-Internet" for sale to those with the deepest pockets (read: most able to send an army of partisans to the working groups)? This needs to be confronted. Please sign me up as another of those "wackos". -- Best regards, -- Arthur From owner-seamoby@diameter.org Fri Apr 13 16:23:11 2001 Received: from charizard.diameter.org ([24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA17288 for ; Fri, 13 Apr 2001 16:23:10 -0400 (EDT) Received: (qmail 5951 invoked by alias); 13 Apr 2001 20:13:03 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 5945 invoked by uid 200); 13 Apr 2001 20:13:02 -0000 Received: (qmail 5940 invoked from network); 13 Apr 2001 20:13:00 -0000 Received: from patan.sun.com (192.18.98.43) by c900656-a.plstn1.sfba.home.com with SMTP; 13 Apr 2001 20:13:00 -0000 Received: from heliopolis.eng.sun.com ([152.70.1.39]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA00911; Fri, 13 Apr 2001 13:22:05 -0700 (PDT) Received: from srmtv29a (srmtv29a [152.70.1.41]) by heliopolis.eng.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id NAA12324; Fri, 13 Apr 2001 13:22:04 -0700 (PDT) Message-Id: <200104132022.NAA12324@heliopolis.eng.sun.com> Date: Fri, 13 Apr 2001 13:22:05 -0700 (PDT) From: James Kempf Reply-To: James Kempf Subject: Timers (was: RE: [seamoby] IETF Architecture Work (RANT)) To: neumiller@telocity.com, kulwinder.atwal@zucotto.com, seamoby@cdma-2000.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: koSu9PP4T0Rwdu3lOI7qGQ== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 sun4u sparc Sender: owner-seamoby@diameter.org Precedence: bulk >I attended the MANET WG meeting. All of the proposals had timers. >I discussed this with the Co-Chair, Joe Macker. It appears as if most of >the work seems to be taylored to 802.11. > >Since 802.11 is primarily a PHY, with no link reliability mechanisms (no >MAC), the solutions presented introduced timers to compensate for a full >MAC. > Then why don't you take this to the MANET mailing list? I don't see anything specifically seamoby related here. jak From owner-seamoby@diameter.org Fri Apr 13 16:27:26 2001 Received: from charizard.diameter.org ([24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA17325 for ; Fri, 13 Apr 2001 16:27:24 -0400 (EDT) Received: (qmail 6421 invoked by alias); 13 Apr 2001 20:17:09 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 6415 invoked by uid 200); 13 Apr 2001 20:17:09 -0000 Received: (qmail 6410 invoked from network); 13 Apr 2001 20:17:07 -0000 Received: from unknown (HELO NEPTUNE.zucotto.com) (216.95.209.154) by c900656-a.plstn1.sfba.home.com with SMTP; 13 Apr 2001 20:17:07 -0000 Received: by NEPTUNE.zucotto.com with Internet Mail Service (5.5.2653.19) id ; Fri, 13 Apr 2001 16:26:13 -0400 Message-ID: <6833D86F1B05CA4FBAB3C73DD98BD8B90D2B3B@NEPTUNE.zucotto.com> From: Kulwinder Atwal To: "'Pat.Calhoun@Sun.COM'" , Kulwinder Atwal , James Kempf , john.loughney@nokia.com, Phil Neumiller Cc: seamoby@cdma-2000.org Subject: RE: [seamoby] IETF Architecture Work (RANT) Date: Fri, 13 Apr 2001 16:26:12 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-seamoby@diameter.org Precedence: bulk > -----Original Message----- > From: Patrice Calhoun [mailto:Pat.Calhoun@Sun.COM] > Sent: Friday, April 13, 2001 6:00 PM > To: Kulwinder Atwal; James Kempf; john.loughney@nokia.com; Phil > Neumiller; 'Pat.Calhoun@Sun.COM' > Cc: seamoby@cdma-2000.org > Subject: RE: [seamoby] IETF Architecture Work (RANT) > > > btw, I was not in any way shape or form, stating that > bluetooth, or any other > SDO doesn't want to collaborate. This is a response to why > MIP has been > listening to 3GPP2. Bluetooth, up to now, has never been > putting requirments > in the Mobile IP WG The SIG members that I have talked to feel that MIP is a cellular protocol for 3GPP2. And as such, feel that MANET is probably the best place for a Mobile Router protocol. Like the IETF the SIG has a loose organizational structure. It will be impossible to get 100% agreement on everything. The best that we can hope for is that the SIG Usage Models that deal with the Internet also deal with the IETF. Also, the IETF will need to start considering how to enable other Usage Models besides stationary computers with fixed IP addresses. Although, this Usage Model has not be stated explicitly by the IETF as 'Architecture', it has been developed implicitly through design assumptions. Thanks for the link. - Kulwinder. > . However, look at the following for a > great example of how > some external SDOs can get their requirements heard in the > IETF (note that the > document is not "authored" by an SDO, but by IETF folks that > have an interest > in the particular SDO. > > ftp://ftp.isi.edu/internet-drafts/draft-hiller-cdma2000-aaa-02.txt > > Oh and for what it's worth, AAA was not custom designed for > 3GPP2. However, > their requirements were fulfilled in the protocol design phase. > > Hope this helps, > > PatC > From owner-seamoby@diameter.org Fri Apr 13 16:35:48 2001 Received: from charizard.diameter.org ([24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA17613 for ; Fri, 13 Apr 2001 16:35:45 -0400 (EDT) Received: (qmail 6994 invoked by alias); 13 Apr 2001 20:25:00 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 6988 invoked by uid 200); 13 Apr 2001 20:24:59 -0000 Received: (qmail 6983 invoked from network); 13 Apr 2001 20:24:57 -0000 Received: from mercury.sun.com (192.9.25.1) by c900656-a.plstn1.sfba.home.com with SMTP; 13 Apr 2001 20:24:57 -0000 Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA22009; Fri, 13 Apr 2001 13:30:21 -0700 (PDT) Received: from nasnfs.Eng.Sun.COM (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA24545; Fri, 13 Apr 2001 13:32:49 -0700 (PDT) Received: from darius (darius [152.70.40.121]) by nasnfs.Eng.Sun.COM (8.9.3+Sun/8.9.1) with SMTP id NAA08669; Fri, 13 Apr 2001 13:32:47 -0700 (PDT) Date: Fri, 13 Apr 2001 13:32:47 -0700 (PDT) From: Patrice Calhoun Reply-To: Patrice Calhoun Subject: RE: [seamoby] IETF Architecture Work (RANT) To: Kulwinder Atwal Cc: "'Pat.Calhoun@Sun.COM'" , James Kempf , john.loughney@nokia.com, Phil Neumiller , seamoby@cdma-2000.org In-Reply-To: "Your message with ID" <6833D86F1B05CA4FBAB3C73DD98BD8B90D2B3B@NEPTUNE.zucotto.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-seamoby@diameter.org Precedence: bulk > > btw, I was not in any way shape or form, stating that > > bluetooth, or any other > > SDO doesn't want to collaborate. This is a response to why > > MIP has been > > listening to 3GPP2. Bluetooth, up to now, has never been > > putting requirments > > in the Mobile IP WG > > The SIG members that I have talked to feel that MIP is a cellular protocol > for 3GPP2. And as such, feel that MANET is probably the best place for a > Mobile Router protocol. Well that is a shame. I would really like these people to work with the WG, instead of assuming that it is custom tailored to the cellular industry. The reality is that these are the folks that showed some interest in Mobile IP, so there was a fair amount of collaboration. However, if there are some requirements that aren't satisfied in MIP, now would be a great time to make that known. If you have specific requirements that aren't in the charter, then those should also be made known. I am quite certain that the Mobile IP WG would be most willing to entertain a list of new requirements from some peole with Bluetooth interest. > Like the IETF the SIG has a loose organizational structure. It will be > impossible to get 100% agreement on everything. The best that we can hope > for is that the SIG Usage Models that deal with the Internet also deal with > the IETF. sure, some collaboration is a hell of alot better than none. > Also, the IETF will need to start considering how to enable other Usage > Models besides stationary computers with fixed IP addresses. Although, this > Usage Model has not be stated explicitly by the IETF as 'Architecture', it > has been developed implicitly through design assumptions. I believe that the IESG has recently acknowledged that wireless is a big market, and has been very willing to listen to market needs. PatC From owner-seamoby@diameter.org Fri Apr 13 16:38:03 2001 Received: from charizard.diameter.org ([24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA17691 for ; Fri, 13 Apr 2001 16:38:02 -0400 (EDT) Received: (qmail 7034 invoked by alias); 13 Apr 2001 20:25:23 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 7028 invoked by uid 200); 13 Apr 2001 20:25:22 -0000 Received: (qmail 7023 invoked from network); 13 Apr 2001 20:25:21 -0000 Received: from unknown (HELO NEPTUNE.zucotto.com) (216.95.209.154) by c900656-a.plstn1.sfba.home.com with SMTP; 13 Apr 2001 20:25:21 -0000 Received: by NEPTUNE.zucotto.com with Internet Mail Service (5.5.2653.19) id ; Fri, 13 Apr 2001 16:34:27 -0400 Message-ID: <6833D86F1B05CA4FBAB3C73DD98BD8B90D2B3C@NEPTUNE.zucotto.com> From: Kulwinder Atwal To: "'James Kempf'" , neumiller@telocity.com, Kulwinder Atwal , seamoby@cdma-2000.org Subject: RE: Timers (was: RE: [seamoby] IETF Architecture Work (RANT)) Date: Fri, 13 Apr 2001 16:34:24 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-seamoby@diameter.org Precedence: bulk > -----Original Message----- > From: James Kempf [mailto:James.Kempf@Sun.COM] > Sent: Friday, April 13, 2001 4:22 PM > To: neumiller@telocity.com; kulwinder.atwal@zucotto.com; > seamoby@cdma-2000.org > Subject: Timers (was: RE: [seamoby] IETF Architecture Work (RANT)) > > > Then why don't you take this to the MANET mailing list? I don't > see anything specifically seamoby related here. Just a few days ago on the Context Transfer Design team we discussed Timers. A few days before that we taked about Timers in IP Paging. Your Requirements draft: "time-slotted dormant mode where the mobile periodicaly wake-up" Sounds like a timer. Is it an L2 timer propagated up the stack as an L3 Trigger? - Kulwinder. > > jak > From owner-seamoby@diameter.org Fri Apr 13 16:40:37 2001 Received: from charizard.diameter.org ([24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA17836 for ; Fri, 13 Apr 2001 16:40:36 -0400 (EDT) Received: (qmail 7456 invoked by alias); 13 Apr 2001 20:27:33 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 7446 invoked by uid 200); 13 Apr 2001 20:27:33 -0000 Received: (qmail 7434 invoked from network); 13 Apr 2001 20:27:28 -0000 Received: from sj-msg-core-4.cisco.com (171.71.163.10) by c900656-a.plstn1.sfba.home.com with SMTP; 13 Apr 2001 20:27:28 -0000 Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-4.cisco.com (8.9.3/8.9.1) with ESMTP id NAA02444; Fri, 13 Apr 2001 13:36:06 -0700 (PDT) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id ADZ28142; Fri, 13 Apr 2001 13:36:01 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id NAA08283; Fri, 13 Apr 2001 13:36:01 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15063.25392.892795.587295@thomasm-u1.cisco.com> Date: Fri, 13 Apr 2001 13:36:00 -0700 (PDT) To: Kulwinder Atwal Cc: "'Pat.Calhoun@Sun.COM'" , James Kempf , john.loughney@nokia.com, Phil Neumiller , seamoby@cdma-2000.org Subject: RE: [seamoby] IETF Architecture Work (RANT) In-Reply-To: <6833D86F1B05CA4FBAB3C73DD98BD8B90D2B3B@NEPTUNE.zucotto.com> References: <6833D86F1B05CA4FBAB3C73DD98BD8B90D2B3B@NEPTUNE.zucotto.com> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-seamoby@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit Kulwinder Atwal writes: > Like the IETF the SIG has a loose organizational structure. It will be > impossible to get 100% agreement on everything. The best that we can hope > for is that the SIG Usage Models that deal with the Internet also deal with > the IETF. The best possible thing that your SIG could do is define a good transport for IP and then dissolve itself. Really. Mike From owner-seamoby@diameter.org Fri Apr 13 16:48:19 2001 Received: from charizard.diameter.org ([24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA18200 for ; Fri, 13 Apr 2001 16:48:18 -0400 (EDT) Received: (qmail 8457 invoked by alias); 13 Apr 2001 20:38:03 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 8451 invoked by uid 200); 13 Apr 2001 20:38:02 -0000 Received: (qmail 8446 invoked from network); 13 Apr 2001 20:38:00 -0000 Received: from c007-h008.c007.snv.cp.net (HELO c007.snv.cp.net) (209.228.33.214) by c900656-a.plstn1.sfba.home.com with SMTP; 13 Apr 2001 20:38:00 -0000 Received: (cpmta 27760 invoked from network); 13 Apr 2001 13:46:57 -0700 Received: from dsl-64-193-0-129.telocity.com (HELO philneum) (64.193.0.129) by smtp.telocity.com (209.228.33.214) with SMTP; 13 Apr 2001 13:46:57 -0700 X-Sent: 13 Apr 2001 20:46:57 GMT Message-ID: <042001c0c45a$c1c52f40$6501a8c0@philneum> Reply-To: "Phil Neumiller" From: "Phil Neumiller" To: "Michael Thomas" , "Kulwinder Atwal" Cc: , "James Kempf" , , References: <6833D86F1B05CA4FBAB3C73DD98BD8B90D2B3B@NEPTUNE.zucotto.com> <15063.25392.892795.587295@thomasm-u1.cisco.com> Subject: Re: [seamoby] IETF Architecture Work (RANT) Date: Fri, 13 Apr 2001 15:45:57 -0500 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-seamoby@diameter.org Precedence: bulk I agree with Michael. The rest of the profile stuff is fluff, unless it is brought into the IETF to be used with "all" IP supported wireless devices not just Bluetooth. Given a good IP binding this would be very doable otherwise the Bluetooth SIG is blowing smoke. ----- Original Message ----- From: "Michael Thomas" To: "Kulwinder Atwal" Cc: ; "James Kempf" ; ; "Phil Neumiller" ; Sent: Friday, April 13, 2001 3:36 PM Subject: RE: [seamoby] IETF Architecture Work (RANT) > Kulwinder Atwal writes: > > Like the IETF the SIG has a loose organizational structure. It will be > > impossible to get 100% agreement on everything. The best that we can hope > > for is that the SIG Usage Models that deal with the Internet also deal with > > the IETF. > > The best possible thing that your SIG could do > is define a good transport for IP and then > dissolve itself. > > Really. > > Mike > From owner-seamoby@diameter.org Fri Apr 13 16:50:23 2001 Received: from charizard.diameter.org ([24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA18248 for ; Fri, 13 Apr 2001 16:50:22 -0400 (EDT) Received: (qmail 8668 invoked by alias); 13 Apr 2001 20:38:54 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 8658 invoked by uid 200); 13 Apr 2001 20:38:51 -0000 Received: (qmail 8637 invoked from network); 13 Apr 2001 20:38:48 -0000 Received: from unknown (HELO NEPTUNE.zucotto.com) (216.95.209.154) by c900656-a.plstn1.sfba.home.com with SMTP; 13 Apr 2001 20:38:48 -0000 Received: by NEPTUNE.zucotto.com with Internet Mail Service (5.5.2653.19) id ; Fri, 13 Apr 2001 16:47:53 -0400 Message-ID: <6833D86F1B05CA4FBAB3C73DD98BD8B90D2B3D@NEPTUNE.zucotto.com> From: Kulwinder Atwal To: "'Michael Thomas'" , Kulwinder Atwal Cc: "'Pat.Calhoun@Sun.COM'" , James Kempf , john.loughney@nokia.com, Phil Neumiller , seamoby@cdma-2000.org Subject: RE: [seamoby] IETF Architecture Work (RANT) Date: Fri, 13 Apr 2001 16:47:52 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-seamoby@diameter.org Precedence: bulk > -----Original Message----- > From: Michael Thomas [mailto:mat@cisco.com] > Sent: Friday, April 13, 2001 4:36 PM > To: Kulwinder Atwal > Cc: 'Pat.Calhoun@Sun.COM'; James Kempf; john.loughney@nokia.com; Phil > Neumiller; seamoby@cdma-2000.org > Subject: RE: [seamoby] IETF Architecture Work (RANT) > > The best possible thing that your SIG could do > is define a good transport for IP and then > dissolve itself. You could say the same thing about the 80 or so vendors in Wi-Fi (802.11). Right? Are you suggesting that Wi-Fi be disolved? > > Really. > This is a very Internet centric view. It may be hard to imagine, but Bluetooth really does have more applications than a wireless LAN card, or the Internet. The SIG does spec new radios, conduct tests for interoperability, and vendor qualification. - Kulwinder. > Mike > From owner-seamoby@diameter.org Fri Apr 13 17:03:50 2001 Received: from charizard.diameter.org ([24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA18403 for ; Fri, 13 Apr 2001 17:03:48 -0400 (EDT) Received: (qmail 10041 invoked by alias); 13 Apr 2001 20:53:32 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 10035 invoked by uid 200); 13 Apr 2001 20:53:31 -0000 Received: (qmail 10030 invoked from network); 13 Apr 2001 20:53:30 -0000 Received: from sj-msg-core-3.cisco.com (171.70.157.152) by c900656-a.plstn1.sfba.home.com with SMTP; 13 Apr 2001 20:53:30 -0000 Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-3.cisco.com (8.9.3/8.9.1) with ESMTP id OAA00174; Fri, 13 Apr 2001 14:00:40 -0700 (PDT) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id ADZ28705; Fri, 13 Apr 2001 14:01:59 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id OAA08286; Fri, 13 Apr 2001 14:01:59 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15063.26951.631816.12447@thomasm-u1.cisco.com> Date: Fri, 13 Apr 2001 14:01:59 -0700 (PDT) To: Kulwinder Atwal Cc: "'Michael Thomas'" , "'Pat.Calhoun@Sun.COM'" , James Kempf , john.loughney@nokia.com, Phil Neumiller , seamoby@cdma-2000.org Subject: RE: [seamoby] IETF Architecture Work (RANT) In-Reply-To: <6833D86F1B05CA4FBAB3C73DD98BD8B90D2B3D@NEPTUNE.zucotto.com> References: <6833D86F1B05CA4FBAB3C73DD98BD8B90D2B3D@NEPTUNE.zucotto.com> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-seamoby@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit Kulwinder Atwal writes: > > The best possible thing that your SIG could do > > is define a good transport for IP and then > > dissolve itself. > > You could say the same thing about the 80 or so vendors in Wi-Fi (802.11). > Right? > > Are you suggesting that Wi-Fi be disolved? If they are defining use profiles for IP protocols, yes. I can see no reason whatsoever why they should care about MIP, MANET etc, etc. > > Really. > > This is a very Internet centric view. What can I say? I'm a nethead. > It may be hard to imagine, but Bluetooth really does have more applications > than a wireless LAN card, or the Internet. What is the point of not running it over IP? Note that IP is not necessarily synonymous with the Internet. > The SIG does spec new radios, conduct tests for interoperability, and vendor > qualification. Fine, those are great things for the SIG (and IEEE) to do. A fixed set of tasks and then shut down when they're done. Mike From owner-seamoby@diameter.org Fri Apr 13 17:14:21 2001 Received: from charizard.diameter.org ([24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA18623 for ; Fri, 13 Apr 2001 17:14:20 -0400 (EDT) Received: (qmail 10625 invoked by alias); 13 Apr 2001 21:04:01 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 10619 invoked by uid 200); 13 Apr 2001 21:04:01 -0000 Received: (qmail 10614 invoked from network); 13 Apr 2001 21:03:59 -0000 Received: from unknown (HELO NEPTUNE.zucotto.com) (216.95.209.154) by c900656-a.plstn1.sfba.home.com with SMTP; 13 Apr 2001 21:03:59 -0000 Received: by NEPTUNE.zucotto.com with Internet Mail Service (5.5.2653.19) id ; Fri, 13 Apr 2001 17:13:05 -0400 Message-ID: <6833D86F1B05CA4FBAB3C73DD98BD8B90D2B40@NEPTUNE.zucotto.com> From: Kulwinder Atwal To: "'Michael Thomas'" , Kulwinder Atwal Cc: "'Pat.Calhoun@Sun.COM'" , James Kempf , john.loughney@nokia.com, Phil Neumiller , seamoby@cdma-2000.org Subject: RE: [seamoby] IETF Architecture Work (RANT) Date: Fri, 13 Apr 2001 17:13:04 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-seamoby@diameter.org Precedence: bulk > -----Original Message----- > From: Michael Thomas [mailto:mat@cisco.com] > Sent: Friday, April 13, 2001 5:02 PM > To: Kulwinder Atwal > Cc: 'Michael Thomas'; 'Pat.Calhoun@Sun.COM'; James Kempf; > john.loughney@nokia.com; Phil Neumiller; seamoby@cdma-2000.org > Subject: RE: [seamoby] IETF Architecture Work (RANT) > > > > > This is a very Internet centric view. > > What can I say? I'm a nethead. > > > It may be hard to imagine, but Bluetooth really does have > more applications > > than a wireless LAN card, or the Internet. > > What is the point of not running it over IP? > Note that IP is not necessarily synonymous with > the Internet. You need to think of this in phases. Phase 1: First Bluetooth must provide an easy way for vertical market stacks to migrate to Bluetooth: Move Legacy stacks to Bluetooth. Phase 2: The IETF needs to provide the functionality of those stacks in IP based protocols: Write new protocols. Phase 3: Then those vertical markets can then migrate to IP. Currently the IETF protocols do not support the needs of every Usage Model (vertical market stack). First you build it. Then they will come. > > > The SIG does spec new radios, conduct tests for > interoperability, and vendor > > qualification. > > Fine, those are great things for the SIG (and > IEEE) to do. A fixed set of tasks and then > shut down when they're done. There will always be new radios, and new companies wanting their products certified. - Kulwinder. > > Mike > From owner-seamoby@diameter.org Fri Apr 13 17:42:41 2001 Received: from charizard.diameter.org ([24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA19067 for ; Fri, 13 Apr 2001 17:42:41 -0400 (EDT) Received: (qmail 12031 invoked by alias); 13 Apr 2001 21:32:09 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 12025 invoked by uid 200); 13 Apr 2001 21:32:08 -0000 Received: (qmail 12020 invoked from network); 13 Apr 2001 21:32:05 -0000 Received: from mercury.sun.com (192.9.25.1) by c900656-a.plstn1.sfba.home.com with SMTP; 13 Apr 2001 21:32:05 -0000 Received: from heliopolis.eng.sun.com ([152.70.1.39]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA23973; Fri, 13 Apr 2001 14:38:27 -0700 (PDT) Received: from srmtv29a (srmtv29a [152.70.1.41]) by heliopolis.eng.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id OAA14390; Fri, 13 Apr 2001 14:41:08 -0700 (PDT) Message-Id: <200104132141.OAA14390@heliopolis.eng.sun.com> Date: Fri, 13 Apr 2001 14:41:08 -0700 (PDT) From: James Kempf Reply-To: James Kempf Subject: RE: Timers (was: RE: [seamoby] IETF Architecture Work (RANT)) To: James.Kempf@sun.com, neumiller@telocity.com, kulwinder.atwal@zucotto.com, seamoby@cdma-2000.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: B0C8KA9YMh53wVvorMYvqw== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 sun4u sparc Sender: owner-seamoby@diameter.org Precedence: bulk >> >> Then why don't you take this to the MANET mailing list? I don't >> see anything specifically seamoby related here. > >Just a few days ago on the Context Transfer Design team we discussed Timers. > >A few days before that we taked about Timers in IP Paging. > >Your Requirements draft: "time-slotted dormant mode where the mobile >periodicaly wake-up" > >Sounds like a timer. Is it an L2 timer propagated up the stack as an L3 >Trigger? > Sure, but these are specific technical issues, and have nothing to do with MANET. If you have requirements for paging regarding timers, please bring them up on the paging list. Similarly for context transfer. Rather than a blanket statement like "let's get rid of timers at L3". jak From owner-seamoby@diameter.org Fri Apr 13 17:56:02 2001 Received: from charizard.diameter.org ([24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA19229 for ; Fri, 13 Apr 2001 17:56:01 -0400 (EDT) Received: (qmail 12578 invoked by alias); 13 Apr 2001 21:45:14 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 12572 invoked by uid 200); 13 Apr 2001 21:45:13 -0000 Received: (qmail 12567 invoked from network); 13 Apr 2001 21:45:08 -0000 Received: from unknown (HELO NEPTUNE.zucotto.com) (216.95.209.154) by c900656-a.plstn1.sfba.home.com with SMTP; 13 Apr 2001 21:45:08 -0000 Received: by NEPTUNE.zucotto.com with Internet Mail Service (5.5.2653.19) id ; Fri, 13 Apr 2001 17:54:14 -0400 Message-ID: <6833D86F1B05CA4FBAB3C73DD98BD8B90D2B44@NEPTUNE.zucotto.com> From: Kulwinder Atwal To: "'James Kempf'" , neumiller@telocity.com, Kulwinder Atwal , seamoby@cdma-2000.org Subject: RE: Timers (was: RE: [seamoby] IETF Architecture Work (RANT)) Date: Fri, 13 Apr 2001 17:54:13 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-seamoby@diameter.org Precedence: bulk > -----Original Message----- > From: James Kempf [mailto:James.Kempf@sun.com] > Sent: Friday, April 13, 2001 5:41 PM > To: James.Kempf@sun.com; neumiller@telocity.com; > kulwinder.atwal@zucotto.com; seamoby@cdma-2000.org > Subject: RE: Timers (was: RE: [seamoby] IETF Architecture Work (RANT)) > > Sure, but these are specific technical issues, and have nothing to > do with MANET. If you have requirements for paging regarding > timers, please > bring them up on the paging list. I have done so. > Similarly for context transfer. I have done so. > Rather than a blanket statement like "let's get rid of timers at L3". If you check the email archives, you will notice I have been bringing up triggers since December. It is a general statement that applies to mobility, not a collection of special cases. - Kulwinder. > > jak > From owner-seamoby@diameter.org Fri Apr 13 19:37:30 2001 Received: from charizard.diameter.org ([24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA20626 for ; Fri, 13 Apr 2001 19:37:29 -0400 (EDT) Received: (qmail 14266 invoked by alias); 13 Apr 2001 23:24:20 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 14260 invoked by uid 200); 13 Apr 2001 23:24:20 -0000 Received: (qmail 14255 invoked from network); 13 Apr 2001 23:24:18 -0000 Received: from c007-h014.c007.snv.cp.net (HELO c007.snv.cp.net) (209.228.33.221) by c900656-a.plstn1.sfba.home.com with SMTP; 13 Apr 2001 23:24:18 -0000 Received: (cpmta 9141 invoked from network); 13 Apr 2001 16:33:24 -0700 Received: from unknown (HELO philneum) (64.193.0.129) by smtp.telocity.com (209.228.33.221) with SMTP; 13 Apr 2001 16:33:24 -0700 X-Sent: 13 Apr 2001 23:33:24 GMT Message-ID: <048401c0c472$0041c500$6501a8c0@philneum> Reply-To: "Phil Neumiller" From: "Phil Neumiller" To: , Subject: [seamoby] WG Announcement of Appeal: 3G Biases in SeaMoby and MIP Date: Fri, 13 Apr 2001 18:29:35 -0500 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-seamoby@diameter.org Precedence: bulk Attn: SeaMoby and Mobile IP WG members. Description of Appeal ---------------------- As permitted by RFC 2026 section 6.5.1 an individual (or individuals) may disagree with a WG recommendation and may approach the IESG for an appeal in a case where the WG has made an incorrect technical choice which places the quality and/or integrity of the Working Group's product(s) in significant jeopardy. In a nutshell, my appeal, is that: the SeaMoby and Mobile IP WGs have been mis-directed to focus too much on the interests of a group of outside standards development organizations, namely 3GPP (http://www.3gpp.org/) and 3GPP2 (http://www.3gpp2.org/), rather than enhancing the global Internet which is the IETF's primary directive per RFC 2026 section 1.1 which I quote a subsection here for convenience: "In the case of protocols developed and/or standardized by non-Internet organizations, however, the Internet Standards Process normally applies to the application of the protocol or procedure in the Internet context, not to the specification of the protocol itself." I will attempt to prove in this appeals process that the mobileip and seamoby WGs have been developing protocols primarily for a non-Internet organization [namely 3GPP and 3GPP2] and have not kept the Internet context of their process as their primary focus. In this case, I believe the technical error to be in both the mobile IP and SeaMoby WG agendas themselves (therefore by direct consequence each of the WG's priorities), so the appeal is more appropriately directed at the IESG than the WG members or chairs. Since, WG members and chairs must abide by the IESG approved agenda for the WG. In this appeal I will not implicate any individual WG member or chair and all member names will be removed from quotations used in my case. I will refer to a "WG chair" as just that, and a "WG member" as just that, thus removing any prejudices that could intervene in my interest of fairness and the technical correctness of my appeal. I can provide on demand the names of the quoted individuals to the ADs or the IESG if an AD or the IESG needs to cross reference or ask further questions. Next Steps ------------ The matter has been discussed repeatedly and at length with the WG chairs and members on the said lists and they have repeatedly stated that they recognize no bias in the WG activities. By section 6.5.1 of RFC 2026 I hereby open this appeals process to the mobileip and seamoby WGs as a whole for debate. NOTE: This is the final chance for each WG to resolve this issue internally before the appeal will be brought formally to the ADs and possibly the IESG. After the discussion, which [we can agree] to conclude on April 20, 2001 [provided the chairs and ADs believe this is enough time], and if this appeal can not be resolved within the mobileip and seamoby WG confines, the matter will be taken to the ADs for resolution. I welcome the ADs to monitor this public airing of the appeals notice to the WGs and interject guidence as necessary. As WG members concerned about mobility and the global Internet please reply to this message with your own comments that are directly pertinent to this appeal to the ADs and possibly the IESG itself. If you wish your comments to be anonymous please send them to the ADs or WG chairs directly where your privacy will be respected [I request that an anonymous version be reposted to the list by the ADs and/or chairs on this thread]. Thanks, Phil Neumiller From owner-seamoby@diameter.org Fri Apr 13 20:20:37 2001 Received: from charizard.diameter.org ([24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA20967 for ; Fri, 13 Apr 2001 20:20:35 -0400 (EDT) Received: (qmail 15201 invoked by alias); 14 Apr 2001 00:09:53 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 15195 invoked by uid 200); 14 Apr 2001 00:09:52 -0000 Received: (qmail 15190 invoked from network); 14 Apr 2001 00:09:51 -0000 Received: from mercury.sun.com (192.9.25.1) by c900656-a.plstn1.sfba.home.com with SMTP; 14 Apr 2001 00:09:51 -0000 Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id RAA22845; Fri, 13 Apr 2001 17:16:06 -0700 (PDT) Received: from nasnfs.Eng.Sun.COM (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA21253; Fri, 13 Apr 2001 17:18:50 -0700 (PDT) Received: from darius (darius [152.70.40.121]) by nasnfs.Eng.Sun.COM (8.9.3+Sun/8.9.1) with SMTP id RAA11409; Fri, 13 Apr 2001 17:18:32 -0700 (PDT) Date: Fri, 13 Apr 2001 17:18:32 -0700 (PDT) From: Patrice Calhoun Reply-To: Patrice Calhoun Subject: Re: [seamoby] WG Announcement of Appeal: 3G Biases in SeaMoby and MIP To: Phil Neumiller Cc: mobile-ip@sunroof.eng.sun.com, seamoby@cdma-2000.org In-Reply-To: "Your message with ID" <048401c0c472$0041c500$6501a8c0@philneum> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-seamoby@diameter.org Precedence: bulk > Attn: SeaMoby and Mobile IP WG members. > > Description of Appeal > ---------------------- > As permitted by RFC 2026 section 6.5.1 an individual (or individuals) may > disagree with a WG recommendation and may approach the IESG for an > appeal in a case where the WG has made an incorrect technical choice which > places the quality and/or integrity of the Working Group's product(s) in > significant jeopardy. > > In a nutshell, my appeal, is that: the SeaMoby and Mobile IP WGs have > been mis-directed to focus too much on the interests of a group of outside > standards development organizations, namely 3GPP (http://www.3gpp.org/) > and 3GPP2 (http://www.3gpp2.org/), rather than enhancing the global Internet > which is the IETF's primary directive per RFC 2026 section 1.1 which I > quote a subsection here for convenience: > > "In the case of protocols developed and/or standardized by non-Internet > organizations, however, the Internet Standards Process normally applies > to the application of the protocol or procedure in the Internet context, > not to the specification of the protocol itself." > > I will attempt to prove in this appeals process that the mobileip and seamoby > WGs have been developing protocols primarily for a non-Internet organization > [namely 3GPP and 3GPP2] and have not kept the Internet context of their > process as their primary focus. > > In this case, I believe the technical error to be in both the mobile IP and > SeaMoby WG agendas themselves (therefore by direct consequence each of > the WG's priorities), so the appeal is more appropriately directed at the > IESG than the WG members or chairs. Since, WG members and chairs must abide > by the IESG approved agenda for the WG. > > In this appeal I will not implicate any individual WG member or chair and all > member names will be removed from quotations used in my case. I will refer > to a "WG chair" as just that, and a "WG member" as just that, thus removing > any prejudices that could intervene in my interest of fairness and the > technical correctness of my appeal. I can provide on demand the names of > the quoted individuals to the ADs or the IESG if an AD or the IESG needs to > cross reference or ask further questions. > > Next Steps > ------------ > The matter has been discussed repeatedly and at length with the WG chairs and > members on the said lists and they have repeatedly stated that they > recognize no bias in the WG activities. By section 6.5.1 of RFC 2026 I > hereby open this appeals process to the mobileip and seamoby WGs as a whole > for debate. > > NOTE: > This is the final chance for each WG to resolve this issue internally before > the appeal will be brought formally to the ADs and possibly the IESG. > > After the discussion, which [we can agree] to conclude on April 20, 2001 > [provided the chairs and ADs believe this is enough time], and if this appeal > can not be resolved within the mobileip and seamoby WG confines, the matter > will be taken to the ADs for resolution. Given that I will be on vacation, and not have access to the Internet, between April 14th through the 22nd, I would ask for this timeline to be extended to April 30th. PatC From owner-seamoby@diameter.org Fri Apr 13 20:35:31 2001 Received: from charizard.diameter.org ([24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA21115 for ; Fri, 13 Apr 2001 20:35:29 -0400 (EDT) Received: (qmail 15768 invoked by alias); 14 Apr 2001 00:24:27 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 15762 invoked by uid 200); 14 Apr 2001 00:24:27 -0000 Received: (qmail 15757 invoked from network); 14 Apr 2001 00:24:25 -0000 Received: from mailhost.iprg.nokia.com (205.226.5.12) by c900656-a.plstn1.sfba.home.com with SMTP; 14 Apr 2001 00:24:25 -0000 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 RAA16685; Fri, 13 Apr 2001 17:33:01 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f3E0X0m24003; Fri, 13 Apr 2001 17:33:00 -0700 X-mProtect: Fri, 13 Apr 2001 17:33:00 -0700 Nokia Silicon Valley Messaging Protection Received: from dhcp-3-129.iprg.nokia.com (205.226.3.129, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(WTS.12.69) smtpdyWnara; Fri, 13 Apr 2001 17:32:53 PDT Message-ID: <3AD79BC7.9FBD3355@iprg.nokia.com> Date: Fri, 13 Apr 2001 17:37:27 -0700 From: Cedric Westphal Organization: NOKIA X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Phil Neumiller CC: mobile-ip@sunroof.eng.sun.com, seamoby@cdma-2000.org Subject: Re: [seamoby] WG Announcement of Appeal: 3G Biases in SeaMoby and MIP References: <048401c0c472$0041c500$6501a8c0@philneum> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-seamoby@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit Phil, assuming your appeal is validated, and there is indeed a bias in MIP and seamoby towards 3GPPs, what would be the consequences? I have a hard time figuring out what is the purpose of this crusade. If it makes you happy, I'll agree to all the biases you want. Yes, many members of MIP and seamoby WG that earn a paycheck get it from one of the 76 companies that are 3GPP2 members (including all 3 chairs, one area director, one technical advisor, and yourself till a couple weeks ago). Do they influence the outcome? You bet. QED. WGs are biased. Congratulations, you won. To answer my first question, what consequences? I suggest to ban from the IETF all these pesky corporate sell-outs working for cisco, lucent, nokia, sun, nortel, etc. They are way too influential. Cedric. Phil Neumiller wrote: > Attn: SeaMoby and Mobile IP WG members. > > Description of Appeal > ---------------------- > As permitted by RFC 2026 section 6.5.1 an individual (or individuals) may > disagree with a WG recommendation and may approach the IESG for an > appeal in a case where the WG has made an incorrect technical choice which > places the quality and/or integrity of the Working Group's product(s) in > significant jeopardy. > > In a nutshell, my appeal, is that: the SeaMoby and Mobile IP WGs have > been mis-directed to focus too much on the interests of a group of outside > standards development organizations, namely 3GPP (http://www.3gpp.org/) > and 3GPP2 (http://www.3gpp2.org/), rather than enhancing the global Internet > which is the IETF's primary directive per RFC 2026 section 1.1 which I > quote a subsection here for convenience: > > "In the case of protocols developed and/or standardized by non-Internet > organizations, however, the Internet Standards Process normally applies > to the application of the protocol or procedure in the Internet context, > not to the specification of the protocol itself." > > I will attempt to prove in this appeals process that the mobileip and seamoby > WGs have been developing protocols primarily for a non-Internet organization > [namely 3GPP and 3GPP2] and have not kept the Internet context of their > process as their primary focus. > > In this case, I believe the technical error to be in both the mobile IP and > SeaMoby WG agendas themselves (therefore by direct consequence each of > the WG's priorities), so the appeal is more appropriately directed at the IESG > than the WG members or chairs. Since, WG members and chairs must abide > by the IESG approved agenda for the WG. > > In this appeal I will not implicate any individual WG member or chair and all > member names will be removed from quotations used in my case. I will refer > to a "WG chair" as just that, and a "WG member" as just that, thus removing > any prejudices that could intervene in my interest of fairness and the technical > correctness of my appeal. I can provide on demand the names of the quoted > individuals to the ADs or the IESG if an AD or the IESG needs to cross > reference or ask further questions. > > Next Steps > ------------ > The matter has been discussed repeatedly and at length with the WG chairs and > members on the said lists and they have repeatedly stated that they recognize no > bias in the WG activities. By section 6.5.1 of RFC 2026 I hereby open this > appeals process to the mobileip and seamoby WGs as a whole for debate. > > NOTE: > This is the final chance for each WG to resolve this issue internally before the > appeal will be brought formally to the ADs and possibly the IESG. > > After the discussion, which [we can agree] to conclude on April 20, 2001 > [provided the chairs and ADs believe this is enough time], and if this appeal > can not be resolved within the mobileip and seamoby WG confines, the matter > will be taken to the ADs for resolution. I welcome the ADs to monitor this > public airing of the appeals notice to the WGs and interject guidence as > necessary. > > As WG members concerned about mobility and the global Internet please > reply to this message with your own comments that are directly pertinent to this > appeal to the ADs and possibly the IESG itself. If you wish your comments > to be anonymous please send them to the ADs or WG chairs directly where > your privacy will be respected [I request that an anonymous version be reposted > to the list by the ADs and/or chairs on this thread]. > > Thanks, > > Phil Neumiller From owner-seamoby@diameter.org Fri Apr 13 20:52:04 2001 Received: from charizard.diameter.org ([24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA21196 for ; Fri, 13 Apr 2001 20:52:03 -0400 (EDT) Received: (qmail 16322 invoked by alias); 14 Apr 2001 00:40:48 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 16316 invoked by uid 200); 14 Apr 2001 00:40:48 -0000 Received: (qmail 16311 invoked from network); 14 Apr 2001 00:40:46 -0000 Received: from jffdns01.or.intel.com (HELO ganymede.or.intel.com) (134.134.248.3) by c900656-a.plstn1.sfba.home.com with SMTP; 14 Apr 2001 00:40:46 -0000 Received: from SMTP (orsmsx226.jf.intel.com [192.168.65.226]) by ganymede.or.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.35 2001/02/12 09:03:45 smothers Exp $) with SMTP id AAA12510; Sat, 14 Apr 2001 00:48:48 GMT Received: from orsmsx228.JF.INTEL.COM ([192.168.70.228]) by 192.168.70.226 (Norton AntiVirus for Internet Email Gateways 1.0) ; Sat, 14 Apr 2001 00:40:16 0000 (GMT) Received: by ORSMSX228 with Internet Mail Service (5.5.2653.19) id <27AVFBQJ>; Fri, 13 Apr 2001 17:40:13 -0700 Message-ID: <10C8636AE359D4119118009027AE998704F02A57@FMSMSX34> From: "Fleming, Kris D" To: "'Kulwinder Atwal'" , "'Pat.Calhoun@Sun.COM'" , James Kempf , john.loughney@nokia.com, Phil Neumiller Cc: seamoby@cdma-2000.org Subject: RE: [seamoby] IETF Architecture Work (RANT) Date: Fri, 13 Apr 2001 16:11:26 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-seamoby@diameter.org Precedence: bulk > > btw, I was not in any way shape or form, stating that > bluetooth, or any other > SDO doesn't want to collaborate. This is a response to why > MIP has been > listening to 3GPP2. Bluetooth, up to now, has never been > putting requirments > in the Mobile IP WG 3GPP2 has additional requirements to support voice calls. These same requirement and changes to MIP to support voice calls can also be used for Bluetooth to support voice of IP based calls. Bluetooth usage model are often base on best effort service. There should be no addition requirement for Bluetooth. Bluetooth should be view as another media which supports IP similar to 802.11. 802.11 did not have any addition requirements, why should Bluetooth? > The SIG members that I have talked to feel that MIP is a cellular protocol > for 3GPP2. And as such, feel that MANET is probably the best place for a > Mobile Router protocol. I don't know who in the SIG that you have talked to but the Bluetooth SIG has always wanted to support MIP. If you are connected to a Bluetooth PAN Access point then you can use MIP, the same why that you use MIP over 802.11. It in not only a cellular protocol for 3GPP2! What is useful is to send up indications to the MIP layer when you are about to move from one Bluetooth Access point to another. This could trigger a MIP to register with a new FA. This is just one example, there are many other SEAMOBY related issues that should be done, and discussed on this list. The goal of the Bluetooth SIG PAN WG is to allow any IP base protocol to run over Bluetooth. This allows Bluetooth become another PHY media, which supports IP and other networking protocols. In addition, we are encouraging IP base applications and new usage model that people can dream up using IP. Also Kulwinder often make statements about the Bluetooth SIG and it's direction. The problem is with that is that he isn't a member of the Bluetooth PAN WG, nor is he a member of any other SIG WG, and makes incorrect and misleading statements like the original statement. From owner-seamoby@diameter.org Fri Apr 13 21:33:41 2001 Received: from charizard.diameter.org ([24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA21489 for ; Fri, 13 Apr 2001 21:33:38 -0400 (EDT) Received: (qmail 17049 invoked by alias); 14 Apr 2001 01:22:08 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 17043 invoked by uid 200); 14 Apr 2001 01:22:08 -0000 Received: (qmail 17038 invoked from network); 14 Apr 2001 01:22:06 -0000 Received: from mailhost.iprg.nokia.com (205.226.5.12) by c900656-a.plstn1.sfba.home.com with SMTP; 14 Apr 2001 01:22:06 -0000 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 SAA19235; Fri, 13 Apr 2001 18:30:37 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f3E1UaL24274; Fri, 13 Apr 2001 18:30:36 -0700 X-mProtect: Fri, 13 Apr 2001 18:30:36 -0700 Nokia Silicon Valley Messaging Protection Received: from Icharliep-1.iprg.nokia.com (205.226.22.18, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(WTS.12.69) smtpd4ZLvT3; Fri, 13 Apr 2001 18:30:30 PDT Message-ID: <3AD7A87E.5492B509@iprg.nokia.com> Date: Fri, 13 Apr 2001 18:31:42 -0700 From: Charlie Perkins Organization: Nokia X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com CC: seamoby@cdma-2000.org, Phil Roberts , "Basavaraj Patil \(NTC/Dallas\)" Subject: [seamoby] Re: [mobile-ip] WG Announcement of Appeal: 3G Biases in SeaMoby and MIP References: <048401c0c472$0041c500$6501a8c0@philneum> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-seamoby@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit Hello, I'm confused about how you can tell whether the working groups were biased. What if the working groups were just working on the agenda items suggested by the participants? Can you suggest an alternative agenda which would not have shown the effects of the claimed bias? What else should the working groups have been working on, other than the things that were brought into discussion by the participants? As someone who was involved in the mobile-ip working group, and also who tried to become familiar with the needs of 3GPP2 and 3GPP, I don't know if I would be considered to be objective. With that understanding, however, I'll state anyway that I don't think the agenda in the mobile-ip working was subservient to the needs of outside SDOs. In fact, even before there was substantial input from those organizations, we had already made a lot of discussion about regional registration (called in those days Hierarchical Foreign Agents). Questions about smooth handover are of more recent vintage, but do not show evidence of being under the control of 3GPP*. There were some drafts to exhibit 3G requirements. I don't think they progressed to Informational RFC, and I don't remember too much recent discussion. Can you characterize the effects of the claimed bias? For possible comparison purposes, I can suggest some things that didn't happen, which would have been more solid evidence of bias: - Allowing GTP as a tunneling choice along with IP-within-IP tunneling - Insertion of additional round trips to HLR before granting network access - Allowing PPP as a tunneling choice along with IP-within-IP tunneling (...maybe it would have been a good idea, though!...) - Specification of SS-7 proxies These things didn't happen. Some things more directly related to 3GPP2 were actively discussed, but they could not at all be characterized as displacing other more important topics like Mobile IPv6. I think you have a very difficult case to make, given the available evidence. Lastly, I do not think that the discussion raised by considerations of 3G requirements have had the harmful effect you claim, except unless you believe that adopting IETF standards would have the effect of making those standards longer-lived and thus antithetical to your goals for a longer time. Regards, Charlie P. Phil Neumiller wrote: > Description of Appeal > ---------------------- > As permitted by RFC 2026 section 6.5.1 an individual (or individuals) may > disagree with a WG recommendation and may approach the IESG for an > appeal in a case where the WG has made an incorrect technical choice which > places the quality and/or integrity of the Working Group's product(s) in > significant jeopardy. > > In a nutshell, my appeal, is that: the SeaMoby and Mobile IP WGs have > been mis-directed to focus too much on the interests of a group of outside > standards development organizations, namely 3GPP (http://www.3gpp.org/) > and 3GPP2 (http://www.3gpp2.org/), rather than enhancing the global Internet > which is the IETF's primary directive per RFC 2026 section 1.1 which I > quote a subsection here for convenience: > > "In the case of protocols developed and/or standardized by non-Internet > organizations, however, the Internet Standards Process normally applies > to the application of the protocol or procedure in the Internet context, > not to the specification of the protocol itself." > > I will attempt to prove in this appeals process that the mobileip and seamoby > WGs have been developing protocols primarily for a non-Internet organization > [namely 3GPP and 3GPP2] and have not kept the Internet context of their > process as their primary focus. > > In this case, I believe the technical error to be in both the mobile IP and > SeaMoby WG agendas themselves (therefore by direct consequence each of > the WG's priorities), so the appeal is more appropriately directed at the IESG > than the WG members or chairs. Since, WG members and chairs must abide > by the IESG approved agenda for the WG. > > In this appeal I will not implicate any individual WG member or chair and all > member names will be removed from quotations used in my case. I will refer > to a "WG chair" as just that, and a "WG member" as just that, thus removing > any prejudices that could intervene in my interest of fairness and the technical > correctness of my appeal. I can provide on demand the names of the quoted > individuals to the ADs or the IESG if an AD or the IESG needs to cross > reference or ask further questions. > > Next Steps > ------------ > The matter has been discussed repeatedly and at length with the WG chairs and > members on the said lists and they have repeatedly stated that they recognize no > bias in the WG activities. By section 6.5.1 of RFC 2026 I hereby open this > appeals process to the mobileip and seamoby WGs as a whole for debate. > > NOTE: > This is the final chance for each WG to resolve this issue internally before the > appeal will be brought formally to the ADs and possibly the IESG. > > After the discussion, which [we can agree] to conclude on April 20, 2001 > [provided the chairs and ADs believe this is enough time], and if this appeal > can not be resolved within the mobileip and seamoby WG confines, the matter > will be taken to the ADs for resolution. I welcome the ADs to monitor this > public airing of the appeals notice to the WGs and interject guidence as > necessary. > > As WG members concerned about mobility and the global Internet please > reply to this message with your own comments that are directly pertinent to this > appeal to the ADs and possibly the IESG itself. If you wish your comments > to be anonymous please send them to the ADs or WG chairs directly where > your privacy will be respected [I request that an anonymous version be reposted > to the list by the ADs and/or chairs on this thread]. > > Thanks, > > Phil Neumiller From owner-seamoby@diameter.org Fri Apr 13 23:07:51 2001 Received: from charizard.diameter.org ([24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA24155 for ; Fri, 13 Apr 2001 23:07:50 -0400 (EDT) Received: (qmail 17926 invoked by alias); 14 Apr 2001 02:56:10 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 17920 invoked by uid 200); 14 Apr 2001 02:56:09 -0000 Received: (qmail 17915 invoked from network); 14 Apr 2001 02:56:08 -0000 Received: from patan.sun.com (192.18.98.43) by c900656-a.plstn1.sfba.home.com with SMTP; 14 Apr 2001 02:56:08 -0000 Received: from heliopolis.eng.sun.com ([152.70.1.39]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA15586 for ; Fri, 13 Apr 2001 20:05:14 -0700 (PDT) Received: from awe171-106 (awe195-32.AWE.Sun.COM [192.29.195.32]) by heliopolis.eng.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id UAA20249; Fri, 13 Apr 2001 20:05:09 -0700 (PDT) Message-Id: <200104140305.UAA20249@heliopolis.eng.sun.com> Date: Fri, 13 Apr 2001 18:57:45 -0700 (PDT) From: kempf Reply-To: kempf Subject: [seamoby] Re: [mobile-ip] WG Announcement of Appeal: 3G Biases in SeaMoby and MIP To: mobile-ip@sunroof.eng.sun.com, seamoby@cdma-2000.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: 3PDL/hTB/dPWf5Ntsa0iPg== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4 SunOS 5.8 i86pc i386 Sender: owner-seamoby@diameter.org Precedence: bulk Phil, Since you seem to have enough time on your hands for this kind of thing, why don't you broaden out your crusade a bit? Here are some other examples: - The IPng working group is having an interim meeting in Seattle next month, at which 3GPP will be presenting requirements. Surely another example of IETF developing standards for the 3Gs. - Some active members from 3GPP (attending IETF as individuals, since that is the only status recognized at IETF) presented requirements to the AAA working group at IETF 50. Yet another example. - Some active members from 3GPP presented requirements at the SIP working group at IETF 50. - And perhaps the worst violation of all: The MEGACO working group developed a protocol for talking to softswitches with IP that was subsequently adopted by the ITU! C'mon. The fact that these groups are coming to IETF for help is a sign of *success*. We need to be expanding our contacts with these groups (hence my email yesterday to the mobile IP list about trying to get 3GPP to move more in the direction of MIP). MIP adoption by 3GPP2 and MEGACO adoption by ITU are great success stories, we need more of them. We just need to make sure they understand the Internet architecture, and the consequences of changing it. IETF would be shooting itself in the foot (or maybe a bit higher, like the head) if it would ignore what are obvious customers for our protocols. People whose companies are participants in the 3Gs are just as welcome, as individuals, as anyone else. jak >X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f >X-Sent: 13 Apr 2001 23:33:24 GMT >From: "Phil Neumiller" >To: , >Subject: [mobile-ip] WG Announcement of Appeal: 3G Biases in SeaMoby and MIP >Date: Fri, 13 Apr 2001 18:29:35 -0500 >X-Priority: 3 >X-MSMail-Priority: Normal >X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 >List-Archive: >List-Owner: >List-Subscribe: >List-Unsubscribe: >Attn: SeaMoby and Mobile IP WG members. > >Description of Appeal >---------------------- >As permitted by RFC 2026 section 6.5.1 an individual (or individuals) may >disagree with a WG recommendation and may approach the IESG for an >appeal in a case where the WG has made an incorrect technical choice which >places the quality and/or integrity of the Working Group's product(s) in >significant jeopardy. > >In a nutshell, my appeal, is that: the SeaMoby and Mobile IP WGs have >been mis-directed to focus too much on the interests of a group of outside >standards development organizations, namely 3GPP (http://www.3gpp.org/) >and 3GPP2 (http://www.3gpp2.org/), rather than enhancing the global Internet >which is the IETF's primary directive per RFC 2026 section 1.1 which I >quote a subsection here for convenience: > > "In the case of protocols developed and/or standardized by non-Internet > organizations, however, the Internet Standards Process normally applies > to the application of the protocol or procedure in the Internet context, > not to the specification of the protocol itself." > >I will attempt to prove in this appeals process that the mobileip and seamoby >WGs have been developing protocols primarily for a non-Internet organization >[namely 3GPP and 3GPP2] and have not kept the Internet context of their >process as their primary focus. > >In this case, I believe the technical error to be in both the mobile IP and >SeaMoby WG agendas themselves (therefore by direct consequence each of >the WG's priorities), so the appeal is more appropriately directed at the IESG >than the WG members or chairs. Since, WG members and chairs must abide >by the IESG approved agenda for the WG. > >In this appeal I will not implicate any individual WG member or chair and all >member names will be removed from quotations used in my case. I will refer >to a "WG chair" as just that, and a "WG member" as just that, thus removing >any prejudices that could intervene in my interest of fairness and the technical >correctness of my appeal. I can provide on demand the names of the quoted >individuals to the ADs or the IESG if an AD or the IESG needs to cross >reference or ask further questions. > >Next Steps >------------ >The matter has been discussed repeatedly and at length with the WG chairs and >members on the said lists and they have repeatedly stated that they recognize no >bias in the WG activities. By section 6.5.1 of RFC 2026 I hereby open this >appeals process to the mobileip and seamoby WGs as a whole for debate. > >NOTE: >This is the final chance for each WG to resolve this issue internally before the >appeal will be brought formally to the ADs and possibly the IESG. > >After the discussion, which [we can agree] to conclude on April 20, 2001 >[provided the chairs and ADs believe this is enough time], and if this appeal >can not be resolved within the mobileip and seamoby WG confines, the matter >will be taken to the ADs for resolution. I welcome the ADs to monitor this >public airing of the appeals notice to the WGs and interject guidence as >necessary. > >As WG members concerned about mobility and the global Internet please >reply to this message with your own comments that are directly pertinent to this >appeal to the ADs and possibly the IESG itself. If you wish your comments >to be anonymous please send them to the ADs or WG chairs directly where >your privacy will be respected [I request that an anonymous version be reposted >to the list by the ADs and/or chairs on this thread]. > >Thanks, > >Phil Neumiller > > From owner-seamoby@diameter.org Sat Apr 14 14:02:24 2001 Received: from charizard.diameter.org ([24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA14006 for ; Sat, 14 Apr 2001 14:02:23 -0400 (EDT) Received: (qmail 21509 invoked by alias); 14 Apr 2001 17:51:19 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 21503 invoked by uid 200); 14 Apr 2001 17:51:19 -0000 Received: (qmail 21498 invoked from network); 14 Apr 2001 17:51:17 -0000 Received: from unknown (HELO NEPTUNE.zucotto.com) (216.95.209.154) by c900656-a.plstn1.sfba.home.com with SMTP; 14 Apr 2001 17:51:17 -0000 Received: by NEPTUNE.zucotto.com with Internet Mail Service (5.5.2653.19) id ; Sat, 14 Apr 2001 14:00:26 -0400 Message-ID: <6833D86F1B05CA4FBAB3C73DD98BD8B90D2B47@NEPTUNE.zucotto.com> From: Kulwinder Atwal To: "'Fleming, Kris D'" , "'Pat.Calhoun@Sun.COM'" , James Kempf , john.loughney@nokia.com, Phil Neumiller Cc: seamoby@cdma-2000.org Subject: RE: [seamoby] IETF Architecture Work (RANT) Date: Sat, 14 Apr 2001 14:00:17 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-seamoby@diameter.org Precedence: bulk > -----Original Message----- > From: Fleming, Kris D [mailto:kris.d.fleming@intel.com] > Sent: Friday, April 13, 2001 7:11 PM > To: 'Kulwinder Atwal'; 'Pat.Calhoun@Sun.COM'; James Kempf; > john.loughney@nokia.com; Phil Neumiller > Cc: seamoby@cdma-2000.org > Subject: RE: [seamoby] IETF Architecture Work (RANT) > > I don't know who in the SIG that you have talked to I have talked to at least half a dozen PAN members, and some SIG members more senior than yourself in the last month. I have received unsolicited emails from three PAN members within the last week on various PAN issues. I think the time to continue this discussion is next month after the release of the PAN docs to the public. Thanks, Kulwinder. From owner-seamoby@diameter.org Sat Apr 14 16:17:09 2001 Received: from charizard.diameter.org ([24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA14496 for ; Sat, 14 Apr 2001 16:17:06 -0400 (EDT) Received: (qmail 22470 invoked by alias); 14 Apr 2001 20:04:49 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 22460 invoked by uid 200); 14 Apr 2001 20:04:49 -0000 Received: (qmail 22455 invoked from network); 14 Apr 2001 20:04:47 -0000 Received: from zcars04f.nortelnetworks.com (HELO zcars04f.ca.nortel.com) (47.129.242.57) by c900656-a.plstn1.sfba.home.com with SMTP; 14 Apr 2001 20:04:47 -0000 Received: from zcard015.ca.nortel.com by zcars04f.ca.nortel.com; Sat, 14 Apr 2001 16:11:30 -0400 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Sat, 14 Apr 2001 16:11:31 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C1257C2@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'Phil Neumiller'" , Pat.Calhoun@Sun.COM, seamoby@diameter.org Subject: RE: [seamoby] MIP & SeaMoby are 3G biased Date: Sat, 14 Apr 2001 16:11:31 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0C51F.18CD0000" X-Orig: Sender: owner-seamoby@diameter.org Precedence: bulk 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_01C0C51F.18CD0000 Content-Type: text/plain; charset="iso-8859-1" I don't know why your throwing innuendos at me, Phil. I am here to work on wireless IP. I don't have the energy right now to cover all that I believe it should be. But, I do know the measure of success: when I can use my PDA or laptop to access the full internet, anytime, anywhere, while sitting at a desk, walking through a building, riding in a car - whatever - and I do not have to swap modems, reconfigure software, or wait while my comms software tries to do it for me. And, the IETF can only contribute partially to this success. There's still a long way to go with wireless transmission technologies. Gary > -----Original Message----- > From: Phil Neumiller [mailto:neumiller@federalmobility.com] > Sent: Friday, April 13, 2001 2:14 PM > To: Pat.Calhoun@Sun.COM; seamoby@diameter.org > Subject: [seamoby] MIP & SeaMoby are 3G biased > > > Pat, Gary, and ADs, > > Interesting you should mention the "Internet community" Pat because > 3G networks are private and not part of "that" community as > far as I can > tell. We are not here to work with or for potential > customers especially if > they are another SDO building private networks. We are here > to improve > the global Internet. > > If that is what you and Gary are here for, I suggest you take > your work > elsewhere (perhaps 3GPP2) and leave SeaMoby to work on the global > Internet as WGs in the IETF are supposed to do. The IETF is supposed > to architect the global Internet and that is "its" priority > not 3GPP or > 3GPP2 "customers". I am going to raise hell about this Pat. > It has become > very clear to me that MIP (from what Raj and Phil R. have said) and > SeaMoby are now completely biased towards 3G and I am taking this > to the IESG. If my appeal goes nowhere, then I have lost, > but at least > I have stated my case and I have stood up for what I believe. I don't > mind being called a "conspiracy wacko" since I will be in > good company. > > Best regards, > > Phil Neumiller > > Patrice Calhoun wrote: > > > >> Pat, Gary, and Hamid, are we working for MIP/3G or not? We > > >> need to know now to stop > > >> a draft that could be completely pointless IMHO. > > > > > >Frankly, you have lost me. I either don't get your point, or your > > >arguing both sides of a solution issue. > > > > Ditto. > > > > Perhaps we could stop the conspiracy theories, and start > working on requirements > > gathering for a protocol that will be useful for the > Internet Community. If the > > 3Gs are a potential customer, then so be it, but we are > focusing on a protocol > > that has wider applicability. > > > > PatC > > ------_=_NextPart_001_01C0C51F.18CD0000 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [seamoby] MIP & SeaMoby are 3G biased

I don't know why your throwing innuendos at me, = Phil.

I am here to work on wireless IP. I don't have the = energy
right now to cover all that I believe it should be. = But,
I do know the measure of success: when I can use my = PDA
or laptop to access the full  internet, = anytime, anywhere,
while sitting at a desk, walking through a building, = riding in
a car - whatever - and I do not have to swap modems, =
reconfigure software, or wait while my comms = software
tries to do it for me.

And, the IETF can only contribute partially to this = success.
There's still a long way to go with wireless = transmission
technologies.

Gary


> -----Original Message-----
> From: Phil Neumiller [mailto:neumiller@federalmo= bility.com]
> Sent: Friday, April 13, 2001 2:14 PM
> To: Pat.Calhoun@Sun.COM; = seamoby@diameter.org
> Subject: [seamoby] MIP & SeaMoby are 3G = biased
>
>
> Pat, Gary, and ADs,
>
> Interesting you should mention the = "Internet community" Pat because
> 3G networks are private and not part of = "that" community as
> far as I can
> tell.  We are not here to work with or for = potential
> customers especially if
> they are another SDO building private = networks.  We are here
> to improve
> the global Internet.
>
> If that is what you and Gary are here for, I = suggest you take
> your  work
> elsewhere (perhaps 3GPP2) and leave SeaMoby to = work on the global
> Internet as WGs in the IETF are supposed to = do.  The IETF is supposed
> to architect the global Internet and that is = "its" priority
> not 3GPP or
> 3GPP2 "customers".  I am going = to raise hell about this Pat. 
> It has become
> very clear to me that MIP (from what Raj and = Phil R. have said) and
> SeaMoby are now completely biased towards 3G = and I am taking this
> to the IESG.  If my appeal goes nowhere, = then I have lost,
> but at least
> I have stated my case and I have stood up for = what I believe.  I don't
> mind being called a "conspiracy = wacko" since I will be in
> good company.
>
> Best regards,
>
> Phil Neumiller
>
> Patrice Calhoun wrote:
>
> > >> Pat, Gary, and Hamid, are we = working for MIP/3G or not?  We
> > >> need to know now to stop
> > >> a draft that could be completely = pointless IMHO.
> > >
> > >Frankly, you have lost me. I either = don't get your point, or your
> > >arguing both sides of a solution = issue.
> >
> > Ditto.
> >
> > Perhaps we could stop the conspiracy = theories, and start
> working on requirements
> > gathering for a protocol that will be = useful for the
> Internet Community. If the
> > 3Gs are a potential customer, then so be = it, but we are
> focusing on a protocol
> > that has wider applicability.
> >
> > PatC
>
>

------_=_NextPart_001_01C0C51F.18CD0000-- From owner-seamoby@diameter.org Sun Apr 15 22:35:01 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA15936 for ; Sun, 15 Apr 2001 22:34:59 -0400 (EDT) Received: (qmail 32313 invoked by alias); 16 Apr 2001 02:23:33 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 32307 invoked by uid 200); 16 Apr 2001 02:23:33 -0000 Received: (qmail 32302 invoked from network); 16 Apr 2001 02:23:31 -0000 Received: from www.bit-net.com (HELO mail.users.bit-net.com) (208.146.132.4) by c900656-a.plstn1.sfba.home.com with SMTP; 16 Apr 2001 02:23:31 -0000 Received: from localhost by mail.users.bit-net.com; (5.65v3.2/1.1.8.2/30Jul96-0143PM) id AA17200; Sun, 15 Apr 2001 22:32:27 -0400 Date: Sun, 15 Apr 2001 22:32:27 -0400 (EDT) From: Jim Bound To: Arthur Ross Cc: Phil Neumiller , Pat.Calhoun@Sun.COM, seamoby@diameter.org Subject: Re: [seamoby] MIP & SeaMoby are 3G biased In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-seamoby@diameter.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by ietf.org id WAA15936 I will take it even further than Arthur or Phil. If the IETF continues to be too slow and engineers are consistently overruled by committee to do things which hold up the market and are not the best technical solution then its time to leave the IETF in some spaces. Not all spaces and as much I would not like to see such a shism I do think this mail thread is one of many wake up calls. I don't believe its a conspiracy but when some person tells me something won't work or will work they say and I know they are wrong and they have not written code or something in 15 years but they win because they are more powerful that is when I think there is a big problem. I am not putting up with it much longer in any part of the IETF. But I have hope it will get fixed somehow. /jim On Fri, 13 Apr 2001, Arthur Ross wrote: > At 11:13 -0700 04/13/2001, Phil Neumiller wrote: > >Pat, Gary, and ADs, > > > >Interesting you should mention the "Internet community" Pat because > >3G networks are private and not part of "that" community as far as I can > >tell. We are not here to work with or for potential customers especially if > >they are another SDO building private networks. We are here to improve > >the global Internet. > > > >If that is what you and Gary are here for, I suggest you take your work > >elsewhere (perhaps 3GPP2) and leave SeaMoby to work on the global > >Internet as WGs in the IETF are supposed to do. The IETF is supposed > >to architect the global Internet and that is "its" priority not 3GPP or > >3GPP2 "customers". I am going to raise hell about this Pat. It has become > >very clear to me that MIP (from what Raj and Phil R. have said) and > >SeaMoby are now completely biased towards 3G and I am taking this > >to the IESG. If my appeal goes nowhere, then I have lost, but at least > >I have stated my case and I have stood up for what I believe. I don't > >mind being called a "conspiracy wacko" since I will be in good company. > > > As usual, I have to echo Phil's view. > > What we have here is a fundamental clash. A clash both of culture, and of > structure/charter. > > There are very fundamental difference between the IETF and the SDOs. The > formal SDOs (the members of the 3GPPs), such as TIA and ETSI, are industry > consortia of for-profit companies. They have membership fees (usually quite > large). They have dedicated offices, full-time paid employees, attorneys, > formal charters, formal rules of procedure, and formal governing bodies. > They exist, to a large degree, as a sort of insurance against accusations > of unfair collusion that undoubtedly would ensue if there were to be > privately cooked up standards. A long-time rep of one of the telecom giants > once told me that those open meetings are "what keeps us all out of jail", > a view that my personal experience with them reinforces. They do indeed > have a very strong mutual self-interest in producing well thought out > standards that work (not always achieved, as we all know), and they do it > with great formality and rigorous process. > > The IETF is a totally different animal. It is, as I understand it, all > volunteer, uncompensated, with facilities, such as they are, provided pro > bono by various educational, government, and corporate entities. Its > organization is loose and informal, depending on a spirit of mutual > cooperation and good will, rather than bureacracies, legalistic procedures, > and attorneys, to accomplish its work. > > This is a sure-fire recipe for conflict, given the fact of the Internet > explosion as a global business platform. The notion of supporting > "customers" for the IETF work product has no formal basis; rather, it is > only a vague notion of openess and reasonableness, with diverse opinions as > to what that means, in the minds of the participants. > > The closest thing I have found to a guiding principle relevant to this > argument seems to be RFC2026, §1.1: > > The Internet, a loosely-organized international collaboration of > autonomous, interconnected networks, supports host-to-host > communication through voluntary adherence to open protocols and > procedures defined by Internet Standards. There are also many > isolated interconnected networks, which are not connected to the > global Internet but use the Internet Standards. > > The Internet Standards Process described in this document is > concerned with all protocols, procedures, and conventions that are > used in or by the Internet, whether or not they are part of the > TCP/IP protocol suite. In the case of protocols developed and/or > standardized by non-Internet organizations, however, the Internet > Standards Process normally applies to the application of the protocol > or procedure in the Internet context, not to the specification of the > protocol itself. > > It does seem that Phil's right, given this current framework. The IETF > exists for the good of the global Internet, not necessarily as a service > organization to the business world, except where the business interest > coincides with the good-of-the-Internet criterion. > > This seems like a very fundamental question of philosophy, scope, & > charter. Is it perhaps time to think about creating a formal charter for > the IETF? I personally tend to oppose that, but the fact of the well-funded > 800 pound gorilla that is "3G" may make this attitude difficult to sustain > in practice. Is the "good-of-the-Internet" for sale to those with the > deepest pockets (read: most able to send an army of partisans to the > working groups)? This needs to be confronted. > > Please sign me up as another of those "wackos". > > -- Best regards, > -- Arthur > From owner-seamoby@diameter.org Tue Apr 17 02:04:43 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA02725 for ; Tue, 17 Apr 2001 02:04:42 -0400 (EDT) Received: (qmail 5773 invoked by alias); 17 Apr 2001 05:53:45 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 5767 invoked by uid 200); 17 Apr 2001 05:53:45 -0000 Received: (qmail 5762 invoked from network); 17 Apr 2001 05:53:43 -0000 Received: from mgw-x3.nokia.com (131.228.20.26) by c900656-a.plstn1.sfba.home.com with SMTP; 17 Apr 2001 05:53:43 -0000 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x3.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f3H63MH19590 for ; Tue, 17 Apr 2001 09:03:23 +0300 (EET DST) Received: from esebh24nok.ntc.nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Tue, 17 Apr 2001 09:02:55 +0300 Received: by esebh24nok with Internet Mail Service (5.5.2652.78) id ; Tue, 17 Apr 2001 09:00:04 +0300 Message-ID: <01D91AFB08B6D211BFD00008C7EABAE10680AD2D@eseis04nok> From: john.loughney@nokia.com To: neumiller@telocity.com, charliep@IPRG.nokia.com Cc: seamoby@cdma-2000.org Subject: RE: [seamoby] IETF Architecture Work (RANT) Date: Tue, 17 Apr 2001 08:59:59 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-seamoby@diameter.org Precedence: bulk Hi Phil, > I am going to respectfully disagree Charlie. It *COULD* have been > already deployed massively over WPAN and WLAN technology > had we ignored the cellular concerns of AAA and QoS and minutes > of use carrier class requirements and gone rapidly with a data only > model. I'm probably out of the loop, but what technologies supporting WPANs are widely available? Also, WLAN devices are becoming more popular, but I don't think that they are still being mass produced (however, I will say that a local service provider is rolling out HIPPERLAN service in my neighborhood - though the hardware & cost is still too high, IMO). best regards, John From owner-seamoby@diameter.org Tue Apr 17 02:19:59 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA03603 for ; Tue, 17 Apr 2001 02:19:59 -0400 (EDT) Received: (qmail 6302 invoked by alias); 17 Apr 2001 06:09:18 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 6296 invoked by uid 200); 17 Apr 2001 06:09:17 -0000 Received: (qmail 6291 invoked from network); 17 Apr 2001 06:09:15 -0000 Received: from mgw-x3.nokia.com (131.228.20.26) by c900656-a.plstn1.sfba.home.com with SMTP; 17 Apr 2001 06:09:15 -0000 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x3.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f3H6IuH26585 for ; Tue, 17 Apr 2001 09:18:56 +0300 (EET DST) Received: from esebh25nok.ntc.nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Tue, 17 Apr 2001 09:18:24 +0300 Received: by esebh25nok with Internet Mail Service (5.5.2652.78) id ; Tue, 17 Apr 2001 09:07:08 +0300 Message-ID: <01D91AFB08B6D211BFD00008C7EABAE10680AD2E@eseis04nok> From: john.loughney@nokia.com To: mat@cisco.com Cc: seamoby@cdma-2000.org Subject: RE: [seamoby] IETF Architecture Work (RANT) Date: Tue, 17 Apr 2001 09:06:59 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-seamoby@diameter.org Precedence: bulk Hi Michael, > Can I also point out that we might be using > the term architecture in different ways? I > generally think of "architecture" in the > analogous way as to what an architect does when > she puts lines on a drawing to build a house. > 3GPP, Packetcable, etc, are all in the business > of producing those sorts of architectures. > Under that definition, the IETF has never done > architectures per se. It does have a base level > model, set of assumptions, and guiding > principles which facilitate protocol > development but this isn't really the same; > it's more like a guidelines which instruct > architects the do's and don't on the net. Sort > of like "don't build houses with the roof on > the foundation". I agree completely. This is what I meant in my original mail. cheers, John From owner-seamoby@diameter.org Tue Apr 17 02:22:43 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA03629 for ; Tue, 17 Apr 2001 02:22:43 -0400 (EDT) Received: (qmail 6441 invoked by alias); 17 Apr 2001 06:09:42 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 6434 invoked by uid 200); 17 Apr 2001 06:09:41 -0000 Received: (qmail 6393 invoked from network); 17 Apr 2001 06:09:34 -0000 Received: from mgw-x4.nokia.com (131.228.20.27) by c900656-a.plstn1.sfba.home.com with SMTP; 17 Apr 2001 06:09:34 -0000 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f3H6JY813767 for ; Tue, 17 Apr 2001 09:19:34 +0300 (EET DST) Received: from esebh24nok.ntc.nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Tue, 17 Apr 2001 09:18:27 +0300 Received: by esebh24nok with Internet Mail Service (5.5.2652.78) id ; Tue, 17 Apr 2001 09:11:20 +0300 Message-ID: <01D91AFB08B6D211BFD00008C7EABAE10680AD2F@eseis04nok> From: john.loughney@nokia.com To: seamus@bit-net.com Cc: seamoby@cdma-2000.org Subject: RE: [seamoby] IETF Architecture Work (RANT) Date: Tue, 17 Apr 2001 09:11:10 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-seamoby@diameter.org Precedence: bulk Hi Jim, > At a minimum we need to do good Requirements Definition and Analysis > phase. That has been missing in many working groups for a few years. > That helps with sorting assumptions and guiding light out. I'll second your proposal. I'd like to see a brief exercise of stating what the actual problem we are trying to solve is; and then start to make requirements. I think we all jump to quickly to the solution stage. A little more time thinking about what we want to do before we do it can help a lot. cheers, John From owner-seamoby@diameter.org Tue Apr 17 08:46:53 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA06360 for ; Tue, 17 Apr 2001 08:46:52 -0400 (EDT) Received: (qmail 9206 invoked by alias); 17 Apr 2001 12:36:01 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 9200 invoked by uid 200); 17 Apr 2001 12:36:01 -0000 Received: (qmail 9195 invoked from network); 17 Apr 2001 12:35:59 -0000 Received: from mgw-x1.nokia.com (131.228.20.21) by c900656-a.plstn1.sfba.home.com with SMTP; 17 Apr 2001 12:35:59 -0000 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f3HCiq205870 for ; Tue, 17 Apr 2001 15:44:52 +0300 (EET DST) Received: from esebh24nok.ntc.nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Tue, 17 Apr 2001 15:44:38 +0300 Received: by esebh24nok with Internet Mail Service (5.5.2652.78) id ; Tue, 17 Apr 2001 15:44:14 +0300 Message-ID: <01D91AFB08B6D211BFD00008C7EABAE10680AD4A@eseis04nok> From: john.loughney@nokia.com To: neumiller@telocity.com Cc: mobile-ip@sunroof.eng.sun.com, seamoby@cdma-2000.org Subject: [seamoby] RE: [mobile-ip] WG Announcement of Appeal: 3G Biases in SeaMoby a nd MIP Date: Tue, 17 Apr 2001 15:44:06 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-seamoby@diameter.org Precedence: bulk Hi Phil, > In a nutshell, my appeal, is that: the SeaMoby and Mobile IP WGs have > been mis-directed to focus too much on the interests of a > group of outside standards development organizations, namely 3GPP > (http://www.3gpp.org/) and 3GPP2 (http://www.3gpp2.org/), rather than > enhancing the global Internet which is the IETF's primary directive > per RFC 2026 section 1.1 which I quote a subsection here for convenience: First off, I do not know of ANY work that SeaMoby or Mobile IP is doing for 3GPP. As said by MANY others, Mobile IP can run over 3GPP networks, but none of the internal interfaces in the current 3GPP networks use Mobile IP. I do not see how any of the work in SeaMoby and Mobile IP WGs would be comprimised by 3GPP. In fact, some people have brought 3GPP up in the SeaMoby Context Transfer work and the consensus has been that the current 3GPP architecture does not support context transfer. > I can provide on demand the names of the quoted > individuals to the ADs or the IESG if an AD or the IESG needs to cross > reference or ask further questions. Hopefully, if you do this, you contact the person you are quoting beforehand, just to ensure you don't quote them out of text. > Next Steps Finally, having followed much of the discussion & work that has taken place, I still don't have a clear picture of what it is you are striving for. I think the best way forward would be for you do document your vision/architecture in an Internet Draft. Currently, you have submittend this draft: http://search.ietf.org/internet-drafts/draft-neumiller-seamoby-cnpmobility-0 0.txt which expires on May 18th, 2001. I think that this is a good start for work within SeaMoby. Perhaps it would be useful for you to update it and/or reissue it. Other than that, there is the OBAST requirements draft that was issued last June-ish, but that was, IMO, too vague to base work on. It also has expired. Again, if you feel that is the correct target architecture, then you should re-issue it and update it. If you have issued other drafts, please let me know. I think that this appeal would be much more effective if you document your work via Internet Drafts. If you meet with resistance to your submissions, and you feel that this is the correct direction, then an appeal would be much more reason (again, in my opinion). best regards, John From owner-seamoby@diameter.org Tue Apr 17 11:12:38 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA09780 for ; Tue, 17 Apr 2001 11:12:37 -0400 (EDT) Received: (qmail 10440 invoked by alias); 17 Apr 2001 15:02:29 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 10434 invoked by uid 200); 17 Apr 2001 15:02:29 -0000 Received: (qmail 10429 invoked from network); 17 Apr 2001 15:02:27 -0000 Received: from www.bit-net.com (HELO mail.users.bit-net.com) (208.146.132.4) by c900656-a.plstn1.sfba.home.com with SMTP; 17 Apr 2001 15:02:27 -0000 Received: from localhost by mail.users.bit-net.com; (5.65v3.2/1.1.8.2/30Jul96-0143PM) id AA20598; Tue, 17 Apr 2001 11:11:42 -0400 Date: Tue, 17 Apr 2001 11:11:42 -0400 (EDT) From: Jim Bound To: john.loughney@nokia.com Cc: seamoby@cdma-2000.org Subject: RE: [seamoby] IETF Architecture Work (RANT) In-Reply-To: <01D91AFB08B6D211BFD00008C7EABAE10680AD2F@eseis04nok> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-seamoby@diameter.org Precedence: bulk Hi John, Words of wisdom we should listen too. 100% agree.... /jim On Tue, 17 Apr 2001 john.loughney@nokia.com wrote: > Hi Jim, > > > At a minimum we need to do good Requirements Definition and Analysis > > phase. That has been missing in many working groups for a few years. > > That helps with sorting assumptions and guiding light out. > > I'll second your proposal. I'd like to see a brief exercise > of stating what the actual problem we are trying to solve is; > and then start to make requirements. > > I think we all jump to quickly to the solution stage. A little > more time thinking about what we want to do before we do it > can help a lot. > > cheers, > John > From owner-seamoby@diameter.org Tue Apr 17 17:33:02 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA16905 for ; Tue, 17 Apr 2001 17:32:59 -0400 (EDT) Received: (qmail 15430 invoked by alias); 17 Apr 2001 21:22:14 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 15424 invoked by uid 200); 17 Apr 2001 21:22:13 -0000 Received: (qmail 15419 invoked from network); 17 Apr 2001 21:22:12 -0000 Received: from motgate3.mot.com (144.189.100.103) by c900656-a.plstn1.sfba.home.com with SMTP; 17 Apr 2001 21:22:12 -0000 Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate3.mot.com (motgate3 2.1) with ESMTP id OAA20763 for ; Tue, 17 Apr 2001 14:25:48 -0700 (MST)] Received: [from il35exm01.cig.mot.com (IL35EXM01.cig.mot.com [160.19.16.101]) by mothost.mot.com (MOT-mothost 2.0) with ESMTP id OAA23876 for ; Tue, 17 Apr 2001 14:31:23 -0700 (MST)] Received: by IL35EXM01.cig.mot.com with Internet Mail Service (5.5.2653.19) id <2RXQ3W7B>; Tue, 17 Apr 2001 16:31:23 -0500 Message-ID: <35DBB8B7AC89D4118E98009027B1009B1B7AD8@IL27EXM10.cig.mot.com> From: Nakhjiri Madjid-MNAKHJI1 To: "'john.loughney@nokia.com'" Cc: mobile-ip@sunroof.eng.sun.com, seamoby@cdma-2000.org Subject: RE: [seamoby] RE: [mobile-ip] WG Announcement of Appeal: 3G Biase s in SeaMoby and MIP Date: Tue, 17 Apr 2001 16:31:22 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-seamoby@diameter.org Precedence: bulk I agree with John, How about the following in CT requirement "3GPP and 3GPP2 MUST not use seamoby/CT protocols" would that make sense???? :) see my response below -----Original Message----- From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] Sent: Tuesday, April 17, 2001 7:44 AM To: neumiller@telocity.com Cc: mobile-ip@sunroof.eng.sun.com; seamoby@cdma-2000.org Subject: [seamoby] RE: [mobile-ip] WG Announcement of Appeal: 3G Biases in SeaMoby and MIP First off, I do not know of ANY work that SeaMoby or Mobile IP is doing for 3GPP. As said by MANY others, Mobile IP can run over 3GPP networks, but none of the internal interfaces in the current 3GPP networks use Mobile IP. I do not see how any of the work in SeaMoby and Mobile IP WGs would be comprimised by 3GPP. In fact, some people have brought 3GPP up in the SeaMoby Context Transfer work and the consensus has been that the current 3GPP architecture does not support context transfer. > I can provide on demand the names of the quoted > individuals to the ADs or the IESG if an AD or the IESG needs to cross > reference or ask further questions. Madjid N>> Talking about quoting, last week, Phil himself brought the 3GPP-3GPP2 context transfer issue up on the list (http://www.diameter.org/cgi-bin/lwgate/SEAMOBY-CONTEXT/archives/seamoby-context.archive.0104/Author/article-115.html) "I am not sure if this matters to the CT team or not, but those of you that care about 3GPP and 3GPP2 and/or CT compatibility with MIP SHOULD be concerned about this" We were then accused of doing academic excercises in seamoby and doing a context transfer that does not have any customer. we responded by (http://www.diameter.org/cgi-bin/lwgate/SEAMOBY-CONTEXT/archives/seamoby-context.archive.0104/Subject/article-151.html) We all decided to wait with different technology's specific CT requirements, or specific CT context, so I don't know what the purpose of this thread is,.... This week we were accused of being slaves of 3G/MIP, and were asked to stop the requirement work. which one is it? I don't understand and I don't want to guess what I will be accused of tommorrow, since It is my vacation anyway :) I think the CT work has been very fruitful (until recently) in bringing people from different technologies together to write broad requirements for whoever want to use it. We all agreed the CT is just a transport vehicle for getting context from one place to another, just like a truck. Somebody might use the truck for drug traffic, the other for getting food to starved children, in any cases nobody sues the truck company because the first one used its trucks for drug traffic. Now making a terrible analogy here (my appologies) Can we ban 3GPP* from using CT protocol??? didn't think so. I don't think we had any bias in our work, except that some people might think, our paycheck is coming from the wrong companies. Hey, somebody send me a few million bucks to support myself and I start writing protocols for IETF as a freelance!! Lets put a positive spin to everything, give us some triggers for CT!! From owner-seamoby@diameter.org Tue Apr 17 20:25:58 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA18833 for ; Tue, 17 Apr 2001 20:25:57 -0400 (EDT) Received: (qmail 18241 invoked by alias); 18 Apr 2001 00:15:29 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 18235 invoked by uid 200); 18 Apr 2001 00:15:28 -0000 Received: (qmail 18230 invoked from network); 18 Apr 2001 00:15:27 -0000 Received: from c007-h013.c007.snv.cp.net (HELO c007.snv.cp.net) (209.228.33.220) by c900656-a.plstn1.sfba.home.com with SMTP; 18 Apr 2001 00:15:27 -0000 Received: (cpmta 25756 invoked from network); 17 Apr 2001 17:24:16 -0700 Received: from unknown (HELO philneum) (64.193.0.129) by smtp.telocity.com (209.228.33.220) with SMTP; 17 Apr 2001 17:24:16 -0700 X-Sent: 18 Apr 2001 00:24:16 GMT Message-ID: <021f01c0c79d$32d3ad20$6501a8c0@philneum> Reply-To: "Phil Neumiller" From: "Phil Neumiller" To: , References: <048401c0c472$0041c500$6501a8c0@philneum> Subject: [seamoby] ANNOUNCEMENT: 3G bias appeal cancelled Date: Tue, 17 Apr 2001 19:19:07 -0500 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-seamoby@diameter.org Precedence: bulk I give up. It is clear from the emails I have received thus far that this appeal is not going to go anywhere in the MIP or SeaMoby WGs. Consider it cancelled. I still believe there are too many 3G biases among other problems in the agenda and priorities of the MIP & SeaMoby WGs. However, I will show deference to each WG as a whole. I am sorry for the inconvenience this thread may have caused the WG and chairs. Best regards to all, Phil Neumiller From owner-seamoby@diameter.org Thu Apr 19 04:30:15 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA08714 for ; Thu, 19 Apr 2001 04:30:14 -0400 (EDT) Received: (qmail 30141 invoked by alias); 19 Apr 2001 08:18:45 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 30135 invoked by uid 200); 19 Apr 2001 08:18:45 -0000 Received: (qmail 30130 invoked from network); 19 Apr 2001 08:18:43 -0000 Received: from mgw-x2.nokia.com (131.228.20.22) by c900656-a.plstn1.sfba.home.com with SMTP; 19 Apr 2001 08:18:43 -0000 Received: from esvir06nok.ntc.nokia.com (esvir06nokt.ntc.nokia.com [172.21.143.38]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f3J8SDS24079 for ; Thu, 19 Apr 2001 11:28:13 +0300 (EET DST) Received: from esebh25nok.ntc.nokia.com (unverified) by esvir06nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Thu, 19 Apr 2001 11:28:03 +0300 Received: by esebh25nok with Internet Mail Service (5.5.2652.78) id ; Thu, 19 Apr 2001 11:27:53 +0300 Message-ID: <01D91AFB08B6D211BFD00008C7EABAE10680AD73@eseis04nok> From: john.loughney@nokia.com To: seamoby@diameter.org Subject: [seamoby] SeaMoby MicroMobility Work Date: Thu, 19 Apr 2001 11:27:44 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-seamoby@diameter.org Precedence: bulk Hi all, It seems that the MM Design Team chair is AWOL - I haven't heard anything about this work continuing. The list has been quite quiet about MM. As I understand, there is still this work to do: 1. Completion of the MM Problem Statement 2. Requirements for Smooth Handovers to MIP WG 3. Requirements for for a new protocol that allows for AP discovery to be done (selection of handoff target when multiple exist). Is there still interest and/or will to do this work? Dana, if you are out there, can you confirm your available to chair this work, or shall we pick a new DT chair? best regards, John From owner-seamoby@diameter.org Thu Apr 19 07:16:29 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA09937 for ; Thu, 19 Apr 2001 07:16:28 -0400 (EDT) Received: (qmail 31938 invoked by alias); 19 Apr 2001 11:05:33 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 31932 invoked by uid 200); 19 Apr 2001 11:05:32 -0000 Received: (qmail 31927 invoked from network); 19 Apr 2001 11:05:27 -0000 Received: from c007-h011.c007.snv.cp.net (HELO c007.snv.cp.net) (209.228.33.217) by c900656-a.plstn1.sfba.home.com with SMTP; 19 Apr 2001 11:05:27 -0000 Received: (cpmta 21649 invoked from network); 19 Apr 2001 04:14:20 -0700 Received: from dsl-64-193-0-129.telocity.com (HELO philneum) (64.193.0.129) by smtp.telocity.com (209.228.33.217) with SMTP; 19 Apr 2001 04:14:20 -0700 X-Sent: 19 Apr 2001 11:14:20 GMT Message-ID: <013e01c0c8c1$c2fedda0$6501a8c0@philneum> Reply-To: "Phil Neumiller" From: "Phil Neumiller" To: "Phil Neumiller" , , References: <01D91AFB08B6D211BFD00008C7EABAE10680AD73@eseis04nok> <012b01c0c8c0$edbdf860$6501a8c0@philneum> Subject: Re: [seamoby] SeaMoby MicroMobility Work Date: Thu, 19 Apr 2001 06:13:22 -0500 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-seamoby@diameter.org Precedence: bulk BTW, the other work you mention is SeaMoby WG stuff I believe i.e. not specifically tied to the MM DT. -pdn ----- Original Message ----- From: "Phil Neumiller" To: ; Sent: Thursday, April 19, 2001 6:07 AM Subject: Re: [seamoby] SeaMoby MicroMobility Work > John the MM work was moved the IRTF. There is no more > work in the SeaMoby WG for MM. I thought this was made > clear to all at IETF 50. > > -pdn > ----- Original Message ----- > From: > To: > Sent: Thursday, April 19, 2001 3:27 AM > Subject: [seamoby] SeaMoby MicroMobility Work > > > > Hi all, > > > > It seems that the MM Design Team chair is AWOL - I haven't > > heard anything about this work continuing. > > > > The list has been quite quiet about MM. As I understand, > > there is still this work to do: > > > > 1. Completion of the MM Problem Statement > > 2. Requirements for Smooth Handovers to MIP WG > > 3. Requirements for for a new protocol that allows for AP discovery to be > > done > > (selection of handoff target when multiple exist). > > > > Is there still interest and/or will to do this work? > > > > Dana, if you are out there, can you confirm your available to > > chair this work, or shall we pick a new DT chair? > > > > best regards, > > John > > > > > From owner-seamoby@diameter.org Thu Apr 19 07:46:28 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA10113 for ; Thu, 19 Apr 2001 07:46:27 -0400 (EDT) Received: (qmail 32627 invoked by alias); 19 Apr 2001 11:35:26 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 32621 invoked by uid 200); 19 Apr 2001 11:35:26 -0000 Received: (qmail 32615 invoked from network); 19 Apr 2001 11:35:15 -0000 Received: from mgw-x2.nokia.com (131.228.20.22) by c900656-a.plstn1.sfba.home.com with SMTP; 19 Apr 2001 11:35:15 -0000 Received: from esvir06nok.ntc.nokia.com (esvir06nokt.ntc.nokia.com [172.21.143.38]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f3JBiFS12339 for ; Thu, 19 Apr 2001 14:44:15 +0300 (EET DST) Received: from esebh25nok.ntc.nokia.com (unverified) by esvir06nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Thu, 19 Apr 2001 14:44:06 +0300 Received: by esebh25nok with Internet Mail Service (5.5.2652.78) id ; Thu, 19 Apr 2001 14:38:42 +0300 Message-ID: <01D91AFB08B6D211BFD00008C7EABAE10680AD83@eseis04nok> From: john.loughney@nokia.com To: neumiller@telocity.com, seamoby@diameter.org Subject: RE: [seamoby] SeaMoby MicroMobility Work Date: Thu, 19 Apr 2001 14:38:41 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-seamoby@diameter.org Precedence: bulk Phil, Our Chair wrote the following: 1. The MM DT will write a requirements draft for Mobile IP to understand the seamoby requirements. This will be used by the MIP WG to know how Mobile IP needs to be changed. 2. The IRTF has agreed to take the new local mobility protocol, and as with many other IRTF efforts, the work will move back into the IETF once it is ready. 3. The MM DT will begin to write the requirements for a new protocol that allows for AP discovery to be done (again, I really don't know what the right name of this work is, but it is similar to what Phil Neumiller calls CNP). So, this is what I was talking about. About the Problem Statement, I thought Pat mentioned we should at least clean it up and submit it. I could be wrong, though. John > -----Original Message----- > From: ext Phil Neumiller [mailto:neumiller@telocity.com] > Sent: April 19, 2001 14:07 > To: john.loughney@nokia.com; seamoby@diameter.org > Subject: Re: [seamoby] SeaMoby MicroMobility Work > > > John the MM work was moved the IRTF. There is no more > work in the SeaMoby WG for MM. I thought this was made > clear to all at IETF 50. > > -pdn > ----- Original Message ----- > From: > To: > Sent: Thursday, April 19, 2001 3:27 AM > Subject: [seamoby] SeaMoby MicroMobility Work > > > > Hi all, > > > > It seems that the MM Design Team chair is AWOL - I haven't > > heard anything about this work continuing. > > > > The list has been quite quiet about MM. As I understand, > > there is still this work to do: > > > > 1. Completion of the MM Problem Statement > > 2. Requirements for Smooth Handovers to MIP WG > > 3. Requirements for for a new protocol that allows for AP > discovery to be > > done > > (selection of handoff target when multiple exist). > > > > Is there still interest and/or will to do this work? > > > > Dana, if you are out there, can you confirm your available to > > chair this work, or shall we pick a new DT chair? > > > > best regards, > > John > > > > From owner-seamoby@diameter.org Thu Apr 19 08:08:20 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA10183 for ; Thu, 19 Apr 2001 08:08:19 -0400 (EDT) Received: (qmail 1420 invoked by alias); 19 Apr 2001 11:54:46 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 1414 invoked by uid 200); 19 Apr 2001 11:54:46 -0000 Received: (qmail 1402 invoked from network); 19 Apr 2001 11:54:43 -0000 Received: from c007-h012.c007.snv.cp.net (HELO c007.snv.cp.net) (209.228.33.219) by c900656-a.plstn1.sfba.home.com with SMTP; 19 Apr 2001 11:54:43 -0000 Received: (cpmta 9127 invoked from network); 19 Apr 2001 05:03:58 -0700 Received: from unknown (HELO philneum) (64.193.0.129) by smtp.telocity.com (209.228.33.219) with SMTP; 19 Apr 2001 05:03:58 -0700 X-Sent: 19 Apr 2001 12:03:58 GMT Message-ID: <015f01c0c8c8$b2072140$6501a8c0@philneum> Reply-To: "Phil Neumiller" From: "Phil Neumiller" To: , References: <01D91AFB08B6D211BFD00008C7EABAE10680AD83@eseis04nok> Subject: Re: [seamoby] SeaMoby MicroMobility Work Date: Thu, 19 Apr 2001 07:03:00 -0500 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-seamoby@diameter.org Precedence: bulk Although this sounds like a good plan, I have the following comments. ----- Original Message ----- From: > > 1. The MM DT will write a requirements draft for Mobile IP to > understand > the seamoby requirements. This will be used by the MIP WG to > know how Mobile IP needs to be changed. The SeaMoby DT never got to drafting a set of requirements, in fact never finished the problem statement completely. So, this goal seems rather odd to me. Furthermore, it would seem that the people that are interested in "changing" MIP SHOULD be working in the MIP WG. I would like the WG members to comment on the viability of this goal. > 2. The IRTF has agreed to take the new local mobility protocol, and > as with many other IRTF efforts, the work will move back into the > IETF once it is ready. No comment necessary, except that I would encourage some of the MM DT members to get active in the IRTF work. > 3. The MM DT will begin to write the requirements for a new protocol > that allows for AP discovery to be done (again, I really don't > know > what the right name of this work is, but it is similar to what > Phil Neumiller calls CNP). It would seem to me that this work is really targetted towards MIP again, at least as Pat and the IESG had presented it. It seems odd that the work should be done in SeaMoby. If it is to be done in SeaMoby and it is to be "similar" to contract nets, then I would propose a "new" design team be formed, or the main SeaMoby mail list be the place for discourse, at least until it is clearer where this is headed. Since this type of work has no WG draft, that may be a good first step. > So, this is what I was talking about. > > About the Problem Statement, I thought Pat mentioned we should at least > clean > it up and submit it. I could be wrong, though. This clearly is a MM DT work item. Thanks, Phil Neumiller From owner-seamoby@diameter.org Thu Apr 19 08:15:44 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA10222 for ; Thu, 19 Apr 2001 08:15:44 -0400 (EDT) Received: (qmail 2005 invoked by alias); 19 Apr 2001 12:03:41 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 1999 invoked by uid 200); 19 Apr 2001 12:03:41 -0000 Received: (qmail 1994 invoked from network); 19 Apr 2001 12:03:39 -0000 Received: from unknown (HELO megisto-sql1.megisto.com) (63.113.114.132) by c900656-a.plstn1.sfba.home.com with SMTP; 19 Apr 2001 12:03:39 -0000 Received: by mail.megisto.com with Internet Mail Service (5.5.2650.21) id ; Thu, 19 Apr 2001 08:06:44 -0400 Message-ID: From: Phil Roberts To: "'john.loughney@nokia.com'" , neumiller@telocity.com, seamoby@diameter.org Subject: RE: [seamoby] SeaMoby MicroMobility Work Date: Thu, 19 Apr 2001 08:06:43 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-seamoby@diameter.org Precedence: bulk Hi, I took the token to produce a first draft of a problem statement to give to the IRTF. I few folks volunteered to help work on this. I've got about half a draft and hope to get it out to those volunteers this week and hopefully get a revised version for the WG next week. Phil > -----Original Message----- > From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] > Sent: Thursday, April 19, 2001 7:39 AM > To: neumiller@telocity.com; seamoby@diameter.org > Subject: RE: [seamoby] SeaMoby MicroMobility Work > > > Phil, > > Our Chair wrote the following: > > 1. The MM DT will write a requirements draft for Mobile IP to > understand > the seamoby requirements. This will be used by the MIP WG to > know how Mobile IP needs to be changed. > 2. The IRTF has agreed to take the new local mobility > protocol, and > as with many other IRTF efforts, the work will move > back into the > IETF once it is ready. > 3. The MM DT will begin to write the requirements for a > new protocol > that allows for AP discovery to be done (again, I > really don't > know > what the right name of this work is, but it is > similar to what > Phil Neumiller calls CNP). > > So, this is what I was talking about. > > About the Problem Statement, I thought Pat mentioned we > should at least > clean > it up and submit it. I could be wrong, though. > > John > > > -----Original Message----- > > From: ext Phil Neumiller [mailto:neumiller@telocity.com] > > Sent: April 19, 2001 14:07 > > To: john.loughney@nokia.com; seamoby@diameter.org > > Subject: Re: [seamoby] SeaMoby MicroMobility Work > > > > > > John the MM work was moved the IRTF. There is no more > > work in the SeaMoby WG for MM. I thought this was made > > clear to all at IETF 50. > > > > -pdn > > ----- Original Message ----- > > From: > > To: > > Sent: Thursday, April 19, 2001 3:27 AM > > Subject: [seamoby] SeaMoby MicroMobility Work > > > > > > > Hi all, > > > > > > It seems that the MM Design Team chair is AWOL - I haven't > > > heard anything about this work continuing. > > > > > > The list has been quite quiet about MM. As I understand, > > > there is still this work to do: > > > > > > 1. Completion of the MM Problem Statement > > > 2. Requirements for Smooth Handovers to MIP WG > > > 3. Requirements for for a new protocol that allows for AP > > discovery to be > > > done > > > (selection of handoff target when multiple exist). > > > > > > Is there still interest and/or will to do this work? > > > > > > Dana, if you are out there, can you confirm your available to > > > chair this work, or shall we pick a new DT chair? > > > > > > best regards, > > > John > > > > > > > > From owner-seamoby@diameter.org Thu Apr 19 10:47:34 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA11878 for ; Thu, 19 Apr 2001 10:47:34 -0400 (EDT) Received: (qmail 3309 invoked by alias); 19 Apr 2001 14:36:32 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 3303 invoked by uid 200); 19 Apr 2001 14:36:32 -0000 Received: (qmail 3298 invoked from network); 19 Apr 2001 14:36:30 -0000 Received: from sirius.ctr.columbia.edu (128.59.64.60) by c900656-a.plstn1.sfba.home.com with SMTP; 19 Apr 2001 14:36:30 -0000 Received: from SWEETPEA (sweetpea.comet.columbia.edu [128.59.65.202]) by sirius.ctr.columbia.edu (8.9.3/8.6.4.287) with SMTP id KAA27785; Thu, 19 Apr 2001 10:45:16 -0400 (EDT) From: "Andrew T. Campbell" To: "'Phil Neumiller'" , , Cc: "Andrew Campbell \(E-mail\)" Subject: RE: [seamoby] SeaMoby MicroMobility Work Date: Thu, 19 Apr 2001 10:43:27 -0700 Message-ID: <001201c0c8f8$3df2c9a0$ca413b80@SWEETPEA> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 In-reply-to: <012b01c0c8c0$edbdf860$6501a8c0@philneum> Importance: Normal Sender: owner-seamoby@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit > -----Original Message----- > From: owner-seamoby@diameter.org [mailto:owner-seamoby@diameter.org]On > Behalf Of Phil Neumiller > Sent: Thursday, April 19, 2001 4:07 AM > To: john.loughney@nokia.com; seamoby@diameter.org > Subject: Re: [seamoby] SeaMoby MicroMobility Work > > > John the MM work was moved the IRTF. There is no more > work in the SeaMoby WG for MM. I thought this was made > clear to all at IETF 50. > > -pdn Here is a late comment on that decision: The irony of putting this activity on the back burner is that the companies and market is rushing towards 4G as soon as 2004 and are in need of an IP micro-mobility protocol (incl. fast/seamless handoff, QOS, security, paging etc.) to make 4G work. With hindsight, I think this was a very bad decision (with great respect to the people that made it) potentially putting IETF at a disadvantage for 4G (which is a pseudomon for wireless Internet of course) if people don't buy Mobile IP. IETF is betting all is chips on this protocol. I really do not understand this mentality of "if its a mobile problem then the solution is Mobile IP++". Its just not sound engineering. We are at the starting block for 4G and whatever the question is the answer is always the same - Mobile IP. There has to be a new way. The IEFT has a great opportunity to capitalize on 4G but not if new initiatives are punted and blocked because of the past investment in Mobile IP. I made these comments in San Diego and felt the chill. I repeat them here in hope - wearing my asbestos pants. Best, --- Andrew http://comet.columbia.edu/~campbell From owner-seamoby@diameter.org Thu Apr 19 10:59:22 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA12147 for ; Thu, 19 Apr 2001 10:59:21 -0400 (EDT) Received: (qmail 3809 invoked by alias); 19 Apr 2001 14:48:00 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 3803 invoked by uid 200); 19 Apr 2001 14:47:59 -0000 Received: (qmail 3798 invoked from network); 19 Apr 2001 14:47:58 -0000 Received: from c007-h012.c007.snv.cp.net (HELO c007.snv.cp.net) (209.228.33.219) by c900656-a.plstn1.sfba.home.com with SMTP; 19 Apr 2001 14:47:58 -0000 Received: (cpmta 20841 invoked from network); 19 Apr 2001 07:57:01 -0700 Received: from dsl-64-193-0-129.telocity.com (HELO philneum) (64.193.0.129) by smtp.telocity.com (209.228.33.219) with SMTP; 19 Apr 2001 07:57:01 -0700 X-Sent: 19 Apr 2001 14:57:01 GMT Message-ID: <01b601c0c8e0$de1f5a00$6501a8c0@philneum> Reply-To: "Phil Neumiller" From: "Phil Neumiller" To: "Andrew T. Campbell" , , Cc: "Andrew Campbell \(E-mail\)" References: <001201c0c8f8$3df2c9a0$ca413b80@SWEETPEA> Subject: Re: [seamoby] SeaMoby MicroMobility Work Date: Thu, 19 Apr 2001 09:56:01 -0500 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-seamoby@diameter.org Precedence: bulk I could not agree more Andrew. Unfortunately, this has to be taken up with the IESG if we are to change it. I had a couple comments on this below. ----- Original Message ----- From: "Andrew T. Campbell" To: "'Phil Neumiller'" ; ; Cc: "Andrew Campbell (E-mail)" > Here is a late comment on that decision: > > The irony of putting this activity > on the back burner is that the > companies and market is rushing > towards 4G as soon as 2004 and are > in need of an IP micro-mobility protocol (incl. > fast/seamless handoff, QOS, security, > paging etc.) to make 4G work. When we say 4G (around cellular folks, like those in the MIP WG), we have to be careful, since they see it as a 2010 thing. I see it as thing needed desperately NOW to get us out of the big mess that is 3G. > With hindsight, I think this was a > very bad decision (with great respect to the people > that made it) potentially putting IETF at a disadvantage > for 4G (which is a pseudomon for wireless > Internet of course) if people don't buy Mobile IP. > IETF is betting all is chips on this protocol. I agree whole heartedly, in fact I recently campaigned that the MIP WG is too 3G biased, but I got no traction from the WG which I fealt was needed to procede so I abandoned the "CRUSADE" as some have called it. > > I really do not understand this > mentality of "if its a mobile problem > then the solution is Mobile IP++". > Its just not sound engineering. > > We are at the starting block for 4G > and whatever the question is the answer > is always the same - Mobile IP. > There has to be a new way. > > The IEFT has a great opportunity to > capitalize on 4G but not if new initiatives > are punted and blocked because of the > past investment in Mobile IP. Agree! However, I do think MIPv6 did go in the right direction. Unfortunately, we can't get involved in that since its a "closed" community of designers. Scott Bradner confirmed to me that he did not think design teams should be allowed to last so long as these have in the MIP WG. It would seem to me that the archives should be open before every IETF meeting. > > I made these comments in San Diego and > felt the chill. I repeat them here in hope - > wearing my asbestos pants. I have been getting cold ice cubes and halon freezes ever since I have started my own 4G campaign. We need more voices like yours here Andrew. Thanks, Phil From owner-seamoby@diameter.org Thu Apr 19 12:45:25 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA14246 for ; Thu, 19 Apr 2001 12:45:25 -0400 (EDT) Received: (qmail 4946 invoked by alias); 19 Apr 2001 16:34:55 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 4940 invoked by uid 200); 19 Apr 2001 16:34:55 -0000 Received: (qmail 4935 invoked from network); 19 Apr 2001 16:34:53 -0000 Received: from wall.comdev.cc (HELO cleanup.comdev.cc) (63.150.62.162) by c900656-a.plstn1.sfba.home.com with SMTP; 19 Apr 2001 16:34:53 -0000 Received: (qmail 14799 invoked from network); 19 Apr 2001 16:44:13 -0000 Received: from jersey.comdev.cc (HELO comdev.cc) (msmith@192.168.67.202) by cleanup.comdev.cc with SMTP; 19 Apr 2001 16:44:13 -0000 Message-ID: <3ADF15DD.6020201@comdev.cc> Date: Thu, 19 Apr 2001 09:44:13 -0700 From: Mark Smith Reply-To: mark.smith@comdev.cc Organization: COM DEV Wireless User-Agent: Mozilla/5.0 (X11; U; Linux 2.2.19 i686; en-US; 0.8.1) Gecko/20010326 X-Accept-Language: en MIME-Version: 1.0 To: seamoby@diameter.org Subject: [seamoby] Self introduction, aka "The FNG sticks his head out." Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-seamoby@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit Hello everyone, my name is Mark Smith. I work as a network engineer with Hat Horan at COM DEV Wireless in San Luis Obispo, California. I'll be spending time on the SeaMoby lists in the future and just wanted to poke my head out and introduce myself before I dive into conversation. My background is IP network design, systems administration and a bit of programming. In addition, I'm a bit of a Security Freak(tm) in my spare time. I have to confess, however, that I'm relatively new to the whole IETF bit; please be kind if I start asking stupid questions. :) I've been lurking for the past week or two and probably will for a bit longer, but you'll (hopefully) see me participating once I get a bit of (pardon the pun) context on where we are in the conversations. Y'all are welcome to get ahold of me at the following contact info: Mark Smith Network Engineer, COM DEV Wireless 3450 Broad St., Suite 107 San Luis Obispo, CA 93401 email: mark.smith@comdev.cc phone: 805.544.1089 I look forward to working with y'all! :) -Mark From owner-seamoby@diameter.org Thu Apr 19 12:53:57 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA14340 for ; Thu, 19 Apr 2001 12:53:56 -0400 (EDT) Received: (qmail 5470 invoked by alias); 19 Apr 2001 16:43:34 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 5464 invoked by uid 200); 19 Apr 2001 16:43:34 -0000 Received: (qmail 5459 invoked from network); 19 Apr 2001 16:43:33 -0000 Received: from wall.comdev.cc (HELO cleanup.comdev.cc) (63.150.62.162) by c900656-a.plstn1.sfba.home.com with SMTP; 19 Apr 2001 16:43:33 -0000 Received: (qmail 15006 invoked from network); 19 Apr 2001 16:52:53 -0000 Received: from jersey.comdev.cc (HELO comdev.cc) (msmith@192.168.67.202) by cleanup.comdev.cc with SMTP; 19 Apr 2001 16:52:53 -0000 Message-ID: <3ADF17E5.6020603@comdev.cc> Date: Thu, 19 Apr 2001 09:52:53 -0700 From: Mark Smith Reply-To: mark.smith@comdev.cc Organization: COM DEV Wireless User-Agent: Mozilla/5.0 (X11; U; Linux 2.2.19 i686; en-US; 0.8.1) Gecko/20010326 X-Accept-Language: en MIME-Version: 1.0 To: mark.smith@comdev.cc CC: seamoby@diameter.org Subject: Re: [seamoby] Self introduction, aka "The FNG sticks his head out." References: <3ADF15DD.6020201@comdev.cc> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-seamoby@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit Ack! That'd be MAT Horan, not Hat Horan.. Thanks for pointing that out to me, Alessio. -Mark Mark Smith wrote: > Hello everyone, my name is Mark Smith. I work as a network engineer > with Hat Horan at COM DEV Wireless in San Luis Obispo, California. I'll > be spending time on the SeaMoby lists in the future and just wanted to > poke my head out and introduce myself before I dive into conversation. > > My background is IP network design, systems administration and a bit of > programming. In addition, I'm a bit of a Security Freak(tm) in my spare > time. I have to confess, however, that I'm relatively new to the whole > IETF bit; please be kind if I start asking stupid questions. :) > > I've been lurking for the past week or two and probably will for a bit > longer, but you'll (hopefully) see me participating once I get a bit of > (pardon the pun) context on where we are in the conversations. > > Y'all are welcome to get ahold of me at the following contact info: > > Mark Smith > Network Engineer, COM DEV Wireless > 3450 Broad St., Suite 107 > San Luis Obispo, CA > 93401 > email: mark.smith@comdev.cc > phone: 805.544.1089 > > I look forward to working with y'all! :) > > -Mark From owner-seamoby@diameter.org Thu Apr 19 13:01:41 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA14412 for ; Thu, 19 Apr 2001 13:01:41 -0400 (EDT) Received: (qmail 5962 invoked by alias); 19 Apr 2001 16:51:22 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 5956 invoked by uid 200); 19 Apr 2001 16:51:22 -0000 Received: (qmail 5951 invoked from network); 19 Apr 2001 16:51:21 -0000 Received: from c007-h000.c007.snv.cp.net (HELO c007.snv.cp.net) (209.228.33.206) by c900656-a.plstn1.sfba.home.com with SMTP; 19 Apr 2001 16:51:21 -0000 Received: (cpmta 19794 invoked from network); 19 Apr 2001 09:53:17 -0700 Received: from dsl-64-193-0-129.telocity.com (HELO philneum) (64.193.0.129) by smtp.telocity.com (209.228.33.206) with SMTP; 19 Apr 2001 09:53:17 -0700 X-Sent: 19 Apr 2001 16:53:17 GMT Message-ID: <021401c0c8f1$142c6060$6501a8c0@philneum> Reply-To: "Phil Neumiller" From: "Phil Neumiller" To: "Andrew T. Campbell" , , References: <001201c0c8f8$3df2c9a0$ca413b80@SWEETPEA> Subject: [seamoby] 4G BOF? Date: Thu, 19 Apr 2001 11:52:04 -0500 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-seamoby@diameter.org Precedence: bulk I think we MAY need a 4G BOF, i.e. what SeaMoby was supposed to be as opposed to what it became. This would be working on the global Internet architecture for the purpose of improving global wireless handovers of all types (primarily data, then QoS). A primary goal of this work group could in fact be the large scale deployment of MIP (this being ironic) by focussing on NON-carrier class mobility, i.e. growth of wireless access and handovers would take primary precedence over things like AAA, security, QoS, etc. This would not conflict with MIP or SeaMoby (now son of MIP) since these WGs are now ALMOST exclusively working on 3G network applications of MIP, IMO. -pdn From owner-seamoby@diameter.org Thu Apr 19 13:31:26 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA14969 for ; Thu, 19 Apr 2001 13:31:25 -0400 (EDT) Received: (qmail 7277 invoked by alias); 19 Apr 2001 17:20:37 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 7269 invoked by uid 200); 19 Apr 2001 17:20:37 -0000 Received: (qmail 7256 invoked from network); 19 Apr 2001 17:20:34 -0000 Received: from sj-msg-core-1.cisco.com (171.71.163.11) by c900656-a.plstn1.sfba.home.com with SMTP; 19 Apr 2001 17:20:34 -0000 Received: from mira-sjcm-3.cisco.com (mira-sjcm-3.cisco.com [171.69.43.101]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id KAA13904; Thu, 19 Apr 2001 10:29:24 -0700 (PDT) Received: from gopal.cisco.com (gdommety-dsl5.cisco.com [10.19.17.142]) by mira-sjcm-3.cisco.com (Mirapoint) with ESMTP id ACO18873; Thu, 19 Apr 2001 10:29:22 -0700 (PDT) Message-Id: <4.3.2.7.2.20010419102600.04553a00@mira-sjcm-3.cisco.com> X-Sender: gdommety@mira-sjcm-3.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 19 Apr 2001 10:27:02 -0700 To: "Phil Neumiller" , "Andrew T. Campbell" , , From: Gopal Dommety Subject: Re: [seamoby] 4G BOF? In-Reply-To: <021401c0c8f1$142c6060$6501a8c0@philneum> References: <001201c0c8f8$3df2c9a0$ca413b80@SWEETPEA> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-seamoby@diameter.org Precedence: bulk At 11:52 AM 19/04/01 -0500, Phil Neumiller wrote: >I think we MAY need a 4G BOF, i.e. what SeaMoby was supposed to be >as opposed to what it became. This would be working on the global >Internet architecture for the purpose of improving global wireless >handovers of all types (primarily data, then QoS). A primary goal of this >work group could in fact be the large scale deployment of MIP (this being >ironic) by focussing on NON-carrier class mobility, what is non-carrier class mobility? >i.e. growth of wireless >access and handovers would take primary precedence over things like >AAA, security, QoS, etc. I am a bit confused. Could you elobrate? -gopal >This would not conflict with MIP or SeaMoby (now son of MIP) since >these WGs are now ALMOST exclusively working on 3G network >applications of MIP, IMO. > >-pdn From owner-seamoby@diameter.org Thu Apr 19 14:42:16 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA16129 for ; Thu, 19 Apr 2001 14:42:15 -0400 (EDT) Received: (qmail 8287 invoked by alias); 19 Apr 2001 18:31:51 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 8281 invoked by uid 200); 19 Apr 2001 18:31:51 -0000 Received: (qmail 8276 invoked from network); 19 Apr 2001 18:31:50 -0000 Received: from bucky-rwcmex.excite.com (HELO bucky.excite.com) (198.3.99.218) by c900656-a.plstn1.sfba.home.com with SMTP; 19 Apr 2001 18:31:50 -0000 Received: from knuckles.excite.com ([199.172.148.179]) by bucky.excite.com (InterMail vM.4.01.02.39 201-229-119-122) with ESMTP id <20010419184045.VRSS25251.bucky.excite.com@knuckles.excite.com>; Thu, 19 Apr 2001 11:40:45 -0700 Message-ID: <4880949.987705645363.JavaMail.imail@knuckles.excite.com> Date: Thu, 19 Apr 2001 11:40:44 -0700 (PDT) From: gary kenward To: Phil Neumiller , "Andrew T. Campbell" , john.loughney@nokia.com, seamoby@diameter.org Subject: Re: [seamoby] 4G BOF? Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Excite Inbox X-Sender-Ip: 47.248.0.43 Sender: owner-seamoby@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit While I agree with many of your observations Andrew, a 4G BOF will likely produce the same result. May I suggest that for this BOF to succeed (even as a BOF), we would need to bound the problem domain more then we did for CRAPS or SeaMoby. In other words, if the BOF is to be about all wireless access technologies, it will self-destruct in the usual firestorm. I have my views, but what can we say 4G is that bounds the problem space)? Gary On Thu, 19 Apr 2001 11:52:04 -0500, Phil Neumiller wrote: > I think we MAY need a 4G BOF, i.e. what SeaMoby was supposed to be > as opposed to what it became. This would be working on the global > Internet architecture for the purpose of improving global wireless > handovers of all types (primarily data, then QoS). A primary goal of this > work group could in fact be the large scale deployment of MIP (this being > ironic) by focussing on NON-carrier class mobility, i.e. growth of wireless > access and handovers would take primary precedence over things like > AAA, security, QoS, etc. > > This would not conflict with MIP or SeaMoby (now son of MIP) since > these WGs are now ALMOST exclusively working on 3G network > applications of MIP, IMO. > > -pdn > > _______________________________________________________ Send a cool gift with your E-Card http://www.bluemountain.com/giftcenter/ From owner-seamoby@diameter.org Thu Apr 19 14:44:16 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA16163 for ; Thu, 19 Apr 2001 14:44:15 -0400 (EDT) Received: (qmail 8740 invoked by alias); 19 Apr 2001 18:33:50 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 8734 invoked by uid 200); 19 Apr 2001 18:33:50 -0000 Received: (qmail 8729 invoked from network); 19 Apr 2001 18:33:48 -0000 Received: from gigi.excite.com (199.172.152.110) by c900656-a.plstn1.sfba.home.com with SMTP; 19 Apr 2001 18:33:48 -0000 Received: from knuckles.excite.com ([199.172.148.179]) by gigi.excite.com (InterMail vM.4.01.02.39 201-229-119-122) with ESMTP id <20010419184228.YBIE12263.gigi.excite.com@knuckles.excite.com>; Thu, 19 Apr 2001 11:42:28 -0700 Message-ID: <5842160.987705748659.JavaMail.imail@knuckles.excite.com> Date: Thu, 19 Apr 2001 11:42:28 -0700 (PDT) From: gary kenward To: Gopal Dommety , Phil Neumiller , "Andrew T. Campbell" , john.loughney@nokia.com, seamoby@diameter.org Subject: Re: [seamoby] 4G BOF? Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Excite Inbox X-Sender-Ip: 47.248.0.43 Sender: owner-seamoby@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit Gopal: What is "non-carrier class" packet data? Answer: compare IP with ATM. Gary On Thu, 19 Apr 2001 10:27:02 -0700, Gopal Dommety wrote: > At 11:52 AM 19/04/01 -0500, Phil Neumiller wrote: > >I think we MAY need a 4G BOF, i.e. what SeaMoby was supposed to be > >as opposed to what it became. This would be working on the global > >Internet architecture for the purpose of improving global wireless > >handovers of all types (primarily data, then QoS). A primary goal of this > >work group could in fact be the large scale deployment of MIP (this being > >ironic) by focussing on NON-carrier class mobility, > > > what is non-carrier class mobility? > > >i.e. growth of wireless > >access and handovers would take primary precedence over things like > >AAA, security, QoS, etc. > > I am a bit confused. Could you elobrate? > > -gopal > > >This would not conflict with MIP or SeaMoby (now son of MIP) since > >these WGs are now ALMOST exclusively working on 3G network > >applications of MIP, IMO. > > > >-pdn > _______________________________________________________ Send a cool gift with your E-Card http://www.bluemountain.com/giftcenter/ From owner-seamoby@diameter.org Thu Apr 19 14:48:02 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA16234 for ; Thu, 19 Apr 2001 14:48:02 -0400 (EDT) Received: (qmail 8287 invoked by alias); 19 Apr 2001 18:31:51 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 8281 invoked by uid 200); 19 Apr 2001 18:31:51 -0000 Received: (qmail 8276 invoked from network); 19 Apr 2001 18:31:50 -0000 Received: from bucky-rwcmex.excite.com (HELO bucky.excite.com) (198.3.99.218) by c900656-a.plstn1.sfba.home.com with SMTP; 19 Apr 2001 18:31:50 -0000 Received: from knuckles.excite.com ([199.172.148.179]) by bucky.excite.com (InterMail vM.4.01.02.39 201-229-119-122) with ESMTP id <20010419184045.VRSS25251.bucky.excite.com@knuckles.excite.com>; Thu, 19 Apr 2001 11:40:45 -0700 Message-ID: <4880949.987705645363.JavaMail.imail@knuckles.excite.com> Date: Thu, 19 Apr 2001 11:40:44 -0700 (PDT) From: gary kenward To: Phil Neumiller , "Andrew T. Campbell" , john.loughney@nokia.com, seamoby@diameter.org Subject: Re: [seamoby] 4G BOF? Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Excite Inbox X-Sender-Ip: 47.248.0.43 Sender: owner-seamoby@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit While I agree with many of your observations Andrew, a 4G BOF will likely produce the same result. May I suggest that for this BOF to succeed (even as a BOF), we would need to bound the problem domain more then we did for CRAPS or SeaMoby. In other words, if the BOF is to be about all wireless access technologies, it will self-destruct in the usual firestorm. I have my views, but what can we say 4G is that bounds the problem space)? Gary On Thu, 19 Apr 2001 11:52:04 -0500, Phil Neumiller wrote: > I think we MAY need a 4G BOF, i.e. what SeaMoby was supposed to be > as opposed to what it became. This would be working on the global > Internet architecture for the purpose of improving global wireless > handovers of all types (primarily data, then QoS). A primary goal of this > work group could in fact be the large scale deployment of MIP (this being > ironic) by focussing on NON-carrier class mobility, i.e. growth of wireless > access and handovers would take primary precedence over things like > AAA, security, QoS, etc. > > This would not conflict with MIP or SeaMoby (now son of MIP) since > these WGs are now ALMOST exclusively working on 3G network > applications of MIP, IMO. > > -pdn > > _______________________________________________________ Send a cool gift with your E-Card http://www.bluemountain.com/giftcenter/ From owner-seamoby@diameter.org Thu Apr 19 21:29:45 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA20629 for ; Thu, 19 Apr 2001 21:29:44 -0400 (EDT) Received: (qmail 11720 invoked by alias); 20 Apr 2001 01:19:12 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 11714 invoked by uid 200); 20 Apr 2001 01:19:12 -0000 Received: (qmail 11709 invoked from network); 20 Apr 2001 01:19:10 -0000 Received: from sj-msg-core-2.cisco.com (171.69.43.88) by c900656-a.plstn1.sfba.home.com with SMTP; 20 Apr 2001 01:19:10 -0000 Received: from mira-sjcm-3.cisco.com (mira-sjcm-3.cisco.com [171.69.43.101]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id SAA06643; Thu, 19 Apr 2001 18:28:32 -0700 (PDT) Received: from gopal.cisco.com (dhcp-171-70-57-67.cisco.com [171.70.57.67]) by mira-sjcm-3.cisco.com (Mirapoint) with ESMTP id ACO31924; Thu, 19 Apr 2001 18:28:04 -0700 (PDT) Message-Id: <4.3.2.7.2.20010419181520.00ba4650@mira-sjcm-3.cisco.com> X-Sender: gdommety@mira-sjcm-3.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 19 Apr 2001 18:25:47 -0700 To: gary kenward , seamoby@diameter.org From: Gopal Dommety Subject: Re: [seamoby] 4G BOF? In-Reply-To: <5842160.987705748659.JavaMail.imail@knuckles.excite.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-seamoby@diameter.org Precedence: bulk I was referring to "non-carrier class mobility" in the statement Phil made and not "carrier class packet data". As for your comment of IP vs ATM that is another matter. A comment about the concept of 4G BOF. It might help to put some bounds on the problem(s). -Gopal > What is "non-carrier class" packet data? Answer: compare IP with ATM. >Gary > >On Thu, 19 Apr 2001 10:27:02 -0700, Gopal Dommety wrote: > >> At 11:52 AM 19/04/01 -0500, Phil Neumiller wrote: >> >I think we MAY need a 4G BOF, i.e. what SeaMoby was supposed to be >> >as opposed to what it became. This would be working on the global >> >Internet architecture for the purpose of improving global wireless >> >handovers of all types (primarily data, then QoS). A primary goal of >this >> >work group could in fact be the large scale deployment of MIP (this >being >> >ironic) by focussing on NON-carrier class mobility, >> >> >> what is non-carrier class mobility? >> >> >i.e. growth of wireless >> >access and handovers would take primary precedence over things like >> >AAA, security, QoS, etc. >> >> I am a bit confused. Could you elobrate? >> >> -gopal >> >> >This would not conflict with MIP or SeaMoby (now son of MIP) since >> >these WGs are now ALMOST exclusively working on 3G network >> >applications of MIP, IMO. >> > >> >-pdn >> > > > > > >_______________________________________________________ >Send a cool gift with your E-Card >http://www.bluemountain.com/giftcenter/ From owner-seamoby@diameter.org Thu Apr 19 21:55:20 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA21800 for ; Thu, 19 Apr 2001 21:55:19 -0400 (EDT) Received: (qmail 12353 invoked by alias); 20 Apr 2001 01:44:50 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 12348 invoked by uid 200); 20 Apr 2001 01:44:49 -0000 Received: (qmail 12343 invoked from network); 20 Apr 2001 01:44:48 -0000 Received: from www.bit-net.com (HELO mail.users.bit-net.com) (208.146.132.4) by c900656-a.plstn1.sfba.home.com with SMTP; 20 Apr 2001 01:44:48 -0000 Received: from localhost by mail.users.bit-net.com; (5.65v3.2/1.1.8.2/30Jul96-0143PM) id AA06438; Thu, 19 Apr 2001 21:53:58 -0400 Date: Thu, 19 Apr 2001 21:53:58 -0400 (EDT) From: Jim Bound To: "Andrew T. Campbell" Cc: "'Phil Neumiller'" , john.loughney@nokia.com, seamoby@diameter.org Subject: RE: [seamoby] SeaMoby MicroMobility Work In-Reply-To: <001201c0c8f8$3df2c9a0$ca413b80@SWEETPEA> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-seamoby@diameter.org Precedence: bulk What 4G? What specifically and technical and specification set are you talking about? thanks /jim On Thu, 19 Apr 2001, Andrew T. Campbell wrote: > > > > -----Original Message----- > > From: owner-seamoby@diameter.org [mailto:owner-seamoby@diameter.org]On > > Behalf Of Phil Neumiller > > Sent: Thursday, April 19, 2001 4:07 AM > > To: john.loughney@nokia.com; seamoby@diameter.org > > Subject: Re: [seamoby] SeaMoby MicroMobility Work > > > > > > John the MM work was moved the IRTF. There is no more > > work in the SeaMoby WG for MM. I thought this was made > > clear to all at IETF 50. > > > > -pdn > > > Here is a late comment on that decision: > > The irony of putting this activity > on the back burner is that the > companies and market is rushing > towards 4G as soon as 2004 and are > in need of an IP micro-mobility protocol (incl. > fast/seamless handoff, QOS, security, > paging etc.) to make 4G work. > > With hindsight, I think this was a > very bad decision (with great respect to the people > that made it) potentially putting IETF at a disadvantage > for 4G (which is a pseudomon for wireless > Internet of course) if people don't buy Mobile IP. > IETF is betting all is chips on this protocol. > > I really do not understand this > mentality of "if its a mobile problem > then the solution is Mobile IP++". > Its just not sound engineering. > > We are at the starting block for 4G > and whatever the question is the answer > is always the same - Mobile IP. > There has to be a new way. > > The IEFT has a great opportunity to > capitalize on 4G but not if new initiatives > are punted and blocked because of the > past investment in Mobile IP. > > I made these comments in San Diego and > felt the chill. I repeat them here in hope - > wearing my asbestos pants. > > Best, > --- > Andrew > http://comet.columbia.edu/~campbell > From owner-seamoby@diameter.org Thu Apr 19 23:06:26 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA23121 for ; Thu, 19 Apr 2001 23:06:25 -0400 (EDT) Received: (qmail 13930 invoked by alias); 20 Apr 2001 02:56:04 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 13925 invoked by uid 200); 20 Apr 2001 02:56:04 -0000 Received: (qmail 13920 invoked from network); 20 Apr 2001 02:56:02 -0000 Received: from its-mu-earth.its.rmit.edu.au (131.170.2.10) by c900656-a.plstn1.sfba.home.com with SMTP; 20 Apr 2001 02:56:02 -0000 Received: from ems.rmit.edu.au (ems.rmit.edu.au [131.170.10.112]) by its-mu-earth.its.rmit.edu.au (8.10.1/8.10.1/ANTI-SPAM/ANTI-RELAY/EARTH) with SMTP id f3K35Hu21202 for ; Fri, 20 Apr 2001 13:05:17 +1000 (EST) Received: from INET1-Message_Server by ems.rmit.edu.au with Novell_GroupWise; Fri, 20 Apr 2001 13:05:24 +1000 Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.5.1 Date: Fri, 20 Apr 2001 13:05:14 +1000 From: "Andrew Jennings" To: , Subject: Re: [seamoby] Self introduction... Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Sender: owner-seamoby@diameter.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id XAA23121 I should do similar. My background is in network management and intelligent systems. I am working on a research collaboration project with Advanced Communications Technologies in the area of software defined radio. Following the discussion and looking to contribute to the ongoing development. My interest is that I think that SeaMoby meets a real need to bridge the "two worlds" of broad area ("telco") and local area ("ietf") networking. Actually I could use it right now as I move around a lot. Andrew Jennings RMIT University LaTrobe St. Melbourne Australia ajennings@rmit.edu.au ph: 61 3 9925 5307 From owner-seamoby@diameter.org Fri Apr 20 04:45:46 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA09016 for ; Fri, 20 Apr 2001 04:45:45 -0400 (EDT) Received: (qmail 18531 invoked by alias); 20 Apr 2001 08:34:58 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 18525 invoked by uid 200); 20 Apr 2001 08:34:57 -0000 Received: (qmail 18520 invoked from network); 20 Apr 2001 08:34:56 -0000 Received: from p-mail2.rd.francetelecom.fr (HELO p-mail2.cnet.fr) (193.49.124.32) by c900656-a.plstn1.sfba.home.com with SMTP; 20 Apr 2001 08:34:56 -0000 Received: by p-voyageur.rd.francetelecom.fr with Internet Mail Service (5.5.2653.19) id <22FVRQMZ>; Fri, 20 Apr 2001 10:43:33 +0200 Message-ID: <98388C05D464D111B61800805F15041601A23078@p-ibis.rd.francetelecom.fr> From: MORAND Lionel FTRD/DAC/ISS To: Gopal Dommety , gary kenward , seamoby@diameter.org Subject: RE: [seamoby] 4G BOF? Date: Fri, 20 Apr 2001 10:43:33 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-seamoby@diameter.org Precedence: bulk Hi, What do you really called "4G"? 1G, 2G, 3G were used to refere to new radio access technologies in mobile (cellular) networks. Find a global solution for seamless handovers between different types of access networks doesn't imply to find a new access technology and a new access network design. 4G doesn't have to used in opposition to 3G or each time a new solution is proposed. BTW, I don't think that Seamoby was supposed to deal with 4G but to solve micromobility issues raised with MIP (whatever the definition of "micromobility" is). To simplify the problem, one can say that the aim was to ensure a fast and reliable handoff between two IP access points (IP base stations, routers, etc.). But maybe I'm wrong and I missed something... -----Original Message----- From: Gopal Dommety [mailto:gdommety@cisco.com] Sent: Friday, April 20, 2001 3:26 AM To: gary kenward; seamoby@diameter.org Subject: Re: [seamoby] 4G BOF? I was referring to "non-carrier class mobility" in the statement Phil made and not "carrier class packet data". As for your comment of IP vs ATM that is another matter. A comment about the concept of 4G BOF. It might help to put some bounds on the problem(s). -Gopal > What is "non-carrier class" packet data? Answer: compare IP with ATM. >Gary > >On Thu, 19 Apr 2001 10:27:02 -0700, Gopal Dommety wrote: > >> At 11:52 AM 19/04/01 -0500, Phil Neumiller wrote: >> >I think we MAY need a 4G BOF, i.e. what SeaMoby was supposed to be >> >as opposed to what it became. This would be working on the global >> >Internet architecture for the purpose of improving global wireless >> >handovers of all types (primarily data, then QoS). A primary goal of >this >> >work group could in fact be the large scale deployment of MIP (this >being >> >ironic) by focussing on NON-carrier class mobility, >> >> >> what is non-carrier class mobility? >> >> >i.e. growth of wireless >> >access and handovers would take primary precedence over things like >> >AAA, security, QoS, etc. >> >> I am a bit confused. Could you elobrate? >> >> -gopal >> >> >This would not conflict with MIP or SeaMoby (now son of MIP) since >> >these WGs are now ALMOST exclusively working on 3G network >> >applications of MIP, IMO. >> > >> >-pdn >> > > > > > >_______________________________________________________ >Send a cool gift with your E-Card >http://www.bluemountain.com/giftcenter/ From owner-seamoby@diameter.org Fri Apr 20 05:23:57 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA09299 for ; Fri, 20 Apr 2001 05:23:56 -0400 (EDT) Received: (qmail 19255 invoked by alias); 20 Apr 2001 09:13:21 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 19249 invoked by uid 200); 20 Apr 2001 09:13:21 -0000 Received: (qmail 19244 invoked from network); 20 Apr 2001 09:13:19 -0000 Received: from mgw-x1.nokia.com (131.228.20.21) by c900656-a.plstn1.sfba.home.com with SMTP; 20 Apr 2001 09:13:19 -0000 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f3K9MK213313 for ; Fri, 20 Apr 2001 12:22:20 +0300 (EET DST) Received: from esebh25nok.ntc.nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Fri, 20 Apr 2001 12:22:41 +0300 Received: by esebh25nok with Internet Mail Service (5.5.2652.78) id ; Fri, 20 Apr 2001 12:21:53 +0300 Message-ID: <01D91AFB08B6D211BFD00008C7EABAE10680AD93@eseis04nok> From: john.loughney@nokia.com To: campbell@comet.columbia.edu, seamoby@diameter.org Subject: RE: [seamoby] SeaMoby MicroMobility Work Date: Fri, 20 Apr 2001 12:21:45 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-seamoby@diameter.org Precedence: bulk Hi Andrew, > The irony of putting this activity > on the back burner is that the > companies and market is rushing > towards 4G as soon as 2004 and are > in need of an IP micro-mobility protocol (incl. > fast/seamless handoff, QOS, security, > paging etc.) to make 4G work. As far as I understood, it is only on the backburner if noone participates in the work. There is interest in the IRTF and if you feel that this is important work, then you should get involved. I think engaging in good engineering is much more useful then going back and forth on mailing lists .... best regards, John From owner-seamoby@diameter.org Fri Apr 20 05:25:56 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA09344 for ; Fri, 20 Apr 2001 05:25:55 -0400 (EDT) Received: (qmail 19472 invoked by alias); 20 Apr 2001 09:14:12 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 19462 invoked by uid 200); 20 Apr 2001 09:14:09 -0000 Received: (qmail 19441 invoked from network); 20 Apr 2001 09:14:06 -0000 Received: from mgw-x2.nokia.com (131.228.20.22) by c900656-a.plstn1.sfba.home.com with SMTP; 20 Apr 2001 09:14:06 -0000 Received: from esvir02nok.nokia.com (esvir02nokt.ntc.nokia.com [172.21.143.34]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f3K9NbS24960 for ; Fri, 20 Apr 2001 12:23:37 +0300 (EET DST) Received: from esebh24nok.ntc.nokia.com (unverified) by esvir02nok.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Fri, 20 Apr 2001 12:23:28 +0300 Received: by esebh24nok with Internet Mail Service (5.5.2652.78) id ; Fri, 20 Apr 2001 12:23:10 +0300 Message-ID: <01D91AFB08B6D211BFD00008C7EABAE10680AD94@eseis04nok> From: john.loughney@nokia.com To: PRoberts@MEGISTO.com, seamoby@diameter.org Subject: RE: [seamoby] SeaMoby MicroMobility Work Date: Fri, 20 Apr 2001 12:23:08 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-seamoby@diameter.org Precedence: bulk Hi Phil R, > I took the token to produce a first draft of a problem > statement to give to the IRTF. I few folks volunteered to help > work on this. I've got about half a draft and hope to get it out > to those volunteers this week and hopefully get a revised version > for the WG next week. Do you have any idea what the relation is to the current MM Problem Statement draft? thanks, John From owner-seamoby@diameter.org Fri Apr 20 05:58:59 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA09654 for ; Fri, 20 Apr 2001 05:58:58 -0400 (EDT) Received: (qmail 20432 invoked by alias); 20 Apr 2001 09:48:19 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 20426 invoked by uid 200); 20 Apr 2001 09:48:19 -0000 Received: (qmail 20421 invoked from network); 20 Apr 2001 09:48:17 -0000 Received: from sirius.ctr.columbia.edu (128.59.64.60) by c900656-a.plstn1.sfba.home.com with SMTP; 20 Apr 2001 09:48:17 -0000 Received: from SWEETPEA (sweetpea.comet.columbia.edu [128.59.65.202]) by sirius.ctr.columbia.edu (8.9.3/8.6.4.287) with SMTP id FAA29346; Fri, 20 Apr 2001 05:57:38 -0400 (EDT) From: "Andrew T. Campbell" To: , Cc: "Andrew Campbell \(E-mail\)" Subject: RE: [seamoby] SeaMoby MicroMobility Work Date: Fri, 20 Apr 2001 05:55:44 -0700 Message-ID: <00b001c0c999$36d371a0$ca413b80@SWEETPEA> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 In-reply-to: <01D91AFB08B6D211BFD00008C7EABAE10680AD93@eseis04nok> Importance: Normal Sender: owner-seamoby@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit John: I have been contributing for the last few years and I intend to keep contributing. But we should question the decision making when we believe that it counter productive to wireless IP rollout. Or no? You see I firmly believe that if IETF standardized an IP micro-mobility protocol today then wireless IP access would roll out far quicker than we have seen with MIP. And that protocol would be the basis for 4G. Pushing micro-mobility into the IRTF was the wrong decision in my mind it should have been accelerated in the Seamoby WG - just my opinion. I think you are aware what is going on out there in the industry; the 3G shakedown. --- Andrew http://comet.columbia.edu/~campbell > -----Original Message----- > From: owner-seamoby@diameter.org [mailto:owner-seamoby@diameter.org]On > Behalf Of john.loughney@nokia.com > Sent: Friday, April 20, 2001 2:22 AM > To: campbell@comet.columbia.edu; seamoby@diameter.org > Subject: RE: [seamoby] SeaMoby MicroMobility Work > > > Hi Andrew, > > > The irony of putting this activity > > on the back burner is that the > > companies and market is rushing > > towards 4G as soon as 2004 and are > > in need of an IP micro-mobility protocol (incl. > > fast/seamless handoff, QOS, security, > > paging etc.) to make 4G work. > > As far as I understood, it is only on the > backburner if noone participates in the work. > There is interest in the IRTF and if you feel > that this is important work, then you should > get involved. > > I think engaging in good engineering is much > more useful then going back and forth on > mailing lists .... > > best regards, > John > > From owner-seamoby@diameter.org Fri Apr 20 06:28:26 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA09848 for ; Fri, 20 Apr 2001 06:28:25 -0400 (EDT) Received: (qmail 21094 invoked by alias); 20 Apr 2001 10:17:10 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 21089 invoked by uid 200); 20 Apr 2001 10:17:10 -0000 Received: (qmail 21084 invoked from network); 20 Apr 2001 10:17:08 -0000 Received: from mgw-x4.nokia.com (131.228.20.27) by c900656-a.plstn1.sfba.home.com with SMTP; 20 Apr 2001 10:17:08 -0000 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f3KARO822021 for ; Fri, 20 Apr 2001 13:27:24 +0300 (EET DST) Received: from esebh25nok.ntc.nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Fri, 20 Apr 2001 13:26:07 +0300 Received: by esebh25nok with Internet Mail Service (5.5.2652.78) id ; Fri, 20 Apr 2001 13:23:46 +0300 Message-ID: <01D91AFB08B6D211BFD00008C7EABAE10680AD9B@eseis04nok> From: john.loughney@nokia.com To: campbell@comet.columbia.edu, seamoby@diameter.org Subject: RE: [seamoby] SeaMoby MicroMobility Work Date: Fri, 20 Apr 2001 13:23:41 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-seamoby@diameter.org Precedence: bulk Hi Andrew, > I have been contributing for the last few years and > I intend to keep contributing. That I am aware of. No disrespect intended. Right now, I'm a little tired of long tirades about how things are unfair, or certain models are moral insults to the integrity of the Internet. In my mind, the only way forward is to propose something better. > But we should question the decision making when > we believe that it counter productive to wireless > IP rollout. Or no? I'd suggest that it is neither here nor there. IETF is not a business forum. The wireless IP rollout will be made on a business case decision. If there is money to be made, I'm fairly certain someone will do it. Also, if there is a better solution in the market place, customers will vote with there feet. > You see I firmly believe that if IETF standardized an > IP micro-mobility protocol today then wireless > IP access would roll out far quicker than > we have seen with MIP. And that protocol would > be the basis for 4G. I'm not so sure I'd agree with you about that. Given the current investment in 2.5G / 3G & the current stock situation, I don't think anyone is going to be freely spending money on such things. > Pushing micro-mobility into the IRTF was the > wrong decision in my mind it should have been > accelerated in the Seamoby WG - just my opinion. I'm not so sure the change of venues will affect too much, as long as those who are interested participate. > I think you are aware what is going on out there > in the industry; the 3G shakedown. To be honest, I have yet to really see this mythical beast. 2.5G networks are just being deployed, handsets are generally few and far between. The DSL market is in termoil; the dot-com revolution is bankrupt. However, at least here in Finland, people do seem to be using their cell phones alot, and just just for voice. Mobile commerce is picking up, as services become available. Wireless voice over IP solutions will have to provide some additional incentives before they can compete with cellular. Right now, local calls are cheaper when called from a mobile phone, for example. I can even stream audio over HSCD (43.2k) reasonable well. IMode isn't really the Internet, but it seems to have a lot of subscibers ... Heck, I even use Google with WAP (hopefully that won't discredit me) ... Anyhow, if you have made it this far, I'd just want to re-iterate my main point - let's cut out the doom-n-gloom & the marketing hype and get down to actual engineering? I sent the original mail of this thread, because I wanted to gauge support for the MM work items ... so far, noone has addressed that. I'd still like comments on the MM Problem Statement. In my opinion, that should still go forward, if just to document the problem ... best regards, John From owner-seamoby@diameter.org Fri Apr 20 06:56:16 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA10074 for ; Fri, 20 Apr 2001 06:56:14 -0400 (EDT) Received: (qmail 21771 invoked by alias); 20 Apr 2001 10:45:11 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 21765 invoked by uid 200); 20 Apr 2001 10:45:11 -0000 Received: (qmail 21760 invoked from network); 20 Apr 2001 10:45:09 -0000 Received: from www.bit-net.com (HELO mail.users.bit-net.com) (208.146.132.4) by c900656-a.plstn1.sfba.home.com with SMTP; 20 Apr 2001 10:45:09 -0000 Received: from localhost by mail.users.bit-net.com; (5.65v3.2/1.1.8.2/30Jul96-0143PM) id AA09806; Fri, 20 Apr 2001 06:54:28 -0400 Date: Fri, 20 Apr 2001 06:54:28 -0400 (EDT) From: Jim Bound To: MORAND Lionel FTRD/DAC/ISS Cc: Gopal Dommety , gary kenward , seamoby@diameter.org Subject: RE: [seamoby] 4G BOF? In-Reply-To: <98388C05D464D111B61800805F15041601A23078@p-ibis.rd.francetelecom.fr> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-seamoby@diameter.org Precedence: bulk Hate to be a pain folks. But if we want to talk about reqs for 4G BOF or what 4G means and is next steps thats one thing and I don't think thats our charter is it? But to talk about it like it exists as 3GPP Release 5 or the 3GPP2 specs, which are specs that EXIST and I have to use them to implement production software and hardware, is absurd. If someone knows of a 4G spec I can write code to or even system integrate a solution with as I can with 3GPP or 3GPP2 please share it with me. Otherwise why are we discussing 4G? I vote for the chair to kill this conversation unless we do what I said in my first sentence or something like it. /jim On Fri, 20 Apr 2001, MORAND Lionel FTRD/DAC/ISS wrote: > Hi, > > What do you really called "4G"? 1G, 2G, 3G were used to refere to new radio > access technologies in mobile (cellular) networks. Find a global solution > for seamless handovers between different types of access networks doesn't > imply to find a new access technology and a new access network design. 4G > doesn't have to used in opposition to 3G or each time a new solution is > proposed. > BTW, I don't think that Seamoby was supposed to deal with 4G but to solve > micromobility issues raised with MIP (whatever the definition of > "micromobility" is). To simplify the problem, one can say that the aim was > to ensure a fast and reliable handoff between two IP access points (IP base > stations, routers, etc.). But maybe I'm wrong and I missed something... > > > -----Original Message----- > From: Gopal Dommety [mailto:gdommety@cisco.com] > Sent: Friday, April 20, 2001 3:26 AM > To: gary kenward; seamoby@diameter.org > Subject: Re: [seamoby] 4G BOF? > > > > I was referring to "non-carrier class mobility" in the statement Phil made > and not "carrier class packet data". > As for your comment of IP vs ATM that is another matter. > > A comment about the concept of 4G BOF. It might help to > put some bounds on the problem(s). > > -Gopal > > > > > What is "non-carrier class" packet data? Answer: compare IP with ATM. > > > > >Gary > > > >On Thu, 19 Apr 2001 10:27:02 -0700, Gopal Dommety wrote: > > > >> At 11:52 AM 19/04/01 -0500, Phil Neumiller wrote: > >> >I think we MAY need a 4G BOF, i.e. what SeaMoby was supposed to be > >> >as opposed to what it became. This would be working on the global > >> >Internet architecture for the purpose of improving global wireless > >> >handovers of all types (primarily data, then QoS). A primary goal of > >this > >> >work group could in fact be the large scale deployment of MIP (this > >being > >> >ironic) by focussing on NON-carrier class mobility, > >> > >> > >> what is non-carrier class mobility? > >> > >> >i.e. growth of wireless > >> >access and handovers would take primary precedence over things like > >> >AAA, security, QoS, etc. > >> > >> I am a bit confused. Could you elobrate? > >> > >> -gopal > >> > >> >This would not conflict with MIP or SeaMoby (now son of MIP) since > >> >these WGs are now ALMOST exclusively working on 3G network > >> >applications of MIP, IMO. > >> > > >> >-pdn > >> > > > > > > > > > > > >_______________________________________________________ > >Send a cool gift with your E-Card > >http://www.bluemountain.com/giftcenter/ > From owner-seamoby@diameter.org Fri Apr 20 06:58:40 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA10085 for ; Fri, 20 Apr 2001 06:58:40 -0400 (EDT) Received: (qmail 22208 invoked by alias); 20 Apr 2001 10:47:52 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 22202 invoked by uid 200); 20 Apr 2001 10:47:51 -0000 Received: (qmail 22188 invoked from network); 20 Apr 2001 10:47:48 -0000 Received: from www.bit-net.com (HELO mail.users.bit-net.com) (208.146.132.4) by c900656-a.plstn1.sfba.home.com with SMTP; 20 Apr 2001 10:47:48 -0000 Received: from localhost by mail.users.bit-net.com; (5.65v3.2/1.1.8.2/30Jul96-0143PM) id AA22811; Fri, 20 Apr 2001 06:57:11 -0400 Date: Fri, 20 Apr 2001 06:57:10 -0400 (EDT) From: Jim Bound To: "Andrew T. Campbell" Cc: john.loughney@nokia.com, seamoby@diameter.org Subject: RE: [seamoby] SeaMoby MicroMobility Work In-Reply-To: <00b001c0c999$36d371a0$ca413b80@SWEETPEA> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-seamoby@diameter.org Precedence: bulk Andrew, Just as a note. If I need MM in the market to make 3G work I will work with TEMs and Telcos to make it work and variant suppliers in this space. It might be a blessing the IETF pushed this out to the IRTF now we can go implement it and if we need a standard go do it in 3G. /jim On Fri, 20 Apr 2001, Andrew T. Campbell wrote: > > John: > > I have been contributing for the last few years and > I intend to keep contributing. > > But we should question the decision making when > we believe that it counter productive to wireless > IP rollout. Or no? > > You see I firmly believe that if IETF standardized an > IP micro-mobility protocol today then wireless > IP access would roll out far quicker than > we have seen with MIP. And that protocol would > be the basis for 4G. > > Pushing micro-mobility into the IRTF was the > wrong decision in my mind it should have been > accelerated in the Seamoby WG - just my opinion. > > I think you are aware what is going on out there > in the industry; the 3G shakedown. > > --- > Andrew > http://comet.columbia.edu/~campbell > > > > -----Original Message----- > > From: owner-seamoby@diameter.org [mailto:owner-seamoby@diameter.org]On > > Behalf Of john.loughney@nokia.com > > Sent: Friday, April 20, 2001 2:22 AM > > To: campbell@comet.columbia.edu; seamoby@diameter.org > > Subject: RE: [seamoby] SeaMoby MicroMobility Work > > > > > > Hi Andrew, > > > > > The irony of putting this activity > > > on the back burner is that the > > > companies and market is rushing > > > towards 4G as soon as 2004 and are > > > in need of an IP micro-mobility protocol (incl. > > > fast/seamless handoff, QOS, security, > > > paging etc.) to make 4G work. > > > > As far as I understood, it is only on the > > backburner if noone participates in the work. > > There is interest in the IRTF and if you feel > > that this is important work, then you should > > get involved. > > > > I think engaging in good engineering is much > > more useful then going back and forth on > > mailing lists .... > > > > best regards, > > John > > > > > From owner-seamoby@diameter.org Fri Apr 20 07:02:37 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA10191 for ; Fri, 20 Apr 2001 07:02:36 -0400 (EDT) Received: (qmail 22702 invoked by alias); 20 Apr 2001 10:51:36 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 22696 invoked by uid 200); 20 Apr 2001 10:51:35 -0000 Received: (qmail 22691 invoked from network); 20 Apr 2001 10:51:34 -0000 Received: from www.bit-net.com (HELO mail.users.bit-net.com) (208.146.132.4) by c900656-a.plstn1.sfba.home.com with SMTP; 20 Apr 2001 10:51:34 -0000 Received: from localhost by mail.users.bit-net.com; (5.65v3.2/1.1.8.2/30Jul96-0143PM) id AA02149; Fri, 20 Apr 2001 07:00:48 -0400 Date: Fri, 20 Apr 2001 07:00:48 -0400 (EDT) From: Jim Bound To: john.loughney@nokia.com Cc: campbell@comet.columbia.edu, seamoby@diameter.org Subject: RE: [seamoby] SeaMoby MicroMobility Work In-Reply-To: <01D91AFB08B6D211BFD00008C7EABAE10680AD9B@eseis04nok> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-seamoby@diameter.org Precedence: bulk John, I agree with you again. Also on the East Coast of the U.S. or the Northeast to be specific the cell phones are alive and well. I am seeing more Blackberry's and IPAQs these days for email though than I had a few years ago. I hope anyway that AT&T adopting GSM will be a wakeup call to our providers over here though. /jim On Fri, 20 Apr 2001 john.loughney@nokia.com wrote: > Hi Andrew, > > > I have been contributing for the last few years and > > I intend to keep contributing. > > That I am aware of. No disrespect intended. > > Right now, I'm a little tired of long tirades about how > things are unfair, or certain models are moral insults to > the integrity of the Internet. In my mind, > the only way forward is to propose something better. > > > But we should question the decision making when > > we believe that it counter productive to wireless > > IP rollout. Or no? > > I'd suggest that it is neither here nor there. IETF is not > a business forum. The wireless IP rollout will be made > on a business case decision. If there is money to be made, > I'm fairly certain someone will do it. Also, if there is a > better solution in the market place, customers will vote with > there feet. > > > You see I firmly believe that if IETF standardized an > > IP micro-mobility protocol today then wireless > > IP access would roll out far quicker than > > we have seen with MIP. And that protocol would > > be the basis for 4G. > > I'm not so sure I'd agree with you about that. Given the > current investment in 2.5G / 3G & the current stock situation, > I don't think anyone is going to be freely spending money on > such things. > > > Pushing micro-mobility into the IRTF was the > > wrong decision in my mind it should have been > > accelerated in the Seamoby WG - just my opinion. > > I'm not so sure the change of venues will affect too > much, as long as those who are interested participate. > > > I think you are aware what is going on out there > > in the industry; the 3G shakedown. > > To be honest, I have yet to really see this mythical beast. > 2.5G networks are just being deployed, handsets are > generally few and far between. The DSL market is in > termoil; the dot-com revolution is bankrupt. > > However, at least here in Finland, people do seem to be using > their cell phones alot, and just just for voice. Mobile commerce > is picking up, as services become available. > > Wireless voice over IP solutions will have to provide some > additional incentives before they can compete with cellular. > Right now, local calls are cheaper when called from a mobile > phone, for example. > > I can even stream audio over HSCD (43.2k) reasonable well. > IMode isn't really the Internet, but it seems to have a lot > of subscibers ... Heck, I even use Google with WAP (hopefully > that won't discredit me) ... > > Anyhow, if you have made it this far, I'd just want to re-iterate > my main point - let's cut out the doom-n-gloom & the marketing > hype and get down to actual engineering? > > I sent the original mail of this thread, because I wanted to > gauge support for the MM work items ... so far, noone has > addressed that. I'd still like comments on the MM Problem > Statement. In my opinion, that should still go forward, > if just to document the problem ... > > best regards, > John > From owner-seamoby@diameter.org Fri Apr 20 08:29:51 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA10882 for ; Fri, 20 Apr 2001 08:29:50 -0400 (EDT) Received: (qmail 23858 invoked by alias); 20 Apr 2001 12:18:50 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 23852 invoked by uid 200); 20 Apr 2001 12:18:49 -0000 Received: (qmail 23847 invoked from network); 20 Apr 2001 12:18:47 -0000 Received: from unknown (HELO megisto-sql1.megisto.com) (63.113.114.132) by c900656-a.plstn1.sfba.home.com with SMTP; 20 Apr 2001 12:18:47 -0000 Received: by mail.megisto.com with Internet Mail Service (5.5.2650.21) id ; Fri, 20 Apr 2001 08:21:58 -0400 Message-ID: From: Phil Roberts To: "'john.loughney@nokia.com'" , Phil Roberts , seamoby@diameter.org Subject: RE: [seamoby] SeaMoby MicroMobility Work Date: Fri, 20 Apr 2001 08:21:58 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-seamoby@diameter.org Precedence: bulk I'm compiling a short list of topics that need to be investigated, scaling, latency, performance and a list of references to other work, one of which will be the existing problem statement from the mmdt. > -----Original Message----- > From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] > Sent: Friday, April 20, 2001 5:23 AM > To: PRoberts@megisto.com; seamoby@diameter.org > Subject: RE: [seamoby] SeaMoby MicroMobility Work > > > Hi Phil R, > > > I took the token to produce a first draft of a problem > > statement to give to the IRTF. I few folks volunteered to help > > work on this. I've got about half a draft and hope to get it out > > to those volunteers this week and hopefully get a revised version > > for the WG next week. > > Do you have any idea what the relation is to the current MM > Problem Statement draft? > > thanks, > John > From owner-seamoby@diameter.org Fri Apr 20 13:14:41 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA14750 for ; Fri, 20 Apr 2001 13:14:39 -0400 (EDT) Received: (qmail 26078 invoked by alias); 20 Apr 2001 17:03:30 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 26072 invoked by uid 200); 20 Apr 2001 17:03:29 -0000 Received: (qmail 26067 invoked from network); 20 Apr 2001 17:03:27 -0000 Received: from sj-msg-core-4.cisco.com (171.71.163.10) by c900656-a.plstn1.sfba.home.com with SMTP; 20 Apr 2001 17:03:27 -0000 Received: from mira-sjcm-3.cisco.com (mira-sjcm-3.cisco.com [171.69.43.101]) by sj-msg-core-4.cisco.com (8.9.3/8.9.1) with ESMTP id KAA00709; Fri, 20 Apr 2001 10:12:30 -0700 (PDT) Received: from gopal.cisco.com (gdommety-dsl5.cisco.com [10.19.17.142]) by mira-sjcm-3.cisco.com (Mirapoint) with ESMTP id ACR02043; Fri, 20 Apr 2001 10:12:21 -0700 (PDT) Message-Id: <4.3.2.7.2.20010420100633.00b4ef00@mira-sjcm-3.cisco.com> X-Sender: gdommety@mira-sjcm-3.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 20 Apr 2001 10:10:00 -0700 To: Jim Bound , MORAND Lionel FTRD/DAC/ISS From: Gopal Dommety Subject: RE: [seamoby] 4G BOF? Cc: gary kenward , seamoby@diameter.org In-Reply-To: References: <98388C05D464D111B61800805F15041601A23078@p-ibis.rd.francetelecom.fr> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-seamoby@diameter.org Precedence: bulk Looks like Phil posted and disappeared. I see no point in discussing this further. BTW: I was not advocating for the BOF. I was only trying to understand what is problem the originators of the email had when they said 4 G. anyway, I am out of this. -Gopal At 06:54 AM 20/04/01 -0400, Jim Bound wrote: >Hate to be a pain folks. But if we want to talk about reqs for 4G BOF or >what 4G means and is next steps thats one thing and I don't think thats >our charter is it? > >But to talk about it like it exists as 3GPP Release 5 or the 3GPP2 specs, >which are specs that EXIST and I have to use them to implement production >software and hardware, is absurd. > >If someone knows of a 4G spec I can write code to or even system integrate >a solution with as I can with 3GPP or 3GPP2 please share it with me. > >Otherwise why are we discussing 4G? I vote for the chair to kill this >conversation unless we do what I said in my first sentence or something >like it. > >/jim > >On Fri, 20 Apr 2001, MORAND Lionel FTRD/DAC/ISS wrote: > >> Hi, >> >> What do you really called "4G"? 1G, 2G, 3G were used to refere to new radio >> access technologies in mobile (cellular) networks. Find a global solution >> for seamless handovers between different types of access networks doesn't >> imply to find a new access technology and a new access network design. 4G >> doesn't have to used in opposition to 3G or each time a new solution is >> proposed. >> BTW, I don't think that Seamoby was supposed to deal with 4G but to solve >> micromobility issues raised with MIP (whatever the definition of >> "micromobility" is). To simplify the problem, one can say that the aim was >> to ensure a fast and reliable handoff between two IP access points (IP base >> stations, routers, etc.). But maybe I'm wrong and I missed something... >> >> >> -----Original Message----- >> From: Gopal Dommety [mailto:gdommety@cisco.com] >> Sent: Friday, April 20, 2001 3:26 AM >> To: gary kenward; seamoby@diameter.org >> Subject: Re: [seamoby] 4G BOF? >> >> >> >> I was referring to "non-carrier class mobility" in the statement Phil made >> and not "carrier class packet data". >> As for your comment of IP vs ATM that is another matter. >> >> A comment about the concept of 4G BOF. It might help to >> put some bounds on the problem(s). >> >> -Gopal >> >> >> >> > What is "non-carrier class" packet data? Answer: compare IP with ATM. >> >> >> >> >Gary >> > >> >On Thu, 19 Apr 2001 10:27:02 -0700, Gopal Dommety wrote: >> > >> >> At 11:52 AM 19/04/01 -0500, Phil Neumiller wrote: >> >> >I think we MAY need a 4G BOF, i.e. what SeaMoby was supposed to be >> >> >as opposed to what it became. This would be working on the global >> >> >Internet architecture for the purpose of improving global wireless >> >> >handovers of all types (primarily data, then QoS). A primary goal of >> >this >> >> >work group could in fact be the large scale deployment of MIP (this >> >being >> >> >ironic) by focussing on NON-carrier class mobility, >> >> >> >> >> >> what is non-carrier class mobility? >> >> >> >> >i.e. growth of wireless >> >> >access and handovers would take primary precedence over things like >> >> >AAA, security, QoS, etc. >> >> >> >> I am a bit confused. Could you elobrate? >> >> >> >> -gopal >> >> >> >> >This would not conflict with MIP or SeaMoby (now son of MIP) since >> >> >these WGs are now ALMOST exclusively working on 3G network >> >> >applications of MIP, IMO. >> >> > >> >> >-pdn >> >> >> > >> > >> > >> > >> > >> >_______________________________________________________ >> >Send a cool gift with your E-Card >> >http://www.bluemountain.com/giftcenter/ >> From owner-seamoby@diameter.org Fri Apr 20 14:29:12 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA15944 for ; Fri, 20 Apr 2001 14:29:10 -0400 (EDT) Received: (qmail 29983 invoked by alias); 20 Apr 2001 18:18:04 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 29977 invoked by uid 200); 20 Apr 2001 18:18:03 -0000 Received: (qmail 29972 invoked from network); 20 Apr 2001 18:18:02 -0000 Received: from bucky-rwcmex.excite.com (HELO bucky.excite.com) (198.3.99.218) by c900656-a.plstn1.sfba.home.com with SMTP; 20 Apr 2001 18:18:02 -0000 Received: from knuckles.excite.com ([199.172.148.179]) by bucky.excite.com (InterMail vM.4.01.02.39 201-229-119-122) with ESMTP id <20010420182700.EHDU25251.bucky.excite.com@knuckles.excite.com>; Fri, 20 Apr 2001 11:27:00 -0700 Message-ID: <17858251.987791220650.JavaMail.imail@knuckles.excite.com> Date: Fri, 20 Apr 2001 11:27:00 -0700 (PDT) From: gary kenward To: Jim Bound , "Andrew T. Campbell" Subject: RE: [seamoby] SeaMoby MicroMobility Work Cc: john.loughney@nokia.com, seamoby@diameter.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Excite Inbox X-Sender-Ip: 47.248.0.43 Sender: owner-seamoby@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit I don't really want to hop on the "doom and gloom" bandwagon, and I don't see ranting as being constructive. But, I really think that both John's and Jim's responses to Andrew's posting have missed the point, or at least one part of the point. That is, there is a (growing) contingent of engineers who are tired of the cellular marketing hype (anyone there when CDPD was announced?), and want to see an IP based, or at least, IP friendly intra-domain mobility solution (call it mm, call it LMM, call it Ralph, whatever). Punting the problem back to the 3G standards groups doesn't give me give me many "warm and fuzzies". And do not misunderstand me, I have all the respect in the world for the existing voice cellular standards and the work that went into them. It is simply my expectations that a 3G micromobility solution will not even be portable between NA and Europe, never mind 802.11, Bluetooth, etc. Absolutely, the market will decide, but if people only have one choice, then they have no decision to make. There needs to be a forum for wireless IP access, that is not biased towards 2G, 3G, 802.11, HyperLAN II, Bluetooth, TETRA, or any other existing SDO. Why shouldn't that be the IETF? If not, who? Gary Kenward On Fri, 20 Apr 2001 06:57:10 -0400 (EDT), Jim Bound wrote: > Andrew, > > Just as a note. If I need MM in the market to make 3G work I will work > with TEMs and Telcos to make it work and variant suppliers in this space. > It might be a blessing the IETF pushed this out to the IRTF now we can go > implement it and if we need a standard go do it in 3G. > > /jim > > On Fri, 20 Apr 2001, Andrew T. Campbell wrote: > > > > > John: > > > > I have been contributing for the last few years and > > I intend to keep contributing. > > > > But we should question the decision making when > > we believe that it counter productive to wireless > > IP rollout. Or no? > > > > You see I firmly believe that if IETF standardized an > > IP micro-mobility protocol today then wireless > > IP access would roll out far quicker than > > we have seen with MIP. And that protocol would > > be the basis for 4G. > > > > Pushing micro-mobility into the IRTF was the > > wrong decision in my mind it should have been > > accelerated in the Seamoby WG - just my opinion. > > > > I think you are aware what is going on out there > > in the industry; the 3G shakedown. > > > > --- > > Andrew > > http://comet.columbia.edu/~campbell > > > > > > > -----Original Message----- > > > From: owner-seamoby@diameter.org [mailto:owner-seamoby@diameter.org]On > > > Behalf Of john.loughney@nokia.com > > > Sent: Friday, April 20, 2001 2:22 AM > > > To: campbell@comet.columbia.edu; seamoby@diameter.org > > > Subject: RE: [seamoby] SeaMoby MicroMobility Work > > > > > > > > > Hi Andrew, > > > > > > > The irony of putting this activity > > > > on the back burner is that the > > > > companies and market is rushing > > > > towards 4G as soon as 2004 and are > > > > in need of an IP micro-mobility protocol (incl. > > > > fast/seamless handoff, QOS, security, > > > > paging etc.) to make 4G work. > > > > > > As far as I understood, it is only on the > > > backburner if noone participates in the work. > > > There is interest in the IRTF and if you feel > > > that this is important work, then you should > > > get involved. > > > > > > I think engaging in good engineering is much > > > more useful then going back and forth on > > > mailing lists .... > > > > > > best regards, > > > John > > > > > > > > > _______________________________________________________ Send a cool gift with your E-Card http://www.bluemountain.com/giftcenter/ From owner-seamoby@diameter.org Fri Apr 20 14:40:45 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA16089 for ; Fri, 20 Apr 2001 14:40:42 -0400 (EDT) Received: (qmail 30470 invoked by alias); 20 Apr 2001 18:29:34 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 30464 invoked by uid 200); 20 Apr 2001 18:29:34 -0000 Received: (qmail 30459 invoked from network); 20 Apr 2001 18:29:33 -0000 Received: from gigi.excite.com (199.172.152.110) by c900656-a.plstn1.sfba.home.com with SMTP; 20 Apr 2001 18:29:33 -0000 Received: from knuckles.excite.com ([199.172.148.179]) by gigi.excite.com (InterMail vM.4.01.02.39 201-229-119-122) with ESMTP id <20010420183831.GTFI12263.gigi.excite.com@knuckles.excite.com>; Fri, 20 Apr 2001 11:38:31 -0700 Message-ID: <6772756.987791911202.JavaMail.imail@knuckles.excite.com> Date: Fri, 20 Apr 2001 11:38:30 -0700 (PDT) From: gary kenward To: Jim Bound , MORAND Lionel FTRD/DAC/ISS Subject: RE: [seamoby] 4G BOF? Cc: Gopal Dommety , seamoby@diameter.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Excite Inbox X-Sender-Ip: 47.248.0.43 Sender: owner-seamoby@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit I agree. So let's talk about a Wireless IP Access (WIPA) BOF. Gary On Fri, 20 Apr 2001 06:54:28 -0400 (EDT), Jim Bound wrote: > Hate to be a pain folks. But if we want to talk about reqs for 4G BOF or > what 4G means and is next steps thats one thing and I don't think thats > our charter is it? > > But to talk about it like it exists as 3GPP Release 5 or the 3GPP2 specs, > which are specs that EXIST and I have to use them to implement production > software and hardware, is absurd. > > If someone knows of a 4G spec I can write code to or even system integrate > a solution with as I can with 3GPP or 3GPP2 please share it with me. > > Otherwise why are we discussing 4G? I vote for the chair to kill this > conversation unless we do what I said in my first sentence or something > like it. > > /jim > > On Fri, 20 Apr 2001, MORAND Lionel FTRD/DAC/ISS wrote: > > > Hi, > > > > What do you really called "4G"? 1G, 2G, 3G were used to refere to new radio > > access technologies in mobile (cellular) networks. Find a global solution > > for seamless handovers between different types of access networks doesn't > > imply to find a new access technology and a new access network design. 4G > > doesn't have to used in opposition to 3G or each time a new solution is > > proposed. > > BTW, I don't think that Seamoby was supposed to deal with 4G but to solve > > micromobility issues raised with MIP (whatever the definition of > > "micromobility" is). To simplify the problem, one can say that the aim was > > to ensure a fast and reliable handoff between two IP access points (IP base > > stations, routers, etc.). But maybe I'm wrong and I missed something... > > > > > > -----Original Message----- > > From: Gopal Dommety [mailto:gdommety@cisco.com] > > Sent: Friday, April 20, 2001 3:26 AM > > To: gary kenward; seamoby@diameter.org > > Subject: Re: [seamoby] 4G BOF? > > > > > > > > I was referring to "non-carrier class mobility" in the statement Phil made > > and not "carrier class packet data". > > As for your comment of IP vs ATM that is another matter. > > > > A comment about the concept of 4G BOF. It might help to > > put some bounds on the problem(s). > > > > -Gopal > > > > > > > > > What is "non-carrier class" packet data? Answer: compare IP with ATM. > > > > > > > > >Gary > > > > > >On Thu, 19 Apr 2001 10:27:02 -0700, Gopal Dommety wrote: > > > > > >> At 11:52 AM 19/04/01 -0500, Phil Neumiller wrote: > > >> >I think we MAY need a 4G BOF, i.e. what SeaMoby was supposed to be > > >> >as opposed to what it became. This would be working on the global > > >> >Internet architecture for the purpose of improving global wireless > > >> >handovers of all types (primarily data, then QoS). A primary goal of > > >this > > >> >work group could in fact be the large scale deployment of MIP (this > > >being > > >> >ironic) by focussing on NON-carrier class mobility, > > >> > > >> > > >> what is non-carrier class mobility? > > >> > > >> >i.e. growth of wireless > > >> >access and handovers would take primary precedence over things like > > >> >AAA, security, QoS, etc. > > >> > > >> I am a bit confused. Could you elobrate? > > >> > > >> -gopal > > >> > > >> >This would not conflict with MIP or SeaMoby (now son of MIP) since > > >> >these WGs are now ALMOST exclusively working on 3G network > > >> >applications of MIP, IMO. > > >> > > > >> >-pdn > > >> > > > > > > > > > > > > > > > > > >_______________________________________________________ > > >Send a cool gift with your E-Card > > >http://www.bluemountain.com/giftcenter/ > > > _______________________________________________________ Send a cool gift with your E-Card http://www.bluemountain.com/giftcenter/ From owner-seamoby@diameter.org Fri Apr 20 15:09:27 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA16563 for ; Fri, 20 Apr 2001 15:09:26 -0400 (EDT) Received: (qmail 31663 invoked by alias); 20 Apr 2001 18:59:05 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 31657 invoked by uid 200); 20 Apr 2001 18:59:04 -0000 Received: (qmail 31652 invoked from network); 20 Apr 2001 18:59:03 -0000 Received: from kuku-rwcmta.excite.com (HELO kuku.excite.com) (198.3.99.63) by c900656-a.plstn1.sfba.home.com with SMTP; 20 Apr 2001 18:59:03 -0000 Received: from knuckles.excite.com ([199.172.148.179]) by kuku.excite.com (InterMail vM.4.01.02.39 201-229-119-122) with ESMTP id <20010420190758.IRUQ22770.kuku.excite.com@knuckles.excite.com>; Fri, 20 Apr 2001 12:07:58 -0700 Message-ID: <30937735.987793677989.JavaMail.imail@knuckles.excite.com> Date: Fri, 20 Apr 2001 12:07:57 -0700 (PDT) From: gary kenward To: john.loughney@nokia.com, campbell@comet.columbia.edu, seamoby@diameter.org Subject: RE: [seamoby] SeaMoby MicroMobility Work Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Excite Inbox X-Sender-Ip: 47.248.0.43 Sender: owner-seamoby@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit Does anyone know if the IRTF has agreed to start up an effort in this area? I know that they have been asked, but I do not know of the answer. Perhaps Phil R. knows? Gary On Fri, 20 Apr 2001 12:21:45 +0300, john.loughney@nokia.com wrote: > Hi Andrew, > > > The irony of putting this activity > > on the back burner is that the > > companies and market is rushing > > towards 4G as soon as 2004 and are > > in need of an IP micro-mobility protocol (incl. > > fast/seamless handoff, QOS, security, > > paging etc.) to make 4G work. > > As far as I understood, it is only on the > backburner if noone participates in the work. > There is interest in the IRTF and if you feel > that this is important work, then you should > get involved. > > I think engaging in good engineering is much > more useful then going back and forth on > mailing lists .... > > best regards, > John _______________________________________________________ Send a cool gift with your E-Card http://www.bluemountain.com/giftcenter/ From owner-seamoby@diameter.org Fri Apr 20 15:16:56 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA16695 for ; Fri, 20 Apr 2001 15:16:54 -0400 (EDT) Received: (qmail 32186 invoked by alias); 20 Apr 2001 19:06:27 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 32180 invoked by uid 200); 20 Apr 2001 19:06:27 -0000 Received: (qmail 32175 invoked from network); 20 Apr 2001 19:06:26 -0000 Received: from unknown (HELO megisto-sql1.megisto.com) (63.113.114.132) by c900656-a.plstn1.sfba.home.com with SMTP; 20 Apr 2001 19:06:26 -0000 Received: by mail.megisto.com with Internet Mail Service (5.5.2650.21) id ; Fri, 20 Apr 2001 15:09:37 -0400 Message-ID: From: Phil Roberts To: seamoby@diameter.org Subject: RE: [seamoby] SeaMoby MicroMobility Work Date: Fri, 20 Apr 2001 15:09:37 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-seamoby@diameter.org Precedence: bulk Yes. It's my understanding that the IRTF is willing to take a look at this. Abha is one of the chairs of the IRTF routing group. They are waiting for a problem statement. Phil > -----Original Message----- > From: gary kenward [mailto:ImaginItAll@excite.com] > Sent: Friday, April 20, 2001 3:08 PM > To: john.loughney@nokia.com; campbell@comet.columbia.edu; > seamoby@diameter.org > Subject: RE: [seamoby] SeaMoby MicroMobility Work > > > Does anyone know if the IRTF has agreed to start up an effort > in this area? > I know that they have been asked, but I do not know of the answer. > Perhaps Phil R. knows? > > Gary > > On Fri, 20 Apr 2001 12:21:45 +0300, john.loughney@nokia.com wrote: > > > Hi Andrew, > > > > > The irony of putting this activity > > > on the back burner is that the > > > companies and market is rushing > > > towards 4G as soon as 2004 and are > > > in need of an IP micro-mobility protocol (incl. > > > fast/seamless handoff, QOS, security, > > > paging etc.) to make 4G work. > > > > As far as I understood, it is only on the > > backburner if noone participates in the work. > > There is interest in the IRTF and if you feel > > that this is important work, then you should > > get involved. > > > > I think engaging in good engineering is much > > more useful then going back and forth on > > mailing lists .... > > > > best regards, > > John > > > > > > _______________________________________________________ > Send a cool gift with your E-Card > http://www.bluemountain.com/giftcenter/ > > From owner-seamoby@diameter.org Fri Apr 20 15:20:11 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA16726 for ; Fri, 20 Apr 2001 15:20:09 -0400 (EDT) Received: (qmail 32635 invoked by alias); 20 Apr 2001 19:09:08 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 32629 invoked by uid 200); 20 Apr 2001 19:09:07 -0000 Received: (qmail 32624 invoked from network); 20 Apr 2001 19:09:06 -0000 Received: from fortune-rwcmta.excite.com (HELO fortune.excite.com) (198.3.99.203) by c900656-a.plstn1.sfba.home.com with SMTP; 20 Apr 2001 19:09:06 -0000 Received: from knuckles.excite.com ([199.172.148.179]) by fortune.excite.com (InterMail vM.4.01.02.39 201-229-119-122) with ESMTP id <20010420191834.FDBP10124.fortune.excite.com@knuckles.excite.com>; Fri, 20 Apr 2001 12:18:34 -0700 Message-ID: <2122398.987794314646.JavaMail.imail@knuckles.excite.com> Date: Fri, 20 Apr 2001 12:18:30 -0700 (PDT) From: gary kenward To: MORAND Lionel FTRD/DAC/ISS , Gopal Dommety , seamoby@diameter.org Subject: RE: [seamoby] 4G BOF? Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Excite Inbox X-Sender-Ip: 47.248.0.43 Sender: owner-seamoby@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit Sorry Gopal, but IP vs. ATM is exactly the issue. Both are good solutions from the perspective of the design philosophies adopted. We could argue for ever on the pros and cons of both solutions but we won't be cause it's moot and out of scope for this list. However, the design philsophy behind ATM is the same design philosophhy behind cellular. Mainly because it comes from the same community. This philosophy is what I understood to be what Phil meant by "carrier-class". In essence, every bit transferred is managed and controlled, every resource is optimized. In the Internet, if there is management or control, it is stochastic. The only gaurantees are statistical. I hope this helps. Anyway, I agree about "4G": it is best not to use a term that is already causing much confusion in the wireless community. I prefer wireless IP access. Gary Kenward On Fri, 20 Apr 2001 10:43:33 +0200, MORAND Lionel FTRD/DAC/ISS wrote: > Hi, > > What do you really called "4G"? 1G, 2G, 3G were used to refere to new radio > access technologies in mobile (cellular) networks. Find a global solution > for seamless handovers between different types of access networks doesn't > imply to find a new access technology and a new access network design. 4G > doesn't have to used in opposition to 3G or each time a new solution is > proposed. > BTW, I don't think that Seamoby was supposed to deal with 4G but to solve > micromobility issues raised with MIP (whatever the definition of > "micromobility" is). To simplify the problem, one can say that the aim was > to ensure a fast and reliable handoff between two IP access points (IP base > stations, routers, etc.). But maybe I'm wrong and I missed something... > > > -----Original Message----- > From: Gopal Dommety [mailto:gdommety@cisco.com] > Sent: Friday, April 20, 2001 3:26 AM > To: gary kenward; seamoby@diameter.org > Subject: Re: [seamoby] 4G BOF? > > > > I was referring to "non-carrier class mobility" in the statement Phil made > and not "carrier class packet data". > As for your comment of IP vs ATM that is another matter. > > A comment about the concept of 4G BOF. It might help to > put some bounds on the problem(s). > > -Gopal > > > > > What is "non-carrier class" packet data? Answer: compare IP with ATM. > > > > >Gary > > > >On Thu, 19 Apr 2001 10:27:02 -0700, Gopal Dommety wrote: > > > >> At 11:52 AM 19/04/01 -0500, Phil Neumiller wrote: > >> >I think we MAY need a 4G BOF, i.e. what SeaMoby was supposed to be > >> >as opposed to what it became. This would be working on the global > >> >Internet architecture for the purpose of improving global wireless > >> >handovers of all types (primarily data, then QoS). A primary goal of > >this > >> >work group could in fact be the large scale deployment of MIP (this > >being > >> >ironic) by focussing on NON-carrier class mobility, > >> > >> > >> what is non-carrier class mobility? > >> > >> >i.e. growth of wireless > >> >access and handovers would take primary precedence over things like > >> >AAA, security, QoS, etc. > >> > >> I am a bit confused. Could you elobrate? > >> > >> -gopal > >> > >> >This would not conflict with MIP or SeaMoby (now son of MIP) since > >> >these WGs are now ALMOST exclusively working on 3G network > >> >applications of MIP, IMO. > >> > > >> >-pdn > >> > > > > > > > > > > > >_______________________________________________________ > >Send a cool gift with your E-Card > >http://www.bluemountain.com/giftcenter/ _______________________________________________________ Send a cool gift with your E-Card http://www.bluemountain.com/giftcenter/ From owner-seamoby@diameter.org Fri Apr 20 15:48:59 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA17109 for ; Fri, 20 Apr 2001 15:48:57 -0400 (EDT) Received: (qmail 727 invoked by alias); 20 Apr 2001 19:13:16 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 721 invoked by uid 200); 20 Apr 2001 19:13:16 -0000 Received: (qmail 716 invoked from network); 20 Apr 2001 19:13:13 -0000 Received: from sirius.ctr.columbia.edu (128.59.64.60) by c900656-a.plstn1.sfba.home.com with SMTP; 20 Apr 2001 19:13:13 -0000 Received: from SWEETPEA (sweetpea.comet.columbia.edu [128.59.65.202]) by sirius.ctr.columbia.edu (8.9.3/8.6.4.287) with SMTP id PAA14420; Fri, 20 Apr 2001 15:13:43 -0400 (EDT) From: "Andrew T. Campbell" To: "'Glenn Morrow'" , "'MORAND Lionel FTRD/DAC/ISS'" , "'Gopal Dommety'" , "'gary kenward'" , Subject: RE: [seamoby] 4G BOF? Date: Fri, 20 Apr 2001 15:11:46 -0700 Message-ID: <00e101c0c9e6$e482c3d0$ca413b80@SWEETPEA> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00E2_01C0C9AC.3823EBD0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 In-reply-to: <85AA7486A2C1D411BCA20000F8073E4301F4AF63@crchy271.us.nortel.com> Importance: Normal Sender: owner-seamoby@diameter.org Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_00E2_01C0C9AC.3823EBD0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit RE: [seamoby] 4G BOF?Glen: That is happening. --- Andrew http://comet.columbia.edu/~campbell -----Original Message----- From: owner-seamoby@diameter.org [mailto:owner-seamoby@diameter.org]On Behalf Of Glenn Morrow Sent: Friday, April 20, 2001 11:57 AM To: MORAND Lionel FTRD/DAC/ISS; Gopal Dommety; gary kenward; seamoby@diameter.org Subject: RE: [seamoby] 4G BOF? From a positive perspective, I just think it is great that there are some operators participating at least at the requirements stage. I find it difficult to judge support for requirements and functionality coming just from vendors that usually have solutions in mind. I hope more operators begin actively participating. This should help filter what is a requirement and what isn't. A problem I have seen is that vendors tend to favor the requirements that match their solution - requirements shaping. I just hope the operators can agree on the majority of the requirements. Thanks, Glenn -----Original Message----- From: MORAND Lionel FTRD/DAC/ISS [mailto:lionel.morand@rd.francetelecom.fr] Sent: Friday, April 20, 2001 3:44 AM To: Gopal Dommety; gary kenward; seamoby@diameter.org Subject: RE: [seamoby] 4G BOF? Hi, What do you really called "4G"? 1G, 2G, 3G were used to refere to new radio access technologies in mobile (cellular) networks. Find a global solution for seamless handovers between different types of access networks doesn't imply to find a new access technology and a new access network design. 4G doesn't have to used in opposition to 3G or each time a new solution is proposed. BTW, I don't think that Seamoby was supposed to deal with 4G but to solve micromobility issues raised with MIP (whatever the definition of "micromobility" is). To simplify the problem, one can say that the aim was to ensure a fast and reliable handoff between two IP access points (IP base stations, routers, etc.). But maybe I'm wrong and I missed something... -----Original Message----- From: Gopal Dommety [mailto:gdommety@cisco.com] Sent: Friday, April 20, 2001 3:26 AM To: gary kenward; seamoby@diameter.org Subject: Re: [seamoby] 4G BOF? I was referring to "non-carrier class mobility" in the statement Phil made and not "carrier class packet data". As for your comment of IP vs ATM that is another matter. A comment about the concept of 4G BOF. It might help to put some bounds on the problem(s). -Gopal > What is "non-carrier class" packet data? Answer: compare IP with ATM. >Gary > >On Thu, 19 Apr 2001 10:27:02 -0700, Gopal Dommety wrote: > >> At 11:52 AM 19/04/01 -0500, Phil Neumiller wrote: >> >I think we MAY need a 4G BOF, i.e. what SeaMoby was supposed to be >> >as opposed to what it became. This would be working on the global >> >Internet architecture for the purpose of improving global wireless >> >handovers of all types (primarily data, then QoS). A primary goal of >this >> >work group could in fact be the large scale deployment of MIP (this >being >> >ironic) by focussing on NON-carrier class mobility, >> >> >> what is non-carrier class mobility? >> >> >i.e. growth of wireless >> >access and handovers would take primary precedence over things like >> >AAA, security, QoS, etc. >> >> I am a bit confused. Could you elobrate? >> >> -gopal >> >> >This would not conflict with MIP or SeaMoby (now son of MIP) since >> >these WGs are now ALMOST exclusively working on 3G network >> >applications of MIP, IMO. >> > >> >-pdn >> > > > > > >_______________________________________________________ >Send a cool gift with your E-Card >http://www.bluemountain.com/giftcenter/ ------=_NextPart_000_00E2_01C0C9AC.3823EBD0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [seamoby] 4G BOF?
Glen:
 
That=20 is happening.

---
Andrew=20
http://comet.columbia.edu/~campbell

-----Original Message-----
From: = owner-seamoby@diameter.org=20 [mailto:owner-seamoby@diameter.org]On Behalf Of Glenn=20 Morrow
Sent: Friday, April 20, 2001 11:57 AM
To: = MORAND=20 Lionel FTRD/DAC/ISS; Gopal Dommety; gary kenward;=20 seamoby@diameter.org
Subject: RE: [seamoby] 4G=20 BOF?

From a positive perspective, I just think it is = great that=20 there are some operators participating at least at the requirements = stage. I=20 find it difficult to judge support for requirements and functionality = coming=20 just from vendors that  usually have solutions in mind. I hope = more=20 operators begin actively participating. This should help filter what = is a=20 requirement and what isn't. A problem I have seen is that vendors tend = to=20 favor the requirements that match their solution - requirements = shaping. I=20 just hope the operators can agree on the majority of the=20 requirements.

Thanks,

Glenn

-----Original Message-----
From:=20 MORAND Lionel FTRD/DAC/ISS
[mailto:lionel.morand@rd= .francetelecom.fr]=20
Sent: Friday, April 20, 2001 3:44 AM =
To: Gopal Dommety; gary kenward; seamoby@diameter.org =
Subject: RE: [seamoby] 4G BOF?


Hi,

What do you really called "4G"? 1G, 2G, 3G were used = to refere=20 to new radio
access technologies in mobile = (cellular)=20 networks. Find a global solution
for = seamless=20 handovers between different types of access networks doesn't =
imply to find a new access technology and a new access = network design.=20 4G
doesn't have to used in opposition to 3G = or each=20 time a new solution is
proposed. =
BTW, I don't think that Seamoby was supposed to deal with 4G = but to=20 solve
micromobility issues raised with MIP = (whatever=20 the definition of
"micromobility" is). To = simplify the=20 problem, one can say that the aim was
to = ensure a fast=20 and reliable handoff between two IP access points (IP base =
stations, routers, etc.). But maybe I'm wrong and I missed=20 something...


-----Original Message-----
From: Gopal=20 Dommety [mailto:gdommety@cisco.com] =
Sent: Friday, April 20, 2001 3:26 AM =
To: gary kenward; seamoby@diameter.org
Subject:=20 Re: [seamoby] 4G BOF?



I was referring to  "non-carrier class = mobility" in the=20 statement Phil made
and not "carrier class = packet=20 data".
As for your comment of IP vs ATM that = is=20 another matter.

A comment about the concept of 4G BOF. It might help = to=20
put some bounds on the problem(s). =

-Gopal



>  What is "non-carrier class" packet data? = Answer:=20 compare IP with ATM.



>Gary
> =
>On Thu, 19 Apr 2001 10:27:02 -0700, Gopal Dommety = wrote:=20
>
>>  At = 11:52 AM=20 19/04/01 -0500, Phil Neumiller wrote:
>> =20 >I think we MAY need a 4G BOF, i.e. what SeaMoby was supposed to = be=20
>>  >as opposed to what it = became.  This=20 would be working on the global
>> =20 >Internet architecture for the purpose of improving global = wireless=20
>>  >handovers of all types = (primarily data,=20 then QoS).  A primary goal of
>this=20
>>  >work group could in fact be the = large=20 scale deployment of MIP (this
>being=20
>>  >ironic) by focussing on = NON-carrier class=20 mobility,
>> 
>> 
>>  what = is=20 non-carrier class mobility?
>> =20
>>  >i.e. growth of = wireless=20
>>  >access and handovers would take = primary=20 precedence over things like
>>  = >AAA,=20 security, QoS, etc.
>>  =
>>  I am a bit confused. Could you = elobrate?=20
>> 
>> =20 -gopal
>> 
>>  >This would not conflict with MIP or = SeaMoby (now son=20 of MIP) since
>>  >these WGs = are now=20 ALMOST exclusively working on 3G network
>>  >applications of MIP, IMO.
>>  >
>> =20 >-pdn
>>
>=20
>
> =
>
>
>_______________________________________________________=20
>Send a cool gift with your E-Card =
>http://www.bluemountain.com/giftcenter/=20

------=_NextPart_000_00E2_01C0C9AC.3823EBD0-- From owner-seamoby@diameter.org Fri Apr 20 15:51:52 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA17159 for ; Fri, 20 Apr 2001 15:51:51 -0400 (EDT) Received: (qmail 31085 invoked by alias); 20 Apr 2001 18:48:10 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 31080 invoked by uid 200); 20 Apr 2001 18:48:10 -0000 Received: (qmail 31075 invoked from network); 20 Apr 2001 18:48:08 -0000 Received: from unknown (HELO zrc2s03g.us.nortel.com) (47.103.122.66) by c900656-a.plstn1.sfba.home.com with SMTP; 20 Apr 2001 18:48:08 -0000 Received: from smtprch1.nortel.com (erchg0j.us.nortel.com [47.113.64.103]) by zrc2s03g.us.nortel.com (8.9.3+Sun/8.9.1) with ESMTP id NAA00451 for ; Fri, 20 Apr 2001 13:57:20 -0500 (CDT) Received: from zrchb200.us.nortel.com by smtprch1.nortel.com; Fri, 20 Apr 2001 13:56:52 -0500 Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 20 Apr 2001 13:56:42 -0500 Message-ID: <85AA7486A2C1D411BCA20000F8073E4301F4AF63@crchy271.us.nortel.com> From: "Glenn Morrow" To: MORAND Lionel FTRD/DAC/ISS , Gopal Dommety , gary kenward , seamoby@diameter.org Subject: RE: [seamoby] 4G BOF? Date: Fri, 20 Apr 2001 13:56:38 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0C9CB.A0E8CF90" Sender: owner-seamoby@diameter.org Precedence: bulk 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_01C0C9CB.A0E8CF90 Content-Type: text/plain; charset="iso-8859-1" From a positive perspective, I just think it is great that there are some operators participating at least at the requirements stage. I find it difficult to judge support for requirements and functionality coming just from vendors that usually have solutions in mind. I hope more operators begin actively participating. This should help filter what is a requirement and what isn't. A problem I have seen is that vendors tend to favor the requirements that match their solution - requirements shaping. I just hope the operators can agree on the majority of the requirements. Thanks, Glenn -----Original Message----- From: MORAND Lionel FTRD/DAC/ISS [mailto:lionel.morand@rd.francetelecom.fr] Sent: Friday, April 20, 2001 3:44 AM To: Gopal Dommety; gary kenward; seamoby@diameter.org Subject: RE: [seamoby] 4G BOF? Hi, What do you really called "4G"? 1G, 2G, 3G were used to refere to new radio access technologies in mobile (cellular) networks. Find a global solution for seamless handovers between different types of access networks doesn't imply to find a new access technology and a new access network design. 4G doesn't have to used in opposition to 3G or each time a new solution is proposed. BTW, I don't think that Seamoby was supposed to deal with 4G but to solve micromobility issues raised with MIP (whatever the definition of "micromobility" is). To simplify the problem, one can say that the aim was to ensure a fast and reliable handoff between two IP access points (IP base stations, routers, etc.). But maybe I'm wrong and I missed something... -----Original Message----- From: Gopal Dommety [mailto:gdommety@cisco.com] Sent: Friday, April 20, 2001 3:26 AM To: gary kenward; seamoby@diameter.org Subject: Re: [seamoby] 4G BOF? I was referring to "non-carrier class mobility" in the statement Phil made and not "carrier class packet data". As for your comment of IP vs ATM that is another matter. A comment about the concept of 4G BOF. It might help to put some bounds on the problem(s). -Gopal > What is "non-carrier class" packet data? Answer: compare IP with ATM. >Gary > >On Thu, 19 Apr 2001 10:27:02 -0700, Gopal Dommety wrote: > >> At 11:52 AM 19/04/01 -0500, Phil Neumiller wrote: >> >I think we MAY need a 4G BOF, i.e. what SeaMoby was supposed to be >> >as opposed to what it became. This would be working on the global >> >Internet architecture for the purpose of improving global wireless >> >handovers of all types (primarily data, then QoS). A primary goal of >this >> >work group could in fact be the large scale deployment of MIP (this >being >> >ironic) by focussing on NON-carrier class mobility, >> >> >> what is non-carrier class mobility? >> >> >i.e. growth of wireless >> >access and handovers would take primary precedence over things like >> >AAA, security, QoS, etc. >> >> I am a bit confused. Could you elobrate? >> >> -gopal >> >> >This would not conflict with MIP or SeaMoby (now son of MIP) since >> >these WGs are now ALMOST exclusively working on 3G network >> >applications of MIP, IMO. >> > >> >-pdn >> > > > > > >_______________________________________________________ >Send a cool gift with your E-Card >http://www.bluemountain.com/giftcenter/ ------_=_NextPart_001_01C0C9CB.A0E8CF90 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [seamoby] 4G BOF?

From a positive perspective, I just think it is great = that there are some operators participating at least at the = requirements stage. I find it difficult to judge support for = requirements and functionality coming just from vendors that  = usually have solutions in mind. I hope more operators begin actively = participating. This should help filter what is a requirement and what = isn't. A problem I have seen is that vendors tend to favor the = requirements that match their solution - requirements shaping. I just = hope the operators can agree on the majority of the = requirements.

Thanks,

Glenn

-----Original Message-----
From: MORAND Lionel FTRD/DAC/ISS
[mailto:lionel.morand@r= d.francetelecom.fr]
Sent: Friday, April 20, 2001 3:44 AM
To: Gopal Dommety; gary kenward; = seamoby@diameter.org
Subject: RE: [seamoby] 4G BOF?


Hi,

What do you really called "4G"? 1G, 2G, 3G = were used to refere to new radio
access technologies in mobile (cellular) networks. = Find a global solution
for seamless handovers between different types of = access networks doesn't
imply to find a new access technology and a new = access network design. 4G
doesn't have to used in opposition to 3G or each = time a new solution is
proposed.
BTW, I don't think that Seamoby was supposed to deal = with 4G but to solve
micromobility issues raised with MIP (whatever the = definition of
"micromobility" is). To simplify the = problem, one can say that the aim was
to ensure a fast and reliable handoff between two IP = access points (IP base
stations, routers, etc.). But maybe I'm wrong and I = missed something...


-----Original Message-----
From: Gopal Dommety [mailto:gdommety@cisco.com]=
Sent: Friday, April 20, 2001 3:26 AM
To: gary kenward; seamoby@diameter.org
Subject: Re: [seamoby] 4G BOF?



I was referring to  "non-carrier class = mobility" in the statement Phil made
and not "carrier class packet = data".
As for your comment of IP vs ATM that is another = matter.

A comment about the concept of 4G BOF. It might help = to
put some bounds on the problem(s).

-Gopal



>  What is "non-carrier class" = packet data? Answer: compare IP with ATM.



>Gary
>
>On Thu, 19 Apr 2001 10:27:02 -0700, Gopal = Dommety wrote:
>
>>  At 11:52 AM 19/04/01 -0500, Phil = Neumiller wrote:
>>  >I think we MAY need a 4G BOF, = i.e. what SeaMoby was supposed to be
>>  >as opposed to what it = became.  This would be working on the global
>>  >Internet architecture for the = purpose of improving global wireless
>>  >handovers of all types (primarily = data, then QoS).  A primary goal of
>this
>>  >work group could in fact be the = large scale deployment of MIP (this
>being
>>  >ironic) by focussing on = NON-carrier class mobility,
>> 
>> 
>>  what is non-carrier class = mobility?
>> 
>>  >i.e. growth of wireless
>>  >access and handovers would take = primary precedence over things like
>>  >AAA, security, QoS, etc.
>> 
>>  I am a bit confused. Could you = elobrate?
>> 
>>  -gopal
>> 
>>  >This would not conflict with MIP = or SeaMoby (now son of MIP) since
>>  >these WGs are now ALMOST = exclusively working on 3G network
>>  >applications of MIP, IMO.
>>  >
>>  >-pdn
>>
>
>
>
>
>
>_______________________________________________________
>Send a cool gift with your E-Card
>http://www.bluemountain.com/giftcenter/

------_=_NextPart_001_01C0C9CB.A0E8CF90-- From owner-seamoby@diameter.org Fri Apr 20 15:57:28 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA17192 for ; Fri, 20 Apr 2001 15:57:26 -0400 (EDT) Received: (qmail 1565 invoked by alias); 20 Apr 2001 19:46:46 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 1559 invoked by uid 200); 20 Apr 2001 19:46:46 -0000 Received: (qmail 1554 invoked from network); 20 Apr 2001 19:46:44 -0000 Received: from out4.prserv.net (HELO prserv.net) (32.97.166.34) by c900656-a.plstn1.sfba.home.com with SMTP; 20 Apr 2001 19:46:44 -0000 Received: from [32.101.227.128] (slip-32-101-227-128.ca.us.prserv.net[32.101.227.128]) by prserv.net (out4) with ESMTP id <2001042019560720401f3q49e>; Fri, 20 Apr 2001 19:56:09 +0000 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Sender: ahmrphd@pop3.attglobal.net Message-Id: In-Reply-To: <6772756.987791911202.JavaMail.imail@knuckles.excite.com> Date: Fri, 20 Apr 2001 12:56:35 -0700 To: gary kenward , Jim Bound , MORAND Lionel FTRD/DAC/ISS From: Arthur Ross Subject: RE: [seamoby] IP Evolution (was 4G BOF?) Cc: Gopal Dommety , seamoby@diameter.org Sender: owner-seamoby@diameter.org Precedence: bulk At 11:38 -0700 04/20/2001, gary kenward wrote: >I agree. So let's talk about a Wireless IP Access (WIPA) BOF. > >Gary > Yes indeed. This is long overdue. In fact, I am inclined to make the topic even loftier and more general - Perhaps "IP Evolution", of which wireless access would be but one aspect. As the Seamoby discussion has touched on lately, mobility does not necessarily mean wireless. As I see it, this would begin with serious mental noodling on the underlying concepts and formal abstractions of IP. The initial work would document high level concepts, principles, and architecture guidelines. From these would flow, hopefully, a more rational regime of radio access design(s). It would, of course, have to accommodate legacy stuff, but let's get our priorities back in order. 3G, in its various flavors, seems to me an insanely over-complex solution in search of a problem. If we can create, or at least influence, future radio designs based on what is appropriate and necessary for that evolved IP, rather than trying to overlay IP on inappropriate, overly complex network architectures, the result HAS to be happier than this insane tower of (wireless) babel that we have now. I also believe that producing an evolved architecture that is not Balkanized by all sorts of proprietary claims and incompatible components/solutions has to help the industry as a whole - a rising tide that lifts all ships. The multiple incompatible, disjoint air interface designs, chaos, and business uncertainty are, in my opinion, seriously impeding the growth of wireless services. There are many of us who believe that "big wireless", with it's legacy circuit-switched network mindset, has created this monster that is 3G. I do not want to impede or derail it in any way, although I tend to believe it's headed for a marketplace belly flop of its own making. Setting a coherent course for the future Internet, which, some believe, may include nodes ranging from doorknobs to aircraft carriers and spacecraft, should, I think, be a major priority. ... and, as an aside, we might want to talk about national spectrum policy too ... -- Regards, -- Arthur Dr. Arthur H. M. Ross San Diego, CA Tel: 760-634-8173 (Res.) From owner-seamoby@diameter.org Fri Apr 20 16:07:54 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA17372 for ; Fri, 20 Apr 2001 16:07:52 -0400 (EDT) Received: (qmail 2096 invoked by alias); 20 Apr 2001 19:55:59 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 2090 invoked by uid 200); 20 Apr 2001 19:55:59 -0000 Received: (qmail 2085 invoked from network); 20 Apr 2001 19:55:57 -0000 Received: from c007-h013.c007.snv.cp.net (HELO c007.snv.cp.net) (209.228.33.220) by c900656-a.plstn1.sfba.home.com with SMTP; 20 Apr 2001 19:55:57 -0000 Received: (cpmta 25983 invoked from network); 20 Apr 2001 13:04:55 -0700 Received: from unknown (HELO philneum) (64.193.0.129) by smtp.telocity.com (209.228.33.220) with SMTP; 20 Apr 2001 13:04:55 -0700 X-Sent: 20 Apr 2001 20:04:55 GMT Message-ID: <043b01c0c9d4$f3e206e0$6501a8c0@philneum> Reply-To: "Phil Neumiller" From: "Phil Neumiller" To: "gary kenward" , "MORAND Lionel FTRD/DAC/ISS" , "Gopal Dommety" , References: <2122398.987794314646.JavaMail.imail@knuckles.excite.com> Subject: Re: [seamoby] 4G BOF? Date: Fri, 20 Apr 2001 15:03:14 -0500 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-seamoby@diameter.org Precedence: bulk I disagree with Jim Bound on where the appropriate place to discuss this is. Many of us have given almost 2 years of our lives to create SeaMoby and, it did not come out at all as expected. Those folks are still on this list and THIS is the FIRST logical place to discuss breaking off into a new BOF. If this builds some momentum we will get a seperate mail list going in short order. Perhaps a WIPA email list will be created. Anyone offering to host it? Although Gary and I have had our differences in opinion, he has described my feelings on the subject of 4G quite well. Of course, Gary has been involved with SeaMoby from day 1, starting with OBAST, through CRAPS, and then SeaMoby, so he probably understands as well as any of the old timers on this list what "I am getting at". Regarding the word "4G" its not just used in cellular. I understand from an operator perspective how the term is used. However, deep in the bowels of RF research labs where this terminology had its origin the use of 4G is not tied strictly to the evolution of cellular. Many RF engineers were working on 4G about 4-5 years ago, and 3G about 5-6 years ago. Many RF engineers I know today are talking about 5G, 6G and 7G with respect to edge-of-the-art RF technology. The colloquilism of 3G has lead to the "marketing" interpretation of 1G = AMPS, 2G = TDMA/GSM/IS95, 3G = cdma2000/UMTS, etc. Thanks, Phil ----- Original Message ----- From: "gary kenward" To: "MORAND Lionel FTRD/DAC/ISS" ; "Gopal Dommety" ; Sent: Friday, April 20, 2001 2:18 PM Subject: RE: [seamoby] 4G BOF? > Sorry Gopal, but IP vs. ATM is exactly the issue. > Both are good solutions from the perspective of the design philosophies > adopted. We could argue for ever on the pros and cons of both solutions > but we won't be cause it's moot and out of scope for this list. > > However, the design philsophy behind ATM is the same design philosophhy > behind > cellular. Mainly because it comes from the same community. This philosophy > is what I understood to be what Phil meant by "carrier-class". In essence, > every bit transferred is managed and controlled, every resource is > optimized. In the Internet, if there is management or control, it is > stochastic. The only > gaurantees are statistical. > > I hope this helps. Anyway, I agree about "4G": it is best not to use a term > that is already causing much confusion in the wireless community. I prefer > wireless IP access. > > Gary Kenward > > On Fri, 20 Apr 2001 10:43:33 +0200, MORAND Lionel FTRD/DAC/ISS wrote: > > > Hi, > > > > What do you really called "4G"? 1G, 2G, 3G were used to refere to new > radio > > access technologies in mobile (cellular) networks. Find a global solution > > for seamless handovers between different types of access networks doesn't > > imply to find a new access technology and a new access network design. 4G > > doesn't have to used in opposition to 3G or each time a new solution is > > proposed. > > BTW, I don't think that Seamoby was supposed to deal with 4G but to solve > > micromobility issues raised with MIP (whatever the definition of > > "micromobility" is). To simplify the problem, one can say that the aim > was > > to ensure a fast and reliable handoff between two IP access points (IP > base > > stations, routers, etc.). But maybe I'm wrong and I missed something... > > > > > > -----Original Message----- > > From: Gopal Dommety [mailto:gdommety@cisco.com] > > Sent: Friday, April 20, 2001 3:26 AM > > To: gary kenward; seamoby@diameter.org > > Subject: Re: [seamoby] 4G BOF? > > > > > > > > I was referring to "non-carrier class mobility" in the statement Phil > made > > and not "carrier class packet data". > > As for your comment of IP vs ATM that is another matter. > > > > A comment about the concept of 4G BOF. It might help to > > put some bounds on the problem(s). > > > > -Gopal > > > > > From owner-seamoby@diameter.org Fri Apr 20 18:56:41 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA19547 for ; Fri, 20 Apr 2001 18:56:40 -0400 (EDT) Received: (qmail 4005 invoked by alias); 20 Apr 2001 22:45:56 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 3999 invoked by uid 200); 20 Apr 2001 22:45:55 -0000 Received: (qmail 3994 invoked from network); 20 Apr 2001 22:45:54 -0000 Received: from unknown (HELO NEPTUNE.zucotto.com) (216.95.209.154) by c900656-a.plstn1.sfba.home.com with SMTP; 20 Apr 2001 22:45:54 -0000 Received: by NEPTUNE.zucotto.com with Internet Mail Service (5.5.2653.19) id ; Fri, 20 Apr 2001 18:55:22 -0400 Message-ID: <6833D86F1B05CA4FBAB3C73DD98BD8B90D2B6C@NEPTUNE.zucotto.com> From: Kulwinder Atwal To: "'Glenn Morrow'" , MORAND Lionel FTRD/DAC/ISS , Gopal Dommety , gary kenward , seamoby@diameter.org Subject: FW: [seamoby] 4G BOF? Date: Fri, 20 Apr 2001 18:55:13 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-seamoby@diameter.org Precedence: bulk -----Original Message----- From: Kulwinder Atwal Sent: Friday, April 20, 2001 6:54 PM To: 'Glenn Morrow' Subject: RE: [seamoby] 4G BOF? -----Original Message----- From: Glenn Morrow [mailto:gmorrow@nortelnetworks.com] Sent: Friday, April 20, 2001 2:57 PM To: MORAND Lionel FTRD/DAC/ISS; Gopal Dommety; gary kenward; seamoby@diameter.org Subject: RE: [seamoby] 4G BOF? >From a positive perspective, I just think it is great that there are some operators participating at least at >the requirements stage. I find it difficult to judge support for requirements and functionality coming just >from vendors that usually have solutions in mind. I hope more operators begin actively participating. This >should help filter what is a requirement and what isn't. A problem I have seen is that vendors tend to favor >the requirements that match their solution - requirements shaping. I agree. I have witnessed this requirements shaping first hand. I have seen 3G vendors claiming that Bluetooth is just a cable replacement for cellphones. And, I have seen 802.11 vendors claim that Bluetooth should look 'just like 802.11'. What we need to hear from more often are the Internet Service Providers and end-users. >I just hope the operators can agree on the majority of the requirements. I think the customer here is not the Cellular Operator, but the Internet Service Provider wanting to attach Wireless Access Routers for the last hop. The ISP already has the IP network, and the bandwidth. With the right IETF protocols and Wireless Access Routers, an ISP can provide voice and any other type of IP traffic. An ISP can gain revenue by adding wireless voice with an investment much less than the Cellular Operator's investment in 3G infra-structure. The ISP is not building infra-structure just Wireless Access Routers. The ISP also has a low flat monthly billing model that is more appealing to the end user. The end user is not going to pay by the minute for Internet access over 3G. Rather than focusing on turning Cellular Operators into ISPs with 3G, we should be looking at turning ISPs into Wireless Access ISPs. - Kulwinder. > Thanks, > Glenn From owner-seamoby@diameter.org Fri Apr 20 19:55:39 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA20086 for ; Fri, 20 Apr 2001 19:55:38 -0400 (EDT) Received: (qmail 4876 invoked by alias); 20 Apr 2001 23:45:05 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 4870 invoked by uid 200); 20 Apr 2001 23:45:05 -0000 Received: (qmail 4865 invoked from network); 20 Apr 2001 23:45:03 -0000 Received: from c007-h013.c007.snv.cp.net (HELO c007.snv.cp.net) (209.228.33.220) by c900656-a.plstn1.sfba.home.com with SMTP; 20 Apr 2001 23:45:03 -0000 Received: (cpmta 14897 invoked from network); 20 Apr 2001 16:49:24 -0700 Received: from dsl-64-193-0-129.telocity.com (HELO philneum) (64.193.0.129) by smtp.telocity.com (209.228.33.220) with SMTP; 20 Apr 2001 16:49:24 -0700 X-Sent: 20 Apr 2001 23:49:24 GMT Message-ID: <001901c0c9f4$687d01c0$6501a8c0@philneum> Reply-To: "Phil Neumiller" From: "Phil Neumiller" To: "Kulwinder Atwal" , "'Glenn Morrow'" , "MORAND Lionel FTRD/DAC/ISS" , "Gopal Dommety" , "gary kenward" , References: <6833D86F1B05CA4FBAB3C73DD98BD8B90D2B6C@NEPTUNE.zucotto.com> Subject: Re: [seamoby] 4G BOF? Date: Fri, 20 Apr 2001 18:48:23 -0500 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-seamoby@diameter.org Precedence: bulk A man after my own heart. -pdn ----- Original Message ----- From: "Kulwinder Atwal" > > Rather than focusing on turning Cellular Operators into ISPs with 3G, we > should be looking at turning ISPs into Wireless Access ISPs. > > - Kulwinder. From owner-seamoby@diameter.org Sat Apr 21 15:04:36 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA11846 for ; Sat, 21 Apr 2001 15:04:35 -0400 (EDT) Received: (qmail 9448 invoked by alias); 21 Apr 2001 18:53:50 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 9441 invoked by uid 200); 21 Apr 2001 18:53:50 -0000 Received: (qmail 9436 invoked from network); 21 Apr 2001 18:53:47 -0000 Received: from mailhub1.shef.ac.uk (143.167.1.9) by c900656-a.plstn1.sfba.home.com with SMTP; 21 Apr 2001 18:53:47 -0000 Received: from ridingwood.shef.ac.uk ([143.167.59.249]) by mailhub1.shef.ac.uk with esmtp (Exim 3.22 #3) id 14r2eC-0005ZK-00; Sat, 21 Apr 2001 20:02:20 +0100 Received: from RIDINGWOOD/SpoolDir by ridingwood.shef.ac.uk (Mercury 1.48); 21 Apr 01 20:02:22 +0100 Received: from SpoolDir by RIDINGWOOD (Mercury 1.48); 21 Apr 01 20:02:12 +0100 Received: from borg (143.167.251.68) by ridingwood.shef.ac.uk (Mercury 1.48); 21 Apr 01 20:02:02 +0100 Message-ID: <001f01c0ca95$8fce8c70$44fba78f@borg> Reply-To: "cny" From: "cny" To: "Phil Neumiller" , "Kulwinder Atwal" , "'Glenn Morrow'" , "MORAND Lionel FTRD/DAC/ISS" , "Gopal Dommety" , "gary kenward" , References: <6833D86F1B05CA4FBAB3C73DD98BD8B90D2B6C@NEPTUNE.zucotto.com> <001901c0c9f4$687d01c0$6501a8c0@philneum> Subject: Re: [seamoby] 4G BOF? Date: Sat, 21 Apr 2001 21:02:07 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-seamoby@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi all Just for your info Someone has put up a nice little 4G web page supportedby NSF http://users.ece.gatech.edu/~jxie/4G/ Of course not to rememebr Royal Institute of Technology(KTH) http://www.s3.kth.se/radio/4GW/ Still alive and Kicking ...... Chern Nam ----- Original Message ----- From: "Phil Neumiller" To: "Kulwinder Atwal" ; "'Glenn Morrow'" ; "MORAND Lionel FTRD/DAC/ISS" ; "Gopal Dommety" ; "gary kenward" ; Sent: Saturday, April 21, 2001 1:48 AM Subject: Re: [seamoby] 4G BOF? > A man after my own heart. > -pdn > ----- Original Message ----- > From: "Kulwinder Atwal" > > > > Rather than focusing on turning Cellular Operators into ISPs with 3G, we > > should be looking at turning ISPs into Wireless Access ISPs. > > > > - Kulwinder. > > > From owner-seamoby@diameter.org Mon Apr 23 01:51:10 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA22800 for ; Mon, 23 Apr 2001 01:51:09 -0400 (EDT) Received: (qmail 19664 invoked by alias); 23 Apr 2001 05:39:59 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 19657 invoked by uid 200); 23 Apr 2001 05:39:59 -0000 Received: (qmail 19652 invoked from network); 23 Apr 2001 05:39:57 -0000 Received: from mgw-x2.nokia.com (131.228.20.22) by c900656-a.plstn1.sfba.home.com with SMTP; 23 Apr 2001 05:39:57 -0000 Received: from esvir02nok.nokia.com (esvir02nokt.ntc.nokia.com [172.21.143.34]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f3N5nYS08932 for ; Mon, 23 Apr 2001 08:49:34 +0300 (EET DST) Received: from esebh25nok.ntc.nokia.com (unverified) by esvir02nok.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Mon, 23 Apr 2001 08:49:26 +0300 Received: by esebh25nok with Internet Mail Service (5.5.2652.78) id ; Mon, 23 Apr 2001 08:48:55 +0300 Message-ID: <01D91AFB08B6D211BFD00008C7EABAE10680ADA5@eseis04nok> From: john.loughney@nokia.com To: ImaginItAll@excite.com Cc: seamoby@diameter.org Subject: RE: [seamoby] SeaMoby MicroMobility Work Date: Mon, 23 Apr 2001 08:48:48 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-seamoby@diameter.org Precedence: bulk Hi Gary, > I don't really want to hop on the "doom and gloom" bandwagon, > and I don't see ranting as being constructive. But, I really think > that both John's and Jim's responses to Andrew's posting have > missed the point, or at least one part of the point. With all due respect, you misunderstand me. I am suggesting that if folks are not happy with the current state of affairs, then they should propose and work on solutions that they see as viable - rather than complaining. I think that the IRTF has done excellent work in the past and I do not doubt that the work on micromobility (or whatever you want to call it) will be good. I'd further suggest that folks on the SeaMoby list actively participate in it. Anyhow, there has been no responses to the last version of the MM Problem Statement (v01) before or after the IETF meeting. This seems to indicate that this work is unimportant. As far as the other related work in SeaMoby that I outlined in the original mail, I have yet to get any useful feedback on it (except for Phil R.). What this does is make me think that everyone would sooner bitch & moan about the current state of affairs rather than offer anything new. Anyhow, I'd say that this thread is just about dead ... John From owner-seamoby@diameter.org Mon Apr 23 01:53:21 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA22985 for ; Mon, 23 Apr 2001 01:53:20 -0400 (EDT) Received: (qmail 19885 invoked by alias); 23 Apr 2001 05:41:16 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 19879 invoked by uid 200); 23 Apr 2001 05:41:15 -0000 Received: (qmail 19872 invoked from network); 23 Apr 2001 05:41:13 -0000 Received: from mgw-x2.nokia.com (131.228.20.22) by c900656-a.plstn1.sfba.home.com with SMTP; 23 Apr 2001 05:41:13 -0000 Received: from esvir02nok.nokia.com (esvir02nokt.ntc.nokia.com [172.21.143.34]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f3N5ouS09393 for ; Mon, 23 Apr 2001 08:50:56 +0300 (EET DST) Received: from esebh25nok.ntc.nokia.com (unverified) by esvir02nok.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Mon, 23 Apr 2001 08:50:42 +0300 Received: by esebh25nok with Internet Mail Service (5.5.2652.78) id ; Mon, 23 Apr 2001 08:50:42 +0300 Message-ID: <01D91AFB08B6D211BFD00008C7EABAE10680ADA6@eseis04nok> From: john.loughney@nokia.com To: kulwinder.atwal@zucotto.com, seamoby@diameter.org Subject: RE: [seamoby] 4G BOF? Date: Mon, 23 Apr 2001 08:50:39 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-seamoby@diameter.org Precedence: bulk Hi Kulwinder, > Rather than focusing on turning Cellular Operators into ISPs > with 3G, we should be looking at turning ISPs into Wireless > Access ISPs. I'd suggest that it is not the IETF's business to do either. Further more, if the IETF did start to do either, then the IETF would be setting itself up for failure. br, John From owner-seamoby@diameter.org Mon Apr 23 07:03:34 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA03352 for ; Mon, 23 Apr 2001 07:03:34 -0400 (EDT) Received: (qmail 21442 invoked by alias); 23 Apr 2001 10:52:41 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 21436 invoked by uid 200); 23 Apr 2001 10:52:41 -0000 Received: (qmail 21431 invoked from network); 23 Apr 2001 10:52:40 -0000 Received: from c007-h011.c007.snv.cp.net (HELO c007.snv.cp.net) (209.228.33.217) by c900656-a.plstn1.sfba.home.com with SMTP; 23 Apr 2001 10:52:40 -0000 Received: (cpmta 21010 invoked from network); 23 Apr 2001 04:02:13 -0700 Received: from dsl-64-193-0-129.telocity.com (HELO philneum) (64.193.0.129) by smtp.telocity.com (209.228.33.217) with SMTP; 23 Apr 2001 04:02:13 -0700 X-Sent: 23 Apr 2001 11:02:13 GMT Message-ID: <003501c0cbe4$b6be9820$6501a8c0@philneum> Reply-To: "Phil Neumiller" From: "Phil Neumiller" To: Cc: References: <01D91AFB08B6D211BFD00008C7EABAE10680ADA5@eseis04nok> Subject: Re: [seamoby] 4G BOF? Date: Mon, 23 Apr 2001 06:01:07 -0500 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-seamoby@diameter.org Precedence: bulk Hi John, On the contrary, I think many of us are tired of being yelled at for being out of scope. I think a new list would allow the creative juices to flow again. Maybe it won't be a BOF right away, maybe it will take some honing and a bit of time, but at least many of us would be freed from the shackles that are imposed by the charters we have in MIP and SeaMoby. BTW, I agree that SeaMoby people should get involved in the IRTF work. I still believe SeaMoby has a good group of folks to help lead us into the post cellular age of wirelesss Internet as well. -Phil ----- Original Message ----- From: > As far as the other related work in SeaMoby that I outlined in the > original mail, I have yet to get any useful feedback on it (except > for Phil R.). What this does is make me think that everyone would > sooner bitch & moan about the current state of affairs rather than > offer anything new. From owner-seamoby@diameter.org Mon Apr 23 14:19:18 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA09190 for ; Mon, 23 Apr 2001 14:19:16 -0400 (EDT) Received: (qmail 25052 invoked by alias); 23 Apr 2001 18:08:26 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 25046 invoked by uid 200); 23 Apr 2001 18:08:25 -0000 Received: (qmail 25041 invoked from network); 23 Apr 2001 18:08:23 -0000 Received: from mercury.sun.com (192.9.25.1) by c900656-a.plstn1.sfba.home.com with SMTP; 23 Apr 2001 18:08:23 -0000 Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA29723; Mon, 23 Apr 2001 11:17:48 -0700 (PDT) Received: from nasnfs.Eng.Sun.COM (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA10636; Mon, 23 Apr 2001 11:17:47 -0700 (PDT) Received: from darius (darius [152.70.40.121]) by nasnfs.Eng.Sun.COM (8.9.3+Sun/8.9.1) with SMTP id LAA12272; Mon, 23 Apr 2001 11:17:45 -0700 (PDT) Date: Mon, 23 Apr 2001 11:17:46 -0700 (PDT) From: Patrice Calhoun Reply-To: Patrice Calhoun Subject: RE: [seamoby] 4G BOF? To: Jim Bound Cc: MORAND Lionel FTRD/DAC/ISS , Gopal Dommety , gary kenward , seamoby@diameter.org In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-seamoby@diameter.org Precedence: bulk > Otherwise why are we discussing 4G? I vote for the chair to kill this > conversation unless we do what I said in my first sentence or something > like it. Unfortunately (well, fortunately for me), I was on vacation, and am now trying to catch up. I agree that our list seems to be subjected to unnecessary pollution. May I kindly request that people that have mutual BOF ideas either exchange them on ietf@ietf.org, or some other list. We really need to concentrate on the work on our charter. PatC From owner-seamoby@diameter.org Wed Apr 25 07:16:40 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA10824 for ; Wed, 25 Apr 2001 07:16:38 -0400 (EDT) Received: (qmail 5030 invoked by alias); 25 Apr 2001 11:05:18 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 5024 invoked by uid 200); 25 Apr 2001 11:05:18 -0000 Received: (qmail 5019 invoked from network); 25 Apr 2001 11:05:13 -0000 Received: from odin.ietf.org (HELO ietf.org) (132.151.1.176) by c900656-a.plstn1.sfba.home.com with SMTP; 25 Apr 2001 11:05:13 -0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA10517; Wed, 25 Apr 2001 07:14:53 -0400 (EDT) Message-Id: <200104251114.HAA10517@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: seamoby@cdma-2000.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: [seamoby] I-D ACTION:draft-ietf-seamoby-paging-requirements-00.txt Date: Wed, 25 Apr 2001 07:14:53 -0400 Sender: owner-seamoby@diameter.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Context and Micro-mobility Routing Working Group of the IETF. Title : Requirements for an IP Mobile Node Alerting Protocol Author(s) : J. Kempf Filename : draft-ietf-seamoby-paging-requirements-00.txt Pages : Date : 24-Apr-01 This document develops an architecture and a set of requirements needed to support alerting of mobile nodes that are in the dormant mode. The architecture and requirements are designed to guide development of an IP protocol for alerting dormant IP mobile hosts, commonly called paging. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-seamoby-paging-requirements-00.txt 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-ietf-seamoby-paging-requirements-00.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-ietf-seamoby-paging-requirements-00.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: <20010424133306.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-seamoby-paging-requirements-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-seamoby-paging-requirements-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010424133306.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-seamoby@diameter.org Thu Apr 26 18:18:28 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA23854 for ; Thu, 26 Apr 2001 18:18:28 -0400 (EDT) Received: (qmail 1565 invoked by alias); 26 Apr 2001 22:07:13 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 1559 invoked by uid 200); 26 Apr 2001 22:07:13 -0000 Received: (qmail 1554 invoked by uid 500); 26 Apr 2001 22:07:11 -0000 Date: Thu, 26 Apr 2001 15:07:11 -0700 From: Pat Calhoun To: seamoby@cdma-2000.org Subject: [seamoby] Change in contact info Message-ID: <20010426150711.B591@charizard.diameter.org> Mail-Followup-To: seamoby@cdma-2000.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-seamoby@diameter.org Precedence: bulk All, From now on I can be contacted at pcalhoun@diameter.org. I will make sure that this transition will be smooth, and will not slow down WG progress. Thanks, PatC From owner-seamoby@diameter.org Mon Apr 30 11:58:36 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA16674 for ; Mon, 30 Apr 2001 11:58:35 -0400 (EDT) Received: (qmail 3701 invoked by alias); 30 Apr 2001 15:47:18 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 3695 invoked by uid 200); 30 Apr 2001 15:47:17 -0000 Received: (qmail 3690 invoked from network); 30 Apr 2001 15:47:16 -0000 Received: from c007-h000.c007.snv.cp.net (HELO c007.snv.cp.net) (209.228.33.206) by c900656-a.plstn1.sfba.home.com with SMTP; 30 Apr 2001 15:47:16 -0000 Received: (cpmta 19382 invoked from network); 30 Apr 2001 08:57:12 -0700 Received: from unknown (HELO federalmobility.com) (64.193.0.129) by smtp.federalmobility.com (209.228.33.206) with SMTP; 30 Apr 2001 08:57:12 -0700 X-Sent: 30 Apr 2001 15:57:12 GMT Message-ID: <3AED8AEE.4D8780D8@federalmobility.com> Date: Mon, 30 Apr 2001 10:55:26 -0500 From: Phil Neumiller Organization: Federal Mobility X-Mailer: Mozilla 4.77 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: seamoby@diameter.org, mobile-ip@sunroof.eng.sun.com, cellular@diameter.org Subject: [seamoby] New Wireless Internet IETF List Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-seamoby@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit Apologies if you receive multiple copies of this. Greetings, A new wireless internet list has been created and can be subscribed to at: http://internet.motlabs.com/mailman/listinfo/wirelessinternet The WirelessInternet discussion list is devoted to new ideas and proposals on how future wireless technologies should be supported by IETF working groups and their specifications. Topics on this list are open but some of the following seem like appropriate starter discussions: o Expansion of the global Internet over wireless access devices and wireless routers, Internet Over Wireless Expansion (IOWE) pre-BOF? o Massive deployment of Mobile IP in non-cellular and perhaps non-carrier class networks. o Pre-BOF discussions for new wireless WGs, i.e. last mile wireless/mobility BOF? o Commercializing MANETs what is the best way to approach this? o OpenRAN and possibly re-incarnating parts of Motorola's OBAST archictecture? o Neo-3G (post-cellular) network architectures. List moderators are Ron Akers and Phil Neumiller. Thanks, Phil Neumiller From owner-seamoby@diameter.org Mon Apr 30 15:03:42 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA22701 for ; Mon, 30 Apr 2001 15:03:42 -0400 (EDT) Received: (qmail 5470 invoked by alias); 30 Apr 2001 18:53:02 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 5464 invoked by uid 200); 30 Apr 2001 18:53:02 -0000 Received: (qmail 5459 invoked from network); 30 Apr 2001 18:53:00 -0000 Received: from unknown (HELO megisto-sql1.megisto.com) (63.113.114.132) by c900656-a.plstn1.sfba.home.com with SMTP; 30 Apr 2001 18:53:00 -0000 Received: by mail.megisto.com with Internet Mail Service (5.5.2650.21) id ; Mon, 30 Apr 2001 14:56:24 -0400 Message-ID: From: Phil Roberts To: "'seamoby@diameter.org'" Subject: [seamoby] IRTF mm problem statement Date: Mon, 30 Apr 2001 14:56:23 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-seamoby@diameter.org Precedence: bulk Hi folks, a draft of an IRTF problem statement for host routing is now available at: http://www.diameter.org/draft-proberts-hostrouting-problem-00.txt. I'd like to run it by the working group before submitting it as an I-D. All comments and suggestions are welcome. It would probably help if it had a set of proposed deliverables. Phil From owner-seamoby@diameter.org Mon Apr 30 15:31:32 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA23456 for ; Mon, 30 Apr 2001 15:31:30 -0400 (EDT) Received: (qmail 6333 invoked by alias); 30 Apr 2001 19:20:32 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 6323 invoked by uid 200); 30 Apr 2001 19:20:32 -0000 Received: (qmail 6314 invoked from network); 30 Apr 2001 19:20:29 -0000 Received: from goliath.siemens.de (194.138.37.131) by c900656-a.plstn1.sfba.home.com with SMTP; 30 Apr 2001 19:20:29 -0000 X-Envelope-Sender-Is: wwlu@ieee.org (at relayer goliath.siemens.de) Received: from mail2.siemens.de (mail2.siemens.de [139.25.208.11]) by goliath.siemens.de (8.11.1/8.11.1) with ESMTP id f3UJUQC12606; Mon, 30 Apr 2001 21:30:27 +0200 (MET DST) Received: from ieee.org ([219.8.75.114]) by mail2.siemens.de (8.11.0/8.11.0) with ESMTP id f3UJUPK08034; Mon, 30 Apr 2001 21:30:25 +0200 (MET DST) Message-ID: <3AEDBD4F.D47E2DB9@ieee.org> Date: Mon, 30 Apr 2001 12:30:23 -0700 From: "Office of Willie W. LU" Organization: US Office - II of Willie W. Lu X-Mailer: Mozilla 4.73 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Phil Neumiller CC: seamoby@diameter.org, mobile-ip@sunroof.eng.sun.com, cellular@diameter.org Subject: [seamoby] Re: [cellular] New Wireless Internet IETF List References: <3AED8AEE.4D8780D8@federalmobility.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-seamoby@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit thanks, all. wmi is also a hot topic in 3Gwireless'2001 at: 3gwireless.com/3gwireless01 - the most authoritative tech event on 3Gwireless and beyond. rgds. -willie Phil Neumiller wrote: > Apologies if you receive multiple copies of this. > > Greetings, > > A new wireless internet list has been created and can be subscribed to at: > > http://internet.motlabs.com/mailman/listinfo/wirelessinternet > > The WirelessInternet discussion list is devoted to new ideas and proposals on how future wireless technologies should be supported > by IETF working groups and their specifications. > > Topics on this list are open but some of the following seem like appropriate starter discussions: > > o Expansion of the global Internet over wireless access devices and wireless routers, > Internet Over Wireless Expansion (IOWE) pre-BOF? > o Massive deployment of Mobile IP in non-cellular and perhaps non-carrier class networks. > o Pre-BOF discussions for new wireless WGs, i.e. last mile wireless/mobility BOF? > o Commercializing MANETs what is the best way to approach this? > o OpenRAN and possibly re-incarnating parts of Motorola's OBAST archictecture? > o Neo-3G (post-cellular) network architectures. > > List moderators are Ron Akers and Phil Neumiller. > > Thanks, > > Phil Neumiller -- Office of Willie W. LU 3Gwireless'01, Globecom'01, WCNC'02 e-mail: wwlu@ieee.org From owner-seamoby@diameter.org Mon Apr 30 15:48:39 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA24046 for ; Mon, 30 Apr 2001 15:48:38 -0400 (EDT) Received: (qmail 7223 invoked by alias); 30 Apr 2001 19:37:59 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 7217 invoked by uid 200); 30 Apr 2001 19:37:59 -0000 Received: (qmail 7212 invoked from network); 30 Apr 2001 19:37:57 -0000 Received: from mgw-x2.nokia.com (131.228.20.22) by c900656-a.plstn1.sfba.home.com with SMTP; 30 Apr 2001 19:37:57 -0000 Received: from esvir02nok.nokia.com (esvir02nokt.ntc.nokia.com [172.21.143.34]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f3UJm5S06617 for ; Mon, 30 Apr 2001 22:48:05 +0300 (EET DST) Received: from esebh25nok.ntc.nokia.com (unverified) by esvir02nok.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Mon, 30 Apr 2001 22:47:56 +0300 Received: by esebh25nok with Internet Mail Service (5.5.2652.78) id ; Mon, 30 Apr 2001 22:47:55 +0300 Message-ID: <01D91AFB08B6D211BFD00008C7EABAE10680AE23@eseis04nok> From: john.loughney@nokia.com To: PRoberts@MEGISTO.com, seamoby@diameter.org Subject: RE: [seamoby] IRTF mm problem statement Date: Mon, 30 Apr 2001 22:47:45 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-seamoby@diameter.org Precedence: bulk Hi Phil, > It would probably help if it had a set of proposed deliverables. I like the draft so far, I think the minimalist approach is the right way. I'd suggest setting a time limit for comments, after which you send it to the drafts editor. br, John From owner-seamoby@diameter.org Mon Apr 30 16:39:21 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA25261 for ; Mon, 30 Apr 2001 16:39:13 -0400 (EDT) Received: (qmail 8407 invoked by alias); 30 Apr 2001 20:26:16 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 8401 invoked by uid 200); 30 Apr 2001 20:26:15 -0000 Received: (qmail 8396 invoked from network); 30 Apr 2001 20:26:14 -0000 Received: from c007-h011.c007.snv.cp.net (HELO c007.snv.cp.net) (209.228.33.217) by c900656-a.plstn1.sfba.home.com with SMTP; 30 Apr 2001 20:26:14 -0000 Received: (cpmta 3540 invoked from network); 30 Apr 2001 13:35:22 -0700 Received: from dsl-64-193-0-129.telocity.com (HELO philneum) (64.193.0.129) by smtp.telocity.com (209.228.33.217) with SMTP; 30 Apr 2001 13:35:22 -0700 X-Sent: 30 Apr 2001 20:35:22 GMT Message-ID: <004601c0d1b4$a99e0d80$6401a8c0@philneum> Reply-To: "Phil Neumiller" From: "Phil Neumiller" To: "Phil Roberts" , References: Subject: [seamoby] Comments on IRTF mm problem statement Date: Mon, 30 Apr 2001 15:32:19 -0500 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-seamoby@diameter.org Precedence: bulk Hi Phil R, I had MANY questions and comments on the IRTF MM problem statement. They are contained below. In the Abstract >There are a couple of seemingly unrelated problems that > have lead investigators to converge on the desirability of new >routing protocols to implement host routes within a constrained area. The wording of the above sentence could be confusing for MIP/SeaMoby "outsiders". I suggest SOMETHINK LIKE : ...routing protocols that allow for a mobile host to implement a limited host routing table to other mobile hosts in the same constrained routing area. HOWEVER, This seems to beg the questions of: A). Why not use IPv6 MN to MN direct routing optimization? B). All MNs will be MANET capable in the future. If so, they don't they already have a sophisticated host routing algorithm? >The problem is to investigate the limits and issues with using (a) >new protocol(s) to implement host routes to facilitate better mobile >hosts and network recovery in the presence of failed links or >routers. To be fair, you MUST add that there are perceived deficiencies in using MIP all the time. These must be quantified and qualified by the IRTF. Specifically, how fast is a fast handoff, and WHEN IS USING HOST ROUTES EVEN DESIRABLE? >The document is a brief statement of the problem to be >investigated with lots of references to other work that has been done >already by many others in the area. I would reword "with lots of references .. " with "and the references to lots of prior work in this area have been included in this draft." >1. Introduction > The design of Internet routing has evolved largely based on the > assumption that most end systems are static. Not really true. The foundational pieces of the Arpanet and early Internet were all wireless and the MANET work is completely wireless mobile based routing. > As the idea of mobile > devices came along, Mobile IP provided an easy migration path for > supporting end system mobility without significant change or impact > to the Internet infrastructure. This was achieved primarily by > placing the support for routing to mobile devices on the end systems > and at a limited number of centralized points within the > infrastructure, effectively "hiding" the end system mobility from the > infrastructure routing protocols. However, as we anticipate the > desire to support real-time traffic flows to mobile devices and the > possibility that mobile devices may become a significant portion of > all Internet end nodes, investigation of alternative designs merit > consideration. Are we really talking about an alternative design? I don't think so. In this case we are talking about an extension. Now if we were talking about replacing MIP with something like BGP (which could happen in the not too distant future) we would be talking about an "alternative" design to MIP. > Many investigators in this area have converged on > solutions that propose the use of host routing to support mobility > within a limited domain, effectively exposing the mobility of end > systems to the routing protocols. Yes, an MANET has been working on this for years. I don't think that's what we want to say here Phil. What we need to do is talk about is localized host routing and WHAT it means to be local, i.e. how many hops, what kind of hops, how is MIP involved and how does it inter-work. > This draft represents a problem statement to enable investigation of > the use of host routing in IP networks to enable mobility and fast > network recovery. ... AND to take over for MIP when MIP is not the correct solution. > It is a problem statement based on a lot of work > done in attempting to provide low latency handover in mobile networks > and fast recovery in networks with fast recovery requirements. If fast recovery is important, MANET has the fastest non-looping and looping (Distance vector and link state routing) algorithms and protocols around. Fast recovery of what Phil? The link? The MN to AR path? The MN to MN path that bypasses MIP??? <> >2.1 Part One > > Why is there a perceived need for host routing? There are > applications that involve supporting real-time traffic flows to end > devices that are mobile. These applications require that there be > minimal (ideally no) interruption to the packet flows and that these > flows need to preserve the existing QoS and security characteristics > as the end station moves. In addition the movement of the end > devices should not cause excessive signaling in the network as the > devices move. > Such applications often also run on networks in which > link failures or router failures can cause a significant service > disruption. Is it possible to use a similar protocol to allow for > faster restoration of service during link failures. Could such > mobility requirements and fast restoration requirements be met in a > way that is more efficient and simpler than approaches based on > Mobile IP and OSPF by using a routing protocol that implements host > routes within a limited scope within the network? Questions: A). I DONT think link failure is the issue here at all! Its the limitations of MIP. the heart of the issue is for the IRTF to find what the MIP limitations are so that WE KNOW WHEN WE MUST (or it is desirable to) use HOST ROUTES!!! B). Why mention OSPF? Last time I checked, most of the Internet was built with distance vector routers (from Cisco :-)). C). > What would the > limits of such a solution be in terms of scaling? What are the limitations of MIP that force us to consider this solution? > Specifically how > many nodes could be supported across what kind of network breadth and > depth at what cost of complexity in the routers around the edge of > such a network? Completely insane routing tables based on brownian motion mobiles have been simulated up into the 10K+ numbers with both distance vector (Bellman Ford) and link state (Dykstra) approaches for MANETs. Again this seems to be asking the question in reverse! What we want to be asking is how SMALL can MIP get before IT wear's out its welcom, i.e. other solutions are more optimal. These are the numbers we need. > Is it possible to meet traffic engineering > requirements using such a protocol? It is possible to meet traffice engineering requirements with MIP? Where does MIP break so we know if these things are EVEN NEEDED!!! > Could it simplify management of > QoS in the part of the network where mobility is most readily felt? Localizing protocols to where the dynamics are occuring JUST MAKES so much sense. Hiding movement from upstream MIP entities or CNs makes lots of sense. What we need to understand is under which conditions is this NECESSARY. How often can a CN be informed of a BU? Nobody knows. >2.2 Problem Two > > One of the primary principles of the Internet has been end-to-end > communication. Most (if not all) of the protocols running over IP > have been designed with end-to-end signaling in mind. Currently, > changes due mobility induce unwanted end-to-end signaling. This may > cause applications running over IP to fail due to delay and latency > induced by unwanted signaling. Security, QoS and AAA signaling all > suffer due to this. Could a host based routing aid in this respect? A). "due mobility" -> "due to mobility" B). This seems to be presented in reverse terms to me. Host routing is returning to end-to-end signalling as opposed to box-in-the-middle signalling used by MIP. The CNs that are local to an area and that can speak with each other end-to-end are presumably doing this faster than having to relay and signal through a home agent!!! >2.2 Problem Three > > Why is there a need for an investigation of it in the IRTF rather > than a direct move to work on a standard within a working group of > the IETF? The area directors overseeing the activities of the > seamoby working group and the mobile-ip working group have raised > questions about the scale of host routing and the need to introduce > both another routing protocol and another mobility protocol. A > comparison with OSPF and Mobile IP are involved in making such an > assessment both in terms of relative scalability, performance, and > complexity. A). Why OSPF? B). Why not BGP? C). The primary issue needed is to expose the limitations of MIP and harden what we know about MIP quantitatively so ANY holes can be filled with local mobility management protocols. I can not emphasize this enough. THIS IS THE primary REASON. The secondary REASON is to investigate if host routes deployed in a limited scoped way (where the limitations are set by what MIP can't do) is reasonable. Also, carefull analysis of where the MANET boundary is also required. Thanks, Phil Neumiller From owner-seamoby@diameter.org Mon Apr 30 17:32:05 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA26445 for ; Mon, 30 Apr 2001 17:32:04 -0400 (EDT) Received: (qmail 9411 invoked by alias); 30 Apr 2001 21:20:18 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 9405 invoked by uid 200); 30 Apr 2001 21:20:17 -0000 Received: (qmail 9400 invoked from network); 30 Apr 2001 21:20:16 -0000 Received: from unknown (HELO megisto-sql1.megisto.com) (63.113.114.132) by c900656-a.plstn1.sfba.home.com with SMTP; 30 Apr 2001 21:20:16 -0000 Received: by mail.megisto.com with Internet Mail Service (5.5.2650.21) id ; Mon, 30 Apr 2001 17:23:36 -0400 Message-ID: From: Phil Roberts To: "'Phil Neumiller'" , seamoby@cdma-2000.org Subject: RE: [seamoby] Comments on IRTF mm problem statement Date: Mon, 30 Apr 2001 17:23:36 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-seamoby@diameter.org Precedence: bulk > Hi Phil R, Hi, I haven't answered each point by point, but I hope what I've said covers most of the questions you included. > >There are a couple of seemingly unrelated problems that > > have lead investigators to converge on the desirability of new > >routing protocols to implement host routes within a constrained area. > > The wording of the above sentence could be confusing for MIP/SeaMoby > "outsiders". I suggest SOMETHINK LIKE : > > ...routing protocols that allow for a mobile host to > implement a limited > host routing table to other mobile hosts in the same > constrained routing > area. But I don't think this is what we're interested in. The work certainly applies to completely fixed networks (for network recovery of failed routers and links) and the problem of scaling is in the routers. > >The problem is to investigate the limits and issues with using (a) > >new protocol(s) to implement host routes to facilitate better mobile > >hosts and network recovery in the presence of failed links or > >routers. > > To be fair, you MUST add that there are perceived deficiencies > in using MIP all the time. These must be quantified and qualified > by the IRTF. Specifically, how fast is a fast handoff, and WHEN > IS USING HOST ROUTES EVEN DESIRABLE? I'm not opposed to putting in something about the limitations of MIP, but I'm not sure measuring MIP performance is what we want the IRTF to do. Seems like one could get some MIP implementors to measure its performance. What do others think? > > >The document is a brief statement of the problem to be > >investigated with lots of references to other work that has been done > >already by many others in the area. > > I would reword "with lots of references .. " with "and the references > to lots of prior work in this area have been included in this draft." Good. > > > Many investigators in this area have converged on > > solutions that propose the use of host routing to support mobility > > within a limited domain, effectively exposing the mobility of end > > systems to the routing protocols. > > Yes, an MANET has been working on this for years. I don't think > that's what we want to say here Phil. What we need to do is talk > about is localized host routing and WHAT it means to be local, > i.e. how many hops, what kind of hops, how is MIP involved and > how does it inter-work. OK. Doesn't the following take what you're concerned about into account? "Specifically how many nodes could be supported across what kind of network breadth and depth at what cost of complexity in the routers around the edge of such a network?" I hadn't perceived that what we wanted the IRTF to do was come up with an interworking strategy between MIP and some to-be-defined protocol. Again, other feedback? > If fast recovery is important, MANET has the fastest non-looping and > looping (Distance vector and link state routing) algorithms > and protocols > around. Fast recovery of what Phil? The link? The MN to AR path? > The MN to MN path that bypasses MIP??? What *I* have in mind is a completely fixed network with router and link failures where losing the traffic for many seconds results in a much longer service disruption. I'm not sure these specifics need to be specified in the problem statement, but am open to suggestions from others. One of the references describes this. > A). "due mobility" -> "due to mobility" Got it. > A). Why OSPF? > B). Why not BGP? It's a particular problem of link or router failure in a local fixed domain. Hence OSPF. I guess I'm not willing to ask about scaling host routes across domains where BGP operates just yet. > C). The primary issue needed is to expose the limitations of MIP and > harden what we know about MIP quantitatively so ANY holes can > be filled with local mobility management protocols. I can > not emphasize > this enough. THIS IS THE primary REASON. The secondary REASON > is to investigate if host routes deployed in a limited scoped > way (where the > limitations are set by what MIP can't do) is reasonable. > Also, carefull > analysis of where the MANET boundary is also required. I guess our perceptions of what the ADs requested are reversed. Perhaps we can get some clarification. Phil > > > Thanks, > > Phil Neumiller > > From owner-seamoby@diameter.org Mon Apr 30 18:56:36 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA27842 for ; Mon, 30 Apr 2001 18:56:34 -0400 (EDT) Received: (qmail 10692 invoked by alias); 30 Apr 2001 22:44:37 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 10686 invoked by uid 200); 30 Apr 2001 22:44:37 -0000 Received: (qmail 10681 invoked from network); 30 Apr 2001 22:44:35 -0000 Received: from sj-msg-core-4.cisco.com (171.71.163.10) by c900656-a.plstn1.sfba.home.com with SMTP; 30 Apr 2001 22:44:35 -0000 Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id f3UMsAd01289; Mon, 30 Apr 2001 15:54:10 -0700 (PDT) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AEW16659; Mon, 30 Apr 2001 15:54:04 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id PAA13316; Mon, 30 Apr 2001 15:54:03 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15085.60682.928667.654159@thomasm-u1.cisco.com> Date: Mon, 30 Apr 2001 15:54:02 -0700 (PDT) To: Phil Roberts Cc: "'Phil Neumiller'" , seamoby@cdma-2000.org Subject: RE: [seamoby] Comments on IRTF mm problem statement In-Reply-To: References: X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-seamoby@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi Phil, Just as a top level comment, can we remove all references to host routes? There's no reason why we should limit this to /128 and /32 subnets. I think that the exact same thing is happening with MIP (though it's a lot murkier there because of the changed CoA). Mike Phil Roberts writes: > > > Hi Phil R, > > Hi, > > I haven't answered each point by point, but I hope what I've said covers > most of the questions you included. > > > >There are a couple of seemingly unrelated problems that > > > have lead investigators to converge on the desirability of new > > >routing protocols to implement host routes within a constrained area. > > > > The wording of the above sentence could be confusing for MIP/SeaMoby > > "outsiders". I suggest SOMETHINK LIKE : > > > > ...routing protocols that allow for a mobile host to > > implement a limited > > host routing table to other mobile hosts in the same > > constrained routing > > area. > > But I don't think this is what we're interested in. The work certainly > applies to completely fixed networks (for network recovery of failed routers > and links) and the problem of scaling is in the routers. > > > >The problem is to investigate the limits and issues with using (a) > > >new protocol(s) to implement host routes to facilitate better mobile > > >hosts and network recovery in the presence of failed links or > > >routers. > > > > To be fair, you MUST add that there are perceived deficiencies > > in using MIP all the time. These must be quantified and qualified > > by the IRTF. Specifically, how fast is a fast handoff, and WHEN > > IS USING HOST ROUTES EVEN DESIRABLE? > > I'm not opposed to putting in something about the limitations of MIP, but > I'm not sure measuring MIP performance is what we want the IRTF to do. > Seems like one could get some MIP implementors to measure its performance. > What do others think? > > > > > >The document is a brief statement of the problem to be > > >investigated with lots of references to other work that has been done > > >already by many others in the area. > > > > I would reword "with lots of references .. " with "and the references > > to lots of prior work in this area have been included in this draft." > > Good. > > > > > > Many investigators in this area have converged on > > > solutions that propose the use of host routing to support mobility > > > within a limited domain, effectively exposing the mobility of end > > > systems to the routing protocols. > > > > Yes, an MANET has been working on this for years. I don't think > > that's what we want to say here Phil. What we need to do is talk > > about is localized host routing and WHAT it means to be local, > > i.e. how many hops, what kind of hops, how is MIP involved and > > how does it inter-work. > > OK. Doesn't the following take what you're concerned about into account? > "Specifically how many nodes could be supported across what kind of network > breadth and depth at what cost of complexity in the routers around the edge > of such a network?" > > I hadn't perceived that what we wanted the IRTF to do was come up with an > interworking strategy between MIP and some to-be-defined protocol. Again, > other feedback? > > > If fast recovery is important, MANET has the fastest non-looping and > > looping (Distance vector and link state routing) algorithms > > and protocols > > around. Fast recovery of what Phil? The link? The MN to AR path? > > The MN to MN path that bypasses MIP??? > > What *I* have in mind is a completely fixed network with router and link > failures where losing the traffic for many seconds results in a much longer > service disruption. I'm not sure these specifics need to be specified in > the problem statement, but am open to suggestions from others. One of the > references describes this. > > > > A). "due mobility" -> "due to mobility" > Got it. > > > A). Why OSPF? > > B). Why not BGP? > It's a particular problem of link or router failure in a local fixed domain. > Hence OSPF. I guess I'm not willing to ask about scaling host routes across > domains where BGP operates just yet. > > > > C). The primary issue needed is to expose the limitations of MIP and > > harden what we know about MIP quantitatively so ANY holes can > > be filled with local mobility management protocols. I can > > not emphasize > > this enough. THIS IS THE primary REASON. The secondary REASON > > is to investigate if host routes deployed in a limited scoped > > way (where the > > limitations are set by what MIP can't do) is reasonable. > > Also, carefull > > analysis of where the MANET boundary is also required. > > I guess our perceptions of what the ADs requested are reversed. Perhaps we > can get some clarification. > > Phil > > > > > > > Thanks, > > > > Phil Neumiller > > > > From owner-seamoby@diameter.org Mon Apr 30 18:59:05 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA27859 for ; Mon, 30 Apr 2001 18:59:03 -0400 (EDT) Received: (qmail 10951 invoked by alias); 30 Apr 2001 22:46:27 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 10945 invoked by uid 200); 30 Apr 2001 22:46:26 -0000 Received: (qmail 10933 invoked from network); 30 Apr 2001 22:46:22 -0000 Received: from mercury.sun.com (192.9.25.1) by c900656-a.plstn1.sfba.home.com with SMTP; 30 Apr 2001 22:46:22 -0000 Received: from heliopolis.eng.sun.com ([152.70.1.39]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA23835; Mon, 30 Apr 2001 15:56:16 -0700 (PDT) Received: from srmtv29a (srmtv29a [152.70.1.41]) by heliopolis.eng.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id PAA14743; Mon, 30 Apr 2001 15:56:14 -0700 (PDT) Message-Id: <200104302256.PAA14743@heliopolis.eng.sun.com> Date: Mon, 30 Apr 2001 15:56:14 -0700 (PDT) From: James Kempf Reply-To: James Kempf Subject: Re: [seamoby] IRTF mm problem statement To: seamoby@diameter.org, PRoberts@MEGISTO.com Cc: erik.nordmark@sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: Hh4iSHRy83aLUU3Ubyshvg== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 sun4u sparc Sender: owner-seamoby@diameter.org Precedence: bulk Hi Phil, Good summary. One thing you might want to incude is a "Related Problems" section. Erik Nordmark mentioned that one problem with BGP is that it is not possible to deliver targetted updates on particular attributes, and that this is sort of related to the problem with targetted propagation of host routes. Erik may be able to explain more. Perhaps this is generalizing the problem too much, but if some technology could be developed that is broadly applicable to targetted routing updates, and this could be applied across a wide variety of routing protocols, it might result in a benefit beyond the immediate area of mobility management. Or maybe this research is too general for IRTF, I don't have a very good feeling about how broad a problem can be for IRTF to consider it well defined enough to tackle. jak From owner-seamoby@diameter.org Mon Apr 30 19:15:33 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA28146 for ; Mon, 30 Apr 2001 19:15:32 -0400 (EDT) Received: (qmail 12211 invoked by alias); 30 Apr 2001 23:04:36 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 12205 invoked by uid 200); 30 Apr 2001 23:04:36 -0000 Received: (qmail 12200 invoked from network); 30 Apr 2001 23:04:35 -0000 Received: from sj-msg-core-2.cisco.com (171.69.43.88) by c900656-a.plstn1.sfba.home.com with SMTP; 30 Apr 2001 23:04:35 -0000 Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f3UNEWK18645; Mon, 30 Apr 2001 16:14:32 -0700 (PDT) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AEW17249; Mon, 30 Apr 2001 16:14:04 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id QAA13323; Mon, 30 Apr 2001 16:14:03 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15085.61883.12646.20192@thomasm-u1.cisco.com> Date: Mon, 30 Apr 2001 16:14:03 -0700 (PDT) To: Phil Roberts Cc: "'Michael Thomas'" , "'Phil Neumiller'" , seamoby@cdma-2000.org Subject: RE: [seamoby] Comments on IRTF mm problem statement In-Reply-To: References: X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-seamoby@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit Phil Roberts writes: > > Hi Mike, > > Perhaps, but I thought investigation using host routes and routing protocols > to support those was the point of this exercise? What would you suggest as > an alternative? Do you just want to make sure mobile subnets are evaluated? Yes; "host routes" are just a degenerate form of a subnet prefix, after all. IMO, the point of the protocol is to allow subnets to move around within a contained area (ie, still leads to globally aggregated prefixes), that makes them look for all intents and purposes as stationary hosts (except in routers of the contained area). Though host routes for mobile nodes are likely to be the most common, I think it would be a mistake to not consider any old prefix up front so that we can address any hidden problems with the protocol (if any). Mike From owner-seamoby@diameter.org Mon Apr 30 19:26:14 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA28289 for ; Mon, 30 Apr 2001 19:26:14 -0400 (EDT) Received: (qmail 11666 invoked by alias); 30 Apr 2001 22:52:46 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 11660 invoked by uid 200); 30 Apr 2001 22:52:45 -0000 Received: (qmail 11655 invoked from network); 30 Apr 2001 22:52:44 -0000 Received: from unknown (HELO megisto-sql1.megisto.com) (63.113.114.132) by c900656-a.plstn1.sfba.home.com with SMTP; 30 Apr 2001 22:52:44 -0000 Received: by mail.megisto.com with Internet Mail Service (5.5.2650.21) id ; Mon, 30 Apr 2001 18:56:09 -0400 Message-ID: From: Phil Roberts To: "'Michael Thomas'" , Phil Roberts Cc: "'Phil Neumiller'" , seamoby@cdma-2000.org Subject: RE: [seamoby] Comments on IRTF mm problem statement Date: Mon, 30 Apr 2001 18:56:08 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-seamoby@diameter.org Precedence: bulk Hi Mike, Perhaps, but I thought investigation using host routes and routing protocols to support those was the point of this exercise? What would you suggest as an alternative? Do you just want to make sure mobile subnets are evaluated? Phil > -----Original Message----- > From: Michael Thomas [mailto:mat@cisco.com] > Sent: Monday, April 30, 2001 6:54 PM > To: Phil Roberts > Cc: 'Phil Neumiller'; seamoby@cdma-2000.org > Subject: RE: [seamoby] Comments on IRTF mm problem statement > > > > Hi Phil, > > Just as a top level comment, can we remove all > references to host routes? There's no reason why > we should limit this to /128 and /32 subnets. I > think that the exact same thing is happening with > MIP (though it's a lot murkier there because of > the changed CoA). > > Mike > > Phil Roberts writes: > > > > > Hi Phil R, > > > > Hi, > > > > I haven't answered each point by point, but I hope what > I've said covers > > most of the questions you included. > > > > > >There are a couple of seemingly unrelated problems that > > > > have lead investigators to converge on the desirability of new > > > >routing protocols to implement host routes within a > constrained area. > > > > > > The wording of the above sentence could be confusing for > MIP/SeaMoby > > > "outsiders". I suggest SOMETHINK LIKE : > > > > > > ...routing protocols that allow for a mobile host to > > > implement a limited > > > host routing table to other mobile hosts in the same > > > constrained routing > > > area. > > > > But I don't think this is what we're interested in. The > work certainly > > applies to completely fixed networks (for network recovery > of failed routers > > and links) and the problem of scaling is in the routers. > > > > > >The problem is to investigate the limits and issues > with using (a) > > > >new protocol(s) to implement host routes to facilitate > better mobile > > > >hosts and network recovery in the presence of failed links or > > > >routers. > > > > > > To be fair, you MUST add that there are perceived deficiencies > > > in using MIP all the time. These must be quantified and > qualified > > > by the IRTF. Specifically, how fast is a fast handoff, and WHEN > > > IS USING HOST ROUTES EVEN DESIRABLE? > > > > I'm not opposed to putting in something about the > limitations of MIP, but > > I'm not sure measuring MIP performance is what we want the > IRTF to do. > > Seems like one could get some MIP implementors to measure > its performance. > > What do others think? > > > > > > > > >The document is a brief statement of the problem to be > > > >investigated with lots of references to other work that > has been done > > > >already by many others in the area. > > > > > > I would reword "with lots of references .. " with "and > the references > > > to lots of prior work in this area have been included in > this draft." > > > > Good. > > > > > > > > > Many investigators in this area have converged on > > > > solutions that propose the use of host routing to > support mobility > > > > within a limited domain, effectively exposing the > mobility of end > > > > systems to the routing protocols. > > > > > > Yes, an MANET has been working on this for years. I don't think > > > that's what we want to say here Phil. What we need to do is talk > > > about is localized host routing and WHAT it means to be local, > > > i.e. how many hops, what kind of hops, how is MIP involved and > > > how does it inter-work. > > > > OK. Doesn't the following take what you're concerned > about into account? > > "Specifically how many nodes could be supported across > what kind of network > > breadth and depth at what cost of complexity in the > routers around the edge > > of such a network?" > > > > I hadn't perceived that what we wanted the IRTF to do was > come up with an > > interworking strategy between MIP and some to-be-defined > protocol. Again, > > other feedback? > > > > > If fast recovery is important, MANET has the fastest > non-looping and > > > looping (Distance vector and link state routing) algorithms > > > and protocols > > > around. Fast recovery of what Phil? The link? The MN > to AR path? > > > The MN to MN path that bypasses MIP??? > > > > What *I* have in mind is a completely fixed network with > router and link > > failures where losing the traffic for many seconds results > in a much longer > > service disruption. I'm not sure these specifics need to > be specified in > > the problem statement, but am open to suggestions from > others. One of the > > references describes this. > > > > > > > A). "due mobility" -> "due to mobility" > > Got it. > > > > > A). Why OSPF? > > > B). Why not BGP? > > It's a particular problem of link or router failure in a > local fixed domain. > > Hence OSPF. I guess I'm not willing to ask about scaling > host routes across > > domains where BGP operates just yet. > > > > > > > C). The primary issue needed is to expose the > limitations of MIP and > > > harden what we know about MIP quantitatively so ANY holes can > > > be filled with local mobility management protocols. I can > > > not emphasize > > > this enough. THIS IS THE primary REASON. The secondary REASON > > > is to investigate if host routes deployed in a limited scoped > > > way (where the > > > limitations are set by what MIP can't do) is reasonable. > > > Also, carefull > > > analysis of where the MANET boundary is also required. > > > > I guess our perceptions of what the ADs requested are > reversed. Perhaps we > > can get some clarification. > > > > Phil > > > > > > > > > > > Thanks, > > > > > > Phil Neumiller > > > > > > >