From autoconf-bounces@ietf.org Mon Dec 1 07:36:56 2008 Return-Path: X-Original-To: autoconf-archive@megatron.ietf.org Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6F2413A6AB0; Mon, 1 Dec 2008 07:36:56 -0800 (PST) X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 33E433A6AB0 for ; Mon, 1 Dec 2008 07:36:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.504 X-Spam-Level: X-Spam-Status: No, score=-0.504 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VL8nJ5CVK9+R for ; Mon, 1 Dec 2008 07:36:54 -0800 (PST) Received: from mailoutb.tno.nl (mailoutb.tno.nl [134.221.1.17]) by core3.amsl.com (Postfix) with ESMTP id 9EEAE3A6AAE for ; Mon, 1 Dec 2008 07:36:53 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.33,695,1220220000"; d="scan'208";a="3122571" Received: from ms-dt01thalia.tno.nl (HELO ms-dt01thalia.tsn.tno.nl) ([134.221.225.157]) by mailhost1b.tno.nl with ESMTP; 01 Dec 2008 16:36:48 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 1 Dec 2008 16:36:48 +0100 Message-ID: <7877C5C0B5CC894AB26113CF06CF886301238CAD@ms-dt01thalia.tsn.tno.nl> In-Reply-To: <668C2F72-E9AC-4802-97D4-2D966C929DFF@thomasclausen.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Autoconf] Crash meeting? thread-index: AclKV2r51/5j7NUbRiOMFKk4UPnjQwJbek5g References: <00a301c94a4f$9b3c6c70$d1b54550$@nl> <668C2F72-E9AC-4802-97D4-2D966C929DFF@thomasclausen.org> From: "Velt, R. (Ronald) in 't" To: Subject: Re: [Autoconf] Crash meeting? X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org Dear all, As requested by Thomas Clausen (see below), here's a short summary of the "crash meeting" called by Teco Boot. -- Date of meeting: November 19th, 2008 In attendance: Carlos Bernardos, Hasnaa Moustafa, Charles Perkins, Emmanuel Bacelli, Kenichi Mase, Shubhranshu Singh, Teco Boot, Ronald in 't Velt Goal of meeting: Discuss how to proceed with the work on a link model definition / MANET architecture description in the wake of the WG meeting of the day before. The partipants of this meeting agreed to first work on revising / extending draft-clausen-manet-linktype. The document is to describe the notions of "link", "subnet", "MANET router" and others, as understood by the Autoconf WG. Charles Perkins will lead this effort. Others will contribute and review. The document will aim to provide clarity on the meaning of these notions in the context of Autoconf, to members of the WG as well as to interested "outsiders". The attendants felt that the WG has so far failed to provide such clarity in particular to the latter group. At the same time, it was felt that approval of our architecture / link model from interested non-WG-members should not be sought indefinitely and at all cost. Work on a problem statement document should be deferred until the architecture / link model document is completed. It was decided to use the issue-tracker tool (http://tools.ietf.org/wg/autoconf) as a means for collaboratively working on the document. -- Regards, Ronald >-----Original Message----- >From: autoconf-bounces@ietf.org >[mailto:autoconf-bounces@ietf.org] On Behalf Of Thomas Heide Clausen >Sent: woensdag 19 november 2008 16:00 >To: Teco Boot >Cc: autoconf@ietf.org >Subject: Re: [Autoconf] Crash meeting? >Importance: High > >Teco, > >I will, unfortunately, not be able to attend such a meeting >after MANET, as I have to fly back immediately as the meeting >concludes. >It's unfortunate, to be sure, but I support the idea of such a >meeting 100%. > >I'd like to ensure that if it takes place, then Shubhranshu >will be there, and also that there be taken minutes which can >be posted on the mailing list such that discussions can >continue and be shared with those who're unable to attend the >"crash meeting". > >Sounds good? > >Thomas > >On Nov 19, 2008, at 15:03 PM, Teco Boot wrote: > >> I think it is important that we have a clear understanding of the >> situation, on who is doing what. And on the status of the MANET >> architecture document. >> I suggest having a short, informal and non-technical meeting. The >> outcome could be a small design team working on a new >document, to be >> released soon. >> What about a rendezvous after the MANET meeting? We can schedule >> another time and place if we want to. >> Teco. >> >> _______________________________________________ >> Autoconf mailing list >> Autoconf@ietf.org >> https://www.ietf.org/mailman/listinfo/autoconf > >_______________________________________________ >Autoconf mailing list >Autoconf@ietf.org >https://www.ietf.org/mailman/listinfo/autoconf > This e-mail and its contents are subject to the DISCLAIMER at http://www.tno.nl/disclaimer/email.html _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Mon Dec 1 07:57:45 2008 Return-Path: X-Original-To: autoconf-archive@megatron.ietf.org Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BB0DB3A6AF4; Mon, 1 Dec 2008 07:57:45 -0800 (PST) X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D58993A6AF4 for ; Mon, 1 Dec 2008 07:57:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ojsWWYDn3G3X for ; Mon, 1 Dec 2008 07:57:43 -0800 (PST) Received: from mho-01-bos.mailhop.org (mho-01-bos.mailhop.org [63.208.196.178]) by core3.amsl.com (Postfix) with ESMTP id C09963A6AA6 for ; Mon, 1 Dec 2008 07:57:43 -0800 (PST) Received: from aste-genev-bois-153-1-96-94.w86-218.abo.wanadoo.fr ([86.218.122.94] helo=[192.168.147.109]) by mho-01-bos.mailhop.org with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1L7B9X-00064J-9r; Mon, 01 Dec 2008 15:57:39 +0000 X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 86.218.122.94 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1/hUY/Q78Kv9IMVOGlYGeHk In-Reply-To: <7877C5C0B5CC894AB26113CF06CF886301238CAD@ms-dt01thalia.tsn.tno.nl> References: <00a301c94a4f$9b3c6c70$d1b54550$@nl> <668C2F72-E9AC-4802-97D4-2D966C929DFF@thomasclausen.org> <7877C5C0B5CC894AB26113CF06CF886301238CAD@ms-dt01thalia.tsn.tno.nl> Mime-Version: 1.0 (Apple Message framework v753.1) Message-Id: <35ABF80D-CA5F-4A83-BA80-5162CE5E81A6@thomasclausen.org> From: Thomas Heide Clausen Date: Mon, 1 Dec 2008 16:57:39 +0100 To: "Velt, R. (Ronald) in 't" X-Mailer: Apple Mail (2.753.1) Cc: autoconf@ietf.org Subject: Re: [Autoconf] Crash meeting? X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org Thanks, Ronald, for the minutes. Being on the way to the airport when the meeting was on, I appreciate the update. Thomas On Dec 1, 2008, at 16:36 PM, Velt, R. (Ronald) in 't wrote: > Dear all, > > As requested by Thomas Clausen (see below), here's a short summary of > the "crash meeting" called by Teco Boot. > > -- > Date of meeting: November 19th, 2008 > > In attendance: Carlos Bernardos, Hasnaa Moustafa, Charles Perkins, > Emmanuel Bacelli, Kenichi Mase, Shubhranshu Singh, Teco Boot, > Ronald in > 't Velt > > Goal of meeting: Discuss how to proceed with the work on a link model > definition / MANET architecture description in the wake of the WG > meeting of the day before. > > The partipants of this meeting agreed to first work on revising / > extending draft-clausen-manet-linktype. The document is to describe > the > notions of "link", "subnet", "MANET router" and others, as > understood by > the Autoconf WG. Charles Perkins will lead this effort. Others will > contribute and review. The document will aim to provide clarity on the > meaning of these notions in the context of Autoconf, to members of the > WG as well as to interested "outsiders". The attendants felt that > the WG > has so far failed to provide such clarity in particular to the latter > group. At the same time, it was felt that approval of our > architecture / > link model from interested non-WG-members should not be sought > indefinitely and at all cost. Work on a problem statement document > should be deferred until the architecture / link model document is > completed. > > It was decided to use the issue-tracker tool > (http://tools.ietf.org/wg/autoconf) as a means for collaboratively > working on the document. > -- > > Regards, > Ronald > >> -----Original Message----- >> From: autoconf-bounces@ietf.org >> [mailto:autoconf-bounces@ietf.org] On Behalf Of Thomas Heide Clausen >> Sent: woensdag 19 november 2008 16:00 >> To: Teco Boot >> Cc: autoconf@ietf.org >> Subject: Re: [Autoconf] Crash meeting? >> Importance: High >> >> Teco, >> >> I will, unfortunately, not be able to attend such a meeting >> after MANET, as I have to fly back immediately as the meeting >> concludes. >> It's unfortunate, to be sure, but I support the idea of such a >> meeting 100%. >> >> I'd like to ensure that if it takes place, then Shubhranshu >> will be there, and also that there be taken minutes which can >> be posted on the mailing list such that discussions can >> continue and be shared with those who're unable to attend the >> "crash meeting". >> >> Sounds good? >> >> Thomas >> >> On Nov 19, 2008, at 15:03 PM, Teco Boot wrote: >> >>> I think it is important that we have a clear understanding of the >>> situation, on who is doing what. And on the status of the MANET >>> architecture document. >>> I suggest having a short, informal and non-technical meeting. The >>> outcome could be a small design team working on a new >> document, to be >>> released soon. >>> What about a rendezvous after the MANET meeting? We can schedule >>> another time and place if we want to. >>> Teco. >>> >>> _______________________________________________ >>> Autoconf mailing list >>> Autoconf@ietf.org >>> https://www.ietf.org/mailman/listinfo/autoconf >> >> _______________________________________________ >> Autoconf mailing list >> Autoconf@ietf.org >> https://www.ietf.org/mailman/listinfo/autoconf >> > This e-mail and its contents are subject to the DISCLAIMER at > http://www.tno.nl/disclaimer/email.html > _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Mon Dec 1 08:02:14 2008 Return-Path: X-Original-To: autoconf-archive@megatron.ietf.org Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 260053A696B; Mon, 1 Dec 2008 08:02:14 -0800 (PST) X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EAACD3A696B for ; Mon, 1 Dec 2008 08:02:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A1j7qy3PKhiX for ; Mon, 1 Dec 2008 08:02:12 -0800 (PST) Received: from mho-01-bos.mailhop.org (mho-01-bos.mailhop.org [63.208.196.178]) by core3.amsl.com (Postfix) with ESMTP id F2F223A68D0 for ; Mon, 1 Dec 2008 08:02:11 -0800 (PST) Received: from aste-genev-bois-153-1-96-94.w86-218.abo.wanadoo.fr ([86.218.122.94] helo=[192.168.147.109]) by mho-01-bos.mailhop.org with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1L7BDr-0007Uq-HL; Mon, 01 Dec 2008 16:02:07 +0000 X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 86.218.122.94 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1/uUYRyEbBxqifDy96cubhf In-Reply-To: <7877C5C0B5CC894AB26113CF06CF886301238CAD@ms-dt01thalia.tsn.tno.nl> References: <00a301c94a4f$9b3c6c70$d1b54550$@nl> <668C2F72-E9AC-4802-97D4-2D966C929DFF@thomasclausen.org> <7877C5C0B5CC894AB26113CF06CF886301238CAD@ms-dt01thalia.tsn.tno.nl> Mime-Version: 1.0 (Apple Message framework v753.1) Message-Id: From: Thomas Heide Clausen Date: Mon, 1 Dec 2008 17:02:08 +0100 To: "Velt, R. (Ronald) in 't" X-Mailer: Apple Mail (2.753.1) Cc: autoconf@ietf.org Subject: Re: [Autoconf] Crash meeting? X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org Small comment, isn't the IETF-sanctioned issue-tracker URL the following: http://rt.psg.com/ ? Thomas On Dec 1, 2008, at 16:36 PM, Velt, R. (Ronald) in 't wrote: > Dear all, > > As requested by Thomas Clausen (see below), here's a short summary of > the "crash meeting" called by Teco Boot. > > -- > Date of meeting: November 19th, 2008 > > In attendance: Carlos Bernardos, Hasnaa Moustafa, Charles Perkins, > Emmanuel Bacelli, Kenichi Mase, Shubhranshu Singh, Teco Boot, > Ronald in > 't Velt > > Goal of meeting: Discuss how to proceed with the work on a link model > definition / MANET architecture description in the wake of the WG > meeting of the day before. > > The partipants of this meeting agreed to first work on revising / > extending draft-clausen-manet-linktype. The document is to describe > the > notions of "link", "subnet", "MANET router" and others, as > understood by > the Autoconf WG. Charles Perkins will lead this effort. Others will > contribute and review. The document will aim to provide clarity on the > meaning of these notions in the context of Autoconf, to members of the > WG as well as to interested "outsiders". The attendants felt that > the WG > has so far failed to provide such clarity in particular to the latter > group. At the same time, it was felt that approval of our > architecture / > link model from interested non-WG-members should not be sought > indefinitely and at all cost. Work on a problem statement document > should be deferred until the architecture / link model document is > completed. > > It was decided to use the issue-tracker tool > (http://tools.ietf.org/wg/autoconf) as a means for collaboratively > working on the document. > -- > > Regards, > Ronald > >> -----Original Message----- >> From: autoconf-bounces@ietf.org >> [mailto:autoconf-bounces@ietf.org] On Behalf Of Thomas Heide Clausen >> Sent: woensdag 19 november 2008 16:00 >> To: Teco Boot >> Cc: autoconf@ietf.org >> Subject: Re: [Autoconf] Crash meeting? >> Importance: High >> >> Teco, >> >> I will, unfortunately, not be able to attend such a meeting >> after MANET, as I have to fly back immediately as the meeting >> concludes. >> It's unfortunate, to be sure, but I support the idea of such a >> meeting 100%. >> >> I'd like to ensure that if it takes place, then Shubhranshu >> will be there, and also that there be taken minutes which can >> be posted on the mailing list such that discussions can >> continue and be shared with those who're unable to attend the >> "crash meeting". >> >> Sounds good? >> >> Thomas >> >> On Nov 19, 2008, at 15:03 PM, Teco Boot wrote: >> >>> I think it is important that we have a clear understanding of the >>> situation, on who is doing what. And on the status of the MANET >>> architecture document. >>> I suggest having a short, informal and non-technical meeting. The >>> outcome could be a small design team working on a new >> document, to be >>> released soon. >>> What about a rendezvous after the MANET meeting? We can schedule >>> another time and place if we want to. >>> Teco. >>> >>> _______________________________________________ >>> Autoconf mailing list >>> Autoconf@ietf.org >>> https://www.ietf.org/mailman/listinfo/autoconf >> >> _______________________________________________ >> Autoconf mailing list >> Autoconf@ietf.org >> https://www.ietf.org/mailman/listinfo/autoconf >> > This e-mail and its contents are subject to the DISCLAIMER at > http://www.tno.nl/disclaimer/email.html > _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Mon Dec 1 08:27:19 2008 Return-Path: X-Original-To: autoconf-archive@megatron.ietf.org Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6843F3A6961; Mon, 1 Dec 2008 08:27:19 -0800 (PST) X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E3DD73A68A9 for ; Mon, 1 Dec 2008 08:27:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.504 X-Spam-Level: X-Spam-Status: No, score=-0.504 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yBq34csozt68 for ; Mon, 1 Dec 2008 08:27:18 -0800 (PST) Received: from mailouta.tno.nl (mailouta.tno.nl [134.221.1.16]) by core3.amsl.com (Postfix) with ESMTP id 7BD883A6961 for ; Mon, 1 Dec 2008 08:27:17 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.33,695,1220220000"; d="scan'208";a="13455231" Received: from ms-dt01thalia.tno.nl (HELO ms-dt01thalia.tsn.tno.nl) ([134.221.225.157]) by mailhost1a.tno.nl with ESMTP; 01 Dec 2008 17:27:12 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 1 Dec 2008 17:27:12 +0100 Message-ID: <7877C5C0B5CC894AB26113CF06CF886301238CAE@ms-dt01thalia.tsn.tno.nl> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Autoconf] Crash meeting? thread-index: AclTziq6cNXYNFM9TwqPAu4d/3ehtQAAraPQ References: <00a301c94a4f$9b3c6c70$d1b54550$@nl> <668C2F72-E9AC-4802-97D4-2D966C929DFF@thomasclausen.org> <7877C5C0B5CC894AB26113CF06CF886301238CAD@ms-dt01thalia.tsn.tno.nl> From: "Velt, R. (Ronald) in 't" To: "Thomas Heide Clausen" Cc: autoconf@ietf.org Subject: Re: [Autoconf] Crash meeting? X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org Hi Thomas, >-----Original Message----- >From: Thomas Heide Clausen [mailto:ietf@thomasclausen.org] >Sent: maandag 1 december 2008 17:02 >To: Velt, R. (Ronald) in 't >Cc: autoconf@ietf.org; Teco Boot >Subject: Re: [Autoconf] Crash meeting? > >Small comment, isn't the IETF-sanctioned issue-tracker URL the >following: http://rt.psg.com/ ? Very likely. In any case, that URL makes a lot more sense to me than the one I provided. My lame excuse: I couldn't find "issue tracker" on the IETF tools page and then I asked a certain someone who gave me that other URL :-\ Thanks, Ronald > >Thomas > >On Dec 1, 2008, at 16:36 PM, Velt, R. (Ronald) in 't wrote: > >> Dear all, >> >> As requested by Thomas Clausen (see below), here's a short >summary of >> the "crash meeting" called by Teco Boot. >> >> -- >> Date of meeting: November 19th, 2008 >> >> In attendance: Carlos Bernardos, Hasnaa Moustafa, Charles Perkins, >> Emmanuel Bacelli, Kenichi Mase, Shubhranshu Singh, Teco Boot, Ronald >> in 't Velt >> >> Goal of meeting: Discuss how to proceed with the work on a >link model >> definition / MANET architecture description in the wake of the WG >> meeting of the day before. >> >> The partipants of this meeting agreed to first work on revising / >> extending draft-clausen-manet-linktype. The document is to describe >> the notions of "link", "subnet", "MANET router" and others, as >> understood by the Autoconf WG. Charles Perkins will lead >this effort. >> Others will contribute and review. The document will aim to provide >> clarity on the meaning of these notions in the context of >Autoconf, to >> members of the WG as well as to interested "outsiders". The >attendants >> felt that the WG has so far failed to provide such clarity in >> particular to the latter group. At the same time, it was felt that >> approval of our architecture / link model from interested >> non-WG-members should not be sought indefinitely and at all >cost. Work >> on a problem statement document should be deferred until the >> architecture / link model document is completed. >> >> It was decided to use the issue-tracker tool >> (http://tools.ietf.org/wg/autoconf) as a means for collaboratively >> working on the document. >> -- >> >> Regards, >> Ronald >> >>> -----Original Message----- >>> From: autoconf-bounces@ietf.org >>> [mailto:autoconf-bounces@ietf.org] On Behalf Of Thomas Heide Clausen >>> Sent: woensdag 19 november 2008 16:00 >>> To: Teco Boot >>> Cc: autoconf@ietf.org >>> Subject: Re: [Autoconf] Crash meeting? >>> Importance: High >>> >>> Teco, >>> >>> I will, unfortunately, not be able to attend such a meeting after >>> MANET, as I have to fly back immediately as the meeting concludes. >>> It's unfortunate, to be sure, but I support the idea of such a >>> meeting 100%. >>> >>> I'd like to ensure that if it takes place, then Shubhranshu will be >>> there, and also that there be taken minutes which can be posted on >>> the mailing list such that discussions can continue and be shared >>> with those who're unable to attend the "crash meeting". >>> >>> Sounds good? >>> >>> Thomas >>> >>> On Nov 19, 2008, at 15:03 PM, Teco Boot wrote: >>> >>>> I think it is important that we have a clear understanding of the >>>> situation, on who is doing what. And on the status of the MANET >>>> architecture document. >>>> I suggest having a short, informal and non-technical meeting. The >>>> outcome could be a small design team working on a new >>> document, to be >>>> released soon. >>>> What about a rendezvous after the MANET meeting? We can schedule >>>> another time and place if we want to. >>>> Teco. >>>> >>>> _______________________________________________ >>>> Autoconf mailing list >>>> Autoconf@ietf.org >>>> https://www.ietf.org/mailman/listinfo/autoconf >>> >>> _______________________________________________ >>> Autoconf mailing list >>> Autoconf@ietf.org >>> https://www.ietf.org/mailman/listinfo/autoconf >>> >> This e-mail and its contents are subject to the DISCLAIMER at >> http://www.tno.nl/disclaimer/email.html >> > > This e-mail and its contents are subject to the DISCLAIMER at http://www.tno.nl/disclaimer/email.html _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Mon Dec 1 10:13:32 2008 Return-Path: X-Original-To: autoconf-archive@megatron.ietf.org Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D50D33A67FF; Mon, 1 Dec 2008 10:13:32 -0800 (PST) X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0A7A63A67FF for ; Mon, 1 Dec 2008 10:13:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mfUgRY6xb+lX for ; Mon, 1 Dec 2008 10:13:30 -0800 (PST) Received: from elasmtp-kukur.atl.sa.earthlink.net (elasmtp-kukur.atl.sa.earthlink.net [209.86.89.65]) by core3.amsl.com (Postfix) with ESMTP id F11573A6B13 for ; Mon, 1 Dec 2008 10:13:29 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=qfRen/oisvLgvKdgFGQMBLWJomlxrIx2TgBmFM7QnLEd7Ou39ABnUJMU0mhwX4xK; h=Received:Message-ID:Date:From:Organization:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [75.26.137.116] (helo=[10.166.254.36]) by elasmtp-kukur.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1L7DGu-0002g0-3t; Mon, 01 Dec 2008 13:13:24 -0500 Message-ID: <49342944.3080006@earthlink.net> Date: Mon, 01 Dec 2008 10:13:24 -0800 From: "Charles E. Perkins" Organization: Wichorus Inc. User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: Thomas Heide Clausen References: <00a301c94a4f$9b3c6c70$d1b54550$@nl> <668C2F72-E9AC-4802-97D4-2D966C929DFF@thomasclausen.org> <7877C5C0B5CC894AB26113CF06CF886301238CAD@ms-dt01thalia.tsn.tno.nl> In-Reply-To: X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f52c299421dc5e16dbfac535c757ba3d4bf350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 75.26.137.116 Cc: autoconf@ietf.org Subject: Re: [Autoconf] Crash meeting? X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org Hello folks, I have been using the issue tracker for the [mext] WG. For reference, the [mext] "Issues" hyperlink leads one to the following URL: http://trac.tools.ietf.org/wg/mext/trac/report/1 The following URLs also have useful content: http://tools.ietf.org/wg/mext/ http://tools.ietf.org/wg/autoconf but I guess the "Issues" page for [autoconf] needs to be set up by the someone who is a WG chair for the group. If that does not happen, then I think the pages that are available from the other URL, http://rt.psg.com/ could be used to set up a more special-purpose issue tracker for the linktype document. It seems to me that we ought to prefer to use the http://tools.ietf.org/wg/autoconf pages, but I'll leave that decision for someone else to make. Regards, Charlie P. Thomas Heide Clausen wrote: > Small comment, isn't the IETF-sanctioned issue-tracker URL the > following: http://rt.psg.com/ ? > > Thomas > _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Tue Dec 2 03:45:52 2008 Return-Path: X-Original-To: autoconf-archive@megatron.ietf.org Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5178C3A6992; Tue, 2 Dec 2008 03:45:52 -0800 (PST) X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DF8FC3A68FC for ; Tue, 2 Dec 2008 03:45:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IAwIId+1cTmX for ; Tue, 2 Dec 2008 03:45:50 -0800 (PST) Received: from mho-01-bos.mailhop.org (mho-01-bos.mailhop.org [63.208.196.178]) by core3.amsl.com (Postfix) with ESMTP id CA3713A6992 for ; Tue, 2 Dec 2008 03:45:49 -0800 (PST) Received: from aste-genev-bois-153-1-96-94.w86-218.abo.wanadoo.fr ([86.218.122.94] helo=[192.168.147.109]) by mho-01-bos.mailhop.org with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1L7ThJ-000LEx-7J; Tue, 02 Dec 2008 11:45:45 +0000 X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 86.218.122.94 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX18/59DtQgD5/n4jpcQnPUbW In-Reply-To: <49342944.3080006@earthlink.net> References: <00a301c94a4f$9b3c6c70$d1b54550$@nl> <668C2F72-E9AC-4802-97D4-2D966C929DFF@thomasclausen.org> <7877C5C0B5CC894AB26113CF06CF886301238CAD@ms-dt01thalia.tsn.tno.nl> <49342944.3080006@earthlink.net> Mime-Version: 1.0 (Apple Message framework v753.1) Message-Id: <9E38A971-C869-4EF4-A5C2-3C5CA427B035@thomasclausen.org> From: Thomas Heide Clausen Date: Tue, 2 Dec 2008 12:45:48 +0100 To: "Charles E. Perkins" X-Mailer: Apple Mail (2.753.1) Cc: autoconf@ietf.org Subject: Re: [Autoconf] Crash meeting? X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org Charlie, Right. One comment, speaking of experience in other WGs: an issue tracker is a GREAT idea when one has well-defined issues or questions to a specific document. I have not found it particularly helpful for "deciding on an architectural approach in a nebulous space", and I would not personally be able to populate an issues tracker with "the issues that need resolving before an architecture document can hit the IESG". There's a lot of discussion that comes before that, and which we should try to have on the list -- it's quiet enough as it is, I don't think we need to invent ways of getting remaining traffic to disappear. Just one persons opinion, of course. Thomas On Dec 1, 2008, at 19:13 PM, Charles E. Perkins wrote: > > Hello folks, > > I have been using the issue tracker for the [mext] WG. > For reference, the [mext] "Issues" hyperlink leads one to > the following URL: > http://trac.tools.ietf.org/wg/mext/trac/report/1 > > The following URLs also have useful content: > http://tools.ietf.org/wg/mext/ > http://tools.ietf.org/wg/autoconf > but I guess the "Issues" page for [autoconf] needs to be > set up by the someone who is a WG chair for the group. > > If that does not happen, then I think the pages that > are available from the other URL, > http://rt.psg.com/ > could be used to set up a more special-purpose > issue tracker for the linktype document. > > It seems to me that we ought to prefer to use > the http://tools.ietf.org/wg/autoconf pages, but > I'll leave that decision for someone else to make. > > Regards, > Charlie P. > > > > Thomas Heide Clausen wrote: >> Small comment, isn't the IETF-sanctioned issue-tracker URL the >> following: http://rt.psg.com/ ? >> >> Thomas >> > _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Fri Dec 19 01:19:23 2008 Return-Path: X-Original-To: autoconf-archive@megatron.ietf.org Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7CF383A6A0D; Fri, 19 Dec 2008 01:19:23 -0800 (PST) X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 21F883A6A0D for ; Fri, 19 Dec 2008 01:19:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.886 X-Spam-Level: X-Spam-Status: No, score=-1.886 tagged_above=-999 required=5 tests=[AWL=0.090, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qTtYtA4+mfdY for ; Fri, 19 Dec 2008 01:19:21 -0800 (PST) Received: from mail-bw0-f21.google.com (mail-bw0-f21.google.com [209.85.218.21]) by core3.amsl.com (Postfix) with ESMTP id E73173A69F5 for ; Fri, 19 Dec 2008 01:19:20 -0800 (PST) Received: by bwz14 with SMTP id 14so3262082bwz.13 for ; Fri, 19 Dec 2008 01:19:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:mime-version:content-type:x-google-sender-auth; bh=EwQJjMQGV+rlisojtot4v6S9R0irlur8MhAYSjny8p4=; b=TODQychTIJ+N9SXgKd7O3P6GxjtYUSh/+fFZv5auxQrkzjH4Wb7H4xDMWoQBIjkVyO bwmA4cefB2NIlTmRzpYbkykebtAyETBgAr0/iFW/lK6OHfDd+k1ZEOWmLIAKCzBqaSIK qDz3JwhcskJBsg+2CrMCakLYZII+6CdkfwdRw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:mime-version:content-type :x-google-sender-auth; b=dT0DthG9MZWC1cCQMlcJQF/hNZ5BHi8bhzAf/qi6w+h4sLVA2baPpK0kLf2Eq1c6Hg 7mNGM638RHLkVZ78rTiOAkpIcVPVIfm7UT1Qj3rkMEUr5S8Vi83Veu0/9iDbarLdb2ij B5b79doyrBLTDJ8IS8IjxxrKxw7zhDYNSWVh4= Received: by 10.103.52.7 with SMTP id e7mr1147784muk.115.1229678352523; Fri, 19 Dec 2008 01:19:12 -0800 (PST) Received: by 10.103.248.12 with HTTP; Fri, 19 Dec 2008 01:19:12 -0800 (PST) Message-ID: Date: Fri, 19 Dec 2008 10:19:12 +0100 From: "Emmanuel Baccelli" To: autoconf@ietf.org MIME-Version: 1.0 X-Google-Sender-Auth: e5f1402d32fe8ec0 Subject: [Autoconf] aspects of multi-hop wireless communication X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0343609133==" Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org --===============0343609133== Content-Type: multipart/alternative; boundary="----=_Part_32659_1511822.1229678352512" ------=_Part_32659_1511822.1229678352512 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi all, here's a draft that aims at describing important aspects of multi-hop wireless communication, as observed over the past decade of experience with such networks. The goal of this document is to identify a consensus about this topic, and then use this to move on quicker with the working group documents. Please review it, and provide feedback as soon as possible. http://tools.ietf.org/html/draft-baccelli-multi-hop-wireless-communication-00 cheers Emmanuel ------=_Part_32659_1511822.1229678352512 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi all,

here's a draft that aims at describing important aspects of multi-hop wireless communication, as observed over the past decade of experience with such networks.

The goal of this document is to identify a consensus about this topic, and then use this to move on quicker with the working group documents.

Please review it, and provide feedback as soon as possible. 


cheers
Emmanuel
------=_Part_32659_1511822.1229678352512-- --===============0343609133== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf --===============0343609133==-- From autoconf-bounces@ietf.org Fri Dec 19 04:08:05 2008 Return-Path: X-Original-To: autoconf-archive@megatron.ietf.org Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D1053A6978; Fri, 19 Dec 2008 04:08:05 -0800 (PST) X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 252E93A6978 for ; Fri, 19 Dec 2008 04:08:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.523 X-Spam-Level: X-Spam-Status: No, score=-6.523 tagged_above=-999 required=5 tests=[AWL=0.076, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oZIsY9TikfD1 for ; Fri, 19 Dec 2008 04:08:03 -0800 (PST) Received: from mail119.messagelabs.com (mail119.messagelabs.com [216.82.241.195]) by core3.amsl.com (Postfix) with SMTP id F24F73A68A2 for ; Fri, 19 Dec 2008 04:08:02 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-10.tower-119.messagelabs.com!1229688446!34185858!1 X-StarScan-Version: 6.0.0; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 32302 invoked from network); 19 Dec 2008 12:07:26 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-10.tower-119.messagelabs.com with SMTP; 19 Dec 2008 12:07:26 -0000 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id mBJC7Qq1017306; Fri, 19 Dec 2008 05:07:26 -0700 (MST) Received: from il06vts04.mot.com (il06vts04.mot.com [129.188.137.144]) by il06exr04.mot.com (8.13.1/Vontu) with SMTP id mBJC7P2s027812; Fri, 19 Dec 2008 06:07:25 -0600 (CST) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by il06exr04.mot.com (8.13.1/8.13.0) with ESMTP id mBJC7OmO027807; Fri, 19 Dec 2008 06:07:25 -0600 (CST) Message-ID: <494B8E7C.7000505@gmail.com> Date: Fri, 19 Dec 2008 13:07:24 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: Emmanuel Baccelli References: In-Reply-To: X-Antivirus: avast! (VPS 081218-0, 18/12/2008), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected Cc: autoconf@ietf.org Subject: Re: [Autoconf] aspects of multi-hop wireless communication X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org Thanks for the description. I think it's good to lay out our understandings of terminology to clarify and eventually converge. It's a short comprehensive draft covering a few essential points recently discussed on the list about particularities of wireless communications. > In this document, we consider a multi-hop ad hoc wireless network to > be a collection of devices that all have radio transceivers using > the same physical and medium access protocols. All are configured to > provide store-and-forward functionality on top of these protocols, > as needed to enable communications; consequently, they can be > classified as routers in the resulting wireless network. It would be good to clarify that the "top" mentioned above is actually the networking IP layer, decrementing TTL/HopLimit. Otherwise one may read the "routers" mentioned above as "MAC bridges". Or you didn't mean that "top" to be the IP layer? I continue assuming you meant the IP layer. > First, there is no guarantee that a router C within S can, > symmetrically, send IP packets directly to router A. In other words, > even though C can "hear" packets from node A (since it is a member of > set S), there is no guarantee that A can "hear" packets from node C. > Thus, multi-hop ad hoc wireless communications may be "asymmetric". > Such asymmetry is often experienced on multi-hop ad hoc wireless > networks, due to well-known properties of wireless communication. Sorry, could one mention why? What's the example of this? I haven't ever experienced this problem with wifi. I may have noticed a slight difference in bandwidth upstream vs downstream but not a complete cut of communication in one direction while the other direction was ok. What are the well-known properties of wireless communication making this asymmetric behaviour (communication works in one direction but not in the other). > Second, there is no guarantee that two given routers within S can > directly communicate with one another. In other words, even though > two routers R1 and R2 can both "hear" packets from router A, there is > no guarantee that R1 can hear packets from R2, and there is likewise > no guarantee that R2 can hear packets from R1. Thus, multi-hop ad > hoc wireless communications may be "non-transitive". It is of paramount important for me to understand what is meant by "hearing". Is it MAC level or IP level. It is very possible for R1 to not receive from R2 (although the intermediary A receives from both) and this does not represent a problem at all, even less a particular problem of wireless communications. When R1 doesn't hear from R2 it's because it's too "far" from it; the solution could be A to bridge R1 to R2. It is the same problem in wired communication. > Lastly, there is no guarantee that, as a set, S is at all stable. The > membership of set S may in fact change at any rate, any time. One would however differentiate this dynamic nature from a completely disconnected on-off behaviour. One would set the limits of connectivity. If we don't have limits for connectivity then we can't even talk PHY (let alone MAC, Networking, Transport and Application). If it's needed, I could help contribute text defining what movement may mean in terms of fixed points, subnets, TTL/HoLimit and of IP address change. I could also contribute text about radio communication being the same through the air as through copper or fiber, as seen from the MAC layer. Just some thoughts, Alex ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Fri Dec 19 04:10:56 2008 Return-Path: X-Original-To: autoconf-archive@megatron.ietf.org Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CCA033A687B; Fri, 19 Dec 2008 04:10:56 -0800 (PST) X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 966453A687B for ; Fri, 19 Dec 2008 04:10:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.658 X-Spam-Level: X-Spam-Status: No, score=-1.658 tagged_above=-999 required=5 tests=[AWL=0.388, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eR7AYlD8RpBN for ; Fri, 19 Dec 2008 04:10:50 -0800 (PST) Received: from hpsmtp-eml15.kpnxchange.com (hpsmtp-eml15.KPNXCHANGE.COM [213.75.38.115]) by core3.amsl.com (Postfix) with ESMTP id 4D60D3A68A2 for ; Fri, 19 Dec 2008 04:10:50 -0800 (PST) Received: from cpsmtp-eml101.kpnxchange.com ([213.75.84.101]) by hpsmtp-eml15.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 19 Dec 2008 13:08:51 +0100 Received: from M90Teco ([86.83.9.22]) by cpsmtp-eml101.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 19 Dec 2008 13:08:51 +0100 From: "Teco Boot" To: "'Emmanuel Baccelli'" , References: In-Reply-To: Date: Fri, 19 Dec 2008 13:08:48 +0100 Message-ID: <005101c961d2$8c7f4ff0$a57defd0$@nl> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AclhuuDL8V9a4x81S4iEDg1TVsZyCwADq79Q Content-Language: nl X-OriginalArrivalTime: 19 Dec 2008 12:08:51.0949 (UTC) FILETIME=[8E8E59D0:01C961D2] Cc: autoconf@ietf.org Subject: Re: [Autoconf] aspects of multi-hop wireless communication X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org Hi Emmanual and Charles, Thanks for the efforts. = I like the compactness of the draft. Maybe mention alternate terminology =93uni-directional=94 for "asymmetric" ? As discussed before, asymmetry is also used for different link qualities for A to B and B to A, where A and B have a symmetric relation. > - We may say that router B is a neighbor of router A. In this > terminology, there is no guarantee that router A is a neighbor of > router B. In this case, the neighbor table of router B would list router A. So I say router A is neighbor of router B, and there is no guarantee that router B is a neighbor of router A. Or I say the relation between neighbors is symmetric, but some neighbors = may not be aware of this. Regards, Teco =3D=3D=3D Van: autoconf-bounces@ietf.org [mailto:autoconf-bounces@ietf.org] Namens Emmanuel Baccelli Verzonden: vrijdag 19 december 2008 10:19 Aan: autoconf@ietf.org Onderwerp: [Autoconf] aspects of multi-hop wireless communication Hi all, here's a draft that aims at describing important aspects of multi-hop wireless communication, as observed over the past decade of experience with such networks. The goal of this document is to identify a consensus about this topic, and then use this to move on quicker with the working group documents. Please review it, and provide feedback as soon as possible.=A0 http://tools.ietf.org/html/draft-baccelli-multi-hop-wireless-communication-0 0 cheers Emmanuel _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Fri Dec 19 04:12:08 2008 Return-Path: X-Original-To: autoconf-archive@megatron.ietf.org Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 25E343A687B; Fri, 19 Dec 2008 04:12:08 -0800 (PST) X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 998923A687B for ; Fri, 19 Dec 2008 04:12:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.522 X-Spam-Level: X-Spam-Status: No, score=-6.522 tagged_above=-999 required=5 tests=[AWL=0.077, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2iKToodmzXNk for ; Fri, 19 Dec 2008 04:12:06 -0800 (PST) Received: from smtp2.bae.co.uk (smtp2.bae.co.uk [20.133.0.12]) by core3.amsl.com (Postfix) with ESMTP id 490D03A6829 for ; Fri, 19 Dec 2008 04:12:06 -0800 (PST) Received: from smtpb.greenlnk.net (smtpb.greenlnk.net [10.15.160.219]) by smtp2.bae.co.uk (Switch-3.1.10/Switch-3.1.10) with ESMTP id mBJCBsxk013749 for ; Fri, 19 Dec 2008 12:11:54 GMT Received: from glkas0002.GREENLNK.NET (glkas0002.greenlnk.net [10.15.184.52]) by smtpb.greenlnk.net (Switch-3.1.9/Switch-3.1.9) with ESMTP id mBJCBsgO006224 for ; Fri, 19 Dec 2008 12:11:54 GMT Received: from glkms1101.GREENLNK.NET ([10.15.184.109]) by glkas0002.GREENLNK.NET with InterScan Message Security Suite; Fri, 19 Dec 2008 12:11:53 -0000 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1101.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.2499); Fri, 19 Dec 2008 12:11:53 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 19 Dec 2008 12:11:54 -0000 Message-ID: In-Reply-To: <494B8E7C.7000505@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Autoconf] aspects of multi-hop wireless communication Thread-Index: Aclh0nIccwacphKNSaWo6FoyRfcPggAAEEcg References: <494B8E7C.7000505@gmail.com> From: "Dearlove, Christopher (UK)" To: "Alexandru Petrescu" , "Emmanuel Baccelli" X-OriginalArrivalTime: 19 Dec 2008 12:11:53.0292 (UTC) FILETIME=[FAA518C0:01C961D2] Cc: autoconf@ietf.org Subject: Re: [Autoconf] aspects of multi-hop wireless communication X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org >> First, there is no guarantee that a router C within S can, >> symmetrically, send IP packets directly to router A. In other words, >> even though C can "hear" packets from node A (since it is a member of >> set S), there is no guarantee that A can "hear" packets from node C. > Sorry, could one mention why? What's the example of this? The simplest example (but by no means the only) is different power levels transmitted by A and C. ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Fri Dec 19 04:14:58 2008 Return-Path: X-Original-To: autoconf-archive@megatron.ietf.org Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5CBA73A6978; Fri, 19 Dec 2008 04:14:58 -0800 (PST) X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2644D3A6978 for ; Fri, 19 Dec 2008 04:14:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.984 X-Spam-Level: X-Spam-Status: No, score=-5.984 tagged_above=-999 required=5 tests=[AWL=0.615, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kUz-q7RiDX6c for ; Fri, 19 Dec 2008 04:14:56 -0800 (PST) Received: from mail119.messagelabs.com (mail119.messagelabs.com [216.82.241.195]) by core3.amsl.com (Postfix) with SMTP id B4AA83A68A2 for ; Fri, 19 Dec 2008 04:14:55 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-15.tower-119.messagelabs.com!1229688887!24906753!1 X-StarScan-Version: 6.0.0; banners=.,-,- X-Originating-IP: [136.182.1.14] Received: (qmail 19493 invoked from network); 19 Dec 2008 12:14:47 -0000 Received: from unknown (HELO motgate4.mot.com) (136.182.1.14) by server-15.tower-119.messagelabs.com with SMTP; 19 Dec 2008 12:14:47 -0000 Received: from il27exr04.cig.mot.com (il27exr04.mot.com [10.17.196.73]) by motgate4.mot.com (8.12.11/Motorola) with ESMTP id mBJCElJj008763; Fri, 19 Dec 2008 05:14:47 -0700 (MST) Received: from az10vts04.mot.com (il27vts04.cig.mot.com [10.17.196.88]) by il27exr04.cig.mot.com (8.13.1/Vontu) with SMTP id mBJCEkjC002817; Fri, 19 Dec 2008 06:14:46 -0600 (CST) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by il27exr04.cig.mot.com (8.13.1/8.13.0) with ESMTP id mBJCEjwE002804; Fri, 19 Dec 2008 06:14:45 -0600 (CST) Message-ID: <494B9035.40405@gmail.com> Date: Fri, 19 Dec 2008 13:14:45 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: "Dearlove, Christopher (UK)" References: <494B8E7C.7000505@gmail.com> In-Reply-To: X-Antivirus: avast! (VPS 081218-0, 18/12/2008), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected Cc: autoconf@ietf.org, Emmanuel Baccelli Subject: Re: [Autoconf] aspects of multi-hop wireless communication X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org Dearlove, Christopher (UK) wrote: >>> First, there is no guarantee that a router C within S can, >>> symmetrically, send IP packets directly to router A. In other words, >>> even though C can "hear" packets from node A (since it is a member of >>> set S), there is no guarantee that A can "hear" packets from node C. > >> Sorry, could one mention why? What's the example of this? > > The simplest example (but by no means the only) is different power > levels transmitted by A and C. And isn't it the same for wired communications ? (and would a potential solution to this to have the same power levels transmitted by A and C?) Alex > > ******************************************************************** > This email and any attachments are confidential to the intended > recipient and may also be privileged. If you are not the intended > recipient please delete it from your system and notify the sender. > You should not copy it or use it for any purpose nor disclose or > distribute its contents to any other person. > ******************************************************************** > > ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Fri Dec 19 04:17:50 2008 Return-Path: X-Original-To: autoconf-archive@megatron.ietf.org Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 90C723A6829; Fri, 19 Dec 2008 04:17:50 -0800 (PST) X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EFEEA3A68F4 for ; Fri, 19 Dec 2008 04:17:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.527 X-Spam-Level: X-Spam-Status: No, score=-6.527 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qTHcNrLeZExe for ; Fri, 19 Dec 2008 04:17:48 -0800 (PST) Received: from smtp1.bae.co.uk (smtp1.bae.co.uk [20.133.0.11]) by core3.amsl.com (Postfix) with ESMTP id E79723A6829 for ; Fri, 19 Dec 2008 04:17:47 -0800 (PST) Received: from smtpc.greenlnk.net (smtpc.greenlnk.net [10.15.160.220]) by smtp1.bae.co.uk (Switch-3.1.10/Switch-3.1.10) with ESMTP id mBJCHaNU005450 for ; Fri, 19 Dec 2008 12:17:36 GMT Received: from glkas0002.GREENLNK.NET (glkas0002.greenlnk.net [10.15.184.52]) by smtpc.greenlnk.net (Switch-3.1.9/Switch-3.1.9) with ESMTP id mBJCHadj003307 for ; Fri, 19 Dec 2008 12:17:36 GMT Received: from glkms1101.GREENLNK.NET ([10.15.184.109]) by glkas0002.GREENLNK.NET with InterScan Message Security Suite; Fri, 19 Dec 2008 12:17:36 -0000 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1101.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.2499); Fri, 19 Dec 2008 12:17:36 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 19 Dec 2008 12:17:38 -0000 Message-ID: In-Reply-To: <494B9035.40405@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Autoconf] aspects of multi-hop wireless communication Thread-Index: Aclh02j89Y/dAjGzQ/CVflxMq4ZcWQAABMtQ References: <494B8E7C.7000505@gmail.com> <494B9035.40405@gmail.com> From: "Dearlove, Christopher (UK)" To: "Alexandru Petrescu" X-OriginalArrivalTime: 19 Dec 2008 12:17:36.0399 (UTC) FILETIME=[C72711F0:01C961D3] Cc: autoconf@ietf.org, Emmanuel Baccelli Subject: Re: [Autoconf] aspects of multi-hop wireless communication X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org > (and would a potential solution to this to have the same power levels > transmitted by A and C?) This may not be possible. ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Fri Dec 19 04:19:44 2008 Return-Path: X-Original-To: autoconf-archive@megatron.ietf.org Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BE0C43A68E3; Fri, 19 Dec 2008 04:19:44 -0800 (PST) X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3C68B3A6829 for ; Fri, 19 Dec 2008 04:19:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.677 X-Spam-Level: X-Spam-Status: No, score=-1.677 tagged_above=-999 required=5 tests=[AWL=0.369, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fwTqynnEJZVH for ; Fri, 19 Dec 2008 04:19:42 -0800 (PST) Received: from hpsmtp-eml19.kpnxchange.com (hpsmtp-eml19.KPNXCHANGE.COM [213.75.38.84]) by core3.amsl.com (Postfix) with ESMTP id 51E653A6819 for ; Fri, 19 Dec 2008 04:19:42 -0800 (PST) Received: from cpsmtp-eml103.kpnxchange.com ([213.75.84.103]) by hpsmtp-eml19.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 19 Dec 2008 13:19:34 +0100 Received: from M90Teco ([86.83.9.22]) by cpsmtp-eml103.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 19 Dec 2008 13:19:33 +0100 From: "Teco Boot" To: "'Alexandru Petrescu'" References: <494B8E7C.7000505@gmail.com> <494B9035.40405@gmail.com> In-Reply-To: <494B9035.40405@gmail.com> Date: Fri, 19 Dec 2008 13:19:30 +0100 Message-ID: <005701c961d4$0b1fbc40$215f34c0$@nl> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Aclh02XCpVP2uuBxQcqhmW3P7uu20wAAFSQQ Content-Language: nl X-OriginalArrivalTime: 19 Dec 2008 12:19:33.0458 (UTC) FILETIME=[0CECDB20:01C961D4] Cc: autoconf@ietf.org, 'Emmanuel Baccelli' Subject: Re: [Autoconf] aspects of multi-hop wireless communication X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org |>>> First, there is no guarantee that a router C within S can, |>>> symmetrically, send IP packets directly to router A. In other words, |>>> even though C can "hear" packets from node A (since it is a member |of |>>> set S), there is no guarantee that A can "hear" packets from node C. |> |>> Sorry, could one mention why? What's the example of this? |> |> The simplest example (but by no means the only) is different power |> levels transmitted by A and C. | |And isn't it the same for wired communications ? (and would a potential |solution to this to have the same power levels transmitted by A and C?) One other reason is noise levels. Alex, if you can provide a noise suppression device, please send me one. Teco. _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Fri Dec 19 04:20:16 2008 Return-Path: X-Original-To: autoconf-archive@megatron.ietf.org Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0F1753A68A2; Fri, 19 Dec 2008 04:20:16 -0800 (PST) X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5356A3A6829 for ; Fri, 19 Dec 2008 04:20:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.028 X-Spam-Level: X-Spam-Status: No, score=-6.028 tagged_above=-999 required=5 tests=[AWL=0.571, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BHZxxf7bZGnb for ; Fri, 19 Dec 2008 04:20:13 -0800 (PST) Received: from mail119.messagelabs.com (mail119.messagelabs.com [216.82.241.195]) by core3.amsl.com (Postfix) with SMTP id 75B343A68E3 for ; Fri, 19 Dec 2008 04:20:13 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-10.tower-119.messagelabs.com!1229689205!34186474!1 X-StarScan-Version: 6.0.0; banners=.,-,- X-Originating-IP: [136.182.1.12] Received: (qmail 6774 invoked from network); 19 Dec 2008 12:20:05 -0000 Received: from unknown (HELO motgate2.mot.com) (136.182.1.12) by server-10.tower-119.messagelabs.com with SMTP; 19 Dec 2008 12:20:05 -0000 Received: from il27exr02.cig.mot.com (il27exr02.mot.com [10.17.196.71]) by motgate2.mot.com (8.12.11/Motorola) with ESMTP id mBJCK5q9019524; Fri, 19 Dec 2008 05:20:05 -0700 (MST) Received: from az10vts04.mot.com (il27vts04.cig.mot.com [10.17.196.88]) by il27exr02.cig.mot.com (8.13.1/Vontu) with SMTP id mBJCK4aM011774; Fri, 19 Dec 2008 06:20:04 -0600 (CST) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by il27exr02.cig.mot.com (8.13.1/8.13.0) with ESMTP id mBJCK3vd011758; Fri, 19 Dec 2008 06:20:04 -0600 (CST) Message-ID: <494B9173.9050901@gmail.com> Date: Fri, 19 Dec 2008 13:20:03 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: "Dearlove, Christopher (UK)" References: <494B8E7C.7000505@gmail.com> <494B9035.40405@gmail.com> In-Reply-To: X-Antivirus: avast! (VPS 081218-0, 18/12/2008), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected Cc: autoconf@ietf.org, Emmanuel Baccelli Subject: Re: [Autoconf] aspects of multi-hop wireless communication X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org Dearlove, Christopher (UK) wrote: >> (and would a potential solution to this to have the same power levels >> transmitted by A and C?) > > This may not be possible. Thinking about which type of existing IP solutions may accommodate this... maybe SMTP? (store and forward). Not sure what you mean. Alex ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Fri Dec 19 04:21:11 2008 Return-Path: X-Original-To: autoconf-archive@megatron.ietf.org Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 40AD83A68E3; Fri, 19 Dec 2008 04:21:11 -0800 (PST) X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EC2173A68E3 for ; Fri, 19 Dec 2008 04:21:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.066 X-Spam-Level: X-Spam-Status: No, score=-6.066 tagged_above=-999 required=5 tests=[AWL=0.533, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xb5oJIlvc8o6 for ; Fri, 19 Dec 2008 04:21:10 -0800 (PST) Received: from mail128.messagelabs.com (mail128.messagelabs.com [216.82.250.131]) by core3.amsl.com (Postfix) with SMTP id 2F65D3A6829 for ; Fri, 19 Dec 2008 04:21:10 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-12.tower-128.messagelabs.com!1229689261!15747655!1 X-StarScan-Version: 6.0.0; banners=.,-,- X-Originating-IP: [136.182.1.13] Received: (qmail 17933 invoked from network); 19 Dec 2008 12:21:01 -0000 Received: from unknown (HELO motgate3.mot.com) (136.182.1.13) by server-12.tower-128.messagelabs.com with SMTP; 19 Dec 2008 12:21:01 -0000 Received: from il27exr02.cig.mot.com (il27exr02.mot.com [10.17.196.71]) by motgate3.mot.com (8.12.11/Motorola) with ESMTP id mBJCKu4X026839; Fri, 19 Dec 2008 05:21:01 -0700 (MST) Received: from az10vts04.mot.com (il27vts04.cig.mot.com [10.17.196.88]) by il27exr02.cig.mot.com (8.13.1/Vontu) with SMTP id mBJCKtc7012138; Fri, 19 Dec 2008 06:20:55 -0600 (CST) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by il27exr02.cig.mot.com (8.13.1/8.13.0) with ESMTP id mBJCKseC012124; Fri, 19 Dec 2008 06:20:54 -0600 (CST) Message-ID: <494B91A6.3080200@gmail.com> Date: Fri, 19 Dec 2008 13:20:54 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: Teco Boot References: <494B8E7C.7000505@gmail.com> <494B9035.40405@gmail.com> <005701c961d4$0b1fbc40$215f34c0$@nl> In-Reply-To: <005701c961d4$0b1fbc40$215f34c0$@nl> X-Antivirus: avast! (VPS 081218-0, 18/12/2008), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected Cc: autoconf@ietf.org, 'Emmanuel Baccelli' Subject: Re: [Autoconf] aspects of multi-hop wireless communication X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org Teco Boot wrote: > |>>> First, there is no guarantee that a router C within S can, > |>>> symmetrically, send IP packets directly to router A. In other words, > |>>> even though C can "hear" packets from node A (since it is a member > |of > |>>> set S), there is no guarantee that A can "hear" packets from node C. > |> > |>> Sorry, could one mention why? What's the example of this? > |> > |> The simplest example (but by no means the only) is different power > |> levels transmitted by A and C. > | > |And isn't it the same for wired communications ? (and would a potential > |solution to this to have the same power levels transmitted by A and C?) > > One other reason is noise levels. > > Alex, if you can provide a noise suppression device, please send me one. There's noise in the wires as well and gets supressed by PHY and MAC. Not sure whatkind of solutions you think are designable. Alex > > Teco. > > > ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Fri Dec 19 04:32:42 2008 Return-Path: X-Original-To: autoconf-archive@megatron.ietf.org Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 83ACF3A6848; Fri, 19 Dec 2008 04:32:42 -0800 (PST) X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B71683A68FD for ; Fri, 19 Dec 2008 04:32:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.531 X-Spam-Level: X-Spam-Status: No, score=-6.531 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uoy2QOLIOAtn for ; Fri, 19 Dec 2008 04:32:41 -0800 (PST) Received: from smtp2.bae.co.uk (smtp2.bae.co.uk [20.133.0.12]) by core3.amsl.com (Postfix) with ESMTP id B4CD83A68E5 for ; Fri, 19 Dec 2008 04:32:40 -0800 (PST) Received: from smtpb.greenlnk.net (smtpb.greenlnk.net [10.15.160.219]) by smtp2.bae.co.uk (Switch-3.1.10/Switch-3.1.10) with ESMTP id mBJCWV3m021619 for ; Fri, 19 Dec 2008 12:32:31 GMT Received: from glkas0002.GREENLNK.NET (glkas0002.greenlnk.net [10.15.184.52]) by smtpb.greenlnk.net (Switch-3.1.9/Switch-3.1.9) with ESMTP id mBJCWV8j017644 for ; Fri, 19 Dec 2008 12:32:31 GMT Received: from glkms1101.GREENLNK.NET ([10.15.184.109]) by glkas0002.GREENLNK.NET with InterScan Message Security Suite; Fri, 19 Dec 2008 12:32:31 -0000 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1101.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.2499); Fri, 19 Dec 2008 12:32:30 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 19 Dec 2008 12:32:04 -0000 Message-ID: In-Reply-To: <494B91A6.3080200@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Autoconf] aspects of multi-hop wireless communication Thread-Index: Aclh1EpI3Uh9/rALSyWG4Bk1qHqj5AAAJljw References: <494B8E7C.7000505@gmail.com> <494B9035.40405@gmail.com> <005701c961d4$0b1fbc40$215f34c0$@nl> <494B91A6.3080200@gmail.com> From: "Dearlove, Christopher (UK)" To: "Alexandru Petrescu" , "Teco Boot" X-OriginalArrivalTime: 19 Dec 2008 12:32:30.0628 (UTC) FILETIME=[DC279640:01C961D5] Cc: autoconf@ietf.org, Emmanuel Baccelli Subject: Re: [Autoconf] aspects of multi-hop wireless communication X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org > There's noise in the wires as well and gets supressed by PHY and MAC. PHY layers, especially in radio, are not magic noise suppressors. I'm going to spell this one out once, then give up and suggest any elementary text on radio. If I put a loud noise source right next to C, it will mess up C's reception. But A, who is much more distant from the noise, won't care. And before you suggest avoiding noise sources, let's just say they range from things in the environment (inclusing man made things) that are difficult to avoid, to people doing this deliberately. And note that different power levels, and different noise environments are still not the only reasons for asymmetry. But either one is sufficient to make it happen. ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Fri Dec 19 05:04:58 2008 Return-Path: X-Original-To: autoconf-archive@megatron.ietf.org Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AE3A43A687E; Fri, 19 Dec 2008 05:04:58 -0800 (PST) X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C7D023A6830 for ; Fri, 19 Dec 2008 05:04:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.894 X-Spam-Level: X-Spam-Status: No, score=-1.894 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bbvNtN8WlOYp for ; Fri, 19 Dec 2008 05:04:55 -0800 (PST) Received: from mail-bw0-f21.google.com (mail-bw0-f21.google.com [209.85.218.21]) by core3.amsl.com (Postfix) with ESMTP id 0A2CD3A67D1 for ; Fri, 19 Dec 2008 05:04:54 -0800 (PST) Received: by bwz14 with SMTP id 14so3574823bwz.13 for ; Fri, 19 Dec 2008 05:04:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:in-reply-to:mime-version:content-type:references :x-google-sender-auth; bh=namIDCEyKKjCR+f0zaJ1AiAPGDiGZovlh2eQDvIpvLk=; b=f+Lv+QbDhXSuY6kbFY7s2qhQWRshLyk6dahfLbkW/IhTAAL6RXCWrN+pv89mWSXhUg Qw6EAMKbTT+YhQm6GBLG0Bwc7vzznd4xIOSwhKgVK2aVM3zDDMCfASAwnK4o3TOgzCIE tbAqM/TYOuKO+3/rWgx/jVtGslMUNY0ykXTsI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:in-reply-to:mime-version :content-type:references:x-google-sender-auth; b=W4yXHnB48TJXiCLyzvslXMz3Af7LneuMr2ENkq/MmN8nth3W3y2bo1sJeDb47kbNKu ozCuGVViA+JJ5iGdIw2blLAG2hSexrJPFxkpy26h1LEMgqV/YJsNoxV3jAHuIxyszn+N gkBmhaAKC6bXDAaQrQjNxMvsksqV3kdLN8m28= Received: by 10.103.238.4 with SMTP id p4mr1224542mur.68.1229691886138; Fri, 19 Dec 2008 05:04:46 -0800 (PST) Received: by 10.103.248.12 with HTTP; Fri, 19 Dec 2008 05:04:46 -0800 (PST) Message-ID: Date: Fri, 19 Dec 2008 14:04:46 +0100 From: "Emmanuel Baccelli" To: autoconf@ietf.org In-Reply-To: <494B8E7C.7000505@gmail.com> MIME-Version: 1.0 References: <494B8E7C.7000505@gmail.com> X-Google-Sender-Auth: 2c49dc535f03c88d Subject: Re: [Autoconf] aspects of multi-hop wireless communication X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0178462753==" Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org --===============0178462753== Content-Type: multipart/alternative; boundary="----=_Part_34507_10257452.1229691886134" ------=_Part_34507_10257452.1229691886134 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Thanks for your feedback Alex, On Fri, Dec 19, 2008 at 1:07 PM, Alexandru Petrescu < alexandru.petrescu@gmail.com> wrote: > Thanks for the description. I think it's good to lay out our > understandings of terminology to clarify and eventually converge. > > It's a short comprehensive draft covering a few essential points recently > discussed on the list about particularities of wireless communications. > > In this document, we consider a multi-hop ad hoc wireless network to >> be a collection of devices that all have radio transceivers using >> the same physical and medium access protocols. All are configured to >> provide store-and-forward functionality on top of these protocols, >> as needed to enable communications; consequently, they can be classified >> as routers in the resulting wireless network. >> > > It would be good to clarify that the "top" mentioned above is actually > the networking IP layer, decrementing TTL/HopLimit. Otherwise one may > read the "routers" mentioned above as "MAC bridges". > > Or you didn't mean that "top" to be the IP layer? > I guess that in the context of the IETF, yes. We should spell this out in -01. > > I continue assuming you meant the IP layer. > > First, there is no guarantee that a router C within S can, symmetrically, >> send IP packets directly to router A. In other words, even though C can >> "hear" packets from node A (since it is a member of >> set S), there is no guarantee that A can "hear" packets from node C. >> Thus, multi-hop ad hoc wireless communications may be "asymmetric". Such >> asymmetry is often experienced on multi-hop ad hoc wireless networks, due to >> well-known properties of wireless communication. >> > > Sorry, could one mention why? What's the example of this? I haven't > ever experienced this problem with wifi. I may have noticed a slight > difference in bandwidth upstream vs downstream but not a complete cut of > communication in one direction while the other direction was ok. > I have nothing to add to what Chris replied to that ;) > > What are the well-known properties of wireless communication making this > asymmetric behaviour (communication works in one direction but not in > the other). > > Second, there is no guarantee that two given routers within S can directly >> communicate with one another. In other words, even though two routers R1 >> and R2 can both "hear" packets from router A, there is >> no guarantee that R1 can hear packets from R2, and there is likewise >> no guarantee that R2 can hear packets from R1. Thus, multi-hop ad hoc >> wireless communications may be "non-transitive". >> > > It is of paramount important for me to understand what is meant by > "hearing". Is it MAC level or IP level. > > It is very possible for R1 to not receive from R2 (although the > intermediary A receives from both) and this does not represent a problem > at all, even less a particular problem of wireless communications. When > R1 doesn't hear from R2 it's because it's too "far" from it; the > solution could be A to bridge R1 to R2. It is the same problem in wired > communication. Actually this is out of the question because, as stated in the previous paragraph in the draft, there is no guarantee that A can hear either R1, or R2... (all we know is that R1 and R2 can hear A). > > Lastly, there is no guarantee that, as a set, S is at all stable. The >> membership of set S may in fact change at any rate, any time. >> > > One would however differentiate this dynamic nature from a completely > disconnected on-off behaviour. One would set the limits of > connectivity. If we don't have limits for connectivity then we can't > even talk PHY (let alone MAC, Networking, Transport and Application). > > If it's needed, I could help contribute text defining what movement may > mean in terms of fixed points, subnets, TTL/HoLimit and of IP address > change. I could also contribute text about radio communication being > the same through the air as through copper or fiber, as seen from the > MAC layer. > Thanks. But I think this is not in scope for this document. The goal of this document is simply to describe what was experienced over the years on multi-hop wireless networks in terms of communication characteristics. Such "conclusions", based on the characteristics described in this draft, should go in a separate document, in my mind. Emmanuel ------=_Part_34507_10257452.1229691886134 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Thanks for your feedback Alex,


On Fri, Dec 19, 2008 at 1:07 PM, Alexandru Petrescu <alexandru.petrescu@gmail.com> wrote:
Thanks for the description.  I think it's good to lay out our
understandings of terminology to clarify and eventually converge.

It's a short comprehensive draft covering a few essential points recently discussed on the list about particularities of wireless communications.

In this document, we consider a multi-hop ad hoc wireless network to
 be a collection of devices that all have radio transceivers using
the same physical and medium access protocols.  All are configured to
 provide store-and-forward functionality on top of these protocols,
as needed to enable communications; consequently, they can be classified as routers in the resulting wireless network.

It would be good to clarify that the "top" mentioned above is actually
the networking IP layer, decrementing TTL/HopLimit.  Otherwise one may
read the "routers" mentioned above as "MAC bridges".

Or you didn't mean that "top" to be the IP layer?


I guess that in the context of the IETF, yes. We should spell this out in -01.

 

I continue assuming you meant the IP layer.

First, there is no guarantee that a router C within S can, symmetrically, send IP packets directly to router A. In other words, even though C can "hear" packets from node A (since it is a member of
 set S), there is no guarantee that A can "hear" packets from node C.
 Thus, multi-hop ad hoc wireless communications may be "asymmetric". Such asymmetry is often experienced on multi-hop ad hoc wireless networks, due to well-known properties of wireless communication.

Sorry, could one mention why?  What's the example of this?  I haven't
ever experienced this problem with wifi.  I may have noticed a slight
difference in bandwidth upstream vs downstream but not a complete cut of
communication in one direction while the other direction was ok.


I have nothing to add to what Chris replied to that ;)

 

What are the well-known properties of wireless communication making this
asymmetric behaviour (communication works in one direction but not in
the other).

Second, there is no guarantee that two given routers within S can directly communicate with one another.  In other words, even though two routers R1 and R2 can both "hear" packets from router A, there is
 no guarantee that R1 can hear packets from R2, and there is likewise
 no guarantee that R2 can hear packets from R1.  Thus, multi-hop ad hoc wireless communications may be "non-transitive".

It is of paramount important for me to understand what is meant by
"hearing".  Is it MAC level or IP level.

It is very possible for R1 to not receive from R2 (although the
intermediary A receives from both) and this does not represent a problem
at all, even less a particular problem of wireless communications.  When
R1 doesn't hear from R2 it's because it's too "far" from it; the
solution could be A to bridge R1 to R2.  It is the same problem in wired
communication.


 Actually this is out of the question because, as stated in the previous paragraph in the draft, there is no guarantee that A can hear either R1, or R2... (all we know is that R1 and R2 can hear A).

 



Lastly, there is no guarantee that, as a set, S is at all stable. The
membership of set S may in fact change at any rate, any time.

One would however differentiate this dynamic nature from a completely
disconnected on-off behaviour.  One would set the limits of
connectivity.  If we don't have limits for connectivity then we can't
even talk PHY (let alone MAC, Networking, Transport and Application).

If it's needed, I could help contribute text defining what movement may
mean in terms of fixed points, subnets, TTL/HoLimit and of IP address
change.  I could also contribute text about radio communication being
the same through the air as through copper or fiber, as seen from the
MAC layer.


Thanks. But I think this is not in scope for this document. The goal of this document is simply to describe what was experienced over the years on multi-hop wireless networks in terms of communication characteristics. Such "conclusions", based on the characteristics described in this draft, should go in a separate document, in my mind.

Emmanuel

------=_Part_34507_10257452.1229691886134-- --===============0178462753== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf --===============0178462753==-- From autoconf-bounces@ietf.org Fri Dec 19 05:06:58 2008 Return-Path: X-Original-To: autoconf-archive@megatron.ietf.org Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EAA763A6830; Fri, 19 Dec 2008 05:06:58 -0800 (PST) X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5E1913A6830 for ; Fri, 19 Dec 2008 05:06:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0BGyF6mqIu+v for ; Fri, 19 Dec 2008 05:06:56 -0800 (PST) Received: from mail-bw0-f21.google.com (mail-bw0-f21.google.com [209.85.218.21]) by core3.amsl.com (Postfix) with ESMTP id 37B423A67D1 for ; Fri, 19 Dec 2008 05:06:55 -0800 (PST) Received: by bwz14 with SMTP id 14so3577939bwz.13 for ; Fri, 19 Dec 2008 05:06:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:in-reply-to:mime-version:content-type:references :x-google-sender-auth; bh=AmWRXuDvCutwVgCXgobXw9GCBLRGSTytc9RlJclijAg=; b=ICf8Piavjc7SyvEF93MycyJs9nPfRoJ9tzF85Y5vDxl88zDg+7MZO/Bo+0XziwdbMb 6gUdmIx+Ff+XKsyRGPHIuX7xWgvWbLJ5SmhKkvnYEc0sXRSUrobo1wz9RzLVL/Zz13mg nhzLUazmIXx3jq7/2pSIxF2qvvU1xLtTEiq+A= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:in-reply-to:mime-version :content-type:references:x-google-sender-auth; b=Muob5b6wumhCus19TuMnysp4+lcnGm2cAgKHiM3+Jm7XeQhxOqfgXQcjbvbkaCYekd sD9j7Q+1LQIWd+voL/FcFHNnYrltqZQJQIye9ECfcnS02cxVLF99rm3srJ+o82z24+Wy 4CTtdqkmOQfWn2ilcX0GtBKrVK3aYoVZL4b1s= Received: by 10.103.225.11 with SMTP id c11mr1226086mur.24.1229692006526; Fri, 19 Dec 2008 05:06:46 -0800 (PST) Received: by 10.103.248.12 with HTTP; Fri, 19 Dec 2008 05:06:46 -0800 (PST) Message-ID: Date: Fri, 19 Dec 2008 14:06:46 +0100 From: "Emmanuel Baccelli" To: autoconf@ietf.org In-Reply-To: <005701c961d4$0b1fbc40$215f34c0$@nl> MIME-Version: 1.0 References: <494B8E7C.7000505@gmail.com> <494B9035.40405@gmail.com> <005701c961d4$0b1fbc40$215f34c0$@nl> X-Google-Sender-Auth: 3b39bb52d88cc84b Subject: Re: [Autoconf] aspects of multi-hop wireless communication X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1843878740==" Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org --===============1843878740== Content-Type: multipart/alternative; boundary="----=_Part_34512_24818782.1229692006524" ------=_Part_34512_24818782.1229692006524 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Yeah, me too! We'd keep it a secret and we'd get rich ;)Emmanuel On Fri, Dec 19, 2008 at 1:19 PM, Teco Boot wrote: > |>>> First, there is no guarantee that a router C within S can, > |>>> symmetrically, send IP packets directly to router A. In other words, > |>>> even though C can "hear" packets from node A (since it is a member > |of > |>>> set S), there is no guarantee that A can "hear" packets from node C. > |> > |>> Sorry, could one mention why? What's the example of this? > |> > |> The simplest example (but by no means the only) is different power > |> levels transmitted by A and C. > | > |And isn't it the same for wired communications ? (and would a potential > |solution to this to have the same power levels transmitted by A and C?) > > One other reason is noise levels. > > Alex, if you can provide a noise suppression device, please send me one. > > Teco. > > > ------=_Part_34512_24818782.1229692006524 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Yeah, me too! We'd keep it a secret and we'd get rich ;)
Emmanuel

On Fri, Dec 19, 2008 at 1:19 PM, Teco Boot <teco@inf-net.nl> wrote:
|>>> First, there is no guarantee that a router C within S can,
|>>> symmetrically, send IP packets directly to router A. In other words,
|>>> even though C can "hear" packets from node A (since it is a member
|of
|>>> set S), there is no guarantee that A can "hear" packets from node C.
|>
|>> Sorry, could one mention why?  What's the example of this?
|>
|> The simplest example (but by no means the only) is different power
|> levels transmitted by A and C.
|
|And isn't it the same for wired communications ?  (and would a potential
|solution to this to have the same power levels transmitted by A and C?)

One other reason is noise levels.

Alex, if you can provide a noise suppression device, please send me one.

Teco.



------=_Part_34512_24818782.1229692006524-- --===============1843878740== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf --===============1843878740==-- From autoconf-bounces@ietf.org Fri Dec 19 05:11:26 2008 Return-Path: X-Original-To: autoconf-archive@megatron.ietf.org Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 50ADD3A6830; Fri, 19 Dec 2008 05:11:26 -0800 (PST) X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6FAF53A6830 for ; Fri, 19 Dec 2008 05:11:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.907 X-Spam-Level: X-Spam-Status: No, score=-1.907 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GBbXIZT3eobi for ; Fri, 19 Dec 2008 05:11:24 -0800 (PST) Received: from mail-bw0-f21.google.com (mail-bw0-f21.google.com [209.85.218.21]) by core3.amsl.com (Postfix) with ESMTP id BB3673A67D1 for ; Fri, 19 Dec 2008 05:11:23 -0800 (PST) Received: by bwz14 with SMTP id 14so3584933bwz.13 for ; Fri, 19 Dec 2008 05:11:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:in-reply-to:mime-version:content-type:references :x-google-sender-auth; bh=3E8U6mGnpa6wVgRPaWrgUAAfhoG0KFeHD1dz3/VrF9s=; b=eLIP+QA1QAmCL2qmleKHV3L9oDuP+QK3B6bGxV8V8KLubDnR151aLp5WrxG4Vnbmkl BMUG8+I0QpEnByLWWNaGFdfcf3+cWiGVSrNTdf1gXMeC7IYXug+AZcYFlhpvG4sSCW0U qHj1Pj1Apt+Ww3x8eT+CDIgrMOVddMBq4xlAU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:in-reply-to:mime-version :content-type:references:x-google-sender-auth; b=Kh/xsDVPNkLIYnHuLtS91AQ8uKpAlmVudwJ2dhVBTvBRrLS5fXjjZ3wsKc16EF45D6 5qSAAoD5H8+sZU8dpFRfCsDltj8p5dR/ipyFSU0byRaLDu77Dpl1/EcgrznVRGL50D2l b1kLnhj53tblt0B+dAAoKtxrYBfX0yMorKZyk= Received: by 10.103.92.10 with SMTP id u10mr1230951mul.22.1229692274650; Fri, 19 Dec 2008 05:11:14 -0800 (PST) Received: by 10.103.248.12 with HTTP; Fri, 19 Dec 2008 05:11:14 -0800 (PST) Message-ID: Date: Fri, 19 Dec 2008 14:11:14 +0100 From: "Emmanuel Baccelli" To: autoconf@ietf.org In-Reply-To: <005101c961d2$8c7f4ff0$a57defd0$@nl> MIME-Version: 1.0 References: <005101c961d2$8c7f4ff0$a57defd0$@nl> X-Google-Sender-Auth: 0e9060f3671b8887 Subject: Re: [Autoconf] aspects of multi-hop wireless communication X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1684448975==" Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org --===============1684448975== Content-Type: multipart/alternative; boundary="----=_Part_34528_31862934.1229692274646" ------=_Part_34528_31862934.1229692274646 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi Teco, thanks for your feedback, On Fri, Dec 19, 2008 at 1:08 PM, Teco Boot wrote: > Hi Emmanual and Charles, > > Thanks for the efforts. > I like the compactness of the draft. > > > Maybe mention alternate terminology "uni-directional" for "asymmetric" ? > As discussed before, asymmetry is also used for different link qualities > for A to B and B to A, where A and B have a symmetric relation. > I agree. I think it would be nice to have unidirectional mentionned in the alternative terminology. Should have this in -01. > > > > - We may say that router B is a neighbor of router A. In this > > terminology, there is no guarantee that router A is a neighbor of > > router B. > > In this case, the neighbor table of router B would list router A. > So I say router A is neighbor of router B, and there is no guarantee > that router B is a neighbor of router A. > Or I say the relation between neighbors is symmetric, but some neighbors > may not be aware of this. > OK, I think I see what you mean: you are saying that since B hears A, the text should rather be: "A is neighbor of router B, and there is no guarantee that router B is a neighbor of router A" Am I correct? Emmanuel > > Regards, Teco > > > === > Van: autoconf-bounces@ietf.org [mailto:autoconf-bounces@ietf.org] Namens > Emmanuel Baccelli > Verzonden: vrijdag 19 december 2008 10:19 > Aan: autoconf@ietf.org > Onderwerp: [Autoconf] aspects of multi-hop wireless communication > > Hi all, > > here's a draft that aims at describing important aspects of multi-hop > wireless communication, as observed over the past decade of experience with > such networks. > > The goal of this document is to identify a consensus about this topic, and > then use this to move on quicker with the working group documents. > > Please review it, and provide feedback as soon as possible. > > > http://tools.ietf.org/html/draft-baccelli-multi-hop-wireless-communication-0 > 0 > > cheers > Emmanuel > > ------=_Part_34528_31862934.1229692274646 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi Teco, thanks for your feedback,

On Fri, Dec 19, 2008 at 1:08 PM, Teco Boot <teco@inf-net.nl> wrote:
Hi Emmanual and Charles,

Thanks for the efforts.
I like the compactness of the draft.


Maybe mention alternate terminology "uni-directional" for "asymmetric" ?
As discussed before, asymmetry is also used for different link qualities
for A to B and B to A, where A and B have a symmetric relation.

I agree. I think it would be nice to have unidirectional mentionned in the alternative terminology. Should have this in -01.
 


> - We may say that router B is a neighbor of router A. In this
>   terminology, there is no guarantee that router A is a neighbor of
>   router B.

In this case, the neighbor table of router B would list router A.
So I say router A is neighbor of router B, and there is no guarantee
that router B is a neighbor of router A.
Or I say the relation between neighbors is symmetric, but some neighbors
may not be aware of this.


OK, I think I see what you mean: you are saying that since B hears A, the text should rather be:
"A is neighbor of router B, and there is no guarantee that router B is a neighbor of router A"
Am I correct?

 Emmanuel




Regards, Teco


===
Van: autoconf-bounces@ietf.org [mailto:autoconf-bounces@ietf.org] Namens
Emmanuel Baccelli
Verzonden: vrijdag 19 december 2008 10:19
Aan: autoconf@ietf.org
Onderwerp: [Autoconf] aspects of multi-hop wireless communication

Hi all,

here's a draft that aims at describing important aspects of multi-hop
wireless communication, as observed over the past decade of experience with
such networks.

The goal of this document is to identify a consensus about this topic, and
then use this to move on quicker with the working group documents.

Please review it, and provide feedback as soon as possible. 

http://tools.ietf.org/html/draft-baccelli-multi-hop-wireless-communication-0
0

cheers
Emmanuel


------=_Part_34528_31862934.1229692274646-- --===============1684448975== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf --===============1684448975==-- From autoconf-bounces@ietf.org Fri Dec 19 05:34:10 2008 Return-Path: X-Original-To: autoconf-archive@megatron.ietf.org Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2216A3A6883; Fri, 19 Dec 2008 05:34:10 -0800 (PST) X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 733C63A6883 for ; Fri, 19 Dec 2008 05:34:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.765 X-Spam-Level: X-Spam-Status: No, score=-0.765 tagged_above=-999 required=5 tests=[AWL=-0.579, BAYES_20=-0.74, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Aw41k0nOZ1TC for ; Fri, 19 Dec 2008 05:34:08 -0800 (PST) Received: from hpsmtp-eml20.kpnxchange.com (hpsmtp-eml20.KPNXCHANGE.COM [213.75.38.85]) by core3.amsl.com (Postfix) with ESMTP id 3FF683A6808 for ; Fri, 19 Dec 2008 05:34:07 -0800 (PST) Received: from cpsmtp-eml101.kpnxchange.com ([213.75.84.101]) by hpsmtp-eml20.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 19 Dec 2008 14:33:59 +0100 Received: from M90Teco ([86.83.9.22]) by cpsmtp-eml101.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 19 Dec 2008 14:33:59 +0100 From: "Teco Boot" To: "'Emmanuel Baccelli'" , References: <005101c961d2$8c7f4ff0$a57defd0$@nl> In-Reply-To: Date: Fri, 19 Dec 2008 14:33:55 +0100 Message-ID: <006b01c961de$708c80e0$51a582a0$@nl> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Aclh20rzZmiluIqwTHmOY6SWqDJC9AAAroVg Content-Language: nl X-OriginalArrivalTime: 19 Dec 2008 13:33:59.0128 (UTC) FILETIME=[72AC0580:01C961DE] Subject: Re: [Autoconf] aspects of multi-hop wireless communication X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0427652428==" Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org Dit is een meerdelig bericht met een MIME-indeling. --===============0427652428== Content-Type: multipart/alternative; boundary="----=_NextPart_000_006C_01C961E6.D250E8E0" Content-Language: nl Dit is een meerdelig bericht met een MIME-indeling. ------=_NextPart_000_006C_01C961E6.D250E8E0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit > - We may say that router B is a neighbor of router A. In this > terminology, there is no guarantee that router A is a neighbor of > router B. In this case, the neighbor table of router B would list router A. So I say router A is neighbor of router B, and there is no guarantee that router B is a neighbor of router A. Or I say the relation between neighbors is symmetric, but some neighbors may not be aware of this. OK, I think I see what you mean: you are saying that since B hears A, the text should rather be: "A is neighbor of router B, and there is no guarantee that router B is a neighbor of router A" Am I correct? Yes, but others could prefer the original text. If so, I am interested in the protocol that implement such. If there is no such implementation, please update the text. Teco. ------=_NextPart_000_006C_01C961E6.D250E8E0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

> - We may say that router B is a neighbor of = router A. In this
>   terminology, there is no guarantee that router A is a = neighbor of
>   router B.

In this case, the neighbor table of router B would list router A.
So I say router A is neighbor of router B, and there is no guarantee
that router B is a neighbor of router A.
Or I say the relation between neighbors is symmetric, but some = neighbors
may not be aware of this.

 

 

OK, I think I see what you mean: you are saying = that since B hears A, the text should rather be:

"A is neighbor of router B, and there is no guarantee that router B is a neighbor of router = A"

Am I correct?

 

Yes, but others could prefer the original text. =

If so, I am interested in the protocol that implement = such.

If there is no such implementation, please update the = text.

 

Teco.

------=_NextPart_000_006C_01C961E6.D250E8E0-- --===============0427652428== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf --===============0427652428==-- From autoconf-bounces@ietf.org Fri Dec 19 05:49:16 2008 Return-Path: X-Original-To: autoconf-archive@megatron.ietf.org Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 474CB3A69A4; Fri, 19 Dec 2008 05:49:16 -0800 (PST) X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A6C633A69A4 for ; Fri, 19 Dec 2008 05:49:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.912 X-Spam-Level: X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l-B-GDiq-1NU for ; Fri, 19 Dec 2008 05:49:14 -0800 (PST) Received: from fk-out-0910.google.com (fk-out-0910.google.com [209.85.128.185]) by core3.amsl.com (Postfix) with ESMTP id 833983A6842 for ; Fri, 19 Dec 2008 05:49:13 -0800 (PST) Received: by fk-out-0910.google.com with SMTP id 18so528940fkq.5 for ; Fri, 19 Dec 2008 05:49:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:cc:in-reply-to:mime-version:content-type:references :x-google-sender-auth; bh=iAupQrJdt7axiLLR/uCGGKHpbsWu9xcuKtPCdxrTTsc=; b=MoRwXURynv7wyUU/VPpuRGAFYgCh89dK42oRNhipt+c7Tt4LrTODoXrt9TTNGDC1Hi Hvla6Ua8/n914h9htCb31bN64nh0f6h/NGopk8G0SevyjHU+DifDV6xmoN9MqrgDhMLJ ZkV43UB976FjJWf5siKABiciTqKXOdWOfat0o= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:references:x-google-sender-auth; b=eJ/IIg6Fo3H7o9ldp5ZeGoAg/IDunuGSlao+HrgK6mqF9H7jBwaYjKVXRF5q8SwfTE aQf+HhGCtfuvLv/bgUxwPmzwxmz+l7Kex6THRxwHbcyOSIfSrlZ4gQmlUywZ+IA1LR/T V7kljuy4HDHYfxcip/hphpUVyzIRS7XH75B9o= Received: by 10.103.49.12 with SMTP id b12mr1236469muk.65.1229694544941; Fri, 19 Dec 2008 05:49:04 -0800 (PST) Received: by 10.103.248.12 with HTTP; Fri, 19 Dec 2008 05:49:04 -0800 (PST) Message-ID: Date: Fri, 19 Dec 2008 14:49:04 +0100 From: "Emmanuel Baccelli" To: "Teco Boot" In-Reply-To: <006b01c961de$708c80e0$51a582a0$@nl> MIME-Version: 1.0 References: <005101c961d2$8c7f4ff0$a57defd0$@nl> <006b01c961de$708c80e0$51a582a0$@nl> X-Google-Sender-Auth: 263b6387bca7aa8f Cc: autoconf@ietf.org Subject: Re: [Autoconf] aspects of multi-hop wireless communication X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0313865486==" Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org --===============0313865486== Content-Type: multipart/alternative; boundary="----=_Part_34787_12407549.1229694544930" ------=_Part_34787_12407549.1229694544930 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline OK ;) As far as I'm concerned, I think we should update the text; Should be in -01.Emmanuel On Fri, Dec 19, 2008 at 2:33 PM, Teco Boot wrote: > > - We may say that router B is a neighbor of router A. In this > > terminology, there is no guarantee that router A is a neighbor of > > router B. > > In this case, the neighbor table of router B would list router A. > So I say router A is neighbor of router B, and there is no guarantee > that router B is a neighbor of router A. > Or I say the relation between neighbors is symmetric, but some neighbors > may not be aware of this. > > > > > > OK, I think I see what you mean: you are saying that since B hears A, the > text should rather be: > > "A is neighbor of router B, and there is no guarantee that router B is a > neighbor of router A" > > Am I correct? > > > > Yes, but others could prefer the original text. > > If so, I am interested in the protocol that implement such. > > If there is no such implementation, please update the text. > > > > Teco. > ------=_Part_34787_12407549.1229694544930 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline OK ;) As far as I'm concerned, I think we should update the text; Should be in -01.
Emmanuel


On Fri, Dec 19, 2008 at 2:33 PM, Teco Boot <teco@inf-net.nl> wrote:

> - We may say that router B is a neighbor of router A. In this
>   terminology, there is no guarantee that router A is a neighbor of
>   router B.

In this case, the neighbor table of router B would list router A.
So I say router A is neighbor of router B, and there is no guarantee
that router B is a neighbor of router A.
Or I say the relation between neighbors is symmetric, but some neighbors
may not be aware of this.

 

 

OK, I think I see what you mean: you are saying that since B hears A, the text should rather be:

"A is neighbor of router B, and there is no guarantee that router B is a neighbor of router A"

Am I correct?

 

Yes, but others could prefer the original text.

If so, I am interested in the protocol that implement such.

If there is no such implementation, please update the text.

 

Teco.


------=_Part_34787_12407549.1229694544930-- --===============0313865486== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf --===============0313865486==-- From autoconf-bounces@ietf.org Fri Dec 19 06:44:30 2008 Return-Path: X-Original-To: autoconf-archive@megatron.ietf.org Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 835833A6A39; Fri, 19 Dec 2008 06:44:30 -0800 (PST) X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E75A93A6948 for ; Fri, 19 Dec 2008 06:44:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.527 X-Spam-Level: X-Spam-Status: No, score=-6.527 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 51HOa30XS4qT for ; Fri, 19 Dec 2008 06:44:28 -0800 (PST) Received: from mail119.messagelabs.com (mail119.messagelabs.com [216.82.241.195]) by core3.amsl.com (Postfix) with SMTP id A452028C106 for ; Fri, 19 Dec 2008 06:44:26 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-4.tower-119.messagelabs.com!1229697858!32909809!1 X-StarScan-Version: 6.0.0; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 29249 invoked from network); 19 Dec 2008 14:44:18 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-4.tower-119.messagelabs.com with SMTP; 19 Dec 2008 14:44:18 -0000 Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id mBJEiHGO020352; Fri, 19 Dec 2008 07:44:17 -0700 (MST) Received: from il06vts02.mot.com (il06vts02.mot.com [129.188.137.142]) by il06exr03.mot.com (8.13.1/Vontu) with SMTP id mBJEiHRg010408; Fri, 19 Dec 2008 08:44:17 -0600 (CST) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by il06exr03.mot.com (8.13.1/8.13.0) with ESMTP id mBJEiFC3010384; Fri, 19 Dec 2008 08:44:16 -0600 (CST) Message-ID: <494BB33E.2040508@gmail.com> Date: Fri, 19 Dec 2008 15:44:14 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: "Dearlove, Christopher (UK)" References: <494B8E7C.7000505@gmail.com> <494B9035.40405@gmail.com> <005701c961d4$0b1fbc40$215f34c0$@nl> <494B91A6.3080200@gmail.com> In-Reply-To: X-Antivirus: avast! (VPS 081218-0, 18/12/2008), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected Cc: autoconf@ietf.org, Emmanuel Baccelli Subject: Re: [Autoconf] aspects of multi-hop wireless communication X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org Dearlove, Christopher (UK) wrote: >> There's noise in the wires as well and gets supressed by PHY and MAC. > > PHY layers, especially in radio, are not magic noise suppressors. > > I'm going to spell this one out once, then give up and suggest > any elementary text on radio. > > If I put a loud noise source right next to C, it will mess up > C's reception. But A, who is much more distant from the noise, > won't care. > > And before you suggest avoiding noise sources, let's just say > they range from things in the environment (inclusing man made > things) that are difficult to avoid, to people doing this > deliberately. > > And note that different power levels, and different noise > environments are still not the only reasons for asymmetry. But > either one is sufficient to make it happen. Christopher, I'a afraid I won't converge in this direction. Noise and interference are also solved by government regulation (the famous "political" layer). I'm really doubtful I could converge this way... Alex > > ******************************************************************** > This email and any attachments are confidential to the intended > recipient and may also be privileged. If you are not the intended > recipient please delete it from your system and notify the sender. > You should not copy it or use it for any purpose nor disclose or > distribute its contents to any other person. > ******************************************************************** > > ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Fri Dec 19 07:02:08 2008 Return-Path: X-Original-To: autoconf-archive@megatron.ietf.org Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C84403A6A05; Fri, 19 Dec 2008 07:02:08 -0800 (PST) X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9D3523A6A05 for ; Fri, 19 Dec 2008 07:02:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.531 X-Spam-Level: X-Spam-Status: No, score=-6.531 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3VpSFtKL4ZgT for ; Fri, 19 Dec 2008 07:02:06 -0800 (PST) Received: from mail128.messagelabs.com (mail128.messagelabs.com [216.82.250.131]) by core3.amsl.com (Postfix) with SMTP id CE43C3A6968 for ; Fri, 19 Dec 2008 07:02:06 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-11.tower-128.messagelabs.com!1229698917!2865859!1 X-StarScan-Version: 6.0.0; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 17692 invoked from network); 19 Dec 2008 15:01:57 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-11.tower-128.messagelabs.com with SMTP; 19 Dec 2008 15:01:57 -0000 Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id mBJF1pXB025147; Fri, 19 Dec 2008 08:01:51 -0700 (MST) Received: from il06vts01.mot.com (il06vts01.mot.com [129.188.137.141]) by il06exr02.mot.com (8.13.1/Vontu) with SMTP id mBJF1pOK017263; Fri, 19 Dec 2008 09:01:51 -0600 (CST) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by il06exr02.mot.com (8.13.1/8.13.0) with ESMTP id mBJF1o8x017254; Fri, 19 Dec 2008 09:01:51 -0600 (CST) Message-ID: <494BB75E.4050206@gmail.com> Date: Fri, 19 Dec 2008 16:01:50 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: Emmanuel Baccelli References: <494B8E7C.7000505@gmail.com> In-Reply-To: X-Antivirus: avast! (VPS 081218-0, 18/12/2008), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected Cc: autoconf@ietf.org Subject: Re: [Autoconf] aspects of multi-hop wireless communication X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org Emmanuel Baccelli wrote: >>> Second, there is no guarantee that two given routers within S can >>> directly communicate with one another. In other words, even >>> though two routers R1 and R2 can both "hear" packets from router >>> A, there is no guarantee that R1 can hear packets from R2, and >>> there is likewise no guarantee that R2 can hear packets from R1. >>> Thus, multi-hop ad hoc wireless communications may be >>> "non-transitive". >> >> It is of paramount important for me to understand what is meant by >> "hearing". Is it MAC level or IP level. >> >> It is very possible for R1 to not receive from R2 (although the >> intermediary A receives from both) and this does not represent a >> problem at all, even less a particular problem of wireless >> communications. When R1 doesn't hear from R2 it's because it's too >> "far" from it; the solution could be A to bridge R1 to R2. It is >> the same problem in wired communication. > > Actually this is out of the question because, as stated in the > previous paragraph in the draft, there is no guarantee that A can > hear either R1, or R2... (all we know is that R1 and R2 can hear A). So this second issue is tightly bound to the first, it seems. I agree a radio-through-air system may behave that way. I think some solutions exist at PHY and MAC layers in the case of 802.11. I doubt a solution is necessary at IP layer. Maybe there's a need to discuss this radio-through-air problem more in terms of what IP could do for it. Alex ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Fri Dec 19 07:07:09 2008 Return-Path: X-Original-To: autoconf-archive@megatron.ietf.org Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 84BB428C106; Fri, 19 Dec 2008 07:07:09 -0800 (PST) X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 529DA3A6A3D for ; Fri, 19 Dec 2008 07:07:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.534 X-Spam-Level: X-Spam-Status: No, score=-6.534 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s1ZRmEXdJbaC for ; Fri, 19 Dec 2008 07:07:07 -0800 (PST) Received: from smtp2.bae.co.uk (smtp2.bae.co.uk [20.133.0.12]) by core3.amsl.com (Postfix) with ESMTP id 5BE133A6A29 for ; Fri, 19 Dec 2008 07:07:07 -0800 (PST) Received: from smtpb.greenlnk.net (smtpb.greenlnk.net [10.15.160.219]) by smtp2.bae.co.uk (Switch-3.1.10/Switch-3.1.10) with ESMTP id mBJF6vgu007307 for ; Fri, 19 Dec 2008 15:06:57 GMT Received: from glkas0002.GREENLNK.NET (glkas0002.greenlnk.net [10.15.184.52]) by smtpb.greenlnk.net (Switch-3.1.9/Switch-3.1.9) with ESMTP id mBJF6vPa017952 for ; Fri, 19 Dec 2008 15:06:57 GMT Received: from glkms1101.GREENLNK.NET ([10.15.184.109]) by glkas0002.GREENLNK.NET with InterScan Message Security Suite; Fri, 19 Dec 2008 15:06:57 -0000 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1101.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.2499); Fri, 19 Dec 2008 15:06:57 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 19 Dec 2008 15:06:57 -0000 Message-ID: In-Reply-To: <494BB75E.4050206@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Autoconf] aspects of multi-hop wireless communication Thread-Index: Aclh6sG/t37icn9ATquN2m2p85ZeJwAAIwNw References: <494B8E7C.7000505@gmail.com> <494BB75E.4050206@gmail.com> From: "Dearlove, Christopher (UK)" To: "Alexandru Petrescu" , "Emmanuel Baccelli" X-OriginalArrivalTime: 19 Dec 2008 15:06:57.0287 (UTC) FILETIME=[6F838970:01C961EB] Cc: autoconf@ietf.org Subject: Re: [Autoconf] aspects of multi-hop wireless communication X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org > I think some solutions exist at PHY and MAC layers in the case of 802.11. As has been said many times before, MANET is not just about 802.11. ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Fri Dec 19 07:20:55 2008 Return-Path: X-Original-To: autoconf-archive@megatron.ietf.org Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7C20F3A6842; Fri, 19 Dec 2008 07:20:55 -0800 (PST) X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 588643A6842 for ; Fri, 19 Dec 2008 07:20:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.534 X-Spam-Level: X-Spam-Status: No, score=-6.534 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gz3WVXPzR3u5 for ; Fri, 19 Dec 2008 07:20:53 -0800 (PST) Received: from mail128.messagelabs.com (mail128.messagelabs.com [216.82.250.131]) by core3.amsl.com (Postfix) with SMTP id A54803A63CB for ; Fri, 19 Dec 2008 07:20:53 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-5.tower-128.messagelabs.com!1229700045!6702211!1 X-StarScan-Version: 6.0.0; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 14443 invoked from network); 19 Dec 2008 15:20:45 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-5.tower-128.messagelabs.com with SMTP; 19 Dec 2008 15:20:45 -0000 Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id mBJFKjeh029662; Fri, 19 Dec 2008 08:20:45 -0700 (MST) Received: from il06vts03.mot.com (il06vts03.mot.com [129.188.137.143]) by il06exr03.mot.com (8.13.1/Vontu) with SMTP id mBJFKirB001192; Fri, 19 Dec 2008 09:20:44 -0600 (CST) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by il06exr03.mot.com (8.13.1/8.13.0) with ESMTP id mBJFKhRg001178; Fri, 19 Dec 2008 09:20:44 -0600 (CST) Message-ID: <494BBBCB.4080804@gmail.com> Date: Fri, 19 Dec 2008 16:20:43 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: "Dearlove, Christopher (UK)" References: <494B8E7C.7000505@gmail.com> <494BB75E.4050206@gmail.com> In-Reply-To: X-Antivirus: avast! (VPS 081218-0, 18/12/2008), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected Cc: autoconf@ietf.org, Emmanuel Baccelli Subject: Re: [Autoconf] aspects of multi-hop wireless communication X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org Dearlove, Christopher (UK) wrote: >> I think some solutions exist at PHY and MAC layers in the case of >> 802.11. > > As has been said many times before, MANET is not just > about 802.11. I may have missed something. What other than 802.11 is it about? Alex ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Fri Dec 19 07:21:47 2008 Return-Path: X-Original-To: autoconf-archive@megatron.ietf.org Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AEEA53A6A35; Fri, 19 Dec 2008 07:21:47 -0800 (PST) X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1ED4E3A6A3F for ; Fri, 19 Dec 2008 07:21:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.916 X-Spam-Level: X-Spam-Status: No, score=-1.916 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HX5LgO9Prz35 for ; Fri, 19 Dec 2008 07:21:45 -0800 (PST) Received: from fk-out-0910.google.com (fk-out-0910.google.com [209.85.128.186]) by core3.amsl.com (Postfix) with ESMTP id CEEDF3A69F9 for ; Fri, 19 Dec 2008 07:21:44 -0800 (PST) Received: by fk-out-0910.google.com with SMTP id 18so552954fkq.5 for ; Fri, 19 Dec 2008 07:21:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:in-reply-to:mime-version:content-type:references :x-google-sender-auth; bh=j2wk7aiEntkXbT/hURKFmkSZ+GwHiC/Qk8A+uEeiILo=; b=cvrumZnOzGmFFS9/5oJuEV8ytGtTufy+hIQXVidkePZiEpaFC/vf4jf9Ny1yo18KfO 4KG1KnjCD2K06Qs78gw30Dx6BOSARVK0P2deVGav35Z1BaQCYVrvmDdW9esQD43ULxd1 iU114EMgDuhcB6QQLdl0BOh44PByDIfg3UHKo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:in-reply-to:mime-version :content-type:references:x-google-sender-auth; b=e801zUMM2U2kRe4kT1bUsw2SJIl4JPBsz4otCgHTiFOoo2zBFTNJniWfqVOho2O6+n xm6IR1bxgLal8NiDEkgYEAhd1QrOfc++6ncTD/Ts65ZxUrcfdJhCIZpk0Uwhyc96/uFk oX3zueHvllCMQF2+86ZeKv/56191xEFmcwCfs= Received: by 10.102.247.4 with SMTP id u4mr1263029muh.104.1229700095538; Fri, 19 Dec 2008 07:21:35 -0800 (PST) Received: by 10.103.248.12 with HTTP; Fri, 19 Dec 2008 07:21:35 -0800 (PST) Message-ID: Date: Fri, 19 Dec 2008 16:21:35 +0100 From: "Emmanuel Baccelli" To: autoconf@ietf.org In-Reply-To: MIME-Version: 1.0 References: <494B8E7C.7000505@gmail.com> <494BB75E.4050206@gmail.com> X-Google-Sender-Auth: 05ab24bfaa1c4e62 Subject: Re: [Autoconf] aspects of multi-hop wireless communication X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0229219854==" Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org --===============0229219854== Content-Type: multipart/alternative; boundary="----=_Part_35787_23032556.1229700095536" ------=_Part_35787_23032556.1229700095536 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline On Fri, Dec 19, 2008 at 4:06 PM, Dearlove, Christopher (UK) < chris.dearlove@baesystems.com> wrote: > > > I think some solutions exist at PHY and MAC layers in the case of > 802.11. > > As has been said many times before, MANET is not just > about 802.11. > I think Chris makes an important point here. We are discussing things experienced at the IP layer. The draft is not saying "there is a need for a solution". The draft is saying "this is what is often observed". That's it. I think we can agree on this ;) Emmanuel ------=_Part_35787_23032556.1229700095536 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline

On Fri, Dec 19, 2008 at 4:06 PM, Dearlove, Christopher (UK) <chris.dearlove@baesystems.com> wrote:

> I think some solutions exist at PHY and MAC layers in the case of
802.11.

As has been said many times before, MANET is not just
about 802.11.

I think Chris makes an important point here.
We are discussing things experienced at the IP layer. 
The draft is not saying "there is a need for a solution". 
The draft is saying "this is what is often observed". 
That's it. I think we can agree on this ;)

Emmanuel

------=_Part_35787_23032556.1229700095536-- --===============0229219854== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf --===============0229219854==-- From autoconf-bounces@ietf.org Fri Dec 19 07:53:16 2008 Return-Path: X-Original-To: autoconf-archive@megatron.ietf.org Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6A85C3A69F6; Fri, 19 Dec 2008 07:53:16 -0800 (PST) X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8D16D3A69F6 for ; Fri, 19 Dec 2008 07:53:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.099 X-Spam-Level: X-Spam-Status: No, score=-6.099 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t2yCy5bm9lgL for ; Fri, 19 Dec 2008 07:53:14 -0800 (PST) Received: from mail119.messagelabs.com (mail119.messagelabs.com [216.82.241.195]) by core3.amsl.com (Postfix) with SMTP id 9E4383A6986 for ; Fri, 19 Dec 2008 07:53:14 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-10.tower-119.messagelabs.com!1229701986!34196193!1 X-StarScan-Version: 6.0.0; banners=.,-,- X-Originating-IP: [136.182.1.12] Received: (qmail 23610 invoked from network); 19 Dec 2008 15:53:06 -0000 Received: from unknown (HELO motgate2.mot.com) (136.182.1.12) by server-10.tower-119.messagelabs.com with SMTP; 19 Dec 2008 15:53:06 -0000 Received: from il27exr02.cig.mot.com (il27exr02.mot.com [10.17.196.71]) by motgate2.mot.com (8.12.11/Motorola) with ESMTP id mBJFr6uI027525; Fri, 19 Dec 2008 08:53:06 -0700 (MST) Received: from il27vts03 (il27vts03.cig.mot.com [10.17.196.87]) by il27exr02.cig.mot.com (8.13.1/Vontu) with SMTP id mBJFr5Ri014851; Fri, 19 Dec 2008 09:53:05 -0600 (CST) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by il27exr02.cig.mot.com (8.13.1/8.13.0) with ESMTP id mBJFr4Ye014831; Fri, 19 Dec 2008 09:53:05 -0600 (CST) Message-ID: <494BC360.1000109@gmail.com> Date: Fri, 19 Dec 2008 16:53:04 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: Emmanuel Baccelli References: <494B8E7C.7000505@gmail.com> <494BB75E.4050206@gmail.com> In-Reply-To: X-Antivirus: avast! (VPS 081218-0, 18/12/2008), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected Cc: autoconf@ietf.org Subject: Re: [Autoconf] aspects of multi-hop wireless communication X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org Emmanuel Baccelli wrote: > > > On Fri, Dec 19, 2008 at 4:06 PM, Dearlove, Christopher (UK) > > wrote: > > >> I think some solutions exist at PHY and MAC layers in the case of > 802.11. > > As has been said many times before, MANET is not just about 802.11. > > > I think Chris makes an important point here. We are discussing things > experienced at the IP layer. Observation should report the name of the link layer, otherwise a peer may think the author logically extends what s/he sees on one link layer to another (instead of experiencing same phenomena on each link layer individually). The scientist orders the frog to jump, who so does. Then cuts its legs, orders it again to jump; the frog obviously can't jump. Scientist deduces the frog can no longer hear. However, if the order were issued to the legs (instead of ears) in the first place then maybe the false conclusion could have been avoided. > The draft is not saying "there is a need for a solution". The draft > is saying "this is what is often observed". That's it. I think we can > agree on this ;) I agree one may have observed this behaviour. I don't agree it is an often observed behaviour - I didn't. I often observed wifi works ok in the types of deployments described in the draft (R1,R2,A). Alex > > Emmanuel > > > ------------------------------------------------------------------------ > > > > > _______________________________________________ Autoconf mailing list > Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Fri Dec 19 08:11:10 2008 Return-Path: X-Original-To: autoconf-archive@megatron.ietf.org Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7449D3A6A42; Fri, 19 Dec 2008 08:11:10 -0800 (PST) X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EBBC93A6A57 for ; Fri, 19 Dec 2008 08:11:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i5l2XqKcgahm for ; Fri, 19 Dec 2008 08:11:06 -0800 (PST) Received: from fk-out-0910.google.com (fk-out-0910.google.com [209.85.128.191]) by core3.amsl.com (Postfix) with ESMTP id EEF993A6A56 for ; Fri, 19 Dec 2008 08:11:03 -0800 (PST) Received: by fk-out-0910.google.com with SMTP id 18so566393fkq.5 for ; Fri, 19 Dec 2008 08:10:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:cc:in-reply-to:mime-version:content-type:references :x-google-sender-auth; bh=H8d9vmtPgasz5TfjhKiFYrrSXZHTVHBgj6SAfvkCoUk=; b=Hj9aDtly9Nr+xuYKRw9pHxOUryIgNXQFjvyXaDMzAFHjSIsQJIlPP2igxM6mc48gxQ JyGdQXgdOnaObotv2TmGDpJ1v2GsSD0BnbDcZ7pEQ6sSM5vfRDa2ymx4oGR1T5wlPgbf ylDJ7AuQBWFUjfjcKTByctAgiebotMYTKVx/4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:references:x-google-sender-auth; b=D1MgTNNL4MxnBlIj7QvXv8nl7Z3m4J2tocBYEugngl/akTvkqk3ckYptJcPSHWzttr rX/xOAgLWLhXhYzqy6PicMsapAFtIMf/+aweNNyz9JtKj374ld1TjzWsAN+joKT1ZK76 ZNLXTQ3giV2B8oYG07dOnGRyYw5JPiB4r6bv4= Received: by 10.103.165.18 with SMTP id s18mr1277589muo.124.1229703055136; Fri, 19 Dec 2008 08:10:55 -0800 (PST) Received: by 10.103.248.12 with HTTP; Fri, 19 Dec 2008 08:10:55 -0800 (PST) Message-ID: Date: Fri, 19 Dec 2008 17:10:55 +0100 From: "Emmanuel Baccelli" To: "Alexandru Petrescu" In-Reply-To: <494BC360.1000109@gmail.com> MIME-Version: 1.0 References: <494B8E7C.7000505@gmail.com> <494BB75E.4050206@gmail.com> <494BC360.1000109@gmail.com> X-Google-Sender-Auth: b2bb1fa9977ea8d4 Cc: autoconf@ietf.org Subject: Re: [Autoconf] aspects of multi-hop wireless communication X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1487522055==" Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org --===============1487522055== Content-Type: multipart/alternative; boundary="----=_Part_36298_1970793.1229703055115" ------=_Part_36298_1970793.1229703055115 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline On Fri, Dec 19, 2008 at 4:53 PM, Alexandru Petrescu < alexandru.petrescu@gmail.com> wrote: > Emmanuel Baccelli wrote: > >> >> >> On Fri, Dec 19, 2008 at 4:06 PM, Dearlove, Christopher (UK) < >> chris.dearlove@baesystems.com > >> wrote: >> >> >> I think some solutions exist at PHY and MAC layers in the case of >>> >> 802.11. >> >> As has been said many times before, MANET is not just about 802.11. >> >> >> I think Chris makes an important point here. We are discussing things >> experienced at the IP layer. >> > > Observation should report the name of the link layer, otherwise a peer > may think the author logically extends what s/he sees on one link layer > to another (instead of experiencing same phenomena on each link layer > individually). > > The scientist orders the frog to jump, who so does. Then cuts its legs, > orders it again to jump; the frog obviously can't jump. Scientist > deduces the frog can no longer hear. However, if the order were issued > to the legs (instead of ears) in the first place then maybe the false > conclusion could have been avoided. > I knew this joke with a spider instead of a frog. Funny. > > The draft is not saying "there is a need for a solution". The draft is >> saying "this is what is often observed". That's it. I think we can >> agree on this ;) >> > > I agree one may have observed this behaviour. I don't agree it is an > often observed behaviour - I didn't. I often observed wifi works ok in > the types of deployments described in the draft (R1,R2,A). > Well Alex, you are the only one I know that has had such unbelievable luck with radio links (wifi or any other type of radio) during the last decade. I guess this is says a lot about reality ;) Emmanuel > > Alex > > >> Emmanuel >> >> >> ------------------------------------------------------------------------ >> >> >> >> >> _______________________________________________ Autoconf mailing list >> Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf >> > > > ______________________________________________________________________ > This email has been scanned by the MessageLabs Email Security System. > For more information please visit http://www.messagelabs.com/email______________________________________________________________________ > ------=_Part_36298_1970793.1229703055115 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline

On Fri, Dec 19, 2008 at 4:53 PM, Alexandru Petrescu <alexandru.petrescu@gmail.com> wrote:
Emmanuel Baccelli wrote:



On Fri, Dec 19, 2008 at 4:06 PM, Dearlove, Christopher (UK) <chris.dearlove@baesystems.com <mailto:chris.dearlove@baesystems.com>> wrote:


I think some solutions exist at PHY and MAC layers in the case of
802.11.

As has been said many times before, MANET is not just about 802.11.


I think Chris makes an important point here. We are discussing things
 experienced at the IP layer.

Observation should report the name of the link layer, otherwise a peer
may think the author logically extends what s/he sees on one link layer
to another (instead of experiencing same phenomena on each link layer
individually).

The scientist orders the frog to jump, who so does.  Then cuts its legs,
orders it again to jump; the frog obviously can't jump.  Scientist
deduces the frog can no longer hear.  However, if the order were issued
to the legs (instead of ears) in the first place then maybe the false
conclusion could have been avoided.



I knew this joke with a spider instead of a frog. Funny.
 

The draft is not saying "there is a need for a solution". The draft is saying "this is what is often observed". That's it. I think we can
 agree on this ;)

I agree one may have observed this behaviour.  I don't agree it is an
often observed behaviour - I didn't.  I often observed wifi works ok in
the types of deployments described in the draft (R1,R2,A).


Well Alex, you are the only one I know that has had such unbelievable luck with radio links (wifi or any other type of radio) during the last decade. I guess this is says a lot about reality ;)
Emmanuel
 

 

Alex


Emmanuel


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




_______________________________________________ Autoconf mailing list
 Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf


______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email ______________________________________________________________________

------=_Part_36298_1970793.1229703055115-- --===============1487522055== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf --===============1487522055==-- From autoconf-bounces@ietf.org Fri Dec 19 08:18:02 2008 Return-Path: X-Original-To: autoconf-archive@megatron.ietf.org Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 548E43A6A4D; Fri, 19 Dec 2008 08:18:02 -0800 (PST) X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6AF9A3A6A42 for ; Fri, 19 Dec 2008 08:18:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.537 X-Spam-Level: X-Spam-Status: No, score=-6.537 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UzJMOxeYGxEs for ; Fri, 19 Dec 2008 08:17:59 -0800 (PST) Received: from mail128.messagelabs.com (mail128.messagelabs.com [216.82.250.131]) by core3.amsl.com (Postfix) with SMTP id 9B1783A6A4C for ; Fri, 19 Dec 2008 08:17:59 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-7.tower-128.messagelabs.com!1229703470!3765976!1 X-StarScan-Version: 6.0.0; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 12443 invoked from network); 19 Dec 2008 16:17:51 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-7.tower-128.messagelabs.com with SMTP; 19 Dec 2008 16:17:51 -0000 Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id mBJGHjBS015158; Fri, 19 Dec 2008 09:17:45 -0700 (MST) Received: from il06vts03.mot.com (il06vts03.mot.com [129.188.137.143]) by il06exr03.mot.com (8.13.1/Vontu) with SMTP id mBJGHjGo004518; Fri, 19 Dec 2008 10:17:45 -0600 (CST) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by il06exr03.mot.com (8.13.1/8.13.0) with ESMTP id mBJGHi1U004512; Fri, 19 Dec 2008 10:17:44 -0600 (CST) Message-ID: <494BC927.1020400@gmail.com> Date: Fri, 19 Dec 2008 17:17:43 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: Emmanuel Baccelli References: <494B8E7C.7000505@gmail.com> <494BB75E.4050206@gmail.com> <494BC360.1000109@gmail.com> In-Reply-To: X-Antivirus: avast! (VPS 081218-0, 18/12/2008), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected Cc: autoconf@ietf.org Subject: Re: [Autoconf] aspects of multi-hop wireless communication X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org Emmanuel Baccelli wrote: >>> The draft is not saying "there is a need for a solution". The >>> draft is saying "this is what is often observed". That's it. I >>> think we can agree on this ;) >> >> I agree one may have observed this behaviour. I don't agree it is >> an often observed behaviour - I didn't. I often observed wifi >> works ok in the types of deployments described in the draft >> (R1,R2,A). > > Well Alex, you are the only one I know that has had such unbelievable > luck with radio links (wifi or any other type of radio) during the > last decade. I guess this is says a lot about reality ;) Emmanuel I think that's a good point that could be clarified. All I could do, and I already offered to do, is to describe the A-B-C wifi deployment which works ok with MAC bridging. Alex ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Fri Dec 19 08:27:04 2008 Return-Path: X-Original-To: autoconf-archive@megatron.ietf.org Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6C06128C142; Fri, 19 Dec 2008 08:27:04 -0800 (PST) X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6AFBF28C140 for ; Fri, 19 Dec 2008 08:27:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n1ZsfbsNvaJQ for ; Fri, 19 Dec 2008 08:27:02 -0800 (PST) Received: from elasmtp-banded.atl.sa.earthlink.net (elasmtp-banded.atl.sa.earthlink.net [209.86.89.70]) by core3.amsl.com (Postfix) with ESMTP id 7D0D728C12B for ; Fri, 19 Dec 2008 08:27:02 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=bvhNi1ydM5PpnBIShPi+mELbC68jjFHWxrVtepdMhZgT1y1josX0+hzC/zYvK9Cf; h=Received:Message-ID:Date:From:Organization:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [99.51.74.16] (helo=[192.168.1.100]) by elasmtp-banded.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1LDiBg-0006xT-I4; Fri, 19 Dec 2008 11:26:52 -0500 Message-ID: <494BCB4A.9090700@earthlink.net> Date: Fri, 19 Dec 2008 08:26:50 -0800 From: "Charles E. Perkins" Organization: Wichorus Inc. User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: Alexandru Petrescu References: <494B8E7C.7000505@gmail.com> <494BB75E.4050206@gmail.com> <494BC360.1000109@gmail.com> In-Reply-To: <494BC360.1000109@gmail.com> X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f52e1b66689469af32231ed3beabbf03cb2350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.51.74.16 Cc: autoconf@ietf.org Subject: Re: [Autoconf] aspects of multi-hop wireless communication X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org Hello Alex, I have to object!! Alexandru Petrescu wrote: > Observation should report the name of the link layer, otherwise a peer > may think the author logically extends what s/he sees on one link layer > to another (instead of experiencing same phenomena on each link layer > individually). Not really. We've observed that various link technologies exhibit some or all of the communication problems under consideration. I do not want to write a document specific to a particular link technology. > > The scientist orders the frog to jump, who so does. Then cuts its legs, > orders it again to jump; the frog obviously can't jump. Scientist > deduces the frog can no longer hear. However, if the order were issued > to the legs (instead of ears) in the first place then maybe the false > conclusion could have been avoided. Interesting story, but not characteristic of the abilities of the people involved here. I think we're a bit beyond such knee-jerk reactions or frog-jumping contests. > >> The draft is not saying "there is a need for a solution". The draft >> is saying "this is what is often observed". That's it. I think we can >> agree on this ;) > > I agree one may have observed this behaviour. I don't agree it is an > often observed behaviour - I didn't. I often observed wifi works ok in > the types of deployments described in the draft (R1,R2,A). First, you have to be kidding about nontransitivity. That's obvious. It even has a famous name -- "hidden terminal" problem. You can read about that in a google of places. Second, take a look at the MIT Roofnet project papers. That project was a very strong re-verification of the well-known properties discussed in the draft, along with numerous implications drawn out for IP routing protocol behaviors. I'd be very curious if you could find anyone who has seriously studied the matter (e.g., refereed publications) to support your position. Regards, Charlie P. _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Fri Dec 19 08:33:29 2008 Return-Path: X-Original-To: autoconf-archive@megatron.ietf.org Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2692628C140; Fri, 19 Dec 2008 08:33:29 -0800 (PST) X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 23A6B28C12B for ; Fri, 19 Dec 2008 08:33:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6ct2LR2SIZJj for ; Fri, 19 Dec 2008 08:33:27 -0800 (PST) Received: from elasmtp-mealy.atl.sa.earthlink.net (elasmtp-mealy.atl.sa.earthlink.net [209.86.89.69]) by core3.amsl.com (Postfix) with ESMTP id 6BC7628C128 for ; Fri, 19 Dec 2008 08:33:27 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=FC04s/ylbGLXarJt0H4R+/jSYF+p93VynH83Nk/uFKrkEBupFj0AhGfi+3fcgoq+; h=Received:Message-ID:Date:From:Organization:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [99.51.74.16] (helo=[192.168.1.100]) by elasmtp-mealy.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1LDiHt-0002am-Fd; Fri, 19 Dec 2008 11:33:17 -0500 Message-ID: <494BCCCC.6050206@earthlink.net> Date: Fri, 19 Dec 2008 08:33:16 -0800 From: "Charles E. Perkins" Organization: Wichorus Inc. User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: Alexandru Petrescu References: <494B8E7C.7000505@gmail.com> <494BB75E.4050206@gmail.com> <494BC360.1000109@gmail.com> <494BC927.1020400@gmail.com> In-Reply-To: <494BC927.1020400@gmail.com> X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f52b50112d9175f6b93c9890b5e952d5b07350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.51.74.16 Cc: autoconf@ietf.org Subject: Re: [Autoconf] aspects of multi-hop wireless communication X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org Hello again Alex, Alexandru Petrescu wrote: > > All I could do, and I already offered to do, is to describe the A-B-C > wifi deployment which works ok with MAC bridging. Do you mean to say that we should stop engineering solutions to ad hoc network problems, and instead all deployments must install MAC bridging hardware? What if I want to join a working ad hoc network of devices using solutions that have already been developed without bridging? Why is this bad? What if there is a hurricane and some of the relief workers forgot to put their wireless bridging devices in their backpacks? Regards, Charlie P. _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Fri Dec 19 08:46:51 2008 Return-Path: X-Original-To: autoconf-archive@megatron.ietf.org Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7567A3A696C; Fri, 19 Dec 2008 08:46:51 -0800 (PST) X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 85C2D3A696C for ; Fri, 19 Dec 2008 08:46:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.54 X-Spam-Level: X-Spam-Status: No, score=-6.54 tagged_above=-999 required=5 tests=[AWL=0.059, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aO+YPbEOviQV for ; Fri, 19 Dec 2008 08:46:49 -0800 (PST) Received: from mail128.messagelabs.com (mail128.messagelabs.com [216.82.250.131]) by core3.amsl.com (Postfix) with SMTP id B787A3A68EC for ; Fri, 19 Dec 2008 08:46:49 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-7.tower-128.messagelabs.com!1229705201!3767378!1 X-StarScan-Version: 6.0.0; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 32728 invoked from network); 19 Dec 2008 16:46:41 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-7.tower-128.messagelabs.com with SMTP; 19 Dec 2008 16:46:41 -0000 Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id mBJGkf9k022879; Fri, 19 Dec 2008 09:46:41 -0700 (MST) Received: from il06vts01.mot.com (il06vts01.mot.com [129.188.137.141]) by il06exr03.mot.com (8.13.1/Vontu) with SMTP id mBJGkfDR020592; Fri, 19 Dec 2008 10:46:41 -0600 (CST) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by il06exr03.mot.com (8.13.1/8.13.0) with ESMTP id mBJGkeN6020581; Fri, 19 Dec 2008 10:46:40 -0600 (CST) Message-ID: <494BCFEF.2010100@gmail.com> Date: Fri, 19 Dec 2008 17:46:39 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: "Charles E. Perkins" References: <494B8E7C.7000505@gmail.com> <494BB75E.4050206@gmail.com> <494BC360.1000109@gmail.com> <494BC927.1020400@gmail.com> <494BCCCC.6050206@earthlink.net> In-Reply-To: <494BCCCC.6050206@earthlink.net> X-Antivirus: avast! (VPS 081218-0, 18/12/2008), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected Cc: autoconf@ietf.org Subject: Re: [Autoconf] aspects of multi-hop wireless communication X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org Charles, hi, thanks for the reply, Charles E. Perkins wrote: > > Hello again Alex, > > Alexandru Petrescu wrote: >> >> All I could do, and I already offered to do, is to describe the >> A-B-C wifi deployment which works ok with MAC bridging. > > Do you mean to say that we should stop engineering solutions to ad > hoc network problems, and instead all deployments must install MAC > bridging hardware? Errr... somehow yes, if I'm permitted. I simply suggest a link-layer solution to a link-layer problem. > What if I want to join a working ad hoc network of devices using > solutions that have already been developed without bridging? Why is > this bad? It's not bad. One would first deploy bridges in networks that are partitioned and in need of bridges. Then any new terminal needing to join could do so, without needing to be itself a bridge. The question is why does one refuse the use of bridges when the network is partitioned at link-layer? > What if there is a hurricane and some of the relief workers forgot to > put their wireless bridging devices in their backpacks? No no... they won't, because they're trained to never forget these things at home. And if they do, then there exist other super-reliefs aids sending them trucks full of these devices. Alex > > Regards, Charlie P. > > ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Fri Dec 19 09:05:48 2008 Return-Path: X-Original-To: autoconf-archive@megatron.ietf.org Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0B4343A6A63; Fri, 19 Dec 2008 09:05:48 -0800 (PST) X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4F1F43A6A63 for ; Fri, 19 Dec 2008 09:05:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kZpM60+LkhpJ for ; Fri, 19 Dec 2008 09:05:45 -0800 (PST) Received: from elasmtp-masked.atl.sa.earthlink.net (elasmtp-masked.atl.sa.earthlink.net [209.86.89.68]) by core3.amsl.com (Postfix) with ESMTP id 6869F3A6A61 for ; Fri, 19 Dec 2008 09:05:45 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=ke9ZGcSinMjkzkx2+hEooQ46aSMmVxJKAoUwfbKa6hf+gBinTpxwMv3tzMsCBUjp; h=Received:Message-ID:Date:From:Organization:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [99.51.74.16] (helo=[192.168.1.100]) by elasmtp-masked.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1LDinB-0002sK-0C; Fri, 19 Dec 2008 12:05:37 -0500 Message-ID: <494BD45A.2090106@earthlink.net> Date: Fri, 19 Dec 2008 09:05:30 -0800 From: "Charles E. Perkins" Organization: Wichorus Inc. User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: Alexandru Petrescu References: <494B8E7C.7000505@gmail.com> <494BB75E.4050206@gmail.com> <494BC360.1000109@gmail.com> <494BC927.1020400@gmail.com> <494BCCCC.6050206@earthlink.net> <494BCFEF.2010100@gmail.com> In-Reply-To: <494BCFEF.2010100@gmail.com> X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f52862e399afc47aae8d0c1dd552eb105a3350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.51.74.16 Cc: autoconf@ietf.org Subject: Re: [Autoconf] aspects of multi-hop wireless communication X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org Hello Alex, I think we're approaching the point of having to agree to disagree. Alexandru Petrescu wrote: > > Errr... somehow yes, if I'm permitted. I simply suggest a link-layer > solution to a link-layer problem. IP is a solution that puts together different links. If you would like to suggest limiting the applicability of IP to _only_ be allowed to work for links with specific characteristics, then I think you should be explicit about it. Perhaps you would get some support, but I'm guessing it would not arise from the community of engineers and developers within autoconf or manet. > >> What if I want to join a working ad hoc network of devices using >> solutions that have already been developed without bridging? Why is >> this bad? > > It's not bad. Whew! > > One would first deploy bridges in networks that are partitioned and in > need of bridges. Then any new terminal needing to join could do so, > without needing to be itself a bridge. > > The question is why does one refuse the use of bridges when the network > is partitioned at link-layer? That's not a question I have raised, nor do I think that the answer would be illuminating. But my answer is that no one is making any such refusal. The question is, why can't we use IP as a good tool to solve problems of connecting together wireless links into a network, even when bridging solutions are not available? > >> What if there is a hurricane and some of the relief workers forgot to >> put their wireless bridging devices in their backpacks? > > No no... they won't, because they're trained to never forget these > things at home. And if they do, then there exist other super-reliefs > aids sending them trucks full of these devices. Well, here is where we have stark disagreement. I am surprised if you truly suggest that IP should not be engineered to work because it is an "error condition" to not have truckloads of equipment. Regards, Charlie P. _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Fri Dec 19 09:39:34 2008 Return-Path: X-Original-To: autoconf-archive@megatron.ietf.org Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6ABDC28C165; Fri, 19 Dec 2008 09:39:34 -0800 (PST) X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B977828C165 for ; Fri, 19 Dec 2008 09:39:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1jUZxTgvC90F for ; Fri, 19 Dec 2008 09:39:33 -0800 (PST) Received: from virginia.nps.edu (virginia.nps.edu [205.155.65.15]) by core3.amsl.com (Postfix) with ESMTP id 147A628C163 for ; Fri, 19 Dec 2008 09:39:33 -0800 (PST) Received: from [172.20.58.162] ([172.20.58.162]) by virginia.nps.edu with Microsoft SMTPSVC(6.0.3790.3959); Fri, 19 Dec 2008 09:39:22 -0800 From: Rex Buddenberg To: Teco Boot In-Reply-To: <005701c961d4$0b1fbc40$215f34c0$@nl> References: <494B8E7C.7000505@gmail.com> <494B9035.40405@gmail.com> <005701c961d4$0b1fbc40$215f34c0$@nl> Date: Fri, 19 Dec 2008 09:46:27 -0800 Message-Id: <1229708787.29772.142.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 (2.22.3.1-1.fc9) X-OriginalArrivalTime: 19 Dec 2008 17:39:22.0920 (UTC) FILETIME=[BABC6280:01C96200] Cc: autoconf@ietf.org, 'Emmanuel Baccelli' Subject: Re: [Autoconf] aspects of multi-hop wireless communication X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org Cleanest example is in satellite communications where several pipes are out-and-out one-way. On Fri, 2008-12-19 at 13:19 +0100, Teco Boot wrote: > |>>> First, there is no guarantee that a router C within S can, > |>>> symmetrically, send IP packets directly to router A. In other words, > |>>> even though C can "hear" packets from node A (since it is a member > |of > |>>> set S), there is no guarantee that A can "hear" packets from node C. > |> > |>> Sorry, could one mention why? What's the example of this? > |> > |> The simplest example (but by no means the only) is different power > |> levels transmitted by A and C. > | > |And isn't it the same for wired communications ? (and would a potential > |solution to this to have the same power levels transmitted by A and C?) > > One other reason is noise levels. > > Alex, if you can provide a noise suppression device, please send me one. > > Teco. > > > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org > https://www.ietf.org/mailman/listinfo/autoconf _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Fri Dec 19 09:46:33 2008 Return-Path: X-Original-To: autoconf-archive@megatron.ietf.org Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3E7343A6842; Fri, 19 Dec 2008 09:46:33 -0800 (PST) X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A6FB93A6842 for ; Fri, 19 Dec 2008 09:46:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N4N2BMgbupbs for ; Fri, 19 Dec 2008 09:46:32 -0800 (PST) Received: from virginia.nps.edu (virginia.nps.edu [205.155.65.15]) by core3.amsl.com (Postfix) with ESMTP id F2EF13A6820 for ; Fri, 19 Dec 2008 09:46:31 -0800 (PST) Received: from [172.20.58.162] ([172.20.58.162]) by virginia.nps.edu with Microsoft SMTPSVC(6.0.3790.3959); Fri, 19 Dec 2008 09:46:24 -0800 From: Rex Buddenberg To: Alexandru Petrescu In-Reply-To: <494BBBCB.4080804@gmail.com> References: <494B8E7C.7000505@gmail.com> <494BB75E.4050206@gmail.com> <494BBBCB.4080804@gmail.com> Date: Fri, 19 Dec 2008 09:53:28 -0800 Message-Id: <1229709208.29772.146.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 (2.22.3.1-1.fc9) X-OriginalArrivalTime: 19 Dec 2008 17:46:24.0493 (UTC) FILETIME=[B60351D0:01C96201] Cc: autoconf@ietf.org, Emmanuel Baccelli Subject: Re: [Autoconf] aspects of multi-hop wireless communication X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org You haven't been watching ... both US Army and US Marine Corps are filling up the space between brigade and company with IEEE 802.16 gear. And routing it all together. For military, WiFi is a bauble. Army worked through a proposal to implement it in command centers (think tents in the desert) and finally scrapped the proposal. Because you could indeed clip the ethernet wire but not the power cord, so not much payback. And in order to get that niggardly payback they were going to pay a lot for a layer 2 encryption solution. Spent the money on .16 gear instead ... This is wide of the MANET issues. But MANET (and autoconf) is applicable to a lot of wireless LAN and radio-WAN problems well beyond WiFi. On Fri, 2008-12-19 at 16:20 +0100, Alexandru Petrescu wrote: > Dearlove, Christopher (UK) wrote: > >> I think some solutions exist at PHY and MAC layers in the case of > >> 802.11. > > > > As has been said many times before, MANET is not just > > about 802.11. > > I may have missed something. What other than 802.11 is it about? > > Alex > > > ______________________________________________________________________ > This email has been scanned by the MessageLabs Email Security System. > For more information please visit http://www.messagelabs.com/email > ______________________________________________________________________ > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org > https://www.ietf.org/mailman/listinfo/autoconf _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Fri Dec 19 09:58:37 2008 Return-Path: X-Original-To: autoconf-archive@megatron.ietf.org Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A404E28C14C; Fri, 19 Dec 2008 09:58:37 -0800 (PST) X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 52DD828C14C for ; Fri, 19 Dec 2008 09:58:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.128 X-Spam-Level: X-Spam-Status: No, score=-6.128 tagged_above=-999 required=5 tests=[AWL=0.471, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y2hLsIAtgO09 for ; Fri, 19 Dec 2008 09:58:35 -0800 (PST) Received: from mail128.messagelabs.com (mail128.messagelabs.com [216.82.250.131]) by core3.amsl.com (Postfix) with SMTP id 834BB28C136 for ; Fri, 19 Dec 2008 09:58:35 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-14.tower-128.messagelabs.com!1229709506!24453333!1 X-StarScan-Version: 6.0.0; banners=.,-,- X-Originating-IP: [136.182.1.15] Received: (qmail 9468 invoked from network); 19 Dec 2008 17:58:26 -0000 Received: from unknown (HELO motgate5.mot.com) (136.182.1.15) by server-14.tower-128.messagelabs.com with SMTP; 19 Dec 2008 17:58:26 -0000 Received: from il27exr03.cig.mot.com (il27exr03.mot.com [10.17.196.72]) by motgate5.mot.com (8.12.11/Motorola) with ESMTP id mBJHwQ1C020856; Fri, 19 Dec 2008 10:58:26 -0700 (MST) Received: from il27vts03 (il27vts03.cig.mot.com [10.17.196.87]) by il27exr03.cig.mot.com (8.13.1/Vontu) with SMTP id mBJHwPna013893; Fri, 19 Dec 2008 11:58:25 -0600 (CST) Received: from [127.0.0.1] ([10.129.40.88]) by il27exr03.cig.mot.com (8.13.1/8.13.0) with ESMTP id mBJHwO6x013869; Fri, 19 Dec 2008 11:58:24 -0600 (CST) Message-ID: <494BE0BF.5060606@gmail.com> Date: Fri, 19 Dec 2008 18:58:23 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: Rex Buddenberg References: <494B8E7C.7000505@gmail.com> <494BB75E.4050206@gmail.com> <494BBBCB.4080804@gmail.com> <1229709208.29772.146.camel@localhost.localdomain> In-Reply-To: <1229709208.29772.146.camel@localhost.localdomain> X-Antivirus: avast! (VPS 081218-0, 18/12/2008), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected Cc: autoconf@ietf.org, Emmanuel Baccelli Subject: Re: [Autoconf] aspects of multi-hop wireless communication X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org Rex Buddenberg wrote: > You haven't been watching ... both US Army and US Marine Corps are > filling up the space between brigade and company with IEEE 802.16 gear. > And routing it all together. IETF has specs for IPv6 over 802.16 gear. It works, it's been experimented. The A-B-C terminal problem wasn't mentioned. > For military, WiFi is a bauble. Army worked through a proposal to > implement it in command centers (think tents in the desert) and finally > scrapped the proposal. Because you could indeed clip the ethernet wire > but not the power cord, so not much payback. And in order to get that > niggardly payback they were going to pay a lot for a layer 2 encryption > solution. Spent the money on .16 gear instead ... > > This is wide of the MANET issues. But MANET (and autoconf) is > applicable to a lot of wireless LAN and radio-WAN problems well beyond > WiFi. AS above, IPv6 over 802.16 works has been implemented, from emulators to the real link layer. What other link layer? Alex > On Fri, 2008-12-19 at 16:20 +0100, Alexandru Petrescu wrote: >> Dearlove, Christopher (UK) wrote: >>>> I think some solutions exist at PHY and MAC layers in the case of >>>> 802.11. >>> As has been said many times before, MANET is not just >>> about 802.11. >> I may have missed something. What other than 802.11 is it about? >> >> Alex >> >> >> ______________________________________________________________________ >> This email has been scanned by the MessageLabs Email Security System. >> For more information please visit http://www.messagelabs.com/email >> ______________________________________________________________________ >> _______________________________________________ >> Autoconf mailing list >> Autoconf@ietf.org >> https://www.ietf.org/mailman/listinfo/autoconf > > ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Fri Dec 19 09:59:01 2008 Return-Path: X-Original-To: autoconf-archive@megatron.ietf.org Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EE7AB28C170; Fri, 19 Dec 2008 09:59:01 -0800 (PST) X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0CB5D28C14C for ; Fri, 19 Dec 2008 09:59:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.155 X-Spam-Level: X-Spam-Status: No, score=-6.155 tagged_above=-999 required=5 tests=[AWL=0.444, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XVBhti6MaIn4 for ; Fri, 19 Dec 2008 09:59:00 -0800 (PST) Received: from mail153.messagelabs.com (mail153.messagelabs.com [216.82.253.51]) by core3.amsl.com (Postfix) with SMTP id 13B8428C170 for ; Fri, 19 Dec 2008 09:59:00 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-12.tower-153.messagelabs.com!1229709530!14014205!1 X-StarScan-Version: 6.0.0; banners=.,-,- X-Originating-IP: [136.182.1.14] Received: (qmail 2577 invoked from network); 19 Dec 2008 17:58:51 -0000 Received: from unknown (HELO motgate4.mot.com) (136.182.1.14) by server-12.tower-153.messagelabs.com with SMTP; 19 Dec 2008 17:58:51 -0000 Received: from il27exr03.cig.mot.com (il27exr03.mot.com [10.17.196.72]) by motgate4.mot.com (8.12.11/Motorola) with ESMTP id mBJHwos9003037; Fri, 19 Dec 2008 10:58:50 -0700 (MST) Received: from il27vts01 (il27vts01.cig.mot.com [10.17.196.85]) by il27exr03.cig.mot.com (8.13.1/Vontu) with SMTP id mBJHwofq014118; Fri, 19 Dec 2008 11:58:50 -0600 (CST) Received: from [127.0.0.1] ([10.129.40.88]) by il27exr03.cig.mot.com (8.13.1/8.13.0) with ESMTP id mBJHwmTe014114; Fri, 19 Dec 2008 11:58:49 -0600 (CST) Message-ID: <494BE0D8.4070509@gmail.com> Date: Fri, 19 Dec 2008 18:58:48 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: "Charles E. Perkins" References: <494B8E7C.7000505@gmail.com> <494BB75E.4050206@gmail.com> <494BC360.1000109@gmail.com> <494BC927.1020400@gmail.com> <494BCCCC.6050206@earthlink.net> <494BCFEF.2010100@gmail.com> <494BD45A.2090106@earthlink.net> In-Reply-To: <494BD45A.2090106@earthlink.net> X-Antivirus: avast! (VPS 081218-0, 18/12/2008), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected Cc: autoconf@ietf.org Subject: Re: [Autoconf] aspects of multi-hop wireless communication X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org Charles E. Perkins wrote: > Hello Alex, > > I think we're approaching the point of having to agree to disagree. > >> Errr... somehow yes, if I'm permitted. I simply suggest a >> link-layer solution to a link-layer problem. > > IP is a solution that puts together different links. Yes, provided IP knows what are those links, each one in particular detail. > If you would like to suggest limiting the applicability of IP to > _only_ be allowed to work for links with specific characteristics, > then I think you should be explicit about it. YEs, I'm explicit: it's wifi. > Perhaps you would get some support, but I'm guessing it would not > arise from the community of engineers and developers within autoconf > or manet. > > >> >>> What if I want to join a working ad hoc network of devices using >>> solutions that have already been developed without bridging? >>> Why is this bad? >> >> It's not bad. > > Whew! > >> >> One would first deploy bridges in networks that are partitioned and >> in need of bridges. Then any new terminal needing to join could do >> so, without needing to be itself a bridge. >> >> The question is why does one refuse the use of bridges when the >> network is partitioned at link-layer? > > That's not a question I have raised, nor do I think that the answer > would be illuminating. But my answer is that no one is making any > such refusal. > > The question is, why can't we use IP as a good tool to solve problems > of connecting together wireless links into a network, even when > bridging solutions are not available? WE need to be able to know over what is IP supposed to run. If we don't have a good under-IP then it can't run. Actually we could think as much it will run as we think it won't run. Sorry, I can't be clearer than that. Alex >>> What if there is a hurricane and some of the relief workers >>> forgot to put their wireless bridging devices in their backpacks? >>> >> >> No no... they won't, because they're trained to never forget these >> things at home. And if they do, then there exist other >> super-reliefs aids sending them trucks full of these devices. > > Well, here is where we have stark disagreement. I am surprised if > you truly suggest that IP should not be engineered to work because it > is an "error condition" to not have truckloads of equipment. > > > Regards, Charlie P. > > > ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Fri Dec 19 10:01:57 2008 Return-Path: X-Original-To: autoconf-archive@megatron.ietf.org Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5F7113A6A24; Fri, 19 Dec 2008 10:01:57 -0800 (PST) X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CACBB3A6A24 for ; Fri, 19 Dec 2008 10:01:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.178 X-Spam-Level: X-Spam-Status: No, score=-6.178 tagged_above=-999 required=5 tests=[AWL=0.421, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KavWT-ys76XH for ; Fri, 19 Dec 2008 10:01:55 -0800 (PST) Received: from mail153.messagelabs.com (mail153.messagelabs.com [216.82.253.51]) by core3.amsl.com (Postfix) with SMTP id E00623A69F7 for ; Fri, 19 Dec 2008 10:01:54 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-5.tower-153.messagelabs.com!1229709706!7495091!1 X-StarScan-Version: 6.0.0; banners=.,-,- X-Originating-IP: [136.182.1.15] Received: (qmail 14677 invoked from network); 19 Dec 2008 18:01:46 -0000 Received: from unknown (HELO motgate5.mot.com) (136.182.1.15) by server-5.tower-153.messagelabs.com with SMTP; 19 Dec 2008 18:01:46 -0000 Received: from il27exr03.cig.mot.com (il27exr03.mot.com [10.17.196.72]) by motgate5.mot.com (8.12.11/Motorola) with ESMTP id mBJI1f0D021399; Fri, 19 Dec 2008 11:01:41 -0700 (MST) Received: from il27vts02.mot.com (il27vts02.cig.mot.com [10.17.196.86]) by il27exr03.cig.mot.com (8.13.1/Vontu) with SMTP id mBJI1eS7016455; Fri, 19 Dec 2008 12:01:40 -0600 (CST) Received: from [127.0.0.1] ([10.129.40.88]) by il27exr03.cig.mot.com (8.13.1/8.13.0) with ESMTP id mBJI1cGa016426; Fri, 19 Dec 2008 12:01:39 -0600 (CST) Message-ID: <494BE182.9040302@gmail.com> Date: Fri, 19 Dec 2008 19:01:38 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: Rex Buddenberg References: <494B8E7C.7000505@gmail.com> <494B9035.40405@gmail.com> <005701c961d4$0b1fbc40$215f34c0$@nl> <1229708787.29772.142.camel@localhost.localdomain> In-Reply-To: <1229708787.29772.142.camel@localhost.localdomain> X-Antivirus: avast! (VPS 081218-0, 18/12/2008), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected Cc: autoconf@ietf.org, 'Emmanuel Baccelli' Subject: Re: [Autoconf] aspects of multi-hop wireless communication X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org Rex Buddenberg wrote: > Cleanest example is in satellite communications where several pipes > are out-and-out one-way. Hi Rex, sorry, I don't know the terms. But I could legitimately ask about the name of the link layer for out-and-out one-way. I think I know about some specs for IP over uni-directional links (UDLR) and some implementations for it. Alex > > > > On Fri, 2008-12-19 at 13:19 +0100, Teco Boot wrote: >> |>>> First, there is no guarantee that a router C within S can, >> |>>> symmetrically, send IP packets directly to router A. In other >> words, |>>> even though C can "hear" packets from node A (since it >> is a member |of |>>> set S), there is no guarantee that A can >> "hear" packets from node C. |> |>> Sorry, could one mention why? >> What's the example of this? |> |> The simplest example (but by no >> means the only) is different power |> levels transmitted by A and >> C. | |And isn't it the same for wired communications ? (and would >> a potential |solution to this to have the same power levels >> transmitted by A and C?) >> >> One other reason is noise levels. >> >> Alex, if you can provide a noise suppression device, please send me >> one. >> >> Teco. >> >> >> _______________________________________________ Autoconf mailing >> list Autoconf@ietf.org >> https://www.ietf.org/mailman/listinfo/autoconf > > ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Fri Dec 19 10:20:37 2008 Return-Path: X-Original-To: autoconf-archive@megatron.ietf.org Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 87C573A6A60; Fri, 19 Dec 2008 10:20:37 -0800 (PST) X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D23253A6A60 for ; Fri, 19 Dec 2008 10:20:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nLcA6ivRnChU for ; Fri, 19 Dec 2008 10:20:35 -0800 (PST) Received: from elasmtp-curtail.atl.sa.earthlink.net (elasmtp-curtail.atl.sa.earthlink.net [209.86.89.64]) by core3.amsl.com (Postfix) with ESMTP id 0899E3A69AF for ; Fri, 19 Dec 2008 10:20:34 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=XbYJbWzefKVthzO3yj5J2HinJWF34clXoUQUf/yuQKDAMYguL60hsjalCgtBR/Z3; h=Received:Message-ID:Date:From:Organization:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [99.51.74.16] (helo=[192.168.1.100]) by elasmtp-curtail.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1LDjwu-0001lv-7r; Fri, 19 Dec 2008 13:19:44 -0500 Message-ID: <494BE5A5.4020205@earthlink.net> Date: Fri, 19 Dec 2008 10:19:17 -0800 From: "Charles E. Perkins" Organization: Wichorus Inc. User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: Alexandru Petrescu References: <494B8E7C.7000505@gmail.com> <494BB75E.4050206@gmail.com> <494BC360.1000109@gmail.com> <494BC927.1020400@gmail.com> <494BCCCC.6050206@earthlink.net> <494BCFEF.2010100@gmail.com> <494BD45A.2090106@earthlink.net> <494BE0D8.4070509@gmail.com> In-Reply-To: <494BE0D8.4070509@gmail.com> X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f52d9044ce712216df66e5c81d83d8dfccd350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.51.74.16 Cc: autoconf@ietf.org Subject: Re: [Autoconf] aspects of multi-hop wireless communication X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org Hello Alex, Alexandru Petrescu wrote: > >> >> IP is a solution that puts together different links. > > Yes, provided IP knows what are those links, each one in particular > detail. Actually, all that is needed is for IP to have a useful interface to the device driver. > >> If you would like to suggest limiting the applicability of IP to >> _only_ be allowed to work for links with specific characteristics, >> then I think you should be explicit about it. > > YEs, I'm explicit: it's wifi. That restriction is not in the charter. Do you want to campaign for a charter revision? > >> That's not a question I have raised, nor do I think that the answer >> would be illuminating. But my answer is that no one is making any >> such refusal. >> >> The question is, why can't we use IP as a good tool to solve problems >> of connecting together wireless links into a network, even when >> bridging solutions are not available? > > WE need to be able to know over what is IP supposed to run. If we > don't have a good under-IP then it can't run. Actually we could think > as much it will run as we think it won't run. Sorry, I can't be > clearer than that. But is does run. I guess that's also pretty clear. I'd like for it to run using standard protocols. And not just for WiFi. Regards, Charlie P. _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Fri Dec 19 10:36:31 2008 Return-Path: X-Original-To: autoconf-archive@megatron.ietf.org Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 251613A6A60; Fri, 19 Dec 2008 10:36:31 -0800 (PST) X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 31A303A6A15 for ; Fri, 19 Dec 2008 10:36:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.668 X-Spam-Level: X-Spam-Status: No, score=-1.668 tagged_above=-999 required=5 tests=[AWL=0.378, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hMQ9c8yxWT1Z for ; Fri, 19 Dec 2008 10:36:28 -0800 (PST) Received: from cpsmtpo-eml03.kpnxchange.com (cpsmtpo-eml03.KPNXCHANGE.COM [213.75.38.152]) by core3.amsl.com (Postfix) with ESMTP id D3D883A67E9 for ; Fri, 19 Dec 2008 10:36:26 -0800 (PST) Received: from cpsmtp-eml101.kpnxchange.com ([213.75.84.101]) by cpsmtpo-eml03.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 19 Dec 2008 19:36:16 +0100 Received: from M90Teco ([86.83.9.22]) by cpsmtp-eml101.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 19 Dec 2008 19:36:15 +0100 From: "Teco Boot" To: "'Alexandru Petrescu'" References: <494B8E7C.7000505@gmail.com> <494BB75E.4050206@gmail.com> <494BC360.1000109@gmail.com> <494BC927.1020400@gmail.com> <494BCCCC.6050206@earthlink.net> <494BCFEF.2010100@gmail.com> <494BD45A.2090106@earthlink.net> <494BE0D8.4070509@gmail.com> In-Reply-To: <494BE0D8.4070509@gmail.com> Date: Fri, 19 Dec 2008 19:36:10 +0100 Message-ID: <00ae01c96208$aa2ebd20$fe8c3760$@nl> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcliA3aKUduBi6ffSTGyAZWCfya7mQAA62hg Content-Language: nl X-OriginalArrivalTime: 19 Dec 2008 18:36:15.0418 (UTC) FILETIME=[ACBE41A0:01C96208] Cc: autoconf@ietf.org Subject: Re: [Autoconf] aspects of multi-hop wireless communication X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org |YEs, I'm explicit: it's wifi. Please explain to me how I can connect couples of hosts to wifi bridges configured in ad hoc mode. Hint: A bridge shall not connect to an IEEE 802.11 Independent BSS (802.1D-2004) Teco. _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Fri Dec 19 10:39:35 2008 Return-Path: X-Original-To: autoconf-archive@megatron.ietf.org Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 467113A6A63; Fri, 19 Dec 2008 10:39:35 -0800 (PST) X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 114203A6A63 for ; Fri, 19 Dec 2008 10:39:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.543 X-Spam-Level: X-Spam-Status: No, score=-6.543 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NHVewz8LtAlI for ; Fri, 19 Dec 2008 10:39:33 -0800 (PST) Received: from mail128.messagelabs.com (mail128.messagelabs.com [216.82.250.131]) by core3.amsl.com (Postfix) with SMTP id 374AF3A6A24 for ; Fri, 19 Dec 2008 10:39:33 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-7.tower-128.messagelabs.com!1229711964!3772878!1 X-StarScan-Version: 6.0.0; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 14308 invoked from network); 19 Dec 2008 18:39:25 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-7.tower-128.messagelabs.com with SMTP; 19 Dec 2008 18:39:25 -0000 Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id mBJIdJT2020085; Fri, 19 Dec 2008 11:39:19 -0700 (MST) Received: from il06vts04.mot.com (il06vts04.mot.com [129.188.137.144]) by il06exr02.mot.com (8.13.1/Vontu) with SMTP id mBJIdJBa014650; Fri, 19 Dec 2008 12:39:19 -0600 (CST) Received: from [127.0.0.1] ([10.129.40.75]) by il06exr02.mot.com (8.13.1/8.13.0) with ESMTP id mBJIdHCU014628; Fri, 19 Dec 2008 12:39:18 -0600 (CST) Message-ID: <494BEA55.3080304@gmail.com> Date: Fri, 19 Dec 2008 19:39:17 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: "Charles E. Perkins" References: <494B8E7C.7000505@gmail.com> <494BB75E.4050206@gmail.com> <494BC360.1000109@gmail.com> <494BC927.1020400@gmail.com> <494BCCCC.6050206@earthlink.net> <494BCFEF.2010100@gmail.com> <494BD45A.2090106@earthlink.net> <494BE0D8.4070509@gmail.com> <494BE5A5.4020205@earthlink.net> In-Reply-To: <494BE5A5.4020205@earthlink.net> X-Antivirus: avast! (VPS 081218-0, 18/12/2008), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected Cc: autoconf@ietf.org Subject: Re: [Autoconf] aspects of multi-hop wireless communication X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org Charles E. Perkins wrote: > > Hello Alex, > > Alexandru Petrescu wrote: >> >>> >>> IP is a solution that puts together different links. >> >> Yes, provided IP knows what are those links, each one in particular >> detail. > > Actually, all that is needed is for IP to have a useful interface to the > device driver. I agree. Device driver interfaces are known for several wireless link layers. I think there isn't one special for the A-B-C hidden terminal problem. I may be wrong, but I think. >>> If you would like to suggest limiting the applicability of IP to >>> _only_ be allowed to work for links with specific characteristics, >>> then I think you should be explicit about it. >> >> YEs, I'm explicit: it's wifi. > > That restriction is not in the charter. Do you want to campaign > for a charter revision? Right... No, no, I don't want to restrict to wifi. I think the A-B-C hidden terminal problem was mentioned in the wifi context. I haven't seen it elsewhere. I agree for a solution IP to run over several link layers, for example wifi and 802.16. When a router needs to route between a wifi and a 802.16 link it never has the hidden terminal problem. >>> That's not a question I have raised, nor do I think that the answer >>> would be illuminating. But my answer is that no one is making any >>> such refusal. >>> >>> The question is, why can't we use IP as a good tool to solve problems >>> of connecting together wireless links into a network, even when >>> bridging solutions are not available? >> >> WE need to be able to know over what is IP supposed to run. If we >> don't have a good under-IP then it can't run. Actually we could think >> as much it will run as we think it won't run. Sorry, I can't be >> clearer than that. > > But is does run. I guess that's also pretty clear. > > I'd like for it to run using standard protocols. > > And not just for WiFi. Yes, I'd like to help with a protocol for wireless links, like wifi and 802.16. But routing between these two doesn't expose the hidden terminal problem. I'm pretty sure about it, I can say that because I have experience with IP over wifi and over 802.16 (emulated) links. Alex ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Fri Dec 19 10:41:06 2008 Return-Path: X-Original-To: autoconf-archive@megatron.ietf.org Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7469D3A696C; Fri, 19 Dec 2008 10:41:06 -0800 (PST) X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CC7333A6908 for ; Fri, 19 Dec 2008 10:41:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.545 X-Spam-Level: X-Spam-Status: No, score=-6.545 tagged_above=-999 required=5 tests=[AWL=0.054, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yzuv-nE+Ka8t for ; Fri, 19 Dec 2008 10:41:05 -0800 (PST) Received: from mail153.messagelabs.com (mail153.messagelabs.com [216.82.253.51]) by core3.amsl.com (Postfix) with SMTP id 0DB5B3A696C for ; Fri, 19 Dec 2008 10:41:05 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-7.tower-153.messagelabs.com!1229712056!8217677!1 X-StarScan-Version: 6.0.0; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 17413 invoked from network); 19 Dec 2008 18:40:56 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-7.tower-153.messagelabs.com with SMTP; 19 Dec 2008 18:40:56 -0000 Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id mBJIeqT9020462; Fri, 19 Dec 2008 11:40:56 -0700 (MST) Received: from il06vts04.mot.com (il06vts04.mot.com [129.188.137.144]) by il06exr02.mot.com (8.13.1/Vontu) with SMTP id mBJIepvS015255; Fri, 19 Dec 2008 12:40:51 -0600 (CST) Received: from [127.0.0.1] ([10.129.40.75]) by il06exr02.mot.com (8.13.1/8.13.0) with ESMTP id mBJIeowc015249; Fri, 19 Dec 2008 12:40:50 -0600 (CST) Message-ID: <494BEAB1.3040700@gmail.com> Date: Fri, 19 Dec 2008 19:40:49 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: Teco Boot References: <494B8E7C.7000505@gmail.com> <494BB75E.4050206@gmail.com> <494BC360.1000109@gmail.com> <494BC927.1020400@gmail.com> <494BCCCC.6050206@earthlink.net> <494BCFEF.2010100@gmail.com> <494BD45A.2090106@earthlink.net> <494BE0D8.4070509@gmail.com> <00ae01c96208$aa2ebd20$fe8c3760$@nl> In-Reply-To: <00ae01c96208$aa2ebd20$fe8c3760$@nl> X-Antivirus: avast! (VPS 081218-0, 18/12/2008), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected Cc: autoconf@ietf.org Subject: Re: [Autoconf] aspects of multi-hop wireless communication X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org Teco Boot wrote: > |YEs, I'm explicit: it's wifi. > > Please explain to me how I can connect couples of hosts to wifi bridges > configured in ad hoc mode. > Hint: A bridge shall not connect to an IEEE 802.11 Independent BSS > (802.1D-2004) The picture I can draw has a bridge with two wifi interfaces and runs brctl software (which is pure link-layer, no IP). Would this be ok if I do? Alex ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Fri Dec 19 10:54:24 2008 Return-Path: X-Original-To: autoconf-archive@megatron.ietf.org Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 414B53A6896; Fri, 19 Dec 2008 10:54:24 -0800 (PST) X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7C03D3A6896 for ; Fri, 19 Dec 2008 10:54:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s3M4e-pJWwum for ; Fri, 19 Dec 2008 10:54:21 -0800 (PST) Received: from elasmtp-scoter.atl.sa.earthlink.net (elasmtp-scoter.atl.sa.earthlink.net [209.86.89.67]) by core3.amsl.com (Postfix) with ESMTP id 7475C3A67EF for ; Fri, 19 Dec 2008 10:54:21 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=tka83y20Bd0P+G5OUchWp85Vury607Mg8jFDuC6PbilPVXt6qVbUvt7FSe5HJC5Y; h=Received:Message-ID:Date:From:Organization:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [99.51.74.16] (helo=[192.168.1.100]) by elasmtp-scoter.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1LDkUH-000507-AF; Fri, 19 Dec 2008 13:54:13 -0500 Message-ID: <494BEDD0.9020708@earthlink.net> Date: Fri, 19 Dec 2008 10:54:08 -0800 From: "Charles E. Perkins" Organization: Wichorus Inc. User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: Alexandru Petrescu References: <494B8E7C.7000505@gmail.com> <494BB75E.4050206@gmail.com> <494BC360.1000109@gmail.com> <494BC927.1020400@gmail.com> <494BCCCC.6050206@earthlink.net> <494BCFEF.2010100@gmail.com> <494BD45A.2090106@earthlink.net> <494BE0D8.4070509@gmail.com> <494BE5A5.4020205@earthlink.net> <494BEA55.3080304@gmail.com> In-Reply-To: <494BEA55.3080304@gmail.com> X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f5253b8d681a1f00e43642b25aab5f754cc350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.51.74.16 Cc: autoconf@ietf.org Subject: Re: [Autoconf] aspects of multi-hop wireless communication X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org Hello again Alex, Alexandru Petrescu wrote: > >> >> Actually, all that is needed is for IP to have a useful interface to the >> device driver. > > I agree. Device driver interfaces are known for several wireless link > layers. I think there isn't one special for the A-B-C hidden terminal > problem. I may be wrong, but I think. That's because IP doesn't need to know whether the link has problems with hidden terminals. > >>>> If you would like to suggest limiting the applicability of IP to >>>> _only_ be allowed to work for links with specific characteristics, >>>> then I think you should be explicit about it. >>> >>> YEs, I'm explicit: it's wifi. >> >> That restriction is not in the charter. Do you want to campaign >> for a charter revision? > > Right... No, no, I don't want to restrict to wifi. I think the A-B-C > hidden terminal problem was mentioned in the wifi context. I haven't > seen it elsewhere. > > I agree for a solution IP to run over several link layers, for example > wifi and 802.16. > > When a router needs to route between a wifi and a 802.16 link it never > has the hidden terminal problem. The main thing a router needs, is to know the next hop. > > > > Yes, I'd like to help with a protocol for wireless links, like wifi > and 802.16. But routing between these two doesn't expose the hidden > terminal problem. I'm pretty sure about it, I can say that because I > have experience with IP over wifi and over 802.16 (emulated) links. Again, routing doesn't need to know about that. And, in fact, I believe that IP doesn't have to know about asymmetry, nontransitivity, or the time of day. It just has to know about the next hop. But the routing protocols have to be engineered to provide that information. And, as this overly long and time-consuming discussion has shown, there is a bit of confusion about how to engineer routing protocols that work over the links under discussion. You seem to claim that we shouldn't worry about them because the link layer has to solve problems like asymmetry and hidden terminal problems. I'm of the opinion that routing protocols have to be engineered in some circumstances to avoid making unwarranted inferences about symmetry and transitivity. I think it would be nice to identify exactly what your concern is. Once it was WiFi only, now it's not. Do you think that routing protocol work should only be chartered for links that conform to certain regularity assumptions like symmetry and transitivity? Regards, Charlie P. _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Fri Dec 19 11:42:29 2008 Return-Path: X-Original-To: autoconf-archive@megatron.ietf.org Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4E0093A6A76; Fri, 19 Dec 2008 11:42:29 -0800 (PST) X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BA6DB3A6A76 for ; Fri, 19 Dec 2008 11:42:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.685 X-Spam-Level: X-Spam-Status: No, score=-1.685 tagged_above=-999 required=5 tests=[AWL=0.361, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rszznp6mVa2u for ; Fri, 19 Dec 2008 11:42:27 -0800 (PST) Received: from hpsmtp-eml17.kpnxchange.com (hpsmtp-eml17.KPNXCHANGE.COM [213.75.38.117]) by core3.amsl.com (Postfix) with ESMTP id C7B913A6A73 for ; Fri, 19 Dec 2008 11:42:26 -0800 (PST) Received: from cpsmtp-eml109.kpnxchange.com ([213.75.84.109]) by hpsmtp-eml17.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 19 Dec 2008 20:42:16 +0100 Received: from M90Teco ([86.83.9.22]) by cpsmtp-eml109.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 19 Dec 2008 20:42:16 +0100 From: "Teco Boot" To: "'Alexandru Petrescu'" References: <494B8E7C.7000505@gmail.com> <494BB75E.4050206@gmail.com> <494BC360.1000109@gmail.com> <494BC927.1020400@gmail.com> <494BCCCC.6050206@earthlink.net> <494BCFEF.2010100@gmail.com> <494BD45A.2090106@earthlink.net> <494BE0D8.4070509@gmail.com> <00ae01c96208$aa2ebd20$fe8c3760$@nl> <494BEAB1.3040700@gmail.com> In-Reply-To: <494BEAB1.3040700@gmail.com> Date: Fri, 19 Dec 2008 20:42:11 +0100 Message-ID: <00af01c96211$e2c97770$a85c6650$@nl> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcliCVZesVzIjMvES1miQi44lYv9vgAB3TXQ Content-Language: nl X-OriginalArrivalTime: 19 Dec 2008 19:42:16.0078 (UTC) FILETIME=[E57B02E0:01C96211] Cc: autoconf@ietf.org Subject: Re: [Autoconf] aspects of multi-hop wireless communication X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org Try it, and you will see it will fail. OK, you can modify the code if you have a C compiler nearby, and some sources to modify. But that is no longer wifi. You could enable routing, and you are done! Play a little with it, and check your (false) assumptions. Teco. |-----Oorspronkelijk bericht----- |Van: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com] |Verzonden: vrijdag 19 december 2008 19:41 |Aan: Teco Boot |CC: autoconf@ietf.org |Onderwerp: Re: [Autoconf] aspects of multi-hop wireless communication | |Teco Boot wrote: |> |YEs, I'm explicit: it's wifi. |> |> Please explain to me how I can connect couples of hosts to wifi |bridges |> configured in ad hoc mode. |> Hint: A bridge shall not connect to an IEEE 802.11 Independent BSS |> (802.1D-2004) | |The picture I can draw has a bridge with two wifi interfaces and runs |brctl software (which is pure link-layer, no IP). Would this be ok if I |do? | |Alex | | |______________________________________________________________________ |This email has been scanned by the MessageLabs Email Security System. |For more information please visit http://www.messagelabs.com/email |______________________________________________________________________ _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Fri Dec 19 12:04:48 2008 Return-Path: X-Original-To: autoconf-archive@megatron.ietf.org Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C31A33A6A8B; Fri, 19 Dec 2008 12:04:48 -0800 (PST) X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B6B953A6A87 for ; Fri, 19 Dec 2008 12:04:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.199 X-Spam-Level: X-Spam-Status: No, score=-6.199 tagged_above=-999 required=5 tests=[AWL=0.400, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oX5lmXayr5d1 for ; Fri, 19 Dec 2008 12:04:47 -0800 (PST) Received: from mail153.messagelabs.com (mail153.messagelabs.com [216.82.253.51]) by core3.amsl.com (Postfix) with SMTP id D3A713A6A8B for ; Fri, 19 Dec 2008 12:04:46 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-4.tower-153.messagelabs.com!1229717076!12562903!1 X-StarScan-Version: 6.0.0; banners=.,-,- X-Originating-IP: [136.182.1.13] Received: (qmail 28133 invoked from network); 19 Dec 2008 20:04:36 -0000 Received: from unknown (HELO motgate3.mot.com) (136.182.1.13) by server-4.tower-153.messagelabs.com with SMTP; 19 Dec 2008 20:04:36 -0000 Received: from il27exr03.cig.mot.com (il27exr03.mot.com [10.17.196.72]) by motgate3.mot.com (8.12.11/Motorola) with ESMTP id mBJK4UqC008810; Fri, 19 Dec 2008 13:04:35 -0700 (MST) Received: from il27vts01 (il27vts01.cig.mot.com [10.17.196.85]) by il27exr03.cig.mot.com (8.13.1/Vontu) with SMTP id mBJK4TU2002215; Fri, 19 Dec 2008 14:04:29 -0600 (CST) Received: from [127.0.0.1] ([10.129.40.67]) by il27exr03.cig.mot.com (8.13.1/8.13.0) with ESMTP id mBJK4SWi002206; Fri, 19 Dec 2008 14:04:29 -0600 (CST) Message-ID: <494BFE4B.9000601@gmail.com> Date: Fri, 19 Dec 2008 21:04:27 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: Teco Boot References: <494B8E7C.7000505@gmail.com> <494BB75E.4050206@gmail.com> <494BC360.1000109@gmail.com> <494BC927.1020400@gmail.com> <494BCCCC.6050206@earthlink.net> <494BCFEF.2010100@gmail.com> <494BD45A.2090106@earthlink.net> <494BE0D8.4070509@gmail.com> <00ae01c96208$aa2ebd20$fe8c3760$@nl> <494BEAB1.3040700@gmail.com> <00af01c96211$e2c97770$a85c6650$@nl> In-Reply-To: <00af01c96211$e2c97770$a85c6650$@nl> X-Antivirus: avast! (VPS 081218-0, 18/12/2008), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected Cc: autoconf@ietf.org Subject: Re: [Autoconf] aspects of multi-hop wireless communication X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org Teco Boot wrote: > Try it, and you will see it will fail. > OK, you can modify the code if you have a C compiler nearby, and some > sources to modify. I'm not meaning to modify any code. It's existing software doing bridging between two interfaces as it always did. > But that is no longer wifi. Well, it's two 802.11a/b interfaces, running as before. I could put both interfaces in ad-hoc mode with iwconfig. There's probably a misunderstanding between what the IEEE standard documents mean by "ad-hoc" and what iwconfig and related implementations mean by "ad-hoc" but I'm sure it works, by experience. Or I could set up both to act as access points, it's the same. (the only visible difference between AP mode and ad-hoc modes in implementation is the MAC address of the essid... in AP mode it's the real MAC address of the interface doing AP, in ad-hoc mode it's some random 48bit). The resolution between this 48bit number and essid ascii name is done by 802.11 link-layer exchanges (probe req/reply IIRC). > You could enable routing, and you are done! Why doing routing when I could do bridging, simpler, widely available software. > Play a little with it, and check your (false) assumptions. I'm not sure which assumption you think I made false? The fact that I could build a bridge with brctl and two wifi interfaces? Alex ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Fri Dec 19 12:12:33 2008 Return-Path: X-Original-To: autoconf-archive@megatron.ietf.org Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2B16E28C160; Fri, 19 Dec 2008 12:12:33 -0800 (PST) X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C8E3B3A6A80 for ; Fri, 19 Dec 2008 12:12:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.547 X-Spam-Level: X-Spam-Status: No, score=-6.547 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3rZ7FuIwTRpd for ; Fri, 19 Dec 2008 12:12:31 -0800 (PST) Received: from mail153.messagelabs.com (mail153.messagelabs.com [216.82.253.51]) by core3.amsl.com (Postfix) with SMTP id D61583A6A6B for ; Fri, 19 Dec 2008 12:12:30 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-6.tower-153.messagelabs.com!1229717542!6503741!1 X-StarScan-Version: 6.0.0; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 11908 invoked from network); 19 Dec 2008 20:12:22 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-6.tower-153.messagelabs.com with SMTP; 19 Dec 2008 20:12:22 -0000 Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id mBJKCLPD011571; Fri, 19 Dec 2008 13:12:21 -0700 (MST) Received: from il06vts04.mot.com (il06vts04.mot.com [129.188.137.144]) by il06exr03.mot.com (8.13.1/Vontu) with SMTP id mBJKCLvX004161; Fri, 19 Dec 2008 14:12:21 -0600 (CST) Received: from [127.0.0.1] ([10.129.40.67]) by il06exr03.mot.com (8.13.1/8.13.0) with ESMTP id mBJKCK0f004146; Fri, 19 Dec 2008 14:12:20 -0600 (CST) Message-ID: <494C0023.9030004@gmail.com> Date: Fri, 19 Dec 2008 21:12:19 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: "Charles E. Perkins" References: <494B8E7C.7000505@gmail.com> <494BB75E.4050206@gmail.com> <494BC360.1000109@gmail.com> <494BC927.1020400@gmail.com> <494BCCCC.6050206@earthlink.net> <494BCFEF.2010100@gmail.com> <494BD45A.2090106@earthlink.net> <494BE0D8.4070509@gmail.com> <494BE5A5.4020205@earthlink.net> <494BEA55.3080304@gmail.com> <494BEDD0.9020708@earthlink.net> In-Reply-To: <494BEDD0.9020708@earthlink.net> X-Antivirus: avast! (VPS 081218-0, 18/12/2008), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected Cc: autoconf@ietf.org Subject: Re: [Autoconf] aspects of multi-hop wireless communication X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org Charles please let me bring forward a clarifying point, which is your last point, and sorry for too long emails. > Do you think that routing protocol work should only be chartered for > links that conform to certain regularity assumptions like symmetry > and transitivity? Is this a MANET WG question? I think in AUTOCONF WG we don't do work that applies _only_ to DYMO, nor to OLSR, nor to DSR. In this case, an AUTOCONF address and prefix configuration mechanism would be used too by something else than DYMO, other than OLSR, other than DSR. It could be used by two Mobile Routers not running DYMO, nor OLSR, nor DSR. It's very straightforward to clarify this particular point, people could and have expressed opinions. If the AUTOCONF mechanism is to be only for DYMO/OLSR/DSR exclusively then I just say ok for the draft titled 'aspects of multi-hop...'. The points I mainly agree with you follow below... Charles E. Perkins wrote: > > Hello again Alex, > > Alexandru Petrescu wrote: >> >>> >>> Actually, all that is needed is for IP to have a useful interface >>> to the device driver. >> >> I agree. Device driver interfaces are known for several wireless >> link layers. I think there isn't one special for the A-B-C hidden >> terminal problem. I may be wrong, but I think. > > That's because IP doesn't need to know whether the link has problems > with hidden terminals. I fully agree. >> Yes, I'd like to help with a protocol for wireless links, like wifi >> and 802.16. But routing between these two doesn't expose the >> hidden terminal problem. I'm pretty sure about it, I can say that >> because I have experience with IP over wifi and over 802.16 >> (emulated) links. > > Again, routing doesn't need to know about that. And, in fact, I > believe that IP doesn't have to know about asymmetry, > nontransitivity, or the time of day. It just has to know about the > next hop. I partially agree (may need link quality params, maybe expressed as TOS in OSPF, for better decisions) but in this discussion context I fully agree. > You seem to claim that we shouldn't worry about them because the link > layer has to solve problems like asymmetry and hidden terminal > problems. I'm of the opinion that routing protocols have to be > engineered in some circumstances to avoid making unwarranted > inferences about symmetry and transitivity. Maybe yes, but maybe in MANET WG? > I think it would be nice to identify exactly what your concern is. > Once it was WiFi only, now it's not. Sorry, to make myself clear: in this discussion wifi and 802.16 were mentioned. I agree both should be dealt with. I don't agree to deal with a link-layer whose name I don't know. Alex ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Fri Dec 19 12:52:39 2008 Return-Path: X-Original-To: autoconf-archive@megatron.ietf.org Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0FA0E3A6862; Fri, 19 Dec 2008 12:52:39 -0800 (PST) X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A5EE63A6800 for ; Fri, 19 Dec 2008 12:52:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DBUuROeZ6pj5 for ; Fri, 19 Dec 2008 12:52:36 -0800 (PST) Received: from elasmtp-scoter.atl.sa.earthlink.net (elasmtp-scoter.atl.sa.earthlink.net [209.86.89.67]) by core3.amsl.com (Postfix) with ESMTP id B97973A677E for ; Fri, 19 Dec 2008 12:52:36 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=n31th5d9AndxiCzk7gHFhnj3ICUvADwHD4/e0RTvwRP/vGZJiEBxGckmgmBBz6ak; h=Received:Message-ID:Date:From:Organization:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [64.161.0.238] (helo=[10.34.34.68]) by elasmtp-scoter.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1LDmKi-0003aw-2X; Fri, 19 Dec 2008 15:52:28 -0500 Message-ID: <494C0986.9020404@earthlink.net> Date: Fri, 19 Dec 2008 12:52:22 -0800 From: "Charles E. Perkins" Organization: Wichorus Inc. User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: Alexandru Petrescu References: <494B8E7C.7000505@gmail.com> <494BB75E.4050206@gmail.com> <494BC360.1000109@gmail.com> <494BC927.1020400@gmail.com> <494BCCCC.6050206@earthlink.net> <494BCFEF.2010100@gmail.com> <494BD45A.2090106@earthlink.net> <494BE0D8.4070509@gmail.com> <494BE5A5.4020205@earthlink.net> <494BEA55.3080304@gmail.com> <494BEDD0.9020708@earthlink.net> <494BFF7D.40804@motorola.com> In-Reply-To: <494BFF7D.40804@motorola.com> X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f52ac346b4415bed7a60c1228b04c573455350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 64.161.0.238 Cc: autoconf@ietf.org Subject: Re: [Autoconf] aspects of multi-hop wireless communication X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org Hello again Alex, Alexandru Petrescu wrote: >> Do you think that routing protocol work should only be chartered for >> links that conform to certain regularity assumptions like symmetry >> and transitivity? > > Is this a MANET WG question? It is a question that you could use to explain your view of how to engineer solutions for wireless networks. > > I think in AUTOCONF WG we don't do work that applies _only_ to DYMO, nor > to OLSR, nor to DSR. Actually, I'd say the same thing about [manet] wg. And, the authors of TBRPF and many others would bristle that you didn't mention them. > > If the AUTOCONF mechanism is to be only for DYMO/OLSR/DSR exclusively > then I just say ok for the draft titled 'aspects of multi-hop...'. The existing [autoconf] solutions (not yet working group documents) that motivated the creation of the group _did_ have to face the same issues as we have been discussing in the context of engineering routing protocols. > >> You seem to claim that we shouldn't worry about them because the link >> layer has to solve problems like asymmetry and hidden terminal >> problems. I'm of the opinion that routing protocols have to be >> engineered in some circumstances to avoid making unwarranted >> inferences about symmetry and transitivity. > > Maybe yes, but maybe in MANET WG? I'm also of the opinion that there is going to be some overlap between the mechanisms for address assignment, and the routing protocols. For instance, it is very reasonable to use a multi-hop gateway beacon to advertise information relevant to address assignment. I do not say that it is absolutely required to be this way, but on the other hand solutions that take care to avoid the pitfalls under discussion are, in my opinion, more likely to succeed than other more brute force solutions. > >> I think it would be nice to identify exactly what your concern is. >> Once it was WiFi only, now it's not. > > Sorry, to make myself clear: in this discussion wifi and 802.16 were > mentioned. I agree both should be dealt with. I don't agree to deal > with a link-layer whose name I don't know. > > Alex > But, on the other hand, if a solution that works for 802.{11*,16,...} is created in a way that is cognizant of the wireless characteristics as we have described in our Internet Draft, then it is _more likely_ to work for the other unspecified but presumably similar media. Which is why we wrote it. Do you disagree with this motivation? Regards, Charlie P. _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Fri Dec 19 13:35:35 2008 Return-Path: X-Original-To: autoconf-archive@megatron.ietf.org Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 44D6C28C148; Fri, 19 Dec 2008 13:35:35 -0800 (PST) X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C797B28C148 for ; Fri, 19 Dec 2008 13:35:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hRJx-XCRrJ8w for ; Fri, 19 Dec 2008 13:35:27 -0800 (PST) Received: from maili.marvell.com (host2.marvell.com [65.219.4.2]) by core3.amsl.com (Postfix) with ESMTP id A3A7A28C124 for ; Fri, 19 Dec 2008 13:35:27 -0800 (PST) Received: from MSI-MTA.marvell.com (msi-mta.marvell.com [10.68.76.91]) by maili.marvell.com (Postfix) with ESMTP id 03AF16210C; Fri, 19 Dec 2008 13:35:19 -0800 (PST) Received: from sc-owa01.marvell.com ([10.93.76.21]) by MSI-MTA.marvell.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 19 Dec 2008 13:34:47 -0800 Received: from SC-EXCH1.marvell.com ([10.93.76.25]) by sc-owa01.marvell.com ([10.93.76.21]) with mapi; Fri, 19 Dec 2008 13:35:18 -0800 From: Paul Lambert To: Emmanuel Baccelli , "autoconf@ietf.org" Date: Fri, 19 Dec 2008 13:34:45 -0800 Thread-Topic: [Autoconf] aspects of multi-hop wireless communication Thread-Index: Aclhusvnhh7ul/85SOeQq+r38D1nUwAYwhbw Message-ID: <5A22FB9EDAA74547916480634CCC74385E061BC7D4@SC-EXCH1.marvell.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-OriginalArrivalTime: 19 Dec 2008 21:34:47.0955 (UTC) FILETIME=[9DE9AE30:01C96221] Subject: Re: [Autoconf] aspects of multi-hop wireless communication X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1572801664==" Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org --===============1572801664== Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_5A22FB9EDAA74547916480634CCC74385E061BC7D4SCEXCH1marvel_" --_000_5A22FB9EDAA74547916480634CCC74385E061BC7D4SCEXCH1marvel_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, It's great having a clear set of definitions to better describe our problem= space. It is good to be able to have a common understanding of asymmetric, non-tra= nsitive, and time-varying issues - however I feel strongly that all of thes= e attributes should not be used to characterize all ad hoc networks. Spec= ifically - asymmetric networks are interesting, but they are an anomaly tha= t is not present in most commercial link layer protocols. At the link laye= r, radio networks are clearly asymmetric - but the data transfer services u= sed to carry IP packets are acknowledged reliable link transmissions (aka b= i-directional - not asymetric). In this context it would be useful to be able to distinguish symmetric ad h= oc networks versus non-symmetric ad hoc networks. Can these be broken out = as separate use cases in the definitions? In this context I'd propose that you change in section 3 (and similar locat= ions): We may say that router A has a link to router B. In this terminology, there is no guarantee that router B has a link to router A. to We may say that router A has a link to router B. In this terminology, there is no guarantee in an asymmetric network that rout= er B has a link to router A. Other topics that I do not see fully defined are the: - differences in link setup requirements and - in the nature of a ad hoc networks support for multicast. On link setup - it's often assumed that wireless communications once config= ured will allow communications between all peers without any explicit assoc= iation or connection. This has historically been a model of ad hoc communi= cations (at least for 802.11). Going forward (assuming IBSS is not displac= ed from Wi-Fi usage), this model must change to support link layer security= . Security is essentially connection oriented. Every pairwise communicati= on currently requires an explicit connection establishment (aka WPA 4-way h= andshake). This connection is required for both unicast and any multicast = communications (due to per device multicast key). These means that for two= devices on network to "hear" each other they had to first establish a expl= icit WPA link layer 'connection'. So Multicast then becomes a issue - not all ad hoc networks will have an ab= ility to support multicast. This has considerable implications for the d= esign of mechanisms for IP address assignment. Regards, Paul ________________________________ From: autoconf-bounces@ietf.org [mailto:autoconf-bounces@ietf.org] On Behal= f Of Emmanuel Baccelli Sent: Friday, December 19, 2008 1:19 AM To: autoconf@ietf.org Subject: [Autoconf] aspects of multi-hop wireless communication Hi all, here's a draft that aims at describing important aspects of multi-hop wirel= ess communication, as observed over the past decade of experience with such= networks. The goal of this document is to identify a consensus about this topic, and = then use this to move on quicker with the working group documents. Please review it, and provide feedback as soon as possible. http://tools.ietf.org/html/draft-baccelli-multi-hop-wireless-communication-= 00 cheers Emmanuel --_000_5A22FB9EDAA74547916480634CCC74385E061BC7D4SCEXCH1marvel_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

Hi,

 

It’s great having a clear set of definitions to better describe our problem space.   

 

It is good to be able to have a common understanding of asymmetric, non-transitive, and time-varying issues –= ; however I feel strongly that all of these attributes should not be used to characterize all ad hoc networks.   Specifically – asymmetr= ic networks are interesting, but they are an anomaly that is not present in most commer= cial link layer protocols.  At the link layer, radio networks are clearly a= symmetric – but the data transfer services used to carry IP packets are acknowl= edged reliable link transmissions (aka bi-directional – not asymetric). &nb= sp;

 

In this context it would be useful to = be able to distinguish symmetric ad hoc networks versus non-symmetric ad hoc networks.  Can these be broken out as separate use cases in the definitions?

 

In this context I’d propose that= you change in section 3 (and similar locations):

       &nb=
sp;        We may say that=
 router A has a link to router B. In this
  =
    terminology, there is no guarantee that router B has a l=
ink to
  =
    router A.

to

&=
nbsp;       We may say that router A has a li=
nk to router B. In this
  =
    terminology, there is no guarantee in an asymmetric n=
etwork that router B has a link to
<=
font
size=3D2 face=3D"Courier New">  =
    router A.

 

Other topics that I do not see fully defined are the:

- differences in li= nk setup requirements and

- in the nature of = a ad hoc networks support for multicast.  

 

On link setup – it’s often= assumed that wireless communications once configured will allow communications betw= een all peers without any explicit association or connection.  This has hi= storically been a model of ad hoc communications (at least for 802.11).  Going forward (assuming IBSS is not displaced from Wi-Fi usage), this model must change to support link layer security.  Security is essentially connec= tion oriented.  Every pairwise communication currently requires an explicit connection establishment (aka WPA 4-way handshake).  This connection i= s required for both unicast and any multicast communications (due to per devi= ce multicast key).  These means that for two devices on network to “= ;hear” each other they had to first establish a explicit WPA  link layer R= 16;connection’.

 

So Multicast then becomes a issue R= 11; not all ad hoc networks will have an ability  to support multicast. &n= bsp; This has considerable implications for the design of mechanisms for IP address assignment.

 

Regards,

 

 

Paul

 

 

 

 

 

From: autoconf-bounces@ietf.org [mailto:autoconf-bounces@ietf.org] On Behalf Of Emmanuel Baccelli
Sent: Friday, December 19, 2= 008 1:19 AM
To: autoconf@ietf.org
Subject: [Autoconf] aspects = of multi-hop wireless communication

 

Hi all,

 

here's a draft that aims at describing important aspects of multi-h= op wireless communication, as observed over the past decade of experience with such networks.

 

The goal of this document is to identify a consensus about this top= ic, and then use this to move on quicker with the working group documents.=

 

Please review it, and provide feedback as soon as possible. 

 

 

cheers

Emmanuel

--_000_5A22FB9EDAA74547916480634CCC74385E061BC7D4SCEXCH1marvel_-- --===============1572801664== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf --===============1572801664==-- From autoconf-bounces@ietf.org Fri Dec 19 14:20:48 2008 Return-Path: X-Original-To: autoconf-archive@megatron.ietf.org Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D141C28C130; Fri, 19 Dec 2008 14:20:48 -0800 (PST) X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 12CB628C130 for ; Fri, 19 Dec 2008 14:20:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.218 X-Spam-Level: X-Spam-Status: No, score=-6.218 tagged_above=-999 required=5 tests=[AWL=0.381, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X5Yc2CJh1c4W for ; Fri, 19 Dec 2008 14:20:46 -0800 (PST) Received: from mail128.messagelabs.com (mail128.messagelabs.com [216.82.250.131]) by core3.amsl.com (Postfix) with SMTP id 4DE5D28C0EE for ; Fri, 19 Dec 2008 14:20:46 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-2.tower-128.messagelabs.com!1229725236!6436978!1 X-StarScan-Version: 6.0.0; banners=.,-,- X-Originating-IP: [136.182.1.12] Received: (qmail 17015 invoked from network); 19 Dec 2008 22:20:36 -0000 Received: from unknown (HELO motgate2.mot.com) (136.182.1.12) by server-2.tower-128.messagelabs.com with SMTP; 19 Dec 2008 22:20:36 -0000 Received: from il27exr01.cig.mot.com (il27exr01.mot.com [10.17.196.70]) by motgate2.mot.com (8.12.11/Motorola) with ESMTP id mBJMKYFM009308; Fri, 19 Dec 2008 15:20:34 -0700 (MST) Received: from az10vts04.mot.com (il27vts04.cig.mot.com [10.17.196.88]) by il27exr01.cig.mot.com (8.13.1/Vontu) with SMTP id mBJMKY08028661; Fri, 19 Dec 2008 16:20:34 -0600 (CST) Received: from [127.0.0.1] ([10.129.40.63]) by il27exr01.cig.mot.com (8.13.1/8.13.0) with ESMTP id mBJMKWML028652; Fri, 19 Dec 2008 16:20:33 -0600 (CST) Message-ID: <494C1E2F.2010000@gmail.com> Date: Fri, 19 Dec 2008 23:20:31 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: "Charles E. Perkins" References: <494B8E7C.7000505@gmail.com> <494BB75E.4050206@gmail.com> <494BC360.1000109@gmail.com> <494BC927.1020400@gmail.com> <494BCCCC.6050206@earthlink.net> <494BCFEF.2010100@gmail.com> <494BD45A.2090106@earthlink.net> <494BE0D8.4070509@gmail.com> <494BE5A5.4020205@earthlink.net> <494BEA55.3080304@gmail.com> <494BEDD0.9020708@earthlink.net> <494BFF7D.40804@motorola.com> <494C0986.9020404@earthlink.net> In-Reply-To: <494C0986.9020404@earthlink.net> X-Antivirus: avast! (VPS 081218-0, 18/12/2008), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected Cc: autoconf@ietf.org Subject: Re: [Autoconf] aspects of multi-hop wireless communication X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org Hello Charles, Charles E. Perkins wrote: [..] >> I think in AUTOCONF WG we don't do work that applies _only_ to >> DYMO, nor to OLSR, nor to DSR. > > Actually, I'd say the same thing about [manet] wg. And, the authors > of TBRPF and many others would bristle that you didn't mention them. > Sorry, it wasn't intentional. TBRPF too for MANET. [...] > I'm also of the opinion that there is going to be some overlap > between the mechanisms for address assignment, and the routing > protocols. For instance, it is very reasonable to use a multi-hop > gateway beacon to advertise information relevant to address > assignment. I do not say that it is absolutely required to be this > way, but on the other hand solutions that take care to avoid the > pitfalls under discussion are, in my opinion, more likely to succeed > than other more brute force solutions. Well I'm not looking at brute force solutions, but solutions to simpler problems. The advertising you mention - could work without taking into considerations the asymmetricity/nontransitivity, if we think it's about Router Advertisements. > But, on the other hand, if a solution that works for 802.{11*,16,...} > is created in a way that is cognizant of the wireless > characteristics as we have described in our Internet Draft, then it > is _more likely_ to work for the other unspecified but presumably > similar media. > > Which is why we wrote it. > > Do you disagree with this motivation? No, I don't disagree with that motivation - supposedly if it works for non-transitive links it will work for transitive links too. I just look at it as something which may be too much for simpler needs. Alex ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Fri Dec 19 14:21:09 2008 Return-Path: X-Original-To: autoconf-archive@megatron.ietf.org Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E3C128C0F7; Fri, 19 Dec 2008 14:21:09 -0800 (PST) X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0AF0C3A63EC for ; Fri, 19 Dec 2008 14:21:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wc1Ch0cg-bLR for ; Fri, 19 Dec 2008 14:21:06 -0800 (PST) Received: from elasmtp-scoter.atl.sa.earthlink.net (elasmtp-scoter.atl.sa.earthlink.net [209.86.89.67]) by core3.amsl.com (Postfix) with ESMTP id 022DC28C124 for ; Fri, 19 Dec 2008 14:21:05 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=GP4qReJOhyU8LGSXGVyOLiD8HoJIgtGo8sf+RbdC10hdx8wgC5jNOPfF+Yr9JzAg; h=Received:Message-ID:Date:From:Organization:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [75.26.137.116] (helo=[10.166.254.43]) by elasmtp-scoter.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1LDniK-00050t-0d; Fri, 19 Dec 2008 17:20:56 -0500 Message-ID: <494C1E47.2080605@earthlink.net> Date: Fri, 19 Dec 2008 14:20:55 -0800 From: "Charles E. Perkins" Organization: Wichorus Inc. User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: Paul Lambert References: <5A22FB9EDAA74547916480634CCC74385E061BC7D4@SC-EXCH1.marvell.com> In-Reply-To: <5A22FB9EDAA74547916480634CCC74385E061BC7D4@SC-EXCH1.marvell.com> X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f5289bab229a7721d8fafd446aff38648fb350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 75.26.137.116 Cc: "autoconf@ietf.org" Subject: Re: [Autoconf] aspects of multi-hop wireless communication X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="windows-1252"; Format="flowed" Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org Hello Paul, Follow-up inline below... Paul Lambert wrote: > > It is good to be able to have a common understanding of asymmetric, = > non-transitive, and time-varying issues =96 however I feel strongly that = > all of these attributes should not be used to characterize all ad hoc = > networks. > Agreed -- but we are not proposing to do that. I suggest instead that, when designing protocols for ad hoc networks, we keep these potential characteristics in mind so that our results will be applicable to such networks. If it turns out that a simpler protocol would be helpful for a symmetric, transitive, stable network, then that would be a useful additional goal. > Specifically =96 asymmetric networks are interesting, but they are an = > anomaly that is not present in most commercial link layer protocols. = > At the link layer, radio networks are clearly asymmetric =96 but the = > data transfer services used to carry IP packets are acknowledged = > reliable link transmissions (aka bi-directional =96 not asymetric). > This is not really true. Again, look at Roofnet for some examples. I do not remember seeing any requirement that IP should run only over acknowledged media. In fact, we have UDP for such cases. > In this context it would be useful to be able to distinguish symmetric = > ad hoc networks versus non-symmetric ad hoc networks. Can these be = > broken out as separate use cases in the definitions? > Which definitions? To reiterate, it is not the purpose of the document to define ad hoc networks as just those networks that exhibit all of the abovementioned characteristics. > In this context I=92d propose that you change in section 3 (and similar = > locations): > > We may say that router A has a link to router B. In this > terminology, there is no guarantee that router B has a link to > router A. > > to > > We may say that router A has a link to router B. In this > terminology, there is no guarantee _in an asymmetric network_ that = router B has a link to > router A. This is reasonable... a matter of wordsmithing to maintain readability while still avoiding overly tedious correctness. How about, instead, if we just preface these examples with a paragraph that makes it clear what kind of networks we are describing? > Other topics that I do not see fully defined are the: > > - differences in link setup requirements and > > - in the nature of a ad hoc networks support for multicast. > > On link setup =96 it=92s often assumed that wireless communications once = > configured will allow communications between all peers without any = > explicit association or connection. This has historically been a model = > of ad hoc communications (at least for 802.11). Going forward = > (assuming IBSS is not displaced from Wi-Fi usage), this model must = > change to support link layer security. Security is essentially = > connection oriented. Every pairwise communication currently requires = > an explicit connection establishment (aka WPA 4-way handshake). This = > connection is required for both unicast and any multicast = > communications (due to per device multicast key). These means that for = > two devices on network to =93hear=94 each other they had to first = > establish a explicit WPA link layer =91connection=92. > Really, I would hope to avoid these issues in our very simple draft. In fact, I would insist. It is not to say that they are not important. But it is just too far afield from the very simple ideas we are trying to put forth. > So Multicast then becomes a issue =96 not all ad hoc networks will have = > an ability to support multicast. This has considerable implications = > for the design of mechanisms for IP address assignment. > I'd be happy to discuss this with you, and it is appropriate for = [autoconf] wg, but again I'd insist on keeping multicastability out of scope for our very simple draft. Regards, Charlie P. _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Fri Dec 19 15:06:47 2008 Return-Path: X-Original-To: autoconf-archive@megatron.ietf.org Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B34723A67E5; Fri, 19 Dec 2008 15:06:47 -0800 (PST) X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 33EFE3A67E5 for ; Fri, 19 Dec 2008 15:06:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RqKrZRs2HU4e for ; Fri, 19 Dec 2008 15:06:43 -0800 (PST) Received: from elasmtp-dupuy.atl.sa.earthlink.net (elasmtp-dupuy.atl.sa.earthlink.net [209.86.89.62]) by core3.amsl.com (Postfix) with ESMTP id 2DD393A63EC for ; Fri, 19 Dec 2008 15:06:43 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=C5xaaS76+hfceZTZafFTeMiaNNzy6KDnFBhs/ksy0HV2yJxpFE9oq++pISPm585F; h=Received:Message-ID:Date:From:Organization:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [75.26.137.116] (helo=[10.166.254.43]) by elasmtp-dupuy.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1LDoQV-0004Ou-5s; Fri, 19 Dec 2008 18:06:35 -0500 Message-ID: <494C28FA.8030805@earthlink.net> Date: Fri, 19 Dec 2008 15:06:34 -0800 From: "Charles E. Perkins" Organization: Wichorus Inc. User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: Alexandru Petrescu References: <494B8E7C.7000505@gmail.com> <494BB75E.4050206@gmail.com> <494BC360.1000109@gmail.com> <494BC927.1020400@gmail.com> <494BCCCC.6050206@earthlink.net> <494BCFEF.2010100@gmail.com> <494BD45A.2090106@earthlink.net> <494BE0D8.4070509@gmail.com> <494BE5A5.4020205@earthlink.net> <494BEA55.3080304@gmail.com> <494BEDD0.9020708@earthlink.net> <494BFF7D.40804@motorola.com> <494C0986.9020404@earthlink.net> <494C1E2F.2010000@gmail.com> In-Reply-To: <494C1E2F.2010000@gmail.com> X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f5288cd28976ef03680da9e1318dc2948d5350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 75.26.137.116 Cc: autoconf@ietf.org Subject: Re: [Autoconf] aspects of multi-hop wireless communication X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org Hello Alex, Alexandru Petrescu wrote: > > Well I'm not looking at brute force solutions, but solutions to simpler > problems. The advertising you mention - could work without taking into > considerations the asymmetricity/nontransitivity, if we think it's > about Router Advertisements. This is the crux of the discussion, and what I claim you have to decide about. Either you want to restrict the effort to only links which are unaffected by asymmetry/nontransitivity, or not. If you want to make the restriction, and yet the group is chartered to create solutions for networks that do not adhere to the restrictions, then I think it means that you need to charter another group or build support for rechartering [autoconf]. > >> But, on the other hand, if a solution that works for 802.{11*,16,...} >> is created in a way that is cognizant of the wireless >> characteristics as we have described in our Internet Draft, then it >> is _more likely_ to work for the other unspecified but presumably >> similar media. >> >> Which is why we wrote it. >> >> Do you disagree with this motivation? > > No, I don't disagree with that motivation - supposedly if it works for > non-transitive links it will work for transitive links too. I just > look at it as something which may be too much for simpler needs. This is the same point, reformulated. You would like to deal only with simpler networks, and seem to claim that is sufficient. Perhaps at the cost of truckloads of repeaters for disaster situations? Regards, Charlie P. _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Fri Dec 19 15:55:23 2008 Return-Path: X-Original-To: autoconf-archive@megatron.ietf.org Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E30873A6940; Fri, 19 Dec 2008 15:55:23 -0800 (PST) X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8E3413A6940 for ; Fri, 19 Dec 2008 15:55:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.549 X-Spam-Level: X-Spam-Status: No, score=-6.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bsVPQHhsPOb9 for ; Fri, 19 Dec 2008 15:55:21 -0800 (PST) Received: from mail153.messagelabs.com (mail153.messagelabs.com [216.82.253.51]) by core3.amsl.com (Postfix) with SMTP id A19773A67E5 for ; Fri, 19 Dec 2008 15:55:21 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-6.tower-153.messagelabs.com!1229730911!6512272!1 X-StarScan-Version: 6.0.0; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 7062 invoked from network); 19 Dec 2008 23:55:11 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-6.tower-153.messagelabs.com with SMTP; 19 Dec 2008 23:55:11 -0000 Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id mBJNt6Ih020294; Fri, 19 Dec 2008 16:55:06 -0700 (MST) Received: from il06vts01.mot.com (il06vts01.mot.com [129.188.137.141]) by il06exr02.mot.com (8.13.1/Vontu) with SMTP id mBJNt593003783; Fri, 19 Dec 2008 17:55:06 -0600 (CST) Received: from [127.0.0.1] ([10.129.40.19]) by il06exr02.mot.com (8.13.1/8.13.0) with ESMTP id mBJNt4jN003780; Fri, 19 Dec 2008 17:55:05 -0600 (CST) Message-ID: <494C3458.20103@gmail.com> Date: Sat, 20 Dec 2008 00:55:04 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: "Charles E. Perkins" References: <494B8E7C.7000505@gmail.com> <494BB75E.4050206@gmail.com> <494BC360.1000109@gmail.com> <494BC927.1020400@gmail.com> <494BCCCC.6050206@earthlink.net> <494BCFEF.2010100@gmail.com> <494BD45A.2090106@earthlink.net> <494BE0D8.4070509@gmail.com> <494BE5A5.4020205@earthlink.net> <494BEA55.3080304@gmail.com> <494BEDD0.9020708@earthlink.net> <494BFF7D.40804@motorola.com> <494C0986.9020404@earthlink.net> <494C1E2F.2010000@gmail.com> <494C28FA.8030805@earthlink.net> In-Reply-To: <494C28FA.8030805@earthlink.net> X-Antivirus: avast! (VPS 081218-0, 18/12/2008), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected Cc: autoconf@ietf.org Subject: Re: [Autoconf] aspects of multi-hop wireless communication X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org Charles E. Perkins wrote: > > Hello Alex, > > Alexandru Petrescu wrote: >> >> Well I'm not looking at brute force solutions, but solutions to >> simpler problems. The advertising you mention - could work without >> taking into considerations the asymmetricity/nontransitivity, if >> we think it's about Router Advertisements. > > This is the crux of the discussion, and what I claim you have to > decide about. Either you want to restrict the effort to only links > which are unaffected by asymmetry/nontransitivity, or not. If you > want to make the restriction, and yet the group is chartered to > create solutions for networks that do not adhere to the restrictions, > then I think it means that you need to charter another group or > build support for rechartering [autoconf]. Eh, I was looking at it as inserting a little effort into an already large effort. Chartering another group or build support for rechartering already happened while MANEMO and it didn't work. Nothing worked since anyways, so. >>> But, on the other hand, if a solution that works for >>> 802.{11*,16,...} is created in a way that is cognizant of the >>> wireless characteristics as we have described in our Internet >>> Draft, then it is _more likely_ to work for the other unspecified >>> but presumably similar media. >>> >>> Which is why we wrote it. >>> >>> Do you disagree with this motivation? >> >> No, I don't disagree with that motivation - supposedly if it works >> for non-transitive links it will work for transitive links too. I >> just look at it as something which may be too much for simpler >> needs. > > This is the same point, reformulated. You would like to deal only > with simpler networks, and seem to claim that is sufficient. Perhaps > at the cost of truckloads of repeaters for disaster situations? :-) Alex ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Sat Dec 20 01:31:25 2008 Return-Path: X-Original-To: autoconf-archive@megatron.ietf.org Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EF6BA3A6838; Sat, 20 Dec 2008 01:31:24 -0800 (PST) X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 52A333A6838 for ; Sat, 20 Dec 2008 01:31:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_21=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 076O3xRJdDTI for ; Sat, 20 Dec 2008 01:31:23 -0800 (PST) Received: from hpsmtp-eml19.kpnxchange.com (hpsmtp-eml19.KPNXCHANGE.COM [213.75.38.84]) by core3.amsl.com (Postfix) with ESMTP id 3AFB43A6802 for ; Sat, 20 Dec 2008 01:31:22 -0800 (PST) Received: from cpsmtp-eml109.kpnxchange.com ([213.75.84.109]) by hpsmtp-eml19.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.3959); Sat, 20 Dec 2008 10:31:13 +0100 Received: from M90Teco ([86.83.9.22]) by cpsmtp-eml109.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.3959); Sat, 20 Dec 2008 10:31:13 +0100 From: "Teco Boot" To: "'Alexandru Petrescu'" References: <494B8E7C.7000505@gmail.com> <494BB75E.4050206@gmail.com> <494BC360.1000109@gmail.com> <494BC927.1020400@gmail.com> <494BCCCC.6050206@earthlink.net> <494BCFEF.2010100@gmail.com> <494BD45A.2090106@earthlink.net> <494BE0D8.4070509@gmail.com> <00ae01c96208$aa2ebd20$fe8c3760$@nl> <494BEAB1.3040700@gmail.com> <00af01c96211$e2c97770$a85c6650$@nl> <494BFE4B.9000601@gmail.com> In-Reply-To: <494BFE4B.9000601@gmail.com> Date: Sat, 20 Dec 2008 10:31:08 +0100 Message-ID: <000001c96285$b050af60$10f20e20$@nl> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcliFQaFXlQDMQ9lQg6OmkggcxFpIQAa8elw Content-Language: nl X-OriginalArrivalTime: 20 Dec 2008 09:31:13.0266 (UTC) FILETIME=[B3279D20:01C96285] Cc: autoconf@ietf.org Subject: Re: [Autoconf] aspects of multi-hop wireless communication X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org |> Try it, and you will see it will fail. |> OK, you can modify the code if you have a C compiler nearby, and some |> sources to modify. | |I'm not meaning to modify any code. It's existing software doing |bridging between two interfaces as it always did. No, you are prohibited to add a 802.11 IBSS interface to a bridge. OK, you can do it without warnings, but the 802.11 mechanisms will not operate as they should. There are problems with address fields, the NIC cannot send CTS or ACK to the sender, because the transmitter MAC address is missing in the RTS or DATA MAC header. You could disable RTS-CTS and send unicast frames until retry limit, but is this the behavior that you suggest? |> But that is no longer wifi. | |Well, it's two 802.11a/b interfaces, running as before. I could put |both interfaces in ad-hoc mode with iwconfig. There's probably a |misunderstanding between what the IEEE standard documents mean by |"ad-hoc" and what iwconfig and related implementations mean by "ad-hoc" |but I'm sure it works, by experience. I am not aware with problems with iwconfig. It should configure the NIC in IBSS mode. |Or I could set up both to act as access points, it's the same. (the |only visible difference between AP mode and ad-hoc modes in |implementation is the MAC address of the essid... in AP mode it's the |real MAC address of the interface doing AP, in ad-hoc mode it's some |random 48bit). The resolution between this 48bit number and essid ascii |name is done by 802.11 link-layer exchanges (probe req/reply IIRC). There are lots of other differences between IBSS and BSS. On (R1, R2, A): What if A is STA and R1 and R2 are APs? Assume APs cannot communicate with each other (no DS). Assume some kind of disaster. One could deploy dense APs and a (to be standardized) form of mesh MANET protocol. This could be disaster^2! (think of beacon-rain and probe-response-storms, and melt downs due to collisions) |> You could enable routing, and you are done! | |Why doing routing when I could do bridging, simpler, widely available |software. Try and you will see lots of shortcomings with bridging and 802.11 IBSS. I am not saying it cannot be solved at a shim layer, but please accept this is not supported by current wifi standards. And provide evidence if I am wrong. I will ask errata on the IEEE 802 standards if you come up with it. |> Play a little with it, and check your (false) assumptions. | |I'm not sure which assumption you think I made false? The fact that I |could build a bridge with brctl and two wifi interfaces? I explained above your assumption is false. I analyzed your suggestions before and my conclusion 802.1D bridging is indeed not allowed with 802.11 IBSS. By the way, there is code around that improves 802.11 IBSS mode, so bridging is allowed. Ask Ronald In't Velt for details. This could be very useful if you want to connect a 802.11 IBSS bridge to a router (split devices) or just connect a couple of hosts to an ad hoc bridge. Teco. _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Sat Dec 20 16:48:44 2008 Return-Path: X-Original-To: autoconf-archive@megatron.ietf.org Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 618CF3A67BD; Sat, 20 Dec 2008 16:48:44 -0800 (PST) X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 02DD33A67BD for ; Sat, 20 Dec 2008 16:48:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jaE5R0lnfbpO for ; Sat, 20 Dec 2008 16:48:43 -0800 (PST) Received: from yx-out-2324.google.com (yx-out-2324.google.com [74.125.44.30]) by core3.amsl.com (Postfix) with ESMTP id 328093A67AB for ; Sat, 20 Dec 2008 16:48:42 -0800 (PST) Received: by yx-out-2324.google.com with SMTP id 8so587254yxg.49 for ; Sat, 20 Dec 2008 16:48:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references :x-google-sender-auth; bh=FgAlahFLmDBJSvXowNILLqVoHw8VD5EBNot8nMOFpu0=; b=kDQYl4W1oqtdlNnoQFWo0dtGOy+V16LkKktDAvwmHjUiLv3n5CoWxoS/ULRCSkVUM0 UzPe9fpJcEcaphXImXPngf/3GtBUV/Ug4Y6AQholretfx3p92FpJoPx7LsG49AwqZXyd bAw0XEJCm0Pczw8qHAcdfvj1QjeaQysQH0wpE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=V2wp98Ct42z+V0oMSZc3UZp83VDVH0EXHkBfSbpV2zG2x5havwV9UrkkCGINGQQQ+F jR9Ris9XHIq3Z4ZqswGIFFZLIHbFtbJJzWI8sS36SG60iIe7BFUPB4bRiqxUtPCmGQdV tWIQ8b9UkbnSUg1yYxKttRB4fZS01YkTW8SYk= Received: by 10.100.197.7 with SMTP id u7mr3106371anf.72.1229820514602; Sat, 20 Dec 2008 16:48:34 -0800 (PST) Received: by 10.100.138.7 with HTTP; Sat, 20 Dec 2008 16:48:34 -0800 (PST) Message-ID: Date: Sat, 20 Dec 2008 16:48:34 -0800 From: "Seung Yi" To: "Emmanuel Baccelli" In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline References: X-Google-Sender-Auth: 41006b2ff2bee2bf Cc: autoconf@ietf.org Subject: Re: [Autoconf] aspects of multi-hop wireless communication X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org Just one simple comment unrelated to the ongoing interesting discussion threads. Isn't the definition of transitivity "If A->B and B->C, then A->C"? This document seems to use the term to mean "if A->B and A->C, then B->C" in Section 2, second point. - Seung 2008/12/19 Emmanuel Baccelli : > Hi all, > here's a draft that aims at describing important aspects of multi-hop > wireless communication, as observed over the past decade of experience with > such networks. > The goal of this document is to identify a consensus about this topic, and > then use this to move on quicker with the working group documents. > > Please review it, and provide feedback as soon as possible. > http://tools.ietf.org/html/draft-baccelli-multi-hop-wireless-communication-00 > > cheers > Emmanuel > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org > https://www.ietf.org/mailman/listinfo/autoconf > > _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Sat Dec 20 17:11:15 2008 Return-Path: X-Original-To: autoconf-archive@megatron.ietf.org Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3FFC13A67BD; Sat, 20 Dec 2008 17:11:15 -0800 (PST) X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 177AD3A67BD for ; Sat, 20 Dec 2008 17:11:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gs8unCGRu8M3 for ; Sat, 20 Dec 2008 17:11:13 -0800 (PST) Received: from elasmtp-curtail.atl.sa.earthlink.net (elasmtp-curtail.atl.sa.earthlink.net [209.86.89.64]) by core3.amsl.com (Postfix) with ESMTP id 3BE703A67AB for ; Sat, 20 Dec 2008 17:11:13 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=Ghs4057AUEyqeK6A8LuB0Ca3bDWRzu1FE8RefTawwCvIBMIhSy9dsoPOWhGPWgOW; h=Received:Message-ID:Date:From:Organization:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [99.51.74.16] (helo=[192.168.1.100]) by elasmtp-curtail.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1LECq5-0000R2-1o; Sat, 20 Dec 2008 20:10:37 -0500 Message-ID: <494D9768.3040903@earthlink.net> Date: Sat, 20 Dec 2008 17:10:00 -0800 From: "Charles E. Perkins" Organization: Wichorus Inc. User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: Seung Yi References: In-Reply-To: X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f526f3571414de9196f81ec6ec977af3b47350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.51.74.16 Cc: autoconf@ietf.org Subject: Re: [Autoconf] aspects of multi-hop wireless communication X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org Hello Seung, Yes, of course you are right (embarrassment). What is a good name for the property under discussion? Regards, Charlie P. Seung Yi wrote: > Just one simple comment unrelated to the ongoing interesting discussion threads. > > Isn't the definition of transitivity "If A->B and B->C, then A->C"? > This document seems to use the term to mean "if A->B and A->C, then > B->C" in Section 2, second point. > > - Seung > > 2008/12/19 Emmanuel Baccelli : > >> Hi all, >> here's a draft that aims at describing important aspects of multi-hop >> wireless communication, as observed over the past decade of experience with >> such networks. >> The goal of this document is to identify a consensus about this topic, and >> then use this to move on quicker with the working group documents. >> >> Please review it, and provide feedback as soon as possible. >> http://tools.ietf.org/html/draft-baccelli-multi-hop-wireless-communication-00 >> >> cheers >> Emmanuel >> _______________________________________________ >> Autoconf mailing list >> Autoconf@ietf.org >> https://www.ietf.org/mailman/listinfo/autoconf >> >> >> > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org > https://www.ietf.org/mailman/listinfo/autoconf > > > _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Sun Dec 21 03:59:58 2008 Return-Path: X-Original-To: autoconf-archive@megatron.ietf.org Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 169ED3A6902; Sun, 21 Dec 2008 03:59:58 -0800 (PST) X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D32553A6902 for ; Sun, 21 Dec 2008 03:59:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.552 X-Spam-Level: X-Spam-Status: No, score=-0.552 tagged_above=-999 required=5 tests=[AWL=-0.806, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, MANGLED_PILL=2.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a-gfzjW90kRj for ; Sun, 21 Dec 2008 03:59:57 -0800 (PST) Received: from cpsmtpo-eml01.kpnxchange.com (cpsmtpo-eml01.KPNXCHANGE.COM [213.75.38.150]) by core3.amsl.com (Postfix) with ESMTP id CB5B23A67C0 for ; Sun, 21 Dec 2008 03:59:56 -0800 (PST) Received: from cpsmtp-eml103.kpnxchange.com ([213.75.84.103]) by cpsmtpo-eml01.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 21 Dec 2008 12:59:45 +0100 Received: from M90Teco ([86.83.9.22]) by cpsmtp-eml103.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 21 Dec 2008 12:59:44 +0100 From: "Teco Boot" To: "'Charles E. Perkins'" , "'Seung Yi'" References: <494D9768.3040903@earthlink.net> In-Reply-To: <494D9768.3040903@earthlink.net> Date: Sun, 21 Dec 2008 12:59:41 +0100 Message-ID: <000d01c96363$9b42fae0$d1c8f0a0$@nl> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcljCQQEI1l85BCxRNGC6HF2Cm+ZdwAWcfag Content-Language: nl X-OriginalArrivalTime: 21 Dec 2008 11:59:44.0684 (UTC) FILETIME=[9D2FD6C0:01C96363] Cc: autoconf@ietf.org Subject: Re: [Autoconf] aspects of multi-hop wireless communication X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org What about a small adjustment: Second, there is no guarantee that two given routers within S can directly communicate with one another. In other words, even though two routers R1 and R2 have symmetric communication with router A, there is no guarantee that R1 can hear packets from R2, and there is likewise no guarantee that R2 can hear packets from R1. Thus, multi-hop ad hoc wireless communications may be "non-transitive". Such non- transitivity is often observed on multi-hop ad hoc wireless networks, due to well-known properties of wireless communication. Now it says: "If R1->A and A->R2, there is no guarantee for R1->R2". And the second behavior is not mixed up with the first one. Teco. |-----Oorspronkelijk bericht----- |Van: autoconf-bounces@ietf.org [mailto:autoconf-bounces@ietf.org] Namens |Charles E. Perkins |Verzonden: zondag 21 december 2008 2:10 |Aan: Seung Yi |CC: autoconf@ietf.org |Onderwerp: Re: [Autoconf] aspects of multi-hop wireless communication | | |Hello Seung, | |Yes, of course you are right (embarrassment). | |What is a good name for the property under discussion? | |Regards, |Charlie P. | | |Seung Yi wrote: |> Just one simple comment unrelated to the ongoing interesting |discussion threads. |> |> Isn't the definition of transitivity "If A->B and B->C, then A->C"? |> This document seems to use the term to mean "if A->B and A->C, then |> B->C" in Section 2, second point. |> |> - Seung |> |> 2008/12/19 Emmanuel Baccelli : |> |>> Hi all, |>> here's a draft that aims at describing important aspects of multi-hop |>> wireless communication, as observed over the past decade of |experience with |>> such networks. |>> The goal of this document is to identify a consensus about this |topic, and |>> then use this to move on quicker with the working group documents. |>> |>> Please review it, and provide feedback as soon as possible. |>> http://tools.ietf.org/html/draft-baccelli-multi-hop-wireless- |communication-00 |>> |>> cheers |>> Emmanuel |>> _______________________________________________ |>> Autoconf mailing list |>> Autoconf@ietf.org |>> https://www.ietf.org/mailman/listinfo/autoconf |>> |>> |>> |> _______________________________________________ |> Autoconf mailing list |> Autoconf@ietf.org |> https://www.ietf.org/mailman/listinfo/autoconf |> |> |> | |_______________________________________________ |Autoconf mailing list |Autoconf@ietf.org |https://www.ietf.org/mailman/listinfo/autoconf _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Sun Dec 21 15:00:29 2008 Return-Path: X-Original-To: autoconf-archive@megatron.ietf.org Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6AC583A694E; Sun, 21 Dec 2008 15:00:29 -0800 (PST) X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5A8053A694E for ; Sun, 21 Dec 2008 15:00:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.827 X-Spam-Level: X-Spam-Status: No, score=-0.827 tagged_above=-999 required=5 tests=[AWL=-1.150, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MANGLED_PILL=2.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id meUC-Ujq7Uvq for ; Sun, 21 Dec 2008 15:00:27 -0800 (PST) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.246]) by core3.amsl.com (Postfix) with ESMTP id 4CF933A6889 for ; Sun, 21 Dec 2008 15:00:27 -0800 (PST) Received: by an-out-0708.google.com with SMTP id c5so659511anc.4 for ; Sun, 21 Dec 2008 15:00:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references :x-google-sender-auth; bh=rE5WWukEGr83GSiRsrhRyYDG7vqIAsEgVa6Mtp6XrDs=; b=r71QU6VUlgZ+cv/HD83ijUFwX6l7n9Nwbm1fTOg1A3qbkeJB7L8Or+l+X+rivyMKmS frb4tQnUcMM14bYlwcF+ye6UvT0R2JebBD/LZ5TQ/KVsYaLuaDiaGzuWVPUbd6Oydsud 909z7ErEEQTcdSpBjWv3umadGR23JHyuXk/4A= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=Nh52C1sGc6VSRy1fIQKjUKu7ZqLXTaL6+6xkoxOcC3SFBbP66WLgo3pO4E48R1XcRu 4Rc1UyHxWVU549T3tURkzMoZgHZ9W10No3wJGA4tM/g6icQ5J07q+qIDY/LzdKFsHUEF TimaqMrpQ/9lFMeNPARxlmNAWihtp5i1pG+T8= Received: by 10.100.191.9 with SMTP id o9mr3507291anf.63.1229900417612; Sun, 21 Dec 2008 15:00:17 -0800 (PST) Received: by 10.100.138.7 with HTTP; Sun, 21 Dec 2008 15:00:17 -0800 (PST) Message-ID: Date: Sun, 21 Dec 2008 15:00:17 -0800 From: "Seung Yi" To: "Teco Boot" In-Reply-To: <000d01c96363$9b42fae0$d1c8f0a0$@nl> MIME-Version: 1.0 Content-Disposition: inline References: <494D9768.3040903@earthlink.net> <000d01c96363$9b42fae0$d1c8f0a0$@nl> X-Google-Sender-Auth: 092033a68e0ff40a Cc: autoconf@ietf.org Subject: Re: [Autoconf] aspects of multi-hop wireless communication X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org I'm sorry but it sounds even more confusing to me. I'm not sure what to call it but it seems to describe the hidden terminal problem to me. Or, it's simply saying that the link (or whatever you want to call the "S") is of non-broadcast flavor because R1 and R2 can expect to hear each other only when the medium itself provides broadcast capability as in the Ethernet. - Seung On Sun, Dec 21, 2008 at 3:59 AM, Teco Boot wrote: > What about a small adjustment: > > Second, there is no guarantee that two given routers within S can > directly communicate with one another. In other words, even though > two routers R1 and R2 have symmetric communication with router A, there > is > no guarantee that R1 can hear packets from R2, and there is likewise > no guarantee that R2 can hear packets from R1. Thus, multi-hop ad > hoc wireless communications may be "non-transitive". Such non- > transitivity is often observed on multi-hop ad hoc wireless networks, > due to well-known properties of wireless communication. > > > Now it says: "If R1->A and A->R2, there is no guarantee for R1->R2". > And the second behavior is not mixed up with the first one. > > Teco. > > |-----Oorspronkelijk bericht----- > |Van: autoconf-bounces@ietf.org [mailto:autoconf-bounces@ietf.org] Namens > |Charles E. Perkins > |Verzonden: zondag 21 december 2008 2:10 > |Aan: Seung Yi > |CC: autoconf@ietf.org > |Onderwerp: Re: [Autoconf] aspects of multi-hop wireless communication > | > | > |Hello Seung, > | > |Yes, of course you are right (embarrassment). > | > |What is a good name for the property under discussion? > | > |Regards, > |Charlie P. > | > | > |Seung Yi wrote: > |> Just one simple comment unrelated to the ongoing interesting > |discussion threads. > |> > |> Isn't the definition of transitivity "If A->B and B->C, then A->C"? > |> This document seems to use the term to mean "if A->B and A->C, then > |> B->C" in Section 2, second point. > |> > |> - Seung > |> > |> 2008/12/19 Emmanuel Baccelli : > |> > |>> Hi all, > |>> here's a draft that aims at describing important aspects of multi-hop > |>> wireless communication, as observed over the past decade of > |experience with > |>> such networks. > |>> The goal of this document is to identify a consensus about this > |topic, and > |>> then use this to move on quicker with the working group documents. > |>> > |>> Please review it, and provide feedback as soon as possible. > |>> http://tools.ietf.org/html/draft-baccelli-multi-hop-wireless- > |communication-00 > |>> > |>> cheers > |>> Emmanuel > |>> _______________________________________________ > |>> Autoconf mailing list > |>> Autoconf@ietf.org > |>> https://www.ietf.org/mailman/listinfo/autoconf > |>> > |>> > |>> > |> _______________________________________________ > |> Autoconf mailing list > |> Autoconf@ietf.org > |> https://www.ietf.org/mailman/listinfo/autoconf > |> > |> > |> > | > |_______________________________________________ > |Autoconf mailing list > |Autoconf@ietf.org > |https://www.ietf.org/mailman/listinfo/autoconf > > _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Sun Dec 21 16:54:03 2008 Return-Path: X-Original-To: autoconf-archive@megatron.ietf.org Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0B6813A68D3; Sun, 21 Dec 2008 16:54:03 -0800 (PST) X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 73A5D3A68D3 for ; Sun, 21 Dec 2008 16:54:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.377 X-Spam-Level: X-Spam-Status: No, score=-1.377 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_21=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2q+-OVJsfUfg for ; Sun, 21 Dec 2008 16:53:59 -0800 (PST) Received: from mail-bw0-f21.google.com (mail-bw0-f21.google.com [209.85.218.21]) by core3.amsl.com (Postfix) with ESMTP id 264E73A63EB for ; Sun, 21 Dec 2008 16:53:58 -0800 (PST) Received: by bwz14 with SMTP id 14so7233892bwz.13 for ; Sun, 21 Dec 2008 16:53:49 -0800 (PST) Received: by 10.180.235.7 with SMTP id i7mr2108650bkh.24.1229907228095; Sun, 21 Dec 2008 16:53:48 -0800 (PST) Received: by 10.180.245.2 with HTTP; Sun, 21 Dec 2008 16:53:47 -0800 (PST) Message-ID: <2ced936d0812211653v61161e4dp7f1ba79e81c61124@mail.gmail.com> Date: Sun, 21 Dec 2008 21:53:47 -0300 From: "Breno Jacinto" To: "Teco Boot" In-Reply-To: <000001c96285$b050af60$10f20e20$@nl> MIME-Version: 1.0 Content-Disposition: inline References: <494BCCCC.6050206@earthlink.net> <494BCFEF.2010100@gmail.com> <494BD45A.2090106@earthlink.net> <494BE0D8.4070509@gmail.com> <00ae01c96208$aa2ebd20$fe8c3760$@nl> <494BEAB1.3040700@gmail.com> <00af01c96211$e2c97770$a85c6650$@nl> <494BFE4B.9000601@gmail.com> <000001c96285$b050af60$10f20e20$@nl> Cc: autoconf@ietf.org Subject: Re: [Autoconf] aspects of multi-hop wireless communication X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org Hello, That's a very interesting discussion, indeed. I didnt see anyone mentioning related work about underlay networking (meaning: routing below IP), and there has been some interesting work in academia, as well as some practical efforts to prove the concept. Since this is my line of research currently, let me cite some of the related work: - 802.1D bridging: as Alexandru cited, that is an already available implementation, stable and functional and can do bridging and create an illusion for IP that there is a simple Ethernet network below it. Now, as Teco mentioned, I also could NOT make it work with 802.11 in *AD-HOC* mode (Alexandru, I'd be glad to know how you managed to do it without any special patch or tweak on the drivers, using just the standard). Other people tried with AP mode and it works (and this is expected, as the popular APs such as WRT54G do it for Ethernet and 802.11 networks). - 802.11s (http://en.wikipedia.org/wiki/IEEE_802.11s): nobody cited it, but this standard is supposed to implement multi-hopping at layer 2, instead of layer 3 as all Ad Hoc protocols do (OLSR, AODV etc...). As everyone knows, 802.11 b/g standard does not support multi-hop for real. - AWDS (http://awds.berlios.de/) - Ad Hoc Wireless Distribution System. This project is quite stable and functional implementation a layer 2 protocol for doing multi-hop communication over ordinary 802.11 b/g cards. Now, to me this is pretty much what 802.11s is attempting to do, but does it now. It works, and it is being tested in test-beds today. It is a very active project, but it seems it hasnt got very popular up to now. - Ana4 Framework (http://ana4.citi.insa-lyon.fr/): An academic initiative with the intention of transparent connecting heterogeneous networks at the underlay, i.e., at a virtual 2.5 layer. It is supposed to work with any link-layer, including Bluetooth, but actually they just implemented for Ethernet and 802.11 ad hoc networks. I tested it, and it works. It's like bridging, but it actually does real routing in a virtual network (and I could interconnect an Ethernet and 802.11 ad hoc network). - MIT RoofNet (http://pdos.csail.mit.edu/roofnet/) and B.A.T.M.A.N (http://en.wikipedia.org/wiki/B.A.T.M.A.N.), are, as far as I can tell, implemented as a layer 2.5 protocol. Unfortunately I could not study them deeply enough to confirm this, maybe someone on the list can. Now, going back to this draft, which I believe to be of utmost importance, I think some questions must be answered as well: - Should Mult-hop communications happen at the IP layer, really? I think that this decision was taken just because 802.11 b/g standard become popular and could not do multi-hop at layer 2. So, everyone thought, let's do it at layer 3, because it is possible to emulate multi-hop then. - If multi-hopping is done at layer 2, isn't that a good thing? I mean, you can deal with problems specific to the link layer (including the aforementioned hidden node problem, or whatever next-popular-link-layer for multi-hop become available in the future) and make IP more neutral. I think that would conserve the initial aim of IP, which is simply to glue heterogeneous networks, not fixing a particular link-layer problem as it is being done with 802.11 b/g. - Now, if we could assume that multi-hop is done at layer 2; to layer 3 (such as IP), a broadcast should reach (be flooded to) everyone in the network. Now, IP sees the network as a single broadcast domain and issues in the "real" network should be dealt there. We may then shift to the problem of connecting multiple ad hoc networks at the IP layer, doing inter-domain routing etc.. I'm sorry for so many observations: I hope to contribute for the discussion and show some of the research that's been done in the last years in ad hoc networking (and not everyone is aware of, I think). regards, -- = -- = :: Breno Jacinto :: :: breno - at - gprt.ufpe.br :: :: FingerPrint :: 2F15 8A61 F566 E442 8581 E3C0 EFF4 E202 74B7 7484 :: Persistir no dif=EDcil =E9 a =FAnica maneira de torn=E1-lo f=E1cil algum= dia. :: 2008/12/20 Teco Boot : > |> Try it, and you will see it will fail. > |> OK, you can modify the code if you have a C compiler nearby, and some > |> sources to modify. > | > |I'm not meaning to modify any code. It's existing software doing > |bridging between two interfaces as it always did. > > No, you are prohibited to add a 802.11 IBSS interface to a bridge. > > OK, you can do it without warnings, but the 802.11 mechanisms will not > operate as they should. There are problems with address fields, the NIC > cannot send CTS or ACK to the sender, because the transmitter MAC address= is > missing in the RTS or DATA MAC header. > You could disable RTS-CTS and send unicast frames until retry limit, but = is > this the behavior that you suggest? > > > |> But that is no longer wifi. > | > |Well, it's two 802.11a/b interfaces, running as before. I could put > |both interfaces in ad-hoc mode with iwconfig. There's probably a > |misunderstanding between what the IEEE standard documents mean by > |"ad-hoc" and what iwconfig and related implementations mean by "ad-hoc" > |but I'm sure it works, by experience. > > I am not aware with problems with iwconfig. It should configure the NIC in > IBSS mode. > > > |Or I could set up both to act as access points, it's the same. (the > |only visible difference between AP mode and ad-hoc modes in > |implementation is the MAC address of the essid... in AP mode it's the > |real MAC address of the interface doing AP, in ad-hoc mode it's some > |random 48bit). The resolution between this 48bit number and essid ascii > |name is done by 802.11 link-layer exchanges (probe req/reply IIRC). > > There are lots of other differences between IBSS and BSS. > > On (R1, R2, A): > What if A is STA and R1 and R2 are APs? Assume APs cannot communicate with > each other (no DS). Assume some kind of disaster. > > One could deploy dense APs and a (to be standardized) form of mesh MANET > protocol. This could be disaster^2! > (think of beacon-rain and probe-response-storms, and melt downs due to > collisions) > > > |> You could enable routing, and you are done! > | > |Why doing routing when I could do bridging, simpler, widely available > |software. > > Try and you will see lots of shortcomings with bridging and 802.11 IBSS. > I am not saying it cannot be solved at a shim layer, but please accept th= is > is not supported by current wifi standards. > > And provide evidence if I am wrong. I will ask errata on the IEEE 802 > standards if you come up with it. > > > |> Play a little with it, and check your (false) assumptions. > | > |I'm not sure which assumption you think I made false? The fact that I > |could build a bridge with brctl and two wifi interfaces? > > I explained above your assumption is false. I analyzed your suggestions > before and my conclusion 802.1D bridging is indeed not allowed with 802.11 > IBSS. > > > By the way, there is code around that improves 802.11 IBSS mode, so bridg= ing > is allowed. Ask Ronald In't Velt for details. This could be very useful if > you want to connect a 802.11 IBSS bridge to a router (split devices) or j= ust > connect a couple of hosts to an ad hoc bridge. > > > Teco. > > > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org > https://www.ietf.org/mailman/listinfo/autoconf > _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Sun Dec 21 19:36:05 2008 Return-Path: X-Original-To: autoconf-archive@megatron.ietf.org Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 00DF43A68C6; Sun, 21 Dec 2008 19:36:05 -0800 (PST) X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 48B1B3A68C6 for ; Sun, 21 Dec 2008 19:36:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UHtuzadE+7qr for ; Sun, 21 Dec 2008 19:36:03 -0800 (PST) Received: from elasmtp-mealy.atl.sa.earthlink.net (elasmtp-mealy.atl.sa.earthlink.net [209.86.89.69]) by core3.amsl.com (Postfix) with ESMTP id 5A5113A67E4 for ; Sun, 21 Dec 2008 19:36:03 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=Fur3gbs8MJuFCR6qDyI+RdzAEjlheVMPZw8uN5RUPI6hoAaPq0/hINad+JeaoPZ6; h=Received:Message-ID:Date:From:Organization:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [99.51.74.16] (helo=[192.168.1.100]) by elasmtp-mealy.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1LEbaE-0004tD-Kl; Sun, 21 Dec 2008 22:35:54 -0500 Message-ID: <494F0B17.8070806@earthlink.net> Date: Sun, 21 Dec 2008 19:35:51 -0800 From: "Charles E. Perkins" Organization: Wichorus Inc. User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: Breno Jacinto References: <494BCCCC.6050206@earthlink.net> <494BCFEF.2010100@gmail.com> <494BD45A.2090106@earthlink.net> <494BE0D8.4070509@gmail.com> <00ae01c96208$aa2ebd20$fe8c3760$@nl> <494BEAB1.3040700@gmail.com> <00af01c96211$e2c97770$a85c6650$@nl> <494BFE4B.9000601@gmail.com> <000001c96285$b050af60$10f20e20$@nl> <2ced936d0812211653v61161e4dp7f1ba79e81c61124@mail.gmail.com> In-Reply-To: <2ced936d0812211653v61161e4dp7f1ba79e81c61124@mail.gmail.com> X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f5254cda3ef4a882ebe2caa6622079a8621350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.51.74.16 Cc: autoconf@ietf.org Subject: Re: [Autoconf] aspects of multi-hop wireless communication X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org Hello Breno, Breno Jacinto wrote: > - Should Mult-hop communications happen at the IP layer, really? I > think that this decision was taken just because 802.11 b/g standard > become popular and could not do multi-hop at layer 2. So, everyone > thought, let's do it at layer 3, because it is possible to emulate > multi-hop then. > I think this is not an accurate reflection of the evolution of thought on the subject. At least for me, it was clear that one could easily make a routing solution by revising RIP to get rid of poison reverse and other hacks, so that we could have just the next-hop routing as needed. This was a very long time before 802.11. Your word "should" is loaded. IP is, I think, great at stitching together links into a network. They don't even have to be the same physical media. That's a major plus compared to layer 2 solutions. Plus, the same layer 3 solution works for a lot of different wireless physical media. That's better than blasting away with different solutions for each different medium. I just don't see what's wrong with it. > - If multi-hopping is done at layer 2, isn't that a good thing? I > mean, you can deal with problems specific to the link layer (including > the aforementioned hidden node problem, or whatever > next-popular-link-layer for multi-hop become available in the future) > and make IP more neutral. I think that would conserve the initial aim > of IP, which is simply to glue heterogeneous networks, not fixing a > particular link-layer problem as it is being done with 802.11 b/g. > There is no free lunch. You are going to solve those problems at layer 3, or you are going to solve them at layer 2. And, even if the latter, you may still have to worry about it at layer 3 unless you impose some very strong regularity conditions (I'm still puzzling over truckloads of repeaters). > - Now, if we could assume that multi-hop is done at layer 2; to layer > 3 (such as IP), a broadcast should reach (be flooded to) everyone in > the network. Now, IP sees the network as a single broadcast domain and > issues in the "real" network should be dealt there. We may then shift > to the problem of connecting multiple ad hoc networks at the IP layer, > doing inter-domain routing etc. There's that "should" again. In fact, your very example of broadcast disproves your point: what if the best broadcast used multiple media? Regards, Charlie P. _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Mon Dec 22 00:47:52 2008 Return-Path: X-Original-To: autoconf-archive@megatron.ietf.org Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7F74C3A686C; Mon, 22 Dec 2008 00:47:52 -0800 (PST) X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F28EB3A686C for ; Mon, 22 Dec 2008 00:47:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.929 X-Spam-Level: X-Spam-Status: No, score=-1.929 tagged_above=-999 required=5 tests=[AWL=0.047, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bUdEbVAPKei0 for ; Mon, 22 Dec 2008 00:47:50 -0800 (PST) Received: from mail-bw0-f21.google.com (mail-bw0-f21.google.com [209.85.218.21]) by core3.amsl.com (Postfix) with ESMTP id A152A3A6774 for ; Mon, 22 Dec 2008 00:47:49 -0800 (PST) Received: by bwz14 with SMTP id 14so7635064bwz.13 for ; Mon, 22 Dec 2008 00:47:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:in-reply-to:mime-version:content-type:references :x-google-sender-auth; bh=7pBAZFFVwoN8ULcDOM3m4BBwHBqF+wPXtJLzsDAHlKI=; b=tyiSI4hyOk4JCdvgMEsS30vEQrt3JcA9ZlnobQDrMBhZbTNMuNzH9NoP+UuU/xNV3A GiKA0WqYwaTLcOpjP/ESeEenmcpCMSqqk9Pe8ktn1t3Swjs2GY//ADje5+L1+ZRnF93k MxzKLF4c3ea+GMw5g+6IbRWqDrLCrSXKQPNjE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:in-reply-to:mime-version :content-type:references:x-google-sender-auth; b=P/k47E292axXdrLMK5weI5yJi0VW2upCjnCenC4PECzML4z3Iqux3RcIvzUmvEbsLq zAeCdVmBqFnBETpT1djMnaVQgLZz2GAubFhqDXTeUNWlMK+2LkdGqTghhwTF7KWAQacN 7yCVv7+JzekHKzRenhHUdvGqlgQnN2mUzz2n4= Received: by 10.103.247.14 with SMTP id z14mr2203666mur.70.1229935659800; Mon, 22 Dec 2008 00:47:39 -0800 (PST) Received: by 10.103.248.12 with HTTP; Mon, 22 Dec 2008 00:47:39 -0800 (PST) Message-ID: Date: Mon, 22 Dec 2008 09:47:39 +0100 From: "Emmanuel Baccelli" To: autoconf@ietf.org In-Reply-To: <494F0B17.8070806@earthlink.net> MIME-Version: 1.0 References: <494BD45A.2090106@earthlink.net> <494BE0D8.4070509@gmail.com> <00ae01c96208$aa2ebd20$fe8c3760$@nl> <494BEAB1.3040700@gmail.com> <00af01c96211$e2c97770$a85c6650$@nl> <494BFE4B.9000601@gmail.com> <000001c96285$b050af60$10f20e20$@nl> <2ced936d0812211653v61161e4dp7f1ba79e81c61124@mail.gmail.com> <494F0B17.8070806@earthlink.net> X-Google-Sender-Auth: 5d05ef58e4da1066 Subject: Re: [Autoconf] aspects of multi-hop wireless communication X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0611715957==" Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org --===============0611715957== Content-Type: multipart/alternative; boundary="----=_Part_64072_19194375.1229935659786" ------=_Part_64072_19194375.1229935659786 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline On Mon, Dec 22, 2008 at 4:35 AM, Charles E. Perkins < charles.perkins@earthlink.net> wrote: > > > > - If multi-hopping is done at layer 2, isn't that a good thing? I >> mean, you can deal with problems specific to the link layer (including >> the aforementioned hidden node problem, or whatever >> next-popular-link-layer for multi-hop become available in the future) >> and make IP more neutral. I think that would conserve the initial aim >> of IP, which is simply to glue heterogeneous networks, not fixing a >> particular link-layer problem as it is being done with 802.11 b/g. >> >> > > There is no free lunch. You are going to solve those problems at layer 3, > or you are going to solve them at layer 2. And, even if the latter, you > may > still have to worry about it at layer 3 unless you impose some very strong > regularity conditions (I'm still puzzling over truckloads of repeaters). First, this is not just about 802.11 b/g. The same behavior was observed with other radio MAC, such as simple proprietary sensor "MAC" layers for example, and there are many other examples. One can also anticipate some future L2 standards that will have the same properties. We are dealing with a specific _category_ of networks here. And thus, this would not be the first time that something special is done at L3 to cope with a specific category of L2 networks. Lets recall different OSPF interface types, for instance. Emmanuel ------=_Part_64072_19194375.1229935659786 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline

On Mon, Dec 22, 2008 at 4:35 AM, Charles E. Perkins <charles.perkins@earthlink.net> wrote:


- If multi-hopping is done at layer 2, isn't that a good thing? I
mean, you can deal with problems specific to the link layer (including
the aforementioned hidden node problem, or whatever
next-popular-link-layer for multi-hop become available in the future)
and make IP more neutral. I think that would conserve the initial aim
of IP, which is simply to glue heterogeneous networks, not fixing a
particular link-layer problem as it is being done with 802.11 b/g.
 

There is no free lunch.  You are going to solve those problems at layer 3,
or you are going to solve them at layer 2.  And, even if the latter, you may
still have to worry about it at layer 3 unless you impose some very strong
regularity conditions (I'm still puzzling over truckloads of repeaters).


First, this is not just about 802.11 b/g. The same behavior was observed with other radio MAC, such as simple proprietary sensor "MAC" layers for example, and there are many other examples. One can also anticipate some future L2 standards that will have the same properties. 

We are dealing with a specific _category_ of networks here. And thus, this would not be the first time that something special is done at L3 to cope with a specific category of L2 networks. Lets recall different OSPF interface types, for instance.

Emmanuel

------=_Part_64072_19194375.1229935659786-- --===============0611715957== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf --===============0611715957==-- From autoconf-bounces@ietf.org Mon Dec 22 00:48:17 2008 Return-Path: X-Original-To: autoconf-archive@megatron.ietf.org Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B61B93A6984; Mon, 22 Dec 2008 00:48:17 -0800 (PST) X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3B3723A6983 for ; Mon, 22 Dec 2008 00:48:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.521 X-Spam-Level: X-Spam-Status: No, score=-0.521 tagged_above=-999 required=5 tests=[AWL=-0.775, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, MANGLED_PILL=2.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EuYEl+Tr08X9 for ; Mon, 22 Dec 2008 00:48:15 -0800 (PST) Received: from cpsmtpo-eml02.kpnxchange.com (cpsmtpo-eml02.KPNXCHANGE.COM [213.75.38.151]) by core3.amsl.com (Postfix) with ESMTP id DBE473A686C for ; Mon, 22 Dec 2008 00:48:14 -0800 (PST) Received: from cpsmtp-eml103.kpnxchange.com ([213.75.84.103]) by cpsmtpo-eml02.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 22 Dec 2008 09:48:03 +0100 Received: from M90Teco ([86.83.9.22]) by cpsmtp-eml103.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 22 Dec 2008 09:48:03 +0100 From: "Teco Boot" To: "'Seung Yi'" References: <494D9768.3040903@earthlink.net> <000d01c96363$9b42fae0$d1c8f0a0$@nl> In-Reply-To: Date: Mon, 22 Dec 2008 09:48:01 +0100 Message-ID: <003201c96411$ff01a7d0$fd04f770$@nl> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acljv/LKByUzXWX8TT2YMCWj+ZZVrAATbIrQ Content-Language: nl X-OriginalArrivalTime: 22 Dec 2008 08:48:03.0223 (UTC) FILETIME=[0031EA70:01C96412] Cc: autoconf@ietf.org Subject: Re: [Autoconf] aspects of multi-hop wireless communication X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org I tried to get rid of B->A and C->A and [NOT B->A]. Somewhat adjusted proposal, and using C and D and not the newly introduced R1 and R2: Second, there is no guarantee that two given routers within S can directly communicate with one another. In other words, even though two routers C and D have symmetric communication with router A, there is no guarantee that C can hear packets from D, and there is likewise no guarantee that D can hear packets from C. Thus, multi-hop ad hoc wireless communications may be "non-transitive". Such non- transitivity is often observed on multi-hop ad hoc wireless networks, due to well-known properties of wireless communication. Now C->A and A->D, but [NOT C->D] and also D->A and A->D, but [NOT D->C]. This characteristic is "non-transitive" and it is orthogonal with "asymmetry". Your terms "hidden terminal problem" and "non-broadcast" could be used as alternative terminology, but could have different meanings in different context. o "hidden terminal problem" could have to do with collisions. o "non-broadcast" does not apply here, because set S contains at least 3 routers (B, C, D). Term "Semi-Broadcast" (I-D.ietf-autoconf-manetarch) was introduced, where S is subset of N. (N is all nodes in network N). I suggested not introducing new terms if they not needed. Teco. |-----Oorspronkelijk bericht----- |Van: scicarus@gmail.com [mailto:scicarus@gmail.com] Namens Seung Yi |Verzonden: maandag 22 december 2008 0:00 |Aan: Teco Boot |CC: Charles E. Perkins; autoconf@ietf.org |Onderwerp: Re: [Autoconf] aspects of multi-hop wireless communication | |I'm sorry but it sounds even more confusing to me. | |I'm not sure what to call it but it seems to describe the hidden |terminal problem to me. Or, it's simply saying that the link (or |whatever you want to call the "S") is of non-broadcast flavor because |R1 and R2 can expect to hear each other only when the medium itself |provides broadcast capability as in the Ethernet. | |- Seung | |On Sun, Dec 21, 2008 at 3:59 AM, Teco Boot wrote: |> What about a small adjustment: |> |> Second, there is no guarantee that two given routers within S can |> directly communicate with one another. In other words, even though |> two routers R1 and R2 have symmetric communication with router A, |there |> is |> no guarantee that R1 can hear packets from R2, and there is likewise |> no guarantee that R2 can hear packets from R1. Thus, multi-hop ad |> hoc wireless communications may be "non-transitive". Such non- |> transitivity is often observed on multi-hop ad hoc wireless |networks, |> due to well-known properties of wireless communication. |> |> |> Now it says: "If R1->A and A->R2, there is no guarantee for R1->R2". |> And the second behavior is not mixed up with the first one. |> |> Teco. |> |> |-----Oorspronkelijk bericht----- |> |Van: autoconf-bounces@ietf.org [mailto:autoconf-bounces@ietf.org] |Namens |> |Charles E. Perkins |> |Verzonden: zondag 21 december 2008 2:10 |> |Aan: Seung Yi |> |CC: autoconf@ietf.org |> |Onderwerp: Re: [Autoconf] aspects of multi-hop wireless communication |> | |> | |> |Hello Seung, |> | |> |Yes, of course you are right (embarrassment). |> | |> |What is a good name for the property under discussion? |> | |> |Regards, |> |Charlie P. |> | |> | |> |Seung Yi wrote: |> |> Just one simple comment unrelated to the ongoing interesting |> |discussion threads. |> |> |> |> Isn't the definition of transitivity "If A->B and B->C, then A->C"? |> |> This document seems to use the term to mean "if A->B and A->C, then |> |> B->C" in Section 2, second point. |> |> |> |> - Seung |> |> |> |> 2008/12/19 Emmanuel Baccelli : |> |> |> |>> Hi all, |> |>> here's a draft that aims at describing important aspects of multi- |hop |> |>> wireless communication, as observed over the past decade of |> |experience with |> |>> such networks. |> |>> The goal of this document is to identify a consensus about this |> |topic, and |> |>> then use this to move on quicker with the working group documents. |> |>> |> |>> Please review it, and provide feedback as soon as possible. |> |>> http://tools.ietf.org/html/draft-baccelli-multi-hop-wireless- |> |communication-00 |> |>> |> |>> cheers |> |>> Emmanuel |> |>> _______________________________________________ |> |>> Autoconf mailing list |> |>> Autoconf@ietf.org |> |>> https://www.ietf.org/mailman/listinfo/autoconf |> |>> |> |>> |> |>> |> |> _______________________________________________ |> |> Autoconf mailing list |> |> Autoconf@ietf.org |> |> https://www.ietf.org/mailman/listinfo/autoconf |> |> |> |> |> |> |> | |> |_______________________________________________ |> |Autoconf mailing list |> |Autoconf@ietf.org |> |https://www.ietf.org/mailman/listinfo/autoconf |> |> _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Mon Dec 22 01:17:39 2008 Return-Path: X-Original-To: autoconf-archive@megatron.ietf.org Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 551393A6915; Mon, 22 Dec 2008 01:17:39 -0800 (PST) X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9E7B03A67F6 for ; Mon, 22 Dec 2008 01:17:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.926 X-Spam-Level: X-Spam-Status: No, score=-0.926 tagged_above=-999 required=5 tests=[AWL=-1.228, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_43=0.6, MANGLED_PILL=2.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OlB5gdYJR2fH for ; Mon, 22 Dec 2008 01:17:36 -0800 (PST) Received: from mail-bw0-f21.google.com (mail-bw0-f21.google.com [209.85.218.21]) by core3.amsl.com (Postfix) with ESMTP id 901D63A6915 for ; Mon, 22 Dec 2008 01:17:35 -0800 (PST) Received: by bwz14 with SMTP id 14so7669778bwz.13 for ; Mon, 22 Dec 2008 01:17:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:in-reply-to:mime-version:content-type:references; bh=HJVBsXzh1oma8114Mc3Shcci069/IPs+Fx8Gimds2P0=; b=d9jvl/cbIISPfXP6X/GiXk9Hiq9hs23/azoDyKqYb6m4K/+O4T3hSGckVNvyvRPygc 21oM6Myk4HA5urbRroKKugMl05nwlD59uJwlYiwROc46D7OeJptg+nmaS2dg70+IEm9e menTlg0+PsmVXZuFPzNhMIW52vlq3mRJlu4c8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version :content-type:references; b=JZ0rmKLsOkRRMR0s9/WCB41HGcIOVEpJ9C7M+xfyyvYPnIQkhQIX4koJvSqF9jsBMD soqdNLL4Q2S6M98mlx2674X1juRWcXSAx8XKhkhtZ54nzAyEDGtXVBzbvWUDy7gmWmZz zQuS9LL8hrrRrOdhRosfnWw9I3/1Zg0m3oomY= Received: by 10.103.171.6 with SMTP id y6mr2216373muo.31.1229937444769; Mon, 22 Dec 2008 01:17:24 -0800 (PST) Received: by 10.103.248.12 with HTTP; Mon, 22 Dec 2008 01:17:24 -0800 (PST) Message-ID: Date: Mon, 22 Dec 2008 10:17:24 +0100 From: "Emmanuel Baccelli" To: autoconf@ietf.org In-Reply-To: <003201c96411$ff01a7d0$fd04f770$@nl> MIME-Version: 1.0 References: <494D9768.3040903@earthlink.net> <000d01c96363$9b42fae0$d1c8f0a0$@nl> <003201c96411$ff01a7d0$fd04f770$@nl> Subject: Re: [Autoconf] aspects of multi-hop wireless communication X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1952878471==" Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org --===============1952878471== Content-Type: multipart/alternative; boundary="----=_Part_64299_14591113.1229937444759" ------=_Part_64299_14591113.1229937444759 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi Teco,yes I agree, the term "non-transitive" was not very straightforwardly used. Saying as you propose would be better, more precisely (correct me if I'm mistaken about what you meant), that if: C and A can hear each other through A's interface, and, A and D can hear each other through A's interface, then it does not mean that C can hear D or that D can hear C Emmanuel On Mon, Dec 22, 2008 at 9:48 AM, Teco Boot wrote: > I tried to get rid of B->A and C->A and [NOT B->A]. > > Somewhat adjusted proposal, and using C and D and not the newly > introduced R1 and R2: > > Second, there is no guarantee that two given routers within S can > directly communicate with one another. In other words, even though > two routers C and D have symmetric communication with router A, there is > no guarantee that C can hear packets from D, and there is likewise > no guarantee that D can hear packets from C. Thus, multi-hop ad > hoc wireless communications may be "non-transitive". Such non- > transitivity is often observed on multi-hop ad hoc wireless networks, > due to well-known properties of wireless communication. > > Now C->A and A->D, but [NOT C->D] and also D->A and A->D, but [NOT D->C]. > This characteristic is "non-transitive" and it is orthogonal with > "asymmetry". > > Your terms "hidden terminal problem" and "non-broadcast" could be used > as alternative terminology, but could have different meanings in > different context. > o "hidden terminal problem" could have to do with collisions. > o "non-broadcast" does not apply here, because set S contains at > least 3 routers (B, C, D). > Term "Semi-Broadcast" (I-D.ietf-autoconf-manetarch) was introduced, > where S is subset of N. (N is all nodes in network N). I suggested > not introducing new terms if they not needed. > > Teco. > > |-----Oorspronkelijk bericht----- > |Van: scicarus@gmail.com [mailto:scicarus@gmail.com] Namens Seung Yi > |Verzonden: maandag 22 december 2008 0:00 > |Aan: Teco Boot > |CC: Charles E. Perkins; autoconf@ietf.org > |Onderwerp: Re: [Autoconf] aspects of multi-hop wireless communication > | > |I'm sorry but it sounds even more confusing to me. > | > |I'm not sure what to call it but it seems to describe the hidden > |terminal problem to me. Or, it's simply saying that the link (or > |whatever you want to call the "S") is of non-broadcast flavor because > |R1 and R2 can expect to hear each other only when the medium itself > |provides broadcast capability as in the Ethernet. > | > |- Seung > | > |On Sun, Dec 21, 2008 at 3:59 AM, Teco Boot wrote: > |> What about a small adjustment: > |> > |> Second, there is no guarantee that two given routers within S can > |> directly communicate with one another. In other words, even though > |> two routers R1 and R2 have symmetric communication with router A, > |there > |> is > |> no guarantee that R1 can hear packets from R2, and there is likewise > |> no guarantee that R2 can hear packets from R1. Thus, multi-hop ad > |> hoc wireless communications may be "non-transitive". Such non- > |> transitivity is often observed on multi-hop ad hoc wireless > |networks, > |> due to well-known properties of wireless communication. > |> > |> > |> Now it says: "If R1->A and A->R2, there is no guarantee for R1->R2". > |> And the second behavior is not mixed up with the first one. > |> > |> Teco. > |> > |> |-----Oorspronkelijk bericht----- > |> |Van: autoconf-bounces@ietf.org [mailto:autoconf-bounces@ietf.org] > |Namens > |> |Charles E. Perkins > |> |Verzonden: zondag 21 december 2008 2:10 > |> |Aan: Seung Yi > |> |CC: autoconf@ietf.org > |> |Onderwerp: Re: [Autoconf] aspects of multi-hop wireless communication > |> | > |> | > |> |Hello Seung, > |> | > |> |Yes, of course you are right (embarrassment). > |> | > |> |What is a good name for the property under discussion? > |> | > |> |Regards, > |> |Charlie P. > |> | > |> | > |> |Seung Yi wrote: > |> |> Just one simple comment unrelated to the ongoing interesting > |> |discussion threads. > |> |> > |> |> Isn't the definition of transitivity "If A->B and B->C, then A->C"? > |> |> This document seems to use the term to mean "if A->B and A->C, then > |> |> B->C" in Section 2, second point. > |> |> > |> |> - Seung > |> |> > |> |> 2008/12/19 Emmanuel Baccelli : > |> |> > |> |>> Hi all, > |> |>> here's a draft that aims at describing important aspects of multi- > |hop > |> |>> wireless communication, as observed over the past decade of > |> |experience with > |> |>> such networks. > |> |>> The goal of this document is to identify a consensus about this > |> |topic, and > |> |>> then use this to move on quicker with the working group documents. > |> |>> > |> |>> Please review it, and provide feedback as soon as possible. > |> |>> http://tools.ietf.org/html/draft-baccelli-multi-hop-wireless- > |> |communication-00 > |> |>> > |> |>> cheers > |> |>> Emmanuel > |> |>> _______________________________________________ > |> |>> Autoconf mailing list > |> |>> Autoconf@ietf.org > |> |>> https://www.ietf.org/mailman/listinfo/autoconf > |> |>> > |> |>> > |> |>> > |> |> _______________________________________________ > |> |> Autoconf mailing list > |> |> Autoconf@ietf.org > |> |> https://www.ietf.org/mailman/listinfo/autoconf > |> |> > |> |> > |> |> > |> | > |> |_______________________________________________ > |> |Autoconf mailing list > |> |Autoconf@ietf.org > |> |https://www.ietf.org/mailman/listinfo/autoconf > |> > |> > > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org > https://www.ietf.org/mailman/listinfo/autoconf > ------=_Part_64299_14591113.1229937444759 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi Teco,
yes I agree, the term "non-transitive" was not very straightforwardly used. Saying as you propose would be better, more precisely (correct me if I'm mistaken about what you meant), that if:
C and A can hear each other through A's interface, and,
A and D can hear each other through A's interface, then
it does not mean that C can hear D or that D can hear C

Emmanuel


On Mon, Dec 22, 2008 at 9:48 AM, Teco Boot <teco@inf-net.nl> wrote:
I tried to get rid of B->A and C->A and [NOT B->A].

Somewhat adjusted proposal, and using C and D and not the newly
introduced R1 and R2:

 Second, there is no guarantee that two given routers within S can
 directly communicate with one another.  In other words, even though
 two routers C and D have symmetric communication with router A, there is
 no guarantee that C can hear packets from D, and there is likewise
 no guarantee that D can hear packets from C.  Thus, multi-hop ad
 hoc wireless communications may be "non-transitive".  Such non-
 transitivity is often observed on multi-hop ad hoc wireless networks,
 due to well-known properties of wireless communication.

Now C->A and A->D, but [NOT C->D] and also D->A and A->D, but [NOT D->C].
This characteristic is "non-transitive" and it is orthogonal with
"asymmetry".

Your terms "hidden terminal problem" and "non-broadcast" could be used
as alternative terminology, but could have different meanings in
different context.
 o  "hidden terminal problem" could have to do with collisions.
 o  "non-broadcast" does not apply here, because set S contains at
    least 3 routers (B, C, D).
    Term "Semi-Broadcast" (I-D.ietf-autoconf-manetarch) was introduced,
    where S is subset of N. (N is all nodes in network N). I suggested
    not introducing new terms if they not needed.

Teco.

|-----Oorspronkelijk bericht-----
|Van: scicarus@gmail.com [mailto:scicarus@gmail.com] Namens Seung Yi
|Verzonden: maandag 22 december 2008 0:00
|Aan: Teco Boot
|CC: Charles E. Perkins; autoconf@ietf.org
|Onderwerp: Re: [Autoconf] aspects of multi-hop wireless communication
|
|I'm sorry but it sounds even more confusing to me.
|
|I'm not sure what to call it but it seems to describe the hidden
|terminal problem to me. Or, it's simply saying that the link (or
|whatever you want to call the "S") is of non-broadcast flavor because
|R1 and R2 can expect to hear each other only when the medium itself
|provides broadcast capability as in the Ethernet.
|
|- Seung
|
|On Sun, Dec 21, 2008 at 3:59 AM, Teco Boot <teco@inf-net.nl> wrote:
|> What about a small adjustment:
|>
|>   Second, there is no guarantee that two given routers within S can
|>   directly communicate with one another.  In other words, even though
|>   two routers R1 and R2 have symmetric communication with router A,
|there
|> is
|>   no guarantee that R1 can hear packets from R2, and there is likewise
|>   no guarantee that R2 can hear packets from R1.  Thus, multi-hop ad
|>   hoc wireless communications may be "non-transitive".  Such non-
|>   transitivity is often observed on multi-hop ad hoc wireless
|networks,
|>   due to well-known properties of wireless communication.
|>
|>
|> Now it says: "If R1->A and A->R2, there is no guarantee for R1->R2".
|> And the second behavior is not mixed up with the first one.
|>
|> Teco.
|>
|> |-----Oorspronkelijk bericht-----
|> |Van: autoconf-bounces@ietf.org [mailto:autoconf-bounces@ietf.org]
|Namens
|> |Charles E. Perkins
|> |Verzonden: zondag 21 december 2008 2:10
|> |Aan: Seung Yi
|> |CC: autoconf@ietf.org
|> |Onderwerp: Re: [Autoconf] aspects of multi-hop wireless communication
|> |
|> |
|> |Hello Seung,
|> |
|> |Yes, of course you are right (embarrassment).
|> |
|> |What is a good name for the property under discussion?
|> |
|> |Regards,
|> |Charlie P.
|> |
|> |
|> |Seung Yi wrote:
|> |> Just one simple comment unrelated to the ongoing interesting
|> |discussion threads.
|> |>
|> |> Isn't the definition of transitivity "If A->B and B->C, then A->C"?
|> |> This document seems to use the term to mean "if A->B and A->C, then
|> |> B->C" in Section 2, second point.
|> |>
|> |> - Seung
|> |>
|> |> 2008/12/19 Emmanuel Baccelli <Emmanuel.Baccelli@inria.fr>:
|> |>
|> |>> Hi all,
|> |>> here's a draft that aims at describing important aspects of multi-
|hop
|> |>> wireless communication, as observed over the past decade of
|> |experience with
|> |>> such networks.
|> |>> The goal of this document is to identify a consensus about this
|> |topic, and
|> |>> then use this to move on quicker with the working group documents.
|> |>>
|> |>> Please review it, and provide feedback as soon as possible.
|> |>> http://tools.ietf.org/html/draft-baccelli-multi-hop-wireless-
|> |communication-00
|> |>>
|> |>> cheers
|> |>> Emmanuel
|> |>> _______________________________________________
|> |>> Autoconf mailing list
|> |>> Autoconf@ietf.org
|> |>> https://www.ietf.org/mailman/listinfo/autoconf
|> |>>
|> |>>
|> |>>
|> |> _______________________________________________
|> |> Autoconf mailing list
|> |> Autoconf@ietf.org
|> |> https://www.ietf.org/mailman/listinfo/autoconf
|> |>
|> |>
|> |>
|> |
|> |_______________________________________________
|> |Autoconf mailing list
|> |Autoconf@ietf.org
|> |https://www.ietf.org/mailman/listinfo/autoconf
|>
|>

_______________________________________________
Autoconf mailing list
Autoconf@ietf.org
https://www.ietf.org/mailman/listinfo/autoconf

------=_Part_64299_14591113.1229937444759-- --===============1952878471== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf --===============1952878471==-- From autoconf-bounces@ietf.org Mon Dec 22 01:59:32 2008 Return-Path: X-Original-To: autoconf-archive@megatron.ietf.org Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D4D873A69F1; Mon, 22 Dec 2008 01:59:32 -0800 (PST) X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1A93828C0F0 for ; Mon, 22 Dec 2008 01:59:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.642 X-Spam-Level: X-Spam-Status: No, score=-1.642 tagged_above=-999 required=5 tests=[AWL=0.404, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yWUysvho-yjt for ; Mon, 22 Dec 2008 01:59:31 -0800 (PST) Received: from cpsmtpo-eml03.kpnxchange.com (cpsmtpo-eml03.KPNXCHANGE.COM [213.75.38.152]) by core3.amsl.com (Postfix) with ESMTP id 11AEE3A6894 for ; Mon, 22 Dec 2008 01:59:30 -0800 (PST) Received: from cpsmtp-eml109.kpnxchange.com ([213.75.84.109]) by cpsmtpo-eml03.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 22 Dec 2008 10:59:19 +0100 Received: from M90Teco ([86.83.9.22]) by cpsmtp-eml109.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 22 Dec 2008 10:59:19 +0100 From: "Teco Boot" To: "'Emmanuel Baccelli'" References: <494D9768.3040903@earthlink.net> <000d01c96363$9b42fae0$d1c8f0a0$@nl> <003201c96411$ff01a7d0$fd04f770$@nl> In-Reply-To: Date: Mon, 22 Dec 2008 10:59:16 +0100 Message-ID: <003f01c9641b$f3a2ff10$dae8fd30$@nl> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AclkFiFyn7BL7zghRNqRSvySsJyybwAAvAKQ Content-Language: nl X-OriginalArrivalTime: 22 Dec 2008 09:59:19.0202 (UTC) FILETIME=[F4E08820:01C9641B] Cc: autoconf@ietf.org Subject: Re: [Autoconf] aspects of multi-hop wireless communication X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org Oeps, I forgot to include a minor adjustment on "First": c/C/B/ First, there is no guarantee that a router B within S can, symmetrically, send IP packets directly to router A. In other words, even though B can "hear" packets from node A (since it is a member of set S), there is no guarantee that A can "hear" packets from node B. Thus, multi-hop ad hoc wireless communications may be "asymmetric". Such asymmetry is often experienced on multi-hop ad hoc wireless networks, due to well-known properties of wireless communication. Above "First", routers A and B are introduced. Here, A "sends" and B "hears". OK for me. In "First", the same topology is used: A "sends" and B "hears". For "Second", I introduced routers C and D for non-transitive, as B was used for asymmetry. B, C and D are in set S. =========== > yes I agree, the term "non-transitive" was not very straightforwardly > used. Saying as you propose would be better, more precisely (correct > me if I'm mistaken about what you meant), that if: > C and A can hear each other through A's interface, and, > A and D can hear each other through A's interface, then > it does not mean that C can hear D or that D can hear C Yes, this is correct. You introduced "interface". More complete text: C and A can hear each other through A's and C's interface to network N, and A and D can hear each other through A's and D's interface to network N, then it does not mean that C can hear D or that D can hear C through C's and D's interface to network N. Maybe check I-D text on "node". Example: "router A is reachable from node B" c/node/router/ ?? Except first quote: "node equals router", section 2, 1st paragraph. Teco. _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Mon Dec 22 02:43:50 2008 Return-Path: X-Original-To: autoconf-archive@megatron.ietf.org Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C9F653A6A22; Mon, 22 Dec 2008 02:43:50 -0800 (PST) X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BA8183A6A22 for ; Mon, 22 Dec 2008 02:43:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.935 X-Spam-Level: X-Spam-Status: No, score=-5.935 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XmJv7t8DWZ-s for ; Mon, 22 Dec 2008 02:43:48 -0800 (PST) Received: from mail153.messagelabs.com (mail153.messagelabs.com [216.82.253.51]) by core3.amsl.com (Postfix) with SMTP id C3C743A687D for ; Mon, 22 Dec 2008 02:43:48 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-5.tower-153.messagelabs.com!1229942619!7619181!1 X-StarScan-Version: 6.0.0; banners=.,-,- X-Originating-IP: [136.182.1.12] Received: (qmail 4271 invoked from network); 22 Dec 2008 10:43:39 -0000 Received: from unknown (HELO motgate2.mot.com) (136.182.1.12) by server-5.tower-153.messagelabs.com with SMTP; 22 Dec 2008 10:43:39 -0000 Received: from il27exr02.cig.mot.com (il27exr02.mot.com [10.17.196.71]) by motgate2.mot.com (8.12.11/Motorola) with ESMTP id mBMAhYdD007967; Mon, 22 Dec 2008 03:43:39 -0700 (MST) Received: from il27vts02.mot.com (il27vts02.cig.mot.com [10.17.196.86]) by il27exr02.cig.mot.com (8.13.1/Vontu) with SMTP id mBMAhY0m013716; Mon, 22 Dec 2008 04:43:34 -0600 (CST) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by il27exr02.cig.mot.com (8.13.1/8.13.0) with ESMTP id mBMAhWo7013710; Mon, 22 Dec 2008 04:43:33 -0600 (CST) Message-ID: <494F6F54.5090901@gmail.com> Date: Mon, 22 Dec 2008 11:43:32 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: Teco Boot References: <494B8E7C.7000505@gmail.com> <494BB75E.4050206@gmail.com> <494BC360.1000109@gmail.com> <494BC927.1020400@gmail.com> <494BCCCC.6050206@earthlink.net> <494BCFEF.2010100@gmail.com> <494BD45A.2090106@earthlink.net> <494BE0D8.4070509@gmail.com> <00ae01c96208$aa2ebd20$fe8c3760$@nl> <494BEAB1.3040700@gmail.com> <00af01c96211$e2c97770$a85c6650$@nl> <494BFE4B.9000601@gmail.com> <000001c96285$b050af60$10f20e20$@nl> In-Reply-To: <000001c96285$b050af60$10f20e20$@nl> X-Antivirus: avast! (VPS 081221-0, 21/12/2008), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected Cc: autoconf@ietf.org Subject: Re: [Autoconf] aspects of multi-hop wireless communication X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org Teco Boot wrote: > |> Try it, and you will see it will fail. > |> OK, you can modify the code if you have a C compiler nearby, and some > |> sources to modify. > | > |I'm not meaning to modify any code. It's existing software doing > |bridging between two interfaces as it always did. > > No, you are prohibited to add a 802.11 IBSS interface to a bridge. TEco, I can report more details about this particular experiment early next year about the experiment, if you wish. Alex > > OK, you can do it without warnings, but the 802.11 mechanisms will not > operate as they should. There are problems with address fields, the NIC > cannot send CTS or ACK to the sender, because the transmitter MAC address is > missing in the RTS or DATA MAC header. > You could disable RTS-CTS and send unicast frames until retry limit, but is > this the behavior that you suggest? > > > |> But that is no longer wifi. > | > |Well, it's two 802.11a/b interfaces, running as before. I could put > |both interfaces in ad-hoc mode with iwconfig. There's probably a > |misunderstanding between what the IEEE standard documents mean by > |"ad-hoc" and what iwconfig and related implementations mean by "ad-hoc" > |but I'm sure it works, by experience. > > I am not aware with problems with iwconfig. It should configure the NIC in > IBSS mode. > > > |Or I could set up both to act as access points, it's the same. (the > |only visible difference between AP mode and ad-hoc modes in > |implementation is the MAC address of the essid... in AP mode it's the > |real MAC address of the interface doing AP, in ad-hoc mode it's some > |random 48bit). The resolution between this 48bit number and essid ascii > |name is done by 802.11 link-layer exchanges (probe req/reply IIRC). > > There are lots of other differences between IBSS and BSS. > > On (R1, R2, A): > What if A is STA and R1 and R2 are APs? Assume APs cannot communicate with > each other (no DS). Assume some kind of disaster. > > One could deploy dense APs and a (to be standardized) form of mesh MANET > protocol. This could be disaster^2! > (think of beacon-rain and probe-response-storms, and melt downs due to > collisions) > > > |> You could enable routing, and you are done! > | > |Why doing routing when I could do bridging, simpler, widely available > |software. > > Try and you will see lots of shortcomings with bridging and 802.11 IBSS. > I am not saying it cannot be solved at a shim layer, but please accept this > is not supported by current wifi standards. > > And provide evidence if I am wrong. I will ask errata on the IEEE 802 > standards if you come up with it. > > > |> Play a little with it, and check your (false) assumptions. > | > |I'm not sure which assumption you think I made false? The fact that I > |could build a bridge with brctl and two wifi interfaces? > > I explained above your assumption is false. I analyzed your suggestions > before and my conclusion 802.1D bridging is indeed not allowed with 802.11 > IBSS. > > > By the way, there is code around that improves 802.11 IBSS mode, so bridging > is allowed. Ask Ronald In't Velt for details. This could be very useful if > you want to connect a 802.11 IBSS bridge to a router (split devices) or just > connect a couple of hosts to an ad hoc bridge. > > > Teco. > > > ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Mon Dec 22 03:37:24 2008 Return-Path: X-Original-To: autoconf-archive@megatron.ietf.org Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D88743A69FA; Mon, 22 Dec 2008 03:37:24 -0800 (PST) X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 657803A69A1 for ; Mon, 22 Dec 2008 03:37:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.656 X-Spam-Level: X-Spam-Status: No, score=-1.656 tagged_above=-999 required=5 tests=[AWL=0.390, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4-C7unraSWCg for ; Mon, 22 Dec 2008 03:37:22 -0800 (PST) Received: from hpsmtp-eml19.kpnxchange.com (hpsmtp-eml19.KPNXCHANGE.COM [213.75.38.84]) by core3.amsl.com (Postfix) with ESMTP id 393153A67AD for ; Mon, 22 Dec 2008 03:37:21 -0800 (PST) Received: from cpsmtp-eml104.kpnxchange.com ([213.75.84.104]) by hpsmtp-eml19.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 22 Dec 2008 12:37:10 +0100 Received: from M90Teco ([86.83.9.22]) by cpsmtp-eml104.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 22 Dec 2008 12:37:10 +0100 From: "Teco Boot" To: "'Alexandru Petrescu'" References: <494B8E7C.7000505@gmail.com> <494BB75E.4050206@gmail.com> <494BC360.1000109@gmail.com> <494BC927.1020400@gmail.com> <494BCCCC.6050206@earthlink.net> <494BCFEF.2010100@gmail.com> <494BD45A.2090106@earthlink.net> <494BE0D8.4070509@gmail.com> <00ae01c96208$aa2ebd20$fe8c3760$@nl> <494BEAB1.3040700@gmail.com> <00af01c96211$e2c97770$a85c6650$@nl> <494BFE4B.9000601@gmail.com> <000001c96285$b050af60$10f20e20$@nl> <494F6F54.5090901@gmail.com> In-Reply-To: <494F6F54.5090901@gmail.com> Date: Mon, 22 Dec 2008 12:37:08 +0100 Message-ID: <004001c96429$9f210d70$dd632850$@nl> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AclkIiiflG/H2ZHMSlGjzD+AuDDRmwABff9Q Content-Language: nl X-OriginalArrivalTime: 22 Dec 2008 11:37:10.0358 (UTC) FILETIME=[A05BD760:01C96429] Cc: autoconf@ietf.org Subject: Re: [Autoconf] aspects of multi-hop wireless communication X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org |Teco Boot wrote: |> |> Try it, and you will see it will fail. |> |> OK, you can modify the code if you have a C compiler nearby, and |some |> |> sources to modify. |> | |> |I'm not meaning to modify any code. It's existing software doing |> |bridging between two interfaces as it always did. |> |> No, you are prohibited to add a 802.11 IBSS interface to a bridge. | |TEco, I can report more details about this particular experiment early |next year about the experiment, if you wish. Yes, I am interested. I'll compare your results with the nonstandard implementation from Ronald (http://madwifi-project.org/ticket/1131). It would be discouraging for him if his work is needless. Teco. |Alex _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Mon Dec 22 05:10:03 2008 Return-Path: X-Original-To: autoconf-archive@megatron.ietf.org Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AE3013A6848; Mon, 22 Dec 2008 05:10:03 -0800 (PST) X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EAB273A6848 for ; Mon, 22 Dec 2008 05:10:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.551 X-Spam-Level: X-Spam-Status: No, score=-6.551 tagged_above=-999 required=5 tests=[AWL=0.048, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WTe2jGvKSgNW for ; Mon, 22 Dec 2008 05:10:00 -0800 (PST) Received: from mail128.messagelabs.com (mail128.messagelabs.com [216.82.250.131]) by core3.amsl.com (Postfix) with SMTP id 5B2C43A683A for ; Mon, 22 Dec 2008 05:10:00 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-7.tower-128.messagelabs.com!1229951391!3893207!1 X-StarScan-Version: 6.0.0; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 2113 invoked from network); 22 Dec 2008 13:09:51 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-7.tower-128.messagelabs.com with SMTP; 22 Dec 2008 13:09:51 -0000 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id mBMD9jxm018874; Mon, 22 Dec 2008 06:09:50 -0700 (MST) Received: from il06vts03.mot.com (il06vts03.mot.com [129.188.137.143]) by il06exr04.mot.com (8.13.1/Vontu) with SMTP id mBMD9jm6011848; Mon, 22 Dec 2008 07:09:45 -0600 (CST) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by il06exr04.mot.com (8.13.1/8.13.0) with ESMTP id mBMD9h1Y011805; Mon, 22 Dec 2008 07:09:44 -0600 (CST) Message-ID: <494F9194.9020309@gmail.com> Date: Mon, 22 Dec 2008 14:09:40 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: Teco Boot References: <494B8E7C.7000505@gmail.com> <494BB75E.4050206@gmail.com> <494BC360.1000109@gmail.com> <494BC927.1020400@gmail.com> <494BCCCC.6050206@earthlink.net> <494BCFEF.2010100@gmail.com> <494BD45A.2090106@earthlink.net> <494BE0D8.4070509@gmail.com> <00ae01c96208$aa2ebd20$fe8c3760$@nl> <494BEAB1.3040700@gmail.com> <00af01c96211$e2c97770$a85c6650$@nl> <494BFE4B.9000601@gmail.com> <000001c96285$b050af60$10f20e20$@nl> <494F6F54.5090901@gmail.com> <004001c96429$9f210d70$dd632850$@nl> In-Reply-To: <004001c96429$9f210d70$dd632850$@nl> X-Antivirus: avast! (VPS 081221-0, 21/12/2008), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected Cc: autoconf@ietf.org Subject: Re: [Autoconf] aspects of multi-hop wireless communication X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org Teco Boot wrote: > |Teco Boot wrote: |> |> Try it, and you will see it will fail. |> |> > OK, you can modify the code if you have a C compiler nearby, and > |some |> |> sources to modify. |> | |> |I'm not meaning to modify any > code. It's existing software doing |> |bridging between two > interfaces as it always did. |> |> No, you are prohibited to add a > 802.11 IBSS interface to a bridge. | |TEco, I can report more details > about this particular experiment early |next year about the > experiment, if you wish. > > Yes, I am interested. I'll compare your results with the nonstandard > implementation from Ronald (http://madwifi-project.org/ticket/1131). > It would be discouraging for him if his work is needless. Hi Teco, and thanks to Ronald for the madwifi patch. I wanted to say I didn't consider the madwifi driver, I think bridging+adhoc would work without madwifi but with offtheshelf drivers. It is something I should confirm later. About the madwifi bridging adhoc patch: this means that with that patch the bridging could be done with a PC having two wifi interfaces in adhoc mode, right? If that patch goes mainstream then it's all good, right? I understand you also seem to say this patch would break an IEEE specification (802.1D?), right? If so then maybe that spec would be fixed according to implementation? Alex > > Teco. > > > |Alex > > > ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Mon Dec 22 06:30:49 2008 Return-Path: X-Original-To: autoconf-archive@megatron.ietf.org Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1F7643A6A53; Mon, 22 Dec 2008 06:30:49 -0800 (PST) X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5F4B83A6A53 for ; Mon, 22 Dec 2008 06:30:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.67 X-Spam-Level: X-Spam-Status: No, score=-1.67 tagged_above=-999 required=5 tests=[AWL=0.376, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6pOrAuLH4B3Z for ; Mon, 22 Dec 2008 06:30:47 -0800 (PST) Received: from hpsmtp-eml16.kpnxchange.com (hpsmtp-eml16.KPNXCHANGE.COM [213.75.38.116]) by core3.amsl.com (Postfix) with ESMTP id F083A3A6A28 for ; Mon, 22 Dec 2008 06:30:46 -0800 (PST) Received: from cpsmtp-eml102.kpnxchange.com ([213.75.84.102]) by hpsmtp-eml16.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 22 Dec 2008 15:30:35 +0100 Received: from M90Teco ([86.83.9.22]) by cpsmtp-eml102.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 22 Dec 2008 15:30:34 +0100 From: "Teco Boot" To: "'Alexandru Petrescu'" References: <494B8E7C.7000505@gmail.com> <494BB75E.4050206@gmail.com> <494BC360.1000109@gmail.com> <494BC927.1020400@gmail.com> <494BCCCC.6050206@earthlink.net> <494BCFEF.2010100@gmail.com> <494BD45A.2090106@earthlink.net> <494BE0D8.4070509@gmail.com> <00ae01c96208$aa2ebd20$fe8c3760$@nl> <494BEAB1.3040700@gmail.com> <00af01c96211$e2c97770$a85c6650$@nl> <494BFE4B.9000601@gmail.com> <000001c96285$b050af60$10f20e20$@nl> <494F6F54.5090901@gmail.com> <004001c96429$9f210d70$dd632850$@nl> <494F9194.9020309@gmail.com> In-Reply-To: <494F9194.9020309@gmail.com> Date: Mon, 22 Dec 2008 15:30:32 +0100 Message-ID: <004901c96441$d8a2f5a0$89e8e0e0$@nl> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AclkNpUkm0U7Bni1Rsq/s244nQoqtAABcteg Content-Language: nl X-OriginalArrivalTime: 22 Dec 2008 14:30:34.0472 (UTC) FILETIME=[D9B1A680:01C96441] Cc: autoconf@ietf.org Subject: Re: [Autoconf] aspects of multi-hop wireless communication X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org |> Yes, I am interested. I'll compare your results with the nonstandard |> implementation from Ronald (http://madwifi-project.org/ticket/1131). |> It would be discouraging for him if his work is needless. | |Hi Teco, and thanks to Ronald for the madwifi patch. | |I wanted to say I didn't consider the madwifi driver, I think |bridging+adhoc would work without madwifi but with offtheshelf drivers. | It is something I should confirm later. | |About the madwifi bridging adhoc patch: this means that with that patch |the bridging could be done with a PC having two wifi interfaces in adhoc |mode, right? If that patch goes mainstream then it's all good, right? No, there are more problems. Reported problems (bugs...) are split networks due to failing BSSID (clock synchronization problems), and problems with beacon suppression. Personally I think the probe reply storm with high collision probability is a more difficult one to solve. More important, there is a need for multi-hop forwarding. 802.1D does not support that. Some came up with some kind of STP implementation, but this is IMHO not well behaving in a mobile environment. Better approaches use some kind of MANET protocols, often copies from the IETF ones. Anyhow, there are other reasons using IP MANET protocols. Using multiple types of media is often mentioned and in fact you also came up with this one. Scalability and finding the best paths in a dynamic topology is our challenge. |I understand you also seem to say this patch would break an IEEE |specification (802.1D?), right? If so then maybe that spec would be |fixed according to implementation? It is partly solved. 802.1D does not provide multi-hop communication in an ad hoc network. The patch provides support for an Ethernet connection between a MANET router and a WLAN radio in a mode similar to .11 IBSS. 802.11s would provide something that is similar to a MANET. Again, it is .11 only. Not sure on performance / scalability. Not even mentioning split / merges with multi-homing. Teco. _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Mon Dec 22 09:13:29 2008 Return-Path: X-Original-To: autoconf-archive@megatron.ietf.org Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AEA153A6A51; Mon, 22 Dec 2008 09:13:29 -0800 (PST) X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 061203A6A51 for ; Mon, 22 Dec 2008 09:13:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kA1wWHR6inGM for ; Mon, 22 Dec 2008 09:13:28 -0800 (PST) Received: from virginia.nps.edu (virginia.nps.edu [205.155.65.15]) by core3.amsl.com (Postfix) with ESMTP id 190073A6819 for ; Mon, 22 Dec 2008 09:13:28 -0800 (PST) Received: from [172.20.58.162] ([172.20.58.162]) by virginia.nps.edu with Microsoft SMTPSVC(6.0.3790.3959); Mon, 22 Dec 2008 09:13:19 -0800 From: Rex Buddenberg To: Alexandru Petrescu In-Reply-To: <494BE0BF.5060606@gmail.com> References: <494B8E7C.7000505@gmail.com> <494BB75E.4050206@gmail.com> <494BBBCB.4080804@gmail.com> <1229709208.29772.146.camel@localhost.localdomain> <494BE0BF.5060606@gmail.com> Date: Fri, 19 Dec 2008 11:01:20 -0800 Message-Id: <1229713280.29772.158.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 (2.22.3.1-1.fc9) X-OriginalArrivalTime: 22 Dec 2008 17:13:19.0842 (UTC) FILETIME=[964EDC20:01C96458] Cc: autoconf@ietf.org, Emmanuel Baccelli Subject: Re: [Autoconf] aspects of multi-hop wireless communication X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org A layer 2-specific solution is a clear no-no. There are more specific links in the military that have been roped into the internet that we want do catalog here. CAPs around legacy MILSTAR, CAPs around INMARSAT B. Global Broadcast System 'does IP' but isn't integrated (for reasons that I cannot fathom). And the list of specific radio links that _should_ be in the internet is far more immense than you have the patience to listen to. JTRS Wideband Network Waveform JTRS Soldier Network Wavefrom Three flavors of Mil-Std-188-220 God knows how many flavors of data link under Common Data Link program ... ... the list goes on apparently eternally. For most of these, the 'data links' are not routable networks so the subject of routers in general, much less router mobility, is rather moot. But that's really beside the point --we need a general solution view to a general solution problem, not something link-specific (we have enough of those already). I'll recite a point I made to Emmanuel off-line. There's a topology shift that is happening first in the military, but is a general harbinger. Today when one thinks of wireless (in an internet context) most think of WiFi and at the fringe of the network. In other words a LAN solution -- reach from last router to end systems. But that's not the military problem. The most extreme existence proof today is a navy ship with a LAN inside (wired ethernet). End systems all attach to that. Router in radio central to reach out to the radio-WANs. Whether or not there's a satellite between, it's a router-router WAN problem (no end systems in sight -- they're on other side of the router). The question to toy with is 'how long before that's what you see in your automobile?' If you use the term 'fire engine', it may not be long at all. WiFi is a wholly inappropriate technology for the radio-WAN problem for several reasons; the contention MAC being at the top of the list. On Fri, 2008-12-19 at 18:58 +0100, Alexandru Petrescu wrote: > Rex Buddenberg wrote: > > You haven't been watching ... both US Army and US Marine Corps are > > filling up the space between brigade and company with IEEE 802.16 gear. > > And routing it all together. > > IETF has specs for IPv6 over 802.16 gear. It works, it's been > experimented. The A-B-C terminal problem wasn't mentioned. > > > For military, WiFi is a bauble. Army worked through a proposal to > > implement it in command centers (think tents in the desert) and finally > > scrapped the proposal. Because you could indeed clip the ethernet wire > > but not the power cord, so not much payback. And in order to get that > > niggardly payback they were going to pay a lot for a layer 2 encryption > > solution. Spent the money on .16 gear instead ... > > > > This is wide of the MANET issues. But MANET (and autoconf) is > > applicable to a lot of wireless LAN and radio-WAN problems well beyond > > WiFi. > > AS above, IPv6 over 802.16 works has been implemented, from emulators to > the real link layer. > > What other link layer? > > Alex > > > On Fri, 2008-12-19 at 16:20 +0100, Alexandru Petrescu wrote: > >> Dearlove, Christopher (UK) wrote: > >>>> I think some solutions exist at PHY and MAC layers in the case of > >>>> 802.11. > >>> As has been said many times before, MANET is not just > >>> about 802.11. > >> I may have missed something. What other than 802.11 is it about? > >> > >> Alex > >> > >> > >> ______________________________________________________________________ > >> This email has been scanned by the MessageLabs Email Security System. > >> For more information please visit http://www.messagelabs.com/email > >> ______________________________________________________________________ > >> _______________________________________________ > >> Autoconf mailing list > >> Autoconf@ietf.org > >> https://www.ietf.org/mailman/listinfo/autoconf > > > > > > > ______________________________________________________________________ > This email has been scanned by the MessageLabs Email Security System. > For more information please visit http://www.messagelabs.com/email > ______________________________________________________________________ _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Mon Dec 22 09:23:21 2008 Return-Path: X-Original-To: autoconf-archive@megatron.ietf.org Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0EAE83A6A58; Mon, 22 Dec 2008 09:23:21 -0800 (PST) X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C116B3A6A56 for ; Mon, 22 Dec 2008 09:23:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 53smCP923kBQ for ; Mon, 22 Dec 2008 09:23:18 -0800 (PST) Received: from virginia.nps.edu (virginia.nps.edu [205.155.65.15]) by core3.amsl.com (Postfix) with ESMTP id D66CF3A67AC for ; Mon, 22 Dec 2008 09:23:18 -0800 (PST) Received: from [172.20.58.162] ([172.20.58.162]) by virginia.nps.edu with Microsoft SMTPSVC(6.0.3790.3959); Mon, 22 Dec 2008 09:23:10 -0800 From: Rex Buddenberg To: "Charles E. Perkins" In-Reply-To: <494BEDD0.9020708@earthlink.net> References: <494B8E7C.7000505@gmail.com> <494BB75E.4050206@gmail.com> <494BC360.1000109@gmail.com> <494BC927.1020400@gmail.com> <494BCCCC.6050206@earthlink.net> <494BCFEF.2010100@gmail.com> <494BD45A.2090106@earthlink.net> <494BE0D8.4070509@gmail.com> <494BE5A5.4020205@earthlink.net> <494BEA55.3080304@gmail.com> <494BEDD0.9020708@earthlink.net> Date: Mon, 22 Dec 2008 09:31:32 -0800 Message-Id: <1229967092.11046.7.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 (2.22.3.1-1.fc9) X-OriginalArrivalTime: 22 Dec 2008 17:23:10.0838 (UTC) FILETIME=[F691B160:01C96459] Cc: autoconf@ietf.org Subject: Re: [Autoconf] aspects of multi-hop wireless communication X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org Charlie's right. But IMHO, not quite complete. The issue is not one of standards but provisioning. In almost every instance I can think of where we'd want MANET and multi-hop features, high availability is a concern -- indeed usually a trumping one. There are three principles of high availability engineering: the second one is 'reliable crossover'. The protocol design of IP (connectionless, stateless) solves this second principle by protocol design. Routers use altroutes, if they are provisioned, all day every day. Bridges, at least in the classical sense do not. An off-shelf bridge runs spanning tree protocol which curtails loops by killing off the altroutes (turns a graph back into a tree). This flat defeats the second principle of high availability engineering. brctl .... I don't know what that is. But the litmus test I'd apply is whether it still preserves the second principle. This is not really a standards and protocols issue but a configuration, provisioning and implementation one. On Fri, 2008-12-19 at 10:54 -0800, Charles E. Perkins wrote: > Hello again Alex, > > Alexandru Petrescu wrote: > > > >> > >> Actually, all that is needed is for IP to have a useful interface to the > >> device driver. > > > > I agree. Device driver interfaces are known for several wireless link > > layers. I think there isn't one special for the A-B-C hidden terminal > > problem. I may be wrong, but I think. > > That's because IP doesn't need to know whether the link > has problems with hidden terminals. > > > > >>>> If you would like to suggest limiting the applicability of IP to > >>>> _only_ be allowed to work for links with specific characteristics, > >>>> then I think you should be explicit about it. > >>> > >>> YEs, I'm explicit: it's wifi. > >> > >> That restriction is not in the charter. Do you want to campaign > >> for a charter revision? > > > > Right... No, no, I don't want to restrict to wifi. I think the A-B-C > > hidden terminal problem was mentioned in the wifi context. I haven't > > seen it elsewhere. > > > > I agree for a solution IP to run over several link layers, for example > > wifi and 802.16. > > > > When a router needs to route between a wifi and a 802.16 link it never > > has the hidden terminal problem. > > The main thing a router needs, is to know the next hop. > > > > > > > > > > Yes, I'd like to help with a protocol for wireless links, like wifi > > and 802.16. But routing between these two doesn't expose the hidden > > terminal problem. I'm pretty sure about it, I can say that because I > > have experience with IP over wifi and over 802.16 (emulated) links. > > Again, routing doesn't need to know about that. And, in fact, > I believe that IP doesn't have to know about asymmetry, nontransitivity, > or the time of day. It just has to know about the next hop. > > But the routing protocols have to be engineered to provide that > information. And, as this overly long and time-consuming discussion > has shown, there is a bit of confusion about how to engineer > routing protocols that work over the links under discussion. > > You seem to claim that we shouldn't worry about them because > the link layer has to solve problems like asymmetry and hidden > terminal problems. I'm of the opinion that routing protocols have > to be engineered in some circumstances to avoid making > unwarranted inferences about symmetry and transitivity. > > I think it would be nice to identify exactly what your concern is. > Once it was WiFi only, now it's not. Do you think that routing > protocol work should only be chartered for links that conform to > certain regularity assumptions like symmetry and transitivity? > > Regards, > Charlie P. > > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org > https://www.ietf.org/mailman/listinfo/autoconf _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Mon Dec 22 11:28:22 2008 Return-Path: X-Original-To: autoconf-archive@megatron.ietf.org Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 62E9A3A696C; Mon, 22 Dec 2008 11:28:22 -0800 (PST) X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 19C8D3A696C for ; Mon, 22 Dec 2008 11:28:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N8gbdZeLTn1w for ; Mon, 22 Dec 2008 11:28:20 -0800 (PST) Received: from virginia.nps.edu (virginia.nps.edu [205.155.65.15]) by core3.amsl.com (Postfix) with ESMTP id 11A083A68CE for ; Mon, 22 Dec 2008 11:28:20 -0800 (PST) Received: from [172.20.58.162] ([172.20.58.162]) by virginia.nps.edu with Microsoft SMTPSVC(6.0.3790.3959); Mon, 22 Dec 2008 11:28:11 -0800 From: Rex Buddenberg To: Emmanuel Baccelli In-Reply-To: References: Date: Mon, 22 Dec 2008 11:36:35 -0800 Message-Id: <1229974596.11046.67.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 (2.22.3.1-1.fc9) X-OriginalArrivalTime: 22 Dec 2008 19:28:11.0686 (UTC) FILETIME=[6D6C4460:01C9646B] Cc: autoconf@ietf.org Subject: Re: [Autoconf] aspects of multi-hop wireless communication X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org Emmanuel, You've managed to generate a lot of discussion. But a lot of it is 'micro' and tends to blast past some of the macro -- just why are we doing all this? So let me try this: a use case from which we can derive some requirements that places some context around. Sense? This by no means invalidates your draft. Objective: extend the internet to mobile platforms. First, a sorting model. In 15 years of teaching plowshares-into-swords internet (and 20 years as a practitioner prior), I've found that all the requirements differences fall into four categories: - high availability (Ao in the lingo) - security - Quality of Service control - reach to mobile platforms. These categories aren't orthogonal but I've never found diffs that fall outside them so makes a good mental checklist. You can use it to get a feel for priorities too -- I've had to browbeat a lot of folks who start a discussion with QoS and immediately leap to the need for RSVP or something similar that reintroduces state at layer 3 ... Ao is always a trumping requirement. Now to a use case. A fire engine -- it's a good example to illustrate the interplay: - we want a good robust wired internet as far as it can go. The problems are always easier there than when radios get in the act. (We'll assume that the fire engine's dispatching and supervisory command are on the net). - a reach to emergency services vehicles. This is not necessarily a 'mesh' job but one that IEEE 802.16 is well suited for. While some automated config features are useful; they're not essential to getting something that works. Possible to construct mesh use cases where one fire truck becomes a relay between a fixed POP and a second fire truck (and yes, all the transitivity discussion can get in here). But the mesh issues are not necessary to get real value. - a WiFi splotch around the fire engine, to support several end systems, is useful. Again, no meshing here -- just plant an AP on the truck. But the thread should start to show you why you want a router on the fire truck, not a bridge. - now to the firemen working in a burning building. Here's where the mesh issues start to be useful. What we want to do is continue to extend the internet, this time from the fire truck to the firemen in the building. It is entirely practical that this network be homogeneous (e.g. all WiFi). And we can argue about whether the meshing should be solved at layer 2 or 3 ... the central point in the argument is whether I can meet 2nd principle of High Ao engineering (support multiple altroutes, if the meshing arrangement can only be cognizant of one at a time, take it out behind the paint locker). - but we're not finished. We've passed the stage where the fireman has only one end system on his person (e.g. a VOIP rig). In this particular use case, he needs a location sensor too -- knowing where firefighters are in a smoke-filled, blacked out building is a critical safety issue. And he may need a PDA to see where his buddies are. And he may have a heat sensor to detect hot spots (which also should be exporting its data). So we have a LAN problem on the firefighter's person, which then routes into the mesh that reaches to him. Now, gander at the sorting model and see what we can derive: - anyone disagree that this is a high Ao situation? So we need altroutes (principle 1) and we can't use protocols that ace out their use (e.g. spanning tree)(principle 2), and we need a monitoring system (SNMP does this) to detect failures as they occur (principle 3). - security divides into two issues: 1) security of the content, a layer 7 issue which is outside of our scope here (e.g. signed e-mail). 2) infrastructure protection security -- we don't want the neighborhood script kiddies to get into the network while we're trying to fight a fire (but we may want to open the door to another fire department -- don't raise this bar indiscriminately). - QoS is, of course, important. Especially in radio-WANs which are four orders of magnitude less capacious than the wired internet they're extending from. Diff-serve is fine; it doesn't interfere with the Ao issues above. Emergency services data has a much higher multicast content than 'civilian' and once you factor in the high Ao ... everything becomes multicast. And now you have a requirements context to tackle the reach to mobile platforms subject. Any help? On Fri, 2008-12-19 at 10:19 +0100, Emmanuel Baccelli wrote: > Hi all, > > here's a draft that aims at describing important aspects of multi-hop > wireless communication, as observed over the past decade of experience > with such networks. > > > The goal of this document is to identify a consensus about this topic, > and then use this to move on quicker with the working group documents. > > > > Please review it, and provide feedback as soon as possible. > > > http://tools.ietf.org/html/draft-baccelli-multi-hop-wireless-communication-00 > > > > cheers > Emmanuel > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org > https://www.ietf.org/mailman/listinfo/autoconf _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Tue Dec 23 06:26:18 2008 Return-Path: X-Original-To: autoconf-archive@megatron.ietf.org Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8FB8D28C0E4; Tue, 23 Dec 2008 06:26:18 -0800 (PST) X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8973C3A6AF2 for ; Tue, 23 Dec 2008 06:26:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.677 X-Spam-Level: X-Spam-Status: No, score=-1.677 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AATU-xC-jf6A for ; Tue, 23 Dec 2008 06:26:16 -0800 (PST) Received: from mail-bw0-f21.google.com (mail-bw0-f21.google.com [209.85.218.21]) by core3.amsl.com (Postfix) with ESMTP id B2A5A3A6986 for ; Tue, 23 Dec 2008 06:26:15 -0800 (PST) Received: by bwz14 with SMTP id 14so9885839bwz.13 for ; Tue, 23 Dec 2008 06:26:05 -0800 (PST) Received: by 10.181.17.13 with SMTP id u13mr2746337bki.152.1230042364723; Tue, 23 Dec 2008 06:26:04 -0800 (PST) Received: by 10.180.245.2 with HTTP; Tue, 23 Dec 2008 06:26:04 -0800 (PST) Message-ID: <2ced936d0812230626q7182fec8p2d9d5cd901ec2a75@mail.gmail.com> Date: Tue, 23 Dec 2008 11:26:04 -0300 From: "Breno Jacinto" To: "Charles E. Perkins" In-Reply-To: <494F0B17.8070806@earthlink.net> MIME-Version: 1.0 Content-Disposition: inline References: <494BD45A.2090106@earthlink.net> <494BE0D8.4070509@gmail.com> <00ae01c96208$aa2ebd20$fe8c3760$@nl> <494BEAB1.3040700@gmail.com> <00af01c96211$e2c97770$a85c6650$@nl> <494BFE4B.9000601@gmail.com> <000001c96285$b050af60$10f20e20$@nl> <2ced936d0812211653v61161e4dp7f1ba79e81c61124@mail.gmail.com> <494F0B17.8070806@earthlink.net> Cc: autoconf@ietf.org Subject: Re: [Autoconf] aspects of multi-hop wireless communication X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org Hello Charles, 2008/12/22 Charles E. Perkins : > I think this is not an accurate reflection of the evolution of thought > on the subject. At least for me, it was clear that one could easily > make a routing solution by revising RIP to get rid of poison reverse > and other hacks, so that we could have just the next-hop routing > as needed. This was a very long time before 802.11. > > Your word "should" is loaded. IP is, I think, great at stitching together > links into a network. They don't even have to be the same physical > media. That's a major plus compared to layer 2 solutions. Plus, > the same layer 3 solution works for a lot of different wireless physical > media. That's better than blasting away with different solutions for > each different medium. > > I just don't see what's wrong with it. Neither do I :). IP is fine, and great. Let me make my point clearer: you claim that a layer 3 solution may work for a lot of different wireless media. I just don't know any protocol today that does that (for ad hoc networking, not the Internet or wired technologies). I work with Bluetooth, 802.11 and Ethernet networks, and, in practice, they are different enough. For example, Bluetooth barely supports broadcasting, and forces a master-slave topology which is built on-demand (pairing). Multi-hop is, in thesis, possible, but then you need to make scatternets which also force some kind of inter-master communication etc.. 802.11 b/g can do only single-hop communications by default, multi-hopping is done only by IP. So, my view is that IP should really just glue the different iinks together. Underneath, each link should solve their peculiarities and provide a clean interface to IP (or any layer 3 protocol). That splits the problems: we keep on doing inter-networking with IP, but intra-networking is about the layer 2 protocol. In the case of 802.11s and AWDS, see how things are simplified. To IP, it is just a switched ethernet network below it. I wonder if other link-layers provided the same thing: again, I can only see problems getting spitted and solved separately. I don't see what is evil about this, but I still do not have enough evidence in practice. > There is no free lunch. You are going to solve those problems at layer 3, > or you are going to solve them at layer 2. And, even if the latter, you = may > still have to worry about it at layer 3 unless you impose some very strong > regularity conditions (I'm still puzzling over truckloads of repeaters). Yes, that's what I mentioned above. Of course, you may say that I use too much the word "should", and that reality does not offer such regularity conditions at layer 2. Then I can only see a layer 3 protocol that is able to cope with each peculiar link it supports, that would also be different and worth of research. Something like OLSR with Bluetooth support would be interesting for a start. >> - Now, if we could assume that multi-hop is done at layer 2; to layer >> 3 (such as IP), a broadcast should reach (be flooded to) everyone in >> the network. Now, IP sees the network as a single broadcast domain and >> issues in the "real" network should be dealt there. We may then shift >> to the problem of connecting multiple ad hoc networks at the IP layer, >> doing inter-domain routing etc. > > There's that "should" again. In fact, your very example of broadcast > disproves your point: what if the best broadcast used multiple media? I dont quite get it. Broadcasting is specific to each media (meaning, link-layer) and is supposed to reach everyone in the link only. So, to keep that definition, it's necessary to flood the packet in a multi-hop context. Yet, if multiple media are involved, broadcasts are different to each media. That's why I dont follow your best broadcast over different media idea. Could you elaborate a bit more? I think the discussion generated here may seem off-topic, but in my opinion they are not. I think it is really important to try to make the concepts and terminology of ad hoc networking independent of the practical experiences we had, which is restricted (at least to me) to 802.11 and Bluetooth networks. Other people mentioned a lot of proprietary technologies that do ad hoc, as well. So, how can we keep concepts general enough if there are several technologies that work differently from each other? > Regards, > Charlie P. regards, -- = -- = :: Breno Jacinto :: :: breno - at - gprt.ufpe.br :: :: FingerPrint :: 2F15 8A61 F566 E442 8581 E3C0 EFF4 E202 74B7 7484 :: Persistir no dif=EDcil =E9 a =FAnica maneira de torn=E1-lo f=E1cil algum= dia. :: _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Tue Dec 23 10:39:37 2008 Return-Path: X-Original-To: autoconf-archive@megatron.ietf.org Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7C9133A67A1; Tue, 23 Dec 2008 10:39:37 -0800 (PST) X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 059B03A67DA for ; Tue, 23 Dec 2008 10:39:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qCXU2kz5QyRH for ; Tue, 23 Dec 2008 10:39:35 -0800 (PST) Received: from elasmtp-mealy.atl.sa.earthlink.net (elasmtp-mealy.atl.sa.earthlink.net [209.86.89.69]) by core3.amsl.com (Postfix) with ESMTP id EC01F3A6452 for ; Tue, 23 Dec 2008 10:39:34 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=Uoc/MorI3AVfTYFaQMvieLvM6/HccugrR1Iz8BICQGFcza0OuBwPN55nSGI/9maW; h=Received:Message-ID:Date:From:Organization:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [75.26.137.116] (helo=[10.166.254.43]) by elasmtp-mealy.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1LFCA7-00054k-Kx; Tue, 23 Dec 2008 13:39:23 -0500 Message-ID: <49513057.2070603@earthlink.net> Date: Tue, 23 Dec 2008 10:39:19 -0800 From: "Charles E. Perkins" Organization: Wichorus Inc. User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: Breno Jacinto References: <494BD45A.2090106@earthlink.net> <494BE0D8.4070509@gmail.com> <00ae01c96208$aa2ebd20$fe8c3760$@nl> <494BEAB1.3040700@gmail.com> <00af01c96211$e2c97770$a85c6650$@nl> <494BFE4B.9000601@gmail.com> <000001c96285$b050af60$10f20e20$@nl> <2ced936d0812211653v61161e4dp7f1ba79e81c61124@mail.gmail.com> <494F0B17.8070806@earthlink.net> <2ced936d0812230626q7182fec8p2d9d5cd901ec2a75@mail.gmail.com> In-Reply-To: <2ced936d0812230626q7182fec8p2d9d5cd901ec2a75@mail.gmail.com> X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f520466ce14c6ea4446c2d9ec89009b82de350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 75.26.137.116 Cc: autoconf@ietf.org Subject: Re: [Autoconf] aspects of multi-hop wireless communication X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org Hello again Breno, Comments inline... I have modified the order of your original text. >>> - Now, if we could assume that multi-hop is done at layer 2; to layer >>> 3 (such as IP), a broadcast should reach (be flooded to) everyone in >>> the network. Now, IP sees the network as a single broadcast domain >>> .... We may then shift >>> to the problem of connecting multiple ad hoc networks at the IP layer, >>> doing inter-domain routing etc. >>> >> ...... In fact, your very example of broadcast >> disproves your point: what if the best broadcast used multiple media? >> > > I dont quite get it. Broadcasting is specific to each media > (meaning, link-layer) and is supposed to reach everyone in the link > only. So, to keep that definition, it's necessary to flood the packet > in a multi-hop context. Yet, if multiple media are involved, > broadcasts are different to each media. That's why I dont follow your > best broadcast over different media idea. Could you elaborate a bit > more? Suppose we want to broadcast a packet to every node in the system. We can create a reduced relay set to accomplish this, and it could be constructed using nodes across varying physical media. If you want to distinguish between flooding and broadcast, by defining broadcast to be a transmission that cannot be forwarded, then there are still interesting issues about whether or not locally promiscuous reception is better than iterated unicast. The better alternative could reasonably be selected by a good layer-2 design, but it might still benefit from getting neighborhood (or even two-hop neighborhood) information from topology management at a higher level. It's easier at layer 3, I think. > > > I think the discussion generated here may seem off-topic, but in > my opinion they are not. I think it is really important to try to make > the concepts and terminology of ad hoc networking independent of the > practical experiences we had, which is restricted (at least to me) to > 802.11 and Bluetooth networks. Other people mentioned a lot of > proprietary technologies that do ad hoc, as well. So, how can we keep > concepts general enough if there are several technologies that work > differently from each other? > > I thought that we could do this by identifying the appropriate sort of characterizations for the media and putting them into a draft. For instance, I am pretty sure that AODV works well enough over the various media. If, for instance, Bluetooth has not established a proper scatternet for good connectivity, it simply would not report as many links to neighbors. Since making scatternets seems to be so hard, maybe anyway it would have been better to let IP interact with the master/slave coordination. Resolving this issue, however, is not at all easy and, I think, doesn't help us with the matter at hand. > > So, my view is that IP should really just glue the different iinks > together. Underneath, each link should solve their peculiarities and > provide a clean interface to IP (or any layer 3 protocol). That splits > the problems: we keep on doing inter-networking with IP, but > intra-networking is about the layer 2 protocol. > As written, I completely agree with this. I guess the words are susceptible to varying interpretations, though. For instance, if IP required symmetric links, some useful communication paths may simply cease to exist since layer 2 could not provide them. > In the case of 802.11s and AWDS, see how things are simplified. To > IP, it is just a switched ethernet network below it. Yes, but what happens when a non-802.11s node arrives? Is that poor user just another error condition to be blithely cut off from the world? Or, as above, what happens when a nonsymmetric link is encountered? Do we just have to forget about it? Or what if we could have designed a better protocol that made better flooding, but used brute-force broadcast instead because the interface didn't allow any distinction? Regards, Charlie P. _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Wed Dec 24 07:10:15 2008 Return-Path: X-Original-To: autoconf-archive@megatron.ietf.org Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 678643A695A; Wed, 24 Dec 2008 07:10:15 -0800 (PST) X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C85033A695A for ; Wed, 24 Dec 2008 07:10:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.827 X-Spam-Level: X-Spam-Status: No, score=-1.827 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nyD+LQFjPpEh for ; Wed, 24 Dec 2008 07:10:13 -0800 (PST) Received: from fk-out-0910.google.com (fk-out-0910.google.com [209.85.128.185]) by core3.amsl.com (Postfix) with ESMTP id ACEF03A682D for ; Wed, 24 Dec 2008 07:10:12 -0800 (PST) Received: by fk-out-0910.google.com with SMTP id 18so1703487fkq.5 for ; Wed, 24 Dec 2008 07:10:01 -0800 (PST) Received: by 10.181.153.12 with SMTP id f12mr3172280bko.132.1230131401500; Wed, 24 Dec 2008 07:10:01 -0800 (PST) Received: by 10.180.245.2 with HTTP; Wed, 24 Dec 2008 07:10:01 -0800 (PST) Message-ID: <2ced936d0812240710m6faacc5cwab9168363e933728@mail.gmail.com> Date: Wed, 24 Dec 2008 13:10:01 -0200 From: "Breno Jacinto" To: "Charles E. Perkins" In-Reply-To: <49513057.2070603@earthlink.net> MIME-Version: 1.0 Content-Disposition: inline References: <00ae01c96208$aa2ebd20$fe8c3760$@nl> <494BEAB1.3040700@gmail.com> <00af01c96211$e2c97770$a85c6650$@nl> <494BFE4B.9000601@gmail.com> <000001c96285$b050af60$10f20e20$@nl> <2ced936d0812211653v61161e4dp7f1ba79e81c61124@mail.gmail.com> <494F0B17.8070806@earthlink.net> <2ced936d0812230626q7182fec8p2d9d5cd901ec2a75@mail.gmail.com> <49513057.2070603@earthlink.net> Cc: autoconf@ietf.org Subject: Re: [Autoconf] aspects of multi-hop wireless communication X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org Hello Charles, Answers are below, they a bit long, I hope you' re not tired of the discussion :). I'm really enjoying it. 2008/12/23 Charles E. Perkins : > Suppose we want to broadcast a packet to every node in the system. We can > create a reduced relay set to accomplish this, and it could be constructed > using > nodes across varying physical media. By system you mean an heterogeneous network? Which involves multiple media? That's the only way I can imagine it. So, supposing that there are multiple media involved. But, it is certain that for each media, a different network must be formed. Practical example: nodes having Bluetooth, can only form a Bluetooth network. Nodes with 802.11 b/g can only form networks with other nodes with 802.11 b/g. And that applies to any technology. Now, if those nodes (which form different networks) wish to talk, then there must be at least one node that is able to speak both technologies, as in the example, 802.11 AND Bluetooth. Now, if we use bridging or any other mechanism (such as Ana4 that I cited before), we "glue" these networks at layer two, and they form a single broadcast domain (this is in theory, in practice it currently doesn' t seem to work). Then, to IP or any layer 3 protocol, this is just one network where it's possible to broadcast and it's about the underlying technology how is best to do it. I still dont see how IP can improve anything below it in this case? An IP/ UDP broadcast will, ultimately, become a layer 2 broadcast, right? If there is any kind of optimization, then, it' s up to the underlay network. That' s how I see it, if you have a different view about it, I'd really like to know :). If you use IP on top of each of these separate networks, then, a node may also be an IP gateway between those two networks, much like we are used to and confident that works in the wired world. I could successfuly make a Bluetooth network talk to a 802.11 b/g ad hoc network just by using an IP gateway that had IPs for the Bluetooth and 802.11 ad hoc network. But, I was unable to do it at layer 2 (ie, bridging). That's why I also think IP is a better glue in this case. > If you want to distinguish between flooding and broadcast, by defining > broadcast to be a transmission that cannot be forwarded, then there are s= till > interesting issues about whether or not locally promiscuous reception is = better than > iterated unicast. The better alternative could reasonably be selected by= a good > layer-2 design, but it might still benefit from getting neighborhood (or = even > two-hop neighborhood) information from topology management at a higher le= vel. That' s interesting, I never thought about it. Do you know any text with a comparative study between these different techniques, such as iterated unicast versus promiscuous reception? About the broadcast forwarding: yes, it seems to be a norm that routers do not forward any broadcast packet. Up to now I'm just accepting it, wondering that it can get messy if every router starts to rebroadcast whatever broadcasts it receives. But maybe in some cases this can be interesting. About the topology information: I was recently talking to the guys from AWDS, and they did something interesting. For example, their layer 2 protocol is a proactive, link-state one, very much like OLSR. So, any information about the network is generated there, at layer 2. Now, if, at layer 3, I wish to know any information (such as the topology), then, just ask layer 2. They send it to you. That's some kind of cross-layering that could be interesting in designing better layer 3 protocols in this context. > It's easier at layer 3, I think. With the example from AWDS, I still think its better at layer 2 with some layer 3 "talk". > I thought that we could do this by identifying the appropriate > sort of characterizations for the media and putting them into a draft. > For instance, I am pretty sure that AODV works well enough over the > various media. If, for instance, Bluetooth has not established a proper > scatternet for good connectivity, it simply would not report as many > links to neighbors. Since making scatternets seems to be so hard, > maybe anyway it would have been better to let IP interact with the > master/slave coordination. Resolving this issue, however, is not at > all easy and, I think, doesn't help us with the matter at hand. What kind of media did you test AODV? Up to know I only could check it working over 802.11. And that's another point. How can we know the "way" of doing ad hoc networking? Is it just about offering a mesh (multipoint-to-multipoint) topology? Or, maybe the interconnection of multiple star-like topologies, like scatternets? I think that these assumptions may define the reasoning and concepts we'll be dealing with. That's why I think there's a trend to think in terms of 802.11 ad hoc nets: that's what seems to work up to now and most people can try it, verify and even modify. > As written, I completely agree with this. I guess the words are suscepti= ble > to varying interpretations, though. For instance, if IP required symmetr= ic > links, > some useful communication paths may simply cease to exist since layer 2 > could not provide them. OK, but I think that a little bit of talking between layer 2 and 3 (as the AWDS example mentioned) could solve this. But, of course, this not as simple as it sounds. I'm aware that there are challenges involved. >> In the case of 802.11s and AWDS, see how things are simplified. To >> IP, it is just a switched ethernet network below it. > > Yes, but what happens when a non-802.11s node arrives? Is that poor > user just another error condition to be blithely cut off from the world? > Or, as above, what happens when a nonsymmetric link is encountered? > Do we just have to forget about it? Or what if we could have designed > a better protocol that made better flooding, but used brute-force > broadcast instead because the interface didn't allow any distinction? No, never. The non-802.11s (such as 802.11g or whatever) will be able to form their own networks. Now, as I said in the beginning, someone who is able to talk two (or three or many) must make them participate in the world. It's an internetworking world, after all. It's just that 802.11s or AWDS approches make it simpler by handling multi-hop communication transparently to IP. No need of highly specialized protocols such as OLSR at layer 3, something similar is already at layer 2. The rest is up to IP protocols and internetworking. Symmetric / assymetric links can be handled at layer 2 as well... after all, this is a layer 2 problem, right? If it is still important in some cases for layer 3 to know about them, them a little bit of cross-layering sounds good to me. But I do get your point here. I just think that doing something as AWDS did for 802.11 b/g, we could do it for other link-layers, such as Bluetooth. And that would be a bliss from the IP standpoint, in my opinion. > Regards, > Charlie P. best regards, and merry christimas! -- = -- = :: Breno Jacinto :: :: breno - at - gprt.ufpe.br :: :: FingerPrint :: 2F15 8A61 F566 E442 8581 E3C0 EFF4 E202 74B7 7484 :: Persistir no dif=EDcil =E9 a =FAnica maneira de torn=E1-lo f=E1cil algum= dia. :: _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Wed Dec 24 10:42:09 2008 Return-Path: X-Original-To: autoconf-archive@megatron.ietf.org Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 108473A691E; Wed, 24 Dec 2008 10:42:09 -0800 (PST) X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 171473A691E for ; Wed, 24 Dec 2008 10:42:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id khGRYyo4nmue for ; Wed, 24 Dec 2008 10:42:07 -0800 (PST) Received: from elasmtp-curtail.atl.sa.earthlink.net (elasmtp-curtail.atl.sa.earthlink.net [209.86.89.64]) by core3.amsl.com (Postfix) with ESMTP id E39363A67CC for ; Wed, 24 Dec 2008 10:42:06 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=ZjeWf0Ad2+ZSrJwTFpqLy8f5nyjEaNWqhWq2BQUsU2tCSYuhiZM43r7AFT+5qaXu; h=Received:Message-ID:Date:From:Organization:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [75.26.137.116] (helo=[10.166.254.43]) by elasmtp-curtail.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1LFYff-0005zK-Ag; Wed, 24 Dec 2008 13:41:27 -0500 Message-ID: <4952823C.8030203@earthlink.net> Date: Wed, 24 Dec 2008 10:41:00 -0800 From: "Charles E. Perkins" Organization: Wichorus Inc. User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: Breno Jacinto References: <00ae01c96208$aa2ebd20$fe8c3760$@nl> <494BEAB1.3040700@gmail.com> <00af01c96211$e2c97770$a85c6650$@nl> <494BFE4B.9000601@gmail.com> <000001c96285$b050af60$10f20e20$@nl> <2ced936d0812211653v61161e4dp7f1ba79e81c61124@mail.gmail.com> <494F0B17.8070806@earthlink.net> <2ced936d0812230626q7182fec8p2d9d5cd901ec2a75@mail.gmail.com> <49513057.2070603@earthlink.net> <2ced936d0812240710m6faacc5cwab9168363e933728@mail.gmail.com> In-Reply-To: <2ced936d0812240710m6faacc5cwab9168363e933728@mail.gmail.com> X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f52164cbff3a35c410915e51d6a36be30bd350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 75.26.137.116 Cc: autoconf@ietf.org Subject: Re: [Autoconf] aspects of multi-hop wireless communication X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org Hello Breno, I have to make this short, but anyway provide some responses to your comments. Breno Jacinto wrote: > Hello Charles, > > > >> Suppose we want to broadcast a packet to every node in the system. We can >> create a reduced relay set to accomplish this, and it could be constructed >> using >> nodes across varying physical media. >> > > By system you mean an heterogeneous network? Which involves > multiple media? That's the only way I can imagine it. > Yes, I meant potentially heterogeneous network. > So, supposing that there are multiple media involved. But, it is > certain that for each media, a different network must be formed. > Well, depending on what you mean by "network", I don't take that as an article of faith. However, I reckon we can agree that nodes using different physical media won't be able to properly manage access to the disparate media. > Practical example: nodes having Bluetooth, can only form a Bluetooth > network. Nodes with 802.11 b/g can only form networks with other nodes > with 802.11 b/g. And that applies to any technology. > What if you s/networks/links/? > Now, if those nodes (which form different networks) wish to > talk, then there must be at least one node that is able to speak both > technologies, as in the example, 802.11 AND Bluetooth. Now, if we use > bridging or any other mechanism (such as Ana4 that I cited before), we > "glue" these networks at layer two, and they form a single broadcast > domain (this is in theory, in practice it currently doesn' t seem to > work). Well, it does work. > Then, to IP or any layer 3 protocol, this is just one network > where it's possible to broadcast and it's about the underlying > technology how is best to do it. I still dont see how IP can improve > anything below it in this case? Here, I am definitely not seeing your point. > An IP/ UDP broadcast will, ultimately, > become a layer 2 broadcast, right? Not necessarily, especially if one wants to do iterated unicast. > If there is any kind of > optimization, then, it' s up to the underlay network. That' s how I > see it, if you have a different view about it, I'd really like to know > :). > One example I mentioned before, was that IP could decide which nodes handle relay. > About the topology information: I was recently talking to the > guys from AWDS, and they did something interesting. For example, their > layer 2 protocol is a proactive, link-state one, very much like OLSR. > So, any information about the network is generated there, at layer 2. > Now, if, at layer 3, I wish to know any information (such as the > topology), then, just ask layer 2. They send it to you. That's some > kind of cross-layering that could be interesting in designing better > layer 3 protocols in this context. > > >> It's easier at layer 3, I think. >> > > With the example from AWDS, I still think its better at layer 2 > with some layer 3 "talk". > What if your layer-2 signaling eats 30% of the bandwidth and layer-3 signaling would have only used 5%? Again, there's no free lunch. Furthermore, proactive protocols in any sufficiently big domain will eventually use 100% of the bandwidth. I do understand that many proponents don't believe in huge ad hoc networks, so from that perspective it's a moot point. > > And that's another point. How can we know the "way" of doing ad > hoc networking? Well, I am not a religious person, and especially not religious about technology choices. So I don't think there is necessarily any one "way" to do it. For me, the bottom line is performance, including scalability. > > >> As written, I completely agree with this. I guess the words are susceptible >> to varying interpretations, though. For instance, if IP required symmetric >> links, >> some useful communication paths may simply cease to exist since layer 2 >> could not provide them. >> > > OK, but I think that a little bit of talking between layer 2 and > 3 (as the AWDS example mentioned) could solve this. But, of course, > this not as simple as it sounds. I'm aware that there are challenges > involved. > It is my belief that the challenges are exacerbated by trying to do multihop forwarding at layer 2. But lots of engineers enjoy a good challenge, and if they can sell the results, even better, except insofar as new challenges are introduced relating to backwards compatibility to poorer technology choices. > > No, never. The non-802.11s (such as 802.11g or whatever) will be > able to form their own networks. Now, as I said in the beginning, > someone who is able to talk two (or three or many) must make them > participate in the world. It's an internetworking world, after all. > It's just that 802.11s or AWDS approches make it simpler by handling > multi-hop communication transparently to IP. Here I disagree. Complicating one level and reducing proper visibility at another level is not automatically equal to "simpler". > No need of highly > specialized protocols such as OLSR at layer 3, something similar is > already at layer 2. > That's an awfully long stretch. > The rest is up to IP protocols and internetworking. Symmetric / > assymetric links can be handled at layer 2 as well... after all, this > is a layer 2 problem, right? If it is still important in some cases > for layer 3 to know about them, them a little bit of cross-layering > sounds good to me. > So, do you want IP to run over asymmetric links, or not? If layer 2 cannot create the fiction of symmetry, do we lose the link or not? Felicitous Festivities! Regards, Charlie P. _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf