From ternli-bounces@ietf.org Tue Jul 11 19:53:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0S2H-0001Jv-GH; Tue, 11 Jul 2006 19:53:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0S2G-0001Ji-BA for ternli@ietf.org; Tue, 11 Jul 2006 19:53:00 -0400 Received: from sccrmhc13.comcast.net ([63.240.77.83]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G0S2E-0000JD-4U for ternli@ietf.org; Tue, 11 Jul 2006 19:53:00 -0400 Received: from s73602 (h1ad3-net84db.lab.risq.net?[132.219.26.211]) by comcast.net (sccrmhc13) with SMTP id <2006071123525501300jbgo6e>; Tue, 11 Jul 2006 23:52:55 +0000 Message-ID: <0b6401c6a545$01b89bc0$d31adb84@china.huawei.com> From: "Spencer Dawkins" To: Date: Tue, 11 Jul 2006 19:52:02 -0400 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed Subject: [TERNLI] Notes from tonight's ad hoc X-BeenThere: ternli@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport-Enhancing Refinements to the Network Layer Interface List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ternli-bounces@ietf.org Were stuck into jabber log, at http://www.ietf.org/meetings/ietf-logs/tsvwg/2006-07-11.html, at Lar's suggestion. Spencer From ternli-bounces@ietf.org Wed Jul 12 09:35:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0esH-0005F3-6O; Wed, 12 Jul 2006 09:35:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0esG-0005Ey-LZ for ternli@ietf.org; Wed, 12 Jul 2006 09:35:32 -0400 Received: from mx1.grc.nasa.gov ([128.156.11.68]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G0esF-0004TL-BH for ternli@ietf.org; Wed, 12 Jul 2006 09:35:32 -0400 Received: from lombok-fi.grc.nasa.gov (seraph1.grc.nasa.gov [128.156.10.10]) by mx1.grc.nasa.gov (Postfix) with ESMTP id 80853C291 for ; Wed, 12 Jul 2006 09:35:30 -0400 (EDT) Received: from apataki.grc.nasa.gov (apataki.grc.nasa.gov [139.88.112.35]) by lombok-fi.grc.nasa.gov (NASA GRC TCPD 8.13.7/8.13.7) with ESMTP id k6CDZU3O013789; Wed, 12 Jul 2006 09:35:30 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by apataki.grc.nasa.gov (NASA GRC TCPD 8.13.7/8.13.7) with ESMTP id k6CDZTor009873; Wed, 12 Jul 2006 09:35:29 -0400 (EDT) Received: from apataki.grc.nasa.gov ([127.0.0.1])by localhost (apataki.grc.nasa.gov [127.0.0.1]) (amavisd-new, port 10024)with ESMTP id 06288-22; Wed, 12 Jul 2006 09:35:28 -0400 (EDT) Received: from drpepper.grc.nasa.gov (gr2134391.grc.nasa.gov [139.88.44.123])by apataki.grc.nasa.gov (NASA GRC TCPD 8.13.7/8.13.7) with ESMTP id k6CDZNSB009804;Wed, 12 Jul 2006 09:35:23 -0400 (EDT) Received: by drpepper.grc.nasa.gov (Postfix, from userid 501)id DB8C74FCA3; Wed, 12 Jul 2006 09:35:56 -0400 (EDT) Date: Wed, 12 Jul 2006 09:35:56 -0400 From: Wesley Eddy To: Spencer Dawkins Subject: Re: [TERNLI] Notes from tonight's ad hoc Message-ID: <20060712133556.GB11317@grc.nasa.gov> References: <0b6401c6a545$01b89bc0$d31adb84@china.huawei.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0b6401c6a545$01b89bc0$d31adb84@china.huawei.com> User-Agent: Mutt/1.5.5.1i X-imss-version: 2.040 X-imss-result: Passed X-imss-scores: Clean:98.02204 C:2 M:4 S:5 R:5 X-imss-settings: Baseline:2 C:1 M:1 S:1 R:1 (0.1500 0.1500) X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: ternli@ietf.org X-BeenThere: ternli@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: weddy@grc.nasa.gov List-Id: Transport-Enhancing Refinements to the Network Layer Interface List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ternli-bounces@ietf.org On Tue, Jul 11, 2006 at 07:52:02PM -0400, Spencer Dawkins wrote: > Were stuck into jabber log, at > http://www.ietf.org/meetings/ietf-logs/tsvwg/2006-07-11.html, at Lar's > suggestion. > One thing that I took away from yesterday was that it may be productive to build a pair of tables to describe the problem space; one table for "significant path changes" that might be passed up to the transport, and one table for "significant path desires" that the transport can pass down. In each table, we could have a row for each piece of data and columns that describe the time-frame of relevence (per packet, within an RTT, per-connection, etc), any existing "point" solutions, and whether or not the solutions are deployed now, or still research. There are a lot of starting points to feed this, including the IAB link indications document and some of the mobopts work. My thought is that once we have all the diverse things we're talking about clearly listed, it might be easier to pick out commonalities or visualize what an architected solution could look like, and also what the current accidental architecture looks like. Does this sound like a reasonable next step to take? -- Wesley M. Eddy Verizon Federal Network Systems From ternli-bounces@ietf.org Wed Jul 12 10:45:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0fxX-0002I4-II; Wed, 12 Jul 2006 10:45:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0fxV-0002Hy-VK for ternli@ietf.org; Wed, 12 Jul 2006 10:45:01 -0400 Received: from sccrmhc12.comcast.net ([63.240.77.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G0fxU-00006s-Nu for ternli@ietf.org; Wed, 12 Jul 2006 10:45:01 -0400 Received: from s73602 (h1ad3-net84db.lab.risq.net?[132.219.26.211]) by comcast.net (sccrmhc12) with SMTP id <2006071214450001200c1kvae>; Wed, 12 Jul 2006 14:45:00 +0000 Message-ID: <0f4d01c6a5c1$a0fa30a0$d31adb84@china.huawei.com> From: "Spencer Dawkins" To: References: <0b6401c6a545$01b89bc0$d31adb84@china.huawei.com> <20060712133556.GB11317@grc.nasa.gov> Subject: Re: [TERNLI] Notes from tonight's ad hoc Date: Wed, 12 Jul 2006 10:44:06 -0400 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 X-BeenThere: ternli@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport-Enhancing Refinements to the Network Layer Interface List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ternli-bounces@ietf.org Did we end up with a list of lists? This one seemed helpful. Others I think we talked about were - list of WGs, BoFs, and BoF requests, with history, - list of things that transports might care about, - list of things they might do "if they knew", - list of canonical land mines (security, host security considerations, state in the network, complexity of mandatory mechanisms plus "hints" and the interaction between mandatory mechanisms and hints, and transport considerations for notifications, which I forgot to mention but was a big deal in TRIGTRAN - not OK to send a million "link down"s in the reverse direction with no congestion avoidance, etc.) Were there others? Who is holding the bag on action items? (signed) Curious > On Tue, Jul 11, 2006 at 07:52:02PM -0400, Spencer Dawkins wrote: >> Were stuck into jabber log, at >> http://www.ietf.org/meetings/ietf-logs/tsvwg/2006-07-11.html, at Lar's >> suggestion. >> > > One thing that I took away from yesterday was that it may be productive > to build a pair of tables to describe the problem space; one table > for "significant path changes" that might be passed up to the transport, > and one table for "significant path desires" that the transport can > pass down. In each table, we could have a row for each piece of data > and columns that describe the time-frame of relevence (per packet, > within an RTT, per-connection, etc), any existing "point" solutions, and > whether or not the solutions are deployed now, or still research. > > There are a lot of starting points to feed this, including the IAB > link indications document and some of the mobopts work. > > My thought is that once we have all the diverse things we're talking > about clearly listed, it might be easier to pick out commonalities or > visualize what an architected solution could look like, and also what > the current accidental architecture looks like. > > Does this sound like a reasonable next step to take? > > -- > Wesley M. Eddy > Verizon Federal Network Systems > From ternli-bounces@ietf.org Thu Jul 20 19:53:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3iKo-0008R0-42; Thu, 20 Jul 2006 19:53:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3iKf-0008HU-VC for ternli@ietf.org; Thu, 20 Jul 2006 19:53:29 -0400 Received: from wyvern.icir.org ([192.150.187.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3iFh-0005Ti-Bj for ternli@ietf.org; Thu, 20 Jul 2006 19:48:22 -0400 Received: from guns.icir.org (adsl-69-222-35-58.dsl.bcvloh.ameritech.net [69.222.35.58]) by wyvern.icir.org (8.12.11/8.12.11) with ESMTP id k6KNm2p0078968; Thu, 20 Jul 2006 16:48:02 -0700 (PDT) (envelope-from mallman@icir.org) Received: from lawyers.icir.org (guns.icir.org [69.222.35.58]) by guns.icir.org (Postfix) with ESMTP id F1A6E77B6A2; Thu, 20 Jul 2006 19:47:59 -0400 (EDT) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 7BE1243F926; Thu, 20 Jul 2006 14:12:55 -0400 (EDT) To: weddy@grc.nasa.gov From: Mark Allman Subject: Re: [TERNLI] Notes from tonight's ad hoc In-Reply-To: <20060712133556.GB11317@grc.nasa.gov> Organization: ICSI Center for Internet Research (ICIR) Song-of-the-Day: In the City MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=_bOundary"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Thu, 20 Jul 2006 14:12:55 -0400 Message-Id: <20060720181255.7BE1243F926@lawyers.icir.org> X-Spam-Score: 0.1 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: ternli@ietf.org X-BeenThere: ternli@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: mallman@icir.org List-Id: Transport-Enhancing Refinements to the Network Layer Interface List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ternli-bounces@ietf.org --=_bOundary Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: quoted-printable > One thing that I took away from yesterday was that it may be > productive to build a pair of tables to describe the problem space; > one table for "significant path changes" that might be passed up to > the transport, and one table for "significant path desires" that the > transport can pass down.=20=20 This seems like a reasonable first step to me. I would further winnow the list of things to be passed up as "characteristics that impact performance". I.e., there is no use telling TCP that some random AP switched from channel 6 to channel 11. TCP does not care. Now, if that change results in more corruption or a lower bit rate then the TCP would care about the latter. From=20there then we can organize it and figure out where the lowest hanging fruit really is. My two cents. allman --=_bOundary Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (Darwin) iD8DBQFEv8enWyrrWs4yIs4RAohkAJ9bYD/FXoRHvO/NR7cIK4CddDcAqwCbBFuF RAeEKvQu+eiRBuuHLGZJ+uo= =D81G -----END PGP SIGNATURE----- --=_bOundary-- From ternli-bounces@ietf.org Thu Jul 20 22:20:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3kcc-0003pK-Kg; Thu, 20 Jul 2006 22:20:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3kaz-00020u-Mj for ternli@ietf.org; Thu, 20 Jul 2006 22:18:29 -0400 Received: from mga01.intel.com ([192.55.52.88] helo=fmsmga101-1.fm.intel.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3kS7-00032E-EN for ternli@ietf.org; Thu, 20 Jul 2006 22:09:20 -0400 Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by fmsmga101-1.fm.intel.com with ESMTP; 20 Jul 2006 19:09:18 -0700 Received: from saspfm01.fm.intel.com (HELO kfallmobl) ([10.19.12.5]) by fmsmga001.fm.intel.com with ESMTP; 20 Jul 2006 19:09:16 -0700 X-IronPort-AV: i="4.07,164,1151910000"; d="scan'208"; a="101502059:sNHT14985362" From: "Kevin Fall" To: , Subject: RE: [TERNLI] Notes from tonight's ad hoc Date: Thu, 20 Jul 2006 19:09:14 -0700 Organization: Intel Research Berkeley Message-ID: <012b01c6ac6a$ab4fea90$020a010a@kfallmobl> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AcasW+Axmv901FygSOi6EWKzKf4SfgADe8gw In-Reply-To: <20060720181255.7BE1243F926@lawyers.icir.org> X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: ternli@ietf.org X-BeenThere: ternli@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: kfall@intel.com List-Id: Transport-Enhancing Refinements to the Network Layer Interface List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ternli-bounces@ietf.org Channel change might not be so exciting, but stuff like "I switched AP to a different network" might be interesting.... and of course, data rate change (e.g. 802.11b can support 4 rates). 802.16 has different convergence sublayers it can use, which potentially affects mtu (gag). Then there is the issue of L2 flow control, and the sort of curious stuff linux does when it feels "locally" congested {where it basically acts as though it recv'd a 'congestion experienced' indicator in an ack}. - K > -----Original Message----- > From: Mark Allman [mailto:mallman@icir.org] > Sent: Thursday, July 20, 2006 11:13 AM > To: weddy@grc.nasa.gov > Cc: ternli@ietf.org > Subject: Re: [TERNLI] Notes from tonight's ad hoc > > > > One thing that I took away from yesterday was that it may be > > productive to build a pair of tables to describe the problem space; > > one table for "significant path changes" that might be passed up to > > the transport, and one table for "significant path desires" that the > > transport can pass down. > > This seems like a reasonable first step to me. I would further winnow > the list of things to be passed up as "characteristics that impact > performance". I.e., there is no use telling TCP that some random AP > switched from channel 6 to channel 11. TCP does not care. Now, if that > change results in more corruption or a lower bit rate then the TCP would > care about the latter. > > From there then we can organize it and figure out where the lowest > hanging fruit really is. > > My two cents. > > allman > > From ternli-bounces@ietf.org Fri Jul 21 09:06:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3uho-00015A-IM; Fri, 21 Jul 2006 09:06:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3uhn-000155-BU for ternli@ietf.org; Fri, 21 Jul 2006 09:06:11 -0400 Received: from mx2.grc.nasa.gov ([128.156.11.69]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3uhl-0006AB-27 for ternli@ietf.org; Fri, 21 Jul 2006 09:06:11 -0400 Received: from lombok-fi.grc.nasa.gov (seraph1.grc.nasa.gov [128.156.10.10]) by mx2.grc.nasa.gov (Postfix) with ESMTP id 521FAC2D8 for ; Fri, 21 Jul 2006 09:06:08 -0400 (EDT) Received: from apataki.grc.nasa.gov (apataki.grc.nasa.gov [139.88.112.35]) by lombok-fi.grc.nasa.gov (NASA GRC TCPD 8.13.7/8.13.7) with ESMTP id k6LD65nJ016178; Fri, 21 Jul 2006 09:06:05 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by apataki.grc.nasa.gov (NASA GRC TCPD 8.13.7/8.13.7) with ESMTP id k6LD638S012582; Fri, 21 Jul 2006 09:06:05 -0400 (EDT) Received: from apataki.grc.nasa.gov ([127.0.0.1])by localhost (apataki.grc.nasa.gov [127.0.0.1]) (amavisd-new, port 10024)with ESMTP id 07368-27; Fri, 21 Jul 2006 09:05:59 -0400 (EDT) Received: from drpepper.grc.nasa.gov (gr2134391.grc.nasa.gov [139.88.44.123])by apataki.grc.nasa.gov (NASA GRC TCPD 8.13.7/8.13.7) with ESMTP id k6LD5vpS012548;Fri, 21 Jul 2006 09:05:58 -0400 (EDT) Received: by drpepper.grc.nasa.gov (Postfix, from userid 501)id 70AF94FCE4; Fri, 21 Jul 2006 09:06:19 -0400 (EDT) Date: Fri, 21 Jul 2006 09:06:19 -0400 From: Wesley Eddy To: Kevin Fall Subject: Re: [TERNLI] Notes from tonight's ad hoc Message-ID: <20060721130619.GA12398@grc.nasa.gov> References: <20060720181255.7BE1243F926@lawyers.icir.org> <012b01c6ac6a$ab4fea90$020a010a@kfallmobl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <012b01c6ac6a$ab4fea90$020a010a@kfallmobl> User-Agent: Mutt/1.5.5.1i X-imss-version: 2.041 X-imss-result: Passed X-imss-scores: Clean:63.76579 C:2 M:3 S:5 R:5 X-imss-settings: Baseline:2 C:1 M:1 S:1 R:1 (0.1500 0.1500) X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: ternli@ietf.org X-BeenThere: ternli@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: weddy@grc.nasa.gov List-Id: Transport-Enhancing Refinements to the Network Layer Interface List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ternli-bounces@ietf.org On Thu, Jul 20, 2006 at 07:09:14PM -0700, Kevin Fall wrote: > Channel change might not be so exciting, but stuff like "I switched AP to a > different network" might be interesting.... and of course, data rate change > (e.g. 802.11b can support 4 rates). 802.16 has different convergence > sublayers it can use, which potentially affects mtu (gag). > 802.16 also has adaptive modulation and coding that alter the rate of the channel and may vary as the distance between a base station and subscriber station changes. Adaptive coding is common for satellite links as well. It seems like this type of event could be useful to signal if it resulted in more than a doubling or halving of capacity, as a simple filter. -- Wesley M. Eddy Verizon Federal Network Systems From ternli-bounces@ietf.org Fri Jul 28 07:45:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6QmM-0005QU-Im; Fri, 28 Jul 2006 07:45:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6QmL-0005QO-EZ for ternli@ietf.org; Fri, 28 Jul 2006 07:45:17 -0400 Received: from wyvern.icir.org ([192.150.187.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G6QmJ-0001i0-1a for ternli@ietf.org; Fri, 28 Jul 2006 07:45:17 -0400 Received: from guns.icir.org (adsl-69-222-35-58.dsl.bcvloh.ameritech.net [69.222.35.58]) by wyvern.icir.org (8.12.11/8.12.11) with ESMTP id k6SBj7qS054866; Fri, 28 Jul 2006 04:45:07 -0700 (PDT) (envelope-from mallman@icir.org) Received: from lawyers.icir.org (guns.icir.org [69.222.35.58]) by guns.icir.org (Postfix) with ESMTP id 1012777B3AB; Fri, 28 Jul 2006 07:45:07 -0400 (EDT) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 275FB444296; Fri, 28 Jul 2006 07:43:53 -0400 (EDT) To: weddy@grc.nasa.gov From: Mark Allman Subject: Re: [TERNLI] Notes from tonight's ad hoc In-Reply-To: <20060721130619.GA12398@grc.nasa.gov> Organization: ICSI Center for Internet Research (ICIR) Song-of-the-Day: Down on the Corner MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=_bOundary"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Fri, 28 Jul 2006 07:43:52 -0400 Message-Id: <20060728114353.275FB444296@lawyers.icir.org> X-Spam-Score: 0.1 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: ternli@ietf.org X-BeenThere: ternli@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: mallman@icir.org List-Id: Transport-Enhancing Refinements to the Network Layer Interface List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ternli-bounces@ietf.org --=_bOundary Content-Type: text/plain Content-Disposition: inline > 802.16 also has adaptive modulation and coding that alter the rate of > the channel and may vary as the distance between a base station and > subscriber station changes. Adaptive coding is common for satellite > links as well. It seems like this type of event could be useful to > signal if it resulted in more than a doubling or halving of capacity, as > a simple filter. One way to look at this is that the "type of event" is not at all important to communicate. The real thing to get across is the available capacity has changed somewhat dramatically. Does it really matter if this is because 802.11 dropped us from 11mbps to 2mbps or some BoD system just allocated us a ton of capacity or we moved much closer to some access point / basestation and now have a much better signal? Does this make sense? allman --=_bOundary Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (Darwin) iD8DBQFEyfh4WyrrWs4yIs4RAkRXAKCH40QFru8NmO15+C89JJax0eONawCgkiPE oi46s+luw6ouVPMAPGcPO3M= =Pk5H -----END PGP SIGNATURE----- --=_bOundary-- From ternli-bounces@ietf.org Fri Jul 28 08:06:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6R6c-0007Nk-MO; Fri, 28 Jul 2006 08:06:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6R6c-0007Nf-0k for ternli@ietf.org; Fri, 28 Jul 2006 08:06:14 -0400 Received: from lmr1.uibk.ac.at ([138.232.1.142] helo=smtp.uibk.ac.at) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G6R6a-0004mK-D2 for ternli@ietf.org; Fri, 28 Jul 2006 08:06:13 -0400 Received: from localhost (lwm2.uibk.ac.at [138.232.1.161]) by smtp.uibk.ac.at (8.13.1/8.13.1/F1) with ESMTP id k6SC64kF016421; Fri, 28 Jul 2006 14:06:04 +0200 Received: from 30-6-248.wireless.csail.mit.edu (30-6-248.wireless.csail.mit.edu [128.30.6.248]) by web-mail2.uibk.ac.at (IMP) with HTTP for ; Fri, 28 Jul 2006 14:06:04 +0200 Message-ID: <1154088364.44c9fdac35be3@web-mail2.uibk.ac.at> Date: Fri, 28 Jul 2006 14:06:04 +0200 From: Michael Welzl To: mallman@icir.org Subject: Re: [TERNLI] Notes from tonight's ad hoc References: <20060728114353.275FB444296@lawyers.icir.org> In-Reply-To: <20060728114353.275FB444296@lawyers.icir.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.2.6 X-Originating-IP: 128.30.6.248 X-Forwarded-For: X-Spam-Score: -7.4 () ALL_TRUSTED,RCV_SMTP_UIBK,RCV_WEBMAIL X-Scanned-By: MIMEDefang 2.52 at uibk.ac.at on 138.232.1.140 X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: ternli@ietf.org X-BeenThere: ternli@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport-Enhancing Refinements to the Network Layer Interface List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ternli-bounces@ietf.org > > 802.16 also has adaptive modulation and coding that alter the rate of > > the channel and may vary as the distance between a base station and > > subscriber station changes. Adaptive coding is common for satellite > > links as well. It seems like this type of event could be useful to > > signal if it resulted in more than a doubling or halving of capacity, as > > a simple filter. > > One way to look at this is that the "type of event" is not at all > important to communicate. The real thing to get across is the available > capacity has changed somewhat dramatically. Does it really matter if > this is because 802.11 dropped us from 11mbps to 2mbps or some BoD > system just allocated us a ton of capacity or we moved much closer to > some access point / basestation and now have a much better signal? > > Does this make sense? A lot! I was about to say something similar in case the discussion would have moved further in this direction (signaling irrelevant details about link layer occurrences to the transport layer). I think that any comunication from lower layers up to the transport layer should be converted to a transport-layer-related format (where we're interested in things such as the RTT, capacity (even though this is usually not available at the transport layer - but it's an upper limit, so why not communicate it?), all kinds of traffic related information (e.g. imminent sudden growth), ...). I don't want to turn this into an acedemic exercise - all I'm suggesting is to think in such terms when looking at link layer events that should somehow be communicated to the endpoints. Cheers, Michael From ternli-bounces@ietf.org Fri Jul 28 08:16:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6RGV-0005k5-Nf; Fri, 28 Jul 2006 08:16:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6RGV-0005k0-81 for ternli@ietf.org; Fri, 28 Jul 2006 08:16:27 -0400 Received: from mga03.intel.com ([143.182.124.21] helo=azsmga101-1.ch.intel.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G6RGT-0005XD-U1 for ternli@ietf.org; Fri, 28 Jul 2006 08:16:27 -0400 Received: from azsmga001.ch.intel.com ([10.2.17.19]) by azsmga101-1.ch.intel.com with ESMTP; 28 Jul 2006 05:16:25 -0700 Received: from saspfm01.fm.intel.com (HELO kfallmobl) ([10.19.12.5]) by azsmga001.ch.intel.com with ESMTP; 28 Jul 2006 05:16:21 -0700 X-IronPort-AV: i="4.07,191,1151910000"; d="scan'208"; a="72217575:sNHT14730023" From: "Kevin Fall" To: , Subject: RE: [TERNLI] Notes from tonight's ad hoc Date: Fri, 28 Jul 2006 05:16:18 -0700 Organization: Intel Research Berkeley Message-ID: <002301c6b23f$a3ef4a90$0300a8c0@kfallmobl> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AcayO4a9ROcRDoA7Rz+LFWNT5bTluAAA77dw In-Reply-To: <20060728114353.275FB444296@lawyers.icir.org> X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: ternli@ietf.org X-BeenThere: ternli@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: kfall@intel.com List-Id: Transport-Enhancing Refinements to the Network Layer Interface List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ternli-bounces@ietf.org I'm not sure how clear-cut it is. E.g.. a path change might imply a likelihood of a significant capacity and latency change. A capacity change due only to modulation change would likely affect the latency less drammatically, I would think. On the "other other" hand, the system could generate two indicators on a path change :P. - K > -----Original Message----- > From: mallman@icir.org [mailto:mallman@icir.org] > Sent: Friday, July 28, 2006 4:44 AM > To: weddy@grc.nasa.gov > Cc: Kevin Fall; ternli@ietf.org > Subject: Re: [TERNLI] Notes from tonight's ad hoc > > > > 802.16 also has adaptive modulation and coding that alter the rate of > > the channel and may vary as the distance between a base station and > > subscriber station changes. Adaptive coding is common for satellite > > links as well. It seems like this type of event could be useful to > > signal if it resulted in more than a doubling or halving of capacity, as > > a simple filter. > > One way to look at this is that the "type of event" is not at all > important to communicate. The real thing to get across is the available > capacity has changed somewhat dramatically. Does it really matter if > this is because 802.11 dropped us from 11mbps to 2mbps or some BoD > system just allocated us a ton of capacity or we moved much closer to > some access point / basestation and now have a much better signal? > > Does this make sense? > > allman > > From ternli-bounces@ietf.org Fri Jul 28 08:19:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6RJn-0005so-Fe; Fri, 28 Jul 2006 08:19:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6RJl-0005si-Qz for ternli@ietf.org; Fri, 28 Jul 2006 08:19:49 -0400 Received: from lmr1.uibk.ac.at ([138.232.1.142] helo=smtp.uibk.ac.at) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G6RJk-0006AL-Bv for ternli@ietf.org; Fri, 28 Jul 2006 08:19:49 -0400 Received: from localhost (lwm2.uibk.ac.at [138.232.1.161]) by smtp.uibk.ac.at (8.13.1/8.13.1/F1) with ESMTP id k6SCJhKe017603; Fri, 28 Jul 2006 14:19:43 +0200 Received: from 30-6-248.wireless.csail.mit.edu (30-6-248.wireless.csail.mit.edu [128.30.6.248]) by web-mail2.uibk.ac.at (IMP) with HTTP for ; Fri, 28 Jul 2006 14:19:43 +0200 Message-ID: <1154089183.44ca00df115c3@web-mail2.uibk.ac.at> Date: Fri, 28 Jul 2006 14:19:43 +0200 From: Michael Welzl To: kfall@intel.com Subject: RE: [TERNLI] Notes from tonight's ad hoc References: <002301c6b23f$a3ef4a90$0300a8c0@kfallmobl> In-Reply-To: <002301c6b23f$a3ef4a90$0300a8c0@kfallmobl> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.2.6 X-Originating-IP: 128.30.6.248 X-Forwarded-For: X-Spam-Score: -7.4 () ALL_TRUSTED,RCV_SMTP_UIBK,RCV_WEBMAIL X-Scanned-By: MIMEDefang 2.52 at uibk.ac.at on 138.232.1.140 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: ternli@ietf.org X-BeenThere: ternli@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport-Enhancing Refinements to the Network Layer Interface List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ternli-bounces@ietf.org Zitat von Kevin Fall : > I'm not sure how clear-cut it is. E.g.. a path change might imply a > likelihood of a significant capacity and latency change. A capacity change > due only to modulation change would likely affect the latency less > drammatically, I would think. On the "other other" hand, the system could > generate two indicators on a path change :P. yep: two indicators. cheers, michael From ternli-bounces@ietf.org Fri Jul 28 08:57:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6RuH-0006um-9P; Fri, 28 Jul 2006 08:57:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6RuG-0006uh-B3 for ternli@ietf.org; Fri, 28 Jul 2006 08:57:32 -0400 Received: from wyvern.icir.org ([192.150.187.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G6RuE-0005ij-UP for ternli@ietf.org; Fri, 28 Jul 2006 08:57:32 -0400 Received: from guns.icir.org (adsl-69-222-35-58.dsl.bcvloh.ameritech.net [69.222.35.58]) by wyvern.icir.org (8.12.11/8.12.11) with ESMTP id k6SCvNsY056853; Fri, 28 Jul 2006 05:57:24 -0700 (PDT) (envelope-from mallman@icir.org) Received: from lawyers.icir.org (guns.icir.org [69.222.35.58]) by guns.icir.org (Postfix) with ESMTP id E24D277B6F4; Fri, 28 Jul 2006 08:57:22 -0400 (EDT) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 670AF444391; Fri, 28 Jul 2006 08:56:08 -0400 (EDT) To: kfall@intel.com From: Mark Allman Subject: Re: [TERNLI] Notes from tonight's ad hoc In-Reply-To: <002301c6b23f$a3ef4a90$0300a8c0@kfallmobl> Organization: ICSI Center for Internet Research (ICIR) Song-of-the-Day: Down on the Corner MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=_bOundary"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Fri, 28 Jul 2006 08:56:08 -0400 Message-Id: <20060728125608.670AF444391@lawyers.icir.org> X-Spam-Score: 0.1 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: ternli@ietf.org X-BeenThere: ternli@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: mallman@icir.org List-Id: Transport-Enhancing Refinements to the Network Layer Interface List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ternli-bounces@ietf.org --=_bOundary Content-Type: text/plain Content-Disposition: inline > I'm not sure how clear-cut it is. E.g.. a path change might imply a > likelihood of a significant capacity and latency change. A capacity > change due only to modulation change would likely affect the latency > less drammatically, I would think. On the "other other" hand, the > system could generate two indicators on a path change :P. Right... but, the transport isn't going to be able to figure all this out any more than the link-layer. I guess I see the signals as either ... + Giving the transport something it can directly use. E.g., the available bandwidth just increased from 2Mbps to 11Mbps. E.g., the flow experienced congestion. E.g., some probability of the fraction of losses due to corruption. These are different from less-directly-useful information like "switched to a new AP" or "am now using a different coding / modulation scheme" which are much less directly applicable. + Giving a generic signal that *something* has changed and it likely matters and so the transport should re-init itself (e.g., forget the SRTT, RTTVAR, cwnd, ssthresh, MTU value, etc.). allman --=_bOundary Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (Darwin) iD8DBQFEygloWyrrWs4yIs4RAg+RAJ4lawMqKhiur/3WywBQLz7FDL13XwCfXpUU kEGMxzfVw5JNaYjEO/qdtbg= =1Fdo -----END PGP SIGNATURE----- --=_bOundary-- From ternli-bounces@ietf.org Fri Jul 28 14:48:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6XOF-0003lH-Un; Fri, 28 Jul 2006 14:48:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6XOE-0003lC-0f for ternli@ietf.org; Fri, 28 Jul 2006 14:48:50 -0400 Received: from mx2.grc.nasa.gov ([128.156.11.69]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G6XOC-00083b-Kb for ternli@ietf.org; Fri, 28 Jul 2006 14:48:49 -0400 Received: from lombok-fi.grc.nasa.gov (seraph4.grc.nasa.gov [128.156.10.13]) by mx2.grc.nasa.gov (Postfix) with ESMTP id 84E7BCC32 for ; Fri, 28 Jul 2006 14:48:47 -0400 (EDT) Received: from apataki.grc.nasa.gov (apataki.grc.nasa.gov [139.88.112.35]) by lombok-fi.grc.nasa.gov (NASA GRC TCPD 8.13.7/8.13.7) with ESMTP id k6SImkUt017545; Fri, 28 Jul 2006 14:48:46 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by apataki.grc.nasa.gov (NASA GRC TCPD 8.13.7/8.13.7) with ESMTP id k6SImkcb010619; Fri, 28 Jul 2006 14:48:46 -0400 (EDT) Received: from apataki.grc.nasa.gov ([127.0.0.1]) by localhost (apataki.grc.nasa.gov [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08377-13; Fri, 28 Jul 2006 14:48:45 -0400 (EDT) Received: from drpepper.grc.nasa.gov (gr2134391.grc.nasa.gov [139.88.44.123]) by apataki.grc.nasa.gov (NASA GRC TCPD 8.13.7/8.13.7) with ESMTP id k6SImfFg010569; Fri, 28 Jul 2006 14:48:41 -0400 (EDT) Received: by drpepper.grc.nasa.gov (Postfix, from userid 501) id E794A4FCE5; Fri, 28 Jul 2006 14:50:07 -0400 (EDT) Date: Fri, 28 Jul 2006 14:50:07 -0400 From: Wesley Eddy To: Mark Allman Subject: Re: [TERNLI] Notes from tonight's ad hoc Message-ID: <20060728185007.GG7604@grc.nasa.gov> References: <002301c6b23f$a3ef4a90$0300a8c0@kfallmobl> <20060728125608.670AF444391@lawyers.icir.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="PuGuTyElPB9bOcsM" Content-Disposition: inline In-Reply-To: <20060728125608.670AF444391@lawyers.icir.org> User-Agent: Mutt/1.5.5.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Cc: ternli@ietf.org X-BeenThere: ternli@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: weddy@grc.nasa.gov List-Id: Transport-Enhancing Refinements to the Network Layer Interface List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ternli-bounces@ietf.org --PuGuTyElPB9bOcsM Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jul 28, 2006 at 08:56:08AM -0400, Mark Allman wrote: >=20 > I guess I see the signals as either ... >=20 > + Giving the transport something it can directly use. E.g., the > available bandwidth just increased from 2Mbps to 11Mbps. E.g., > the flow experienced congestion. E.g., some probability of the > fraction of losses due to corruption. >=20 > These are different from less-directly-useful information like > "switched to a new AP" or "am now using a different coding / > modulation scheme" which are much less directly applicable.=20 >=20 > + Giving a generic signal that *something* has changed and it likely > matters and so the transport should re-init itself (e.g., forget the > SRTT, RTTVAR, cwnd, ssthresh, MTU value, etc.). Is it possible to generalize this to say that signals should either carry specific actionable information or request specific types of actions? This means: "Modulation changed" is a bad signal to implement. "Available capacity changed from X to Y, please probe" is a good signal to implement, and could be generated in response to a change in modulation or any number of other things. "Registering a new Mobile IP CoA" is a bad signal to implement. "Please reprobe path state" is a good signal to implement, and could be generated in response to a MIP CoA update or several other events from mobility or multihoming mechanisms. I guess this might simplify our task into categorizing the actions that each layer might implement, and defining a signal for each class of actions (with optional additional data to accompany the signal such as X and Y in a capacity change signal -- you could define specific combinations of X and Y to mean "up", "down", and "I don't know", when specific values aren't available). --=20 Wesley M. Eddy Verizon Federal Network Systems --PuGuTyElPB9bOcsM Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) iD8DBQFEylxfzBuYqbnj3IwRAhE+AJ4yYY3+ILda78YT4ccj5TVserx8WgCeI3de F+SKkm3IkSbzOgtWZnHLmug= =IHWT -----END PGP SIGNATURE----- --PuGuTyElPB9bOcsM-- From ternli-bounces@ietf.org Fri Jul 28 17:01:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6ZSi-0003Ve-IO; Fri, 28 Jul 2006 17:01:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6ZSh-0003VY-9u for ternli@ietf.org; Fri, 28 Jul 2006 17:01:35 -0400 Received: from lmr1.uibk.ac.at ([138.232.1.142] helo=smtp.uibk.ac.at) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G6ZSe-0001ZF-Q9 for ternli@ietf.org; Fri, 28 Jul 2006 17:01:35 -0400 Received: from localhost (lwm2.uibk.ac.at [138.232.1.161]) by smtp.uibk.ac.at (8.13.1/8.13.1/F1) with ESMTP id k6SL1Mw2016644; Fri, 28 Jul 2006 23:01:23 +0200 Received: from ip-eis-205.EISInc.com (ip-eis-205.EISInc.com [207.190.204.205]) by web-mail2.uibk.ac.at (IMP) with HTTP for ; Fri, 28 Jul 2006 23:01:22 +0200 Message-ID: <1154120482.44ca7b22ee3bf@web-mail2.uibk.ac.at> Date: Fri, 28 Jul 2006 23:01:22 +0200 From: Michael Welzl To: weddy@grc.nasa.gov Subject: Re: [TERNLI] Notes from tonight's ad hoc References: <002301c6b23f$a3ef4a90$0300a8c0@kfallmobl> <20060728125608.670AF444391@lawyers.icir.org> <20060728185007.GG7604@grc.nasa.gov> In-Reply-To: <20060728185007.GG7604@grc.nasa.gov> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.2.6 X-Originating-IP: 207.190.204.205 X-Forwarded-For: X-Spam-Score: -7.4 () ALL_TRUSTED,RCV_SMTP_UIBK,RCV_WEBMAIL X-Scanned-By: MIMEDefang 2.52 at uibk.ac.at on 138.232.1.140 X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: ternli@ietf.org X-BeenThere: ternli@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport-Enhancing Refinements to the Network Layer Interface List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ternli-bounces@ietf.org > On Fri, Jul 28, 2006 at 08:56:08AM -0400, Mark Allman wrote: > > > > I guess I see the signals as either ... > > > > + Giving the transport something it can directly use. E.g., the > > available bandwidth just increased from 2Mbps to 11Mbps. E.g., > > the flow experienced congestion. E.g., some probability of the > > fraction of losses due to corruption. > > > > These are different from less-directly-useful information like > > "switched to a new AP" or "am now using a different coding / > > modulation scheme" which are much less directly applicable. > > > > + Giving a generic signal that *something* has changed and it likely > > matters and so the transport should re-init itself (e.g., forget the > > SRTT, RTTVAR, cwnd, ssthresh, MTU value, etc.). > > Is it possible to generalize this to say that signals should either > carry specific actionable information or request specific types of > actions? > > This means: > "Modulation changed" is a bad signal to implement. > > "Available capacity changed from X to Y, please probe" is a good signal > to implement, and could be generated in response to a change in > modulation or any number of other things. > > "Registering a new Mobile IP CoA" is a bad signal to implement. > > "Please reprobe path state" is a good signal to implement, and could be > generated in response to a MIP CoA update or several other events from > mobility or multihoming mechanisms. I think this is still going in the right direction, but I would omit the action semantics (like "please reprobe") - one reason is that we shouldn't restrict future protocol designers to (thinking of) just this type of action because the message says so. Another reason is implicitly embedded in one of the examples you've given: "Available capacity changed from X to Y, please probe". A congestion control mechanism always probes - telling it to probe therefore doesn't make a lot of sense. Right now, TCP doesn't have/utilize capacity information - but other congestion control mechanisms have shown that this type of information can be useful. In any case, if we'd decide to include capacity notifications, we wouldn't have a good idea regarding the specific action to recommend. Thus, it's better to leave it open. The reason why I said that this is going in the right direction is that the information should indeed lead to some kind of action at the transport layer, so thinking of possible actions is probably the right way to come up with a useful data set for the messages. And you're absolutely right about the bad examples ("modulation changed" etc). Cheers, Michael From ternli-bounces@ietf.org Fri Jul 28 20:01:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6cGs-0002UI-OY; Fri, 28 Jul 2006 20:01:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6cGr-0002UD-Au for ternli@ietf.org; Fri, 28 Jul 2006 20:01:33 -0400 Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G6cGp-0006FZ-Uj for ternli@ietf.org; Fri, 28 Jul 2006 20:01:33 -0400 Received: from [128.9.168.63] (bet.isi.edu [128.9.168.63]) by vapor.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k6SNxFY12507; Fri, 28 Jul 2006 16:59:15 -0700 (PDT) Message-ID: <44CAA4CE.9050306@isi.edu> Date: Fri, 28 Jul 2006 16:59:10 -0700 From: Joe Touch User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Michael Welzl Subject: Re: [TERNLI] Notes from tonight's ad hoc References: <002301c6b23f$a3ef4a90$0300a8c0@kfallmobl> <20060728125608.670AF444391@lawyers.icir.org> <20060728185007.GG7604@grc.nasa.gov> <1154120482.44ca7b22ee3bf@web-mail2.uibk.ac.at> In-Reply-To: <1154120482.44ca7b22ee3bf@web-mail2.uibk.ac.at> X-Enigmail-Version: 0.94.0.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig8DE91FCD48F485480955B9E9" X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 Cc: ternli@ietf.org X-BeenThere: ternli@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport-Enhancing Refinements to the Network Layer Interface List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ternli-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig8DE91FCD48F485480955B9E9 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Michael Welzl wrote: >> On Fri, Jul 28, 2006 at 08:56:08AM -0400, Mark Allman wrote: >>> I guess I see the signals as either ... >>> >>> + Giving the transport something it can directly use. E.g., the >>> available bandwidth just increased from 2Mbps to 11Mbps. E.g., >>> the flow experienced congestion. E.g., some probability of the >>> fraction of losses due to corruption. Is the network giving this to the transport, or the link? The former seems OK, but the latter not (direct link-transport was - I thought - the thing that this effort would try to avoid). >>> These are different from less-directly-useful information like >>> "switched to a new AP" or "am now using a different coding / >>> modulation scheme" which are much less directly applicable. >>> >>> + Giving a generic signal that *something* has changed and it likel= y >>> matters and so the transport should re-init itself (e.g., forget = the >>> SRTT, RTTVAR, cwnd, ssthresh, MTU value, etc.). >> Is it possible to generalize this to say that signals should either >> carry specific actionable information or request specific types of >> actions? >> >> This means: >> "Modulation changed" is a bad signal to implement. It's useful to the network layer, but irrelevant to the transport. Modulation is a link property, not a path one. >> "Available capacity changed from X to Y, please probe" is a good signa= l >> to implement, and could be generated in response to a change in >> modulation or any number of other things. >> >> "Registering a new Mobile IP CoA" is a bad signal to implement. >> >> "Please reprobe path state" is a good signal to implement, and could b= e >> generated in response to a MIP CoA update or several other events from= >> mobility or multihoming mechanisms. Requesting a reprobe is telling the network layer what to do, and implies that the link knows what the network wants. It seems more useful to say "link state changed" and let the network decide whether it cares about that on a path level. =2E.. > The reason why I said that this is going in the right > direction is that the information should indeed lead to > some kind of action at the transport layer,=20 or the network layer (or is that out of scope - sorry, I wasn't a the meeting, so I don't have that 'state'). > so thinking > of possible actions is probably the right way to come > up with a useful data set for the messages. Agreed, but 'just the facts' is the right way to report those messages. I agree that it's useful to avoid making actionable recommendations, but definitely useful to consider them as motivation. IMO, the most interesting question is "why are you saying this", and "is this the right information to pass between these two layers". The network can't care that the modulation changed (that's a link/physical issue), but it can care about what that means (latency changed, error rate changed, etc.). Joe Joe --------------enig8DE91FCD48F485480955B9E9 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEyqTOE5f5cImnZrsRAqj3AKDbm72nPts0PFw3k+6Zegdjm3rP/ACgtVB1 3Vp9ha93LjPDovsnDvFxYlY= =KC7n -----END PGP SIGNATURE----- --------------enig8DE91FCD48F485480955B9E9-- From ternli-bounces@ietf.org Fri Jul 28 21:15:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6dQm-00070v-5e; Fri, 28 Jul 2006 21:15:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6dQl-00070q-Db for ternli@ietf.org; Fri, 28 Jul 2006 21:15:51 -0400 Received: from wyvern.icir.org ([192.150.187.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G6dQj-00054c-Qy for ternli@ietf.org; Fri, 28 Jul 2006 21:15:51 -0400 Received: from guns.icir.org (adsl-69-222-35-58.dsl.bcvloh.ameritech.net [69.222.35.58]) by wyvern.icir.org (8.12.11/8.12.11) with ESMTP id k6T1FkQI077686; Fri, 28 Jul 2006 18:15:46 -0700 (PDT) (envelope-from mallman@icir.org) Received: from lawyers.icir.org (guns.icir.org [69.222.35.58]) by guns.icir.org (Postfix) with ESMTP id CC87877B3AB; Fri, 28 Jul 2006 21:15:43 -0400 (EDT) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 55D6C4448FF; Fri, 28 Jul 2006 21:14:30 -0400 (EDT) To: Joe Touch From: Mark Allman Subject: Re: [TERNLI] Notes from tonight's ad hoc In-Reply-To: <44CAA4CE.9050306@isi.edu> Organization: ICSI Center for Internet Research (ICIR) Song-of-the-Day: Glory Days MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=_bOundary"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Fri, 28 Jul 2006 21:14:30 -0400 Message-Id: <20060729011430.55D6C4448FF@lawyers.icir.org> X-Spam-Score: 0.1 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: ternli@ietf.org, Michael Welzl X-BeenThere: ternli@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: mallman@icir.org List-Id: Transport-Enhancing Refinements to the Network Layer Interface List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ternli-bounces@ietf.org --=_bOundary Content-Type: text/plain Content-Disposition: inline I am not quite sure if I agree with (or understand) everything you said, Joe. But, ... > IMO, the most interesting question is "why are you saying this", and > "is this the right information to pass between these two layers". The > network can't care that the modulation changed (that's a link/physical > issue), but it can care about what that means (latency changed, error > rate changed, etc.). this is basically what I was trying to get at, but put much better. I see it as somewhat of a balancing act. We don't want to give information that another layer just cannot do anything with, but we also don't want to get too narrow or prescriptive either. allman --=_bOundary Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (Darwin) iD8DBQFEyrZ1WyrrWs4yIs4RAstJAJ45W32PDkmY2B/X5mDCZidGg3q5JACfeQDU l0+7hk1OUUOT7D6hFf8hqqc= =yWMZ -----END PGP SIGNATURE----- --=_bOundary-- From ternli-bounces@ietf.org Fri Jul 28 21:24:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6dZ1-00084J-MT; Fri, 28 Jul 2006 21:24:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6dZ0-00084B-AZ for ternli@ietf.org; Fri, 28 Jul 2006 21:24:22 -0400 Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G6dYy-0005Qd-Vk for ternli@ietf.org; Fri, 28 Jul 2006 21:24:22 -0400 Received: from [192.168.1.42] (pool-71-106-102-77.lsanca.dsl-w.verizon.net [71.106.102.77]) by vapor.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k6T1N8Y29332; Fri, 28 Jul 2006 18:23:08 -0700 (PDT) Message-ID: <44CAB876.8000405@isi.edu> Date: Fri, 28 Jul 2006 18:23:02 -0700 From: Joe Touch User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: mallman@icir.org Subject: Re: [TERNLI] Notes from tonight's ad hoc References: <20060729011430.55D6C4448FF@lawyers.icir.org> In-Reply-To: <20060729011430.55D6C4448FF@lawyers.icir.org> X-Enigmail-Version: 0.94.0.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigCB81CC137C7A015550693110" X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: ternli@ietf.org, Michael Welzl X-BeenThere: ternli@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport-Enhancing Refinements to the Network Layer Interface List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ternli-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigCB81CC137C7A015550693110 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Mark Allman wrote: > I am not quite sure if I agree with (or understand) everything you > said, Joe. But, ... >=20 >> IMO, the most interesting question is "why are you saying this", and >> "is this the right information to pass between these two layers". The >> network can't care that the modulation changed (that's a link/physical= >> issue), but it can care about what that means (latency changed, error >> rate changed, etc.). >=20 > this is basically what I was trying to get at, but put much better. >=20 > I see it as somewhat of a balancing act. We don't want to give > information that another layer just cannot do anything with, but we als= o > don't want to get too narrow or prescriptive either. Right. I like the idea of "only give info that you think the next layer can use", but not "tell the next layer what you want it to do". Also, the information passed ought to be something that makes sense in the context of the next layer, e.g., tell the network layer about a path property, not about a link technology, etc. Joe --------------enigCB81CC137C7A015550693110 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEyrh2E5f5cImnZrsRAtRzAKDRszd5OWXnQWABy/xT4lxNa//gFwCdH87B k4twSroekmLJf5hsL/C0o7g= =W2rp -----END PGP SIGNATURE----- --------------enigCB81CC137C7A015550693110-- From ternli-bounces@ietf.org Sat Jul 29 05:14:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6ktc-0004hy-OR; Sat, 29 Jul 2006 05:14:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6kta-0004ht-S4 for ternli@ietf.org; Sat, 29 Jul 2006 05:14:06 -0400 Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G6ktZ-0001uv-BA for ternli@ietf.org; Sat, 29 Jul 2006 05:14:06 -0400 Received: from lars.local (p54AD2EA7.dip0.t-ipconnect.de [84.173.46.167]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 32E321BAC4D; Sat, 29 Jul 2006 10:57:44 +0200 (CEST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by lars.local (Postfix) with ESMTP id 7D2BD15F4FB; Sat, 29 Jul 2006 11:14:03 +0200 (CEST) In-Reply-To: <44CAB876.8000405@isi.edu> References: <20060729011430.55D6C4448FF@lawyers.icir.org> <44CAB876.8000405@isi.edu> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-38--236417908; protocol="application/pkcs7-signature" Jabber-Id: lars.eggert@jabber.netlab.nec.de Message-Id: <3947AF0D-C12A-4052-B790-EE4F74A017D5@netlab.nec.de> From: Lars Eggert Subject: Re: [TERNLI] Notes from tonight's ad hoc Date: Sat, 29 Jul 2006 11:14:00 +0200 To: Joe Touch X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.1 (/) X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2 Cc: ternli@ietf.org, Michael Welzl X-BeenThere: ternli@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport-Enhancing Refinements to the Network Layer Interface List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ternli-bounces@ietf.org --Apple-Mail-38--236417908 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Hi, On Jul 29, 2006, at 3:23, Joe Touch wrote: > Right. I like the idea of "only give info that you think the next > layer > can use", but not "tell the next layer what you want it to do". Also, > the information passed ought to be something that makes sense in the > context of the next layer, e.g., tell the network layer about a path > property, not about a link technology, etc. this is probably one of the most precise - and concise - descriptions of the idea we've been kicking around I've see so far. Also, we've so far mostly thought about the network/transport interface and what additional information could be passed across it that would allow some new response mechanisms at the transport layer to improve performance. However, the principle of extending interfaces in this way - as you've summarized above - can also be applied to the link/network and transport/application interface. The link/network part is to some degree looked at by mobopts (although maybe not following the approach identified above). I'm unaware of extensions to the transport/app interface. Finally, this discussion has mostly talked about moving information of a certain kind up the stack in a certain way. Someone (Mark Handley?) had pointed out that the reverse direction may also be important to look at. Your text above can be read to apply to both directions, which is nice. Lars -- Lars Eggert NEC Network Laboratories --Apple-Mail-38--236417908 Content-Transfer-Encoding: base64 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKgzCCAyAw ggKJoAMCAQICAw9TWTANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDUwODE4MTAyOTU2WhcNMDYwODE4MTAyOTU2WjBgMQ8wDQYDVQQE EwZFZ2dlcnQxDTALBgNVBCoTBExhcnMxFDASBgNVBAMTC0xhcnMgRWdnZXJ0MSgwJgYJKoZIhvcN AQkBFhlsYXJzLmVnZ2VydEBuZXRsYWIubmVjLmRlMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB CgKCAQEA2gsuG8tAmM6U2ESsQjhcijJSq6oDG2c+KvvXJ/xcJXbSIOY8IInezIP0DP41H0gxwHNv AyOuwM6nh0r2wOhzdr77GlKXiij0LoFOpurScPKsC9KTykGAfZtAuCnWIRdDo67Urcw1e306yYgK xF1UzYwGamLalPjejQTRcjLPIbzM4c7fUN/sxmpkpzT2p6OCJDyPhBfSaZWtv3UEoKF+xssNYzOF DRCTHcLc3iXgF7z7J0ud8maUAadfb/25Gm7tJHzBOEonMPkHx2N8Ci0qNce0MMH/LVOVQlNO5kYJ vUJiT0du7LAo/hf8tq3luZrh/Cwc/313x6oKYVuHDBllrQIDAQABo2IwYDAqBgUrZQEEAQQhMB8C AQAwGjAYAgEEBBNMMnVNeWZmQk5VYk5KSmNkWjJzMCQGA1UdEQQdMBuBGWxhcnMuZWdnZXJ0QG5l dGxhYi5uZWMuZGUwDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQQFAAOBgQAovojiq8758E/78nMS vNvD4359F8XAICzWbhz6cXJaGzv1FJoQcV/RY1x6CQZDt9PqiPiqyQX+xLvqicmEURbGU5+aiWj2 usovQXd+Ts8Doj3tbjk35nD7Etc8a2+Y9fQRUS6spzgJr0fcq2FMYbDnOtf71Bn77KgckoUbIszu mTCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQI EwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1 bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMT G1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJl ZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNV BAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNU aGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAw gYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNa LIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUq VIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1Ud HwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWls Q0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVs Mi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYf qi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa 9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8wggQYMIIDgaADAgECAgEAMA0G CSqGSIb3DQEBBQUAMIG/MQswCQYDVQQGEwJERTEcMBoGA1UECBQTQmFkZW4tV8N1ZXJ0dGVtYmVy ZzETMBEGA1UEBxMKSGVpZGVsYmVyZzEXMBUGA1UEChMOTkVDIEV1cm9wZSBMdGQxHTAbBgNVBAsT FE5ldHdvcmsgTGFib3JhdG9yaWVzMRswGQYDVQQDExJrb2JlLm5ldGxhYi5uZWMuZGUxKDAmBgkq hkiG9w0BCQEWGWxhcnMuZWdnZXJ0QG5ldGxhYi5uZWMuZGUwHhcNMDQwNjE4MTE1MzA4WhcNMDkw NjE3MTE1MzA4WjCBvzELMAkGA1UEBhMCREUxHDAaBgNVBAgUE0JhZGVuLVfDdWVydHRlbWJlcmcx EzARBgNVBAcTCkhlaWRlbGJlcmcxFzAVBgNVBAoTDk5FQyBFdXJvcGUgTHRkMR0wGwYDVQQLExRO ZXR3b3JrIExhYm9yYXRvcmllczEbMBkGA1UEAxMSa29iZS5uZXRsYWIubmVjLmRlMSgwJgYJKoZI hvcNAQkBFhlsYXJzLmVnZ2VydEBuZXRsYWIubmVjLmRlMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCB iQKBgQC0OQwsE86Rrt0Zs0GOCsYmkGpPwcCFvVpOijIPv1dGolr5a8+7hXSAgRlUyoclq9xfhsUT wlU1qkvVRD3/QOfQyPUxQktxba2ksfsPAKUHovInWydC6rvLU89jtYGEdnRCyA+cEB/XcSADbd2z 9/XK4A2cxmMQiYpXIphYQAxIBwIDAQABo4IBIDCCARwwHQYDVR0OBBYEFOh7L9eqGHnAhbJdO4PY LYzxCaNNMIHsBgNVHSMEgeQwgeGAFOh7L9eqGHnAhbJdO4PYLYzxCaNNoYHFpIHCMIG/MQswCQYD VQQGEwJERTEcMBoGA1UECBQTQmFkZW4tV8N1ZXJ0dGVtYmVyZzETMBEGA1UEBxMKSGVpZGVsYmVy ZzEXMBUGA1UEChMOTkVDIEV1cm9wZSBMdGQxHTAbBgNVBAsTFE5ldHdvcmsgTGFib3JhdG9yaWVz MRswGQYDVQQDExJrb2JlLm5ldGxhYi5uZWMuZGUxKDAmBgkqhkiG9w0BCQEWGWxhcnMuZWdnZXJ0 QG5ldGxhYi5uZWMuZGWCAQAwDAYDVR0TBAUwAwEB/zANBgkqhkiG9w0BAQUFAAOBgQCX6Ipd3AF9 3FDzBaw3ZVvQzzCv/kGPBBzzrJ3n5u+4eQppmOifhuWHZfb8h8S++jqcoPHGVjjlP5PaFb+wL0NR piBalRclikD3xIY/hFoxJ1AHCO0AzfFxEflO10b4+smMrBYJtk5d9EAhr5hEgoGCM7QijBtnCwZB KLI9pFgW1zGCA6UwggOhAgEBMGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25z dWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1 aW5nIENBAgMPU1kwCQYFKw4DAhoFAKCCAhEwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkq hkiG9w0BCQUxDxcNMDYwNzI5MDkxNDAxWjAjBgkqhkiG9w0BCQQxFgQUOAe5a2fOgzKw4zyizM1S P1yieQIwgdYGCSsGAQQBgjcQBDGByDCBxTCBvzELMAkGA1UEBhMCREUxHDAaBgNVBAgUE0JhZGVu LVfDdWVydHRlbWJlcmcxEzARBgNVBAcTCkhlaWRlbGJlcmcxFzAVBgNVBAoTDk5FQyBFdXJvcGUg THRkMR0wGwYDVQQLExROZXR3b3JrIExhYm9yYXRvcmllczEbMBkGA1UEAxMSa29iZS5uZXRsYWIu bmVjLmRlMSgwJgYJKoZIhvcNAQkBFhlsYXJzLmVnZ2VydEBuZXRsYWIubmVjLmRlAgEAMIHYBgsq hkiG9w0BCRACCzGByKCBxTCBvzELMAkGA1UEBhMCREUxHDAaBgNVBAgUE0JhZGVuLVfDdWVydHRl bWJlcmcxEzARBgNVBAcTCkhlaWRlbGJlcmcxFzAVBgNVBAoTDk5FQyBFdXJvcGUgTHRkMR0wGwYD VQQLExROZXR3b3JrIExhYm9yYXRvcmllczEbMBkGA1UEAxMSa29iZS5uZXRsYWIubmVjLmRlMSgw JgYJKoZIhvcNAQkBFhlsYXJzLmVnZ2VydEBuZXRsYWIubmVjLmRlAgEAMA0GCSqGSIb3DQEBAQUA BIIBAHBaXWDpQ85ui7r7hs74LdedHjPdJGFLgGeTRjyOq7XNitF61SoXOZz7Iv5r1WvFOPi7/dh4 1jU4q/9PLKE7pHXPD45qYk2/C0XabJ8XSOBuzuQJyrUR8n2c1Hbeof7Tf2skNtkmV/QdFnPc6VYp qFl7eMrUq8MJSFJ7SKX7mGZ9T7hYGQB93WdWiINsWfudw+Va6DvQRPWIxOqqTs7bd1dYkhBDJnpt W1bUufSD1O3OW4XNLT9EEiaDX/D8PZ37G4CZBe4n1P2a5hRub31HkZl4VpoTpKTIAZvOduCsAJ20 BJF8PUDiu7+kdpo7DehzJ7BUzmh6mgkW6buy0nnBGosAAAAAAAA= --Apple-Mail-38--236417908-- From ternli-bounces@ietf.org Mon Jul 31 14:31:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7cYX-0005dx-VP; Mon, 31 Jul 2006 14:31:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7cYW-0005de-KP for ternli@ietf.org; Mon, 31 Jul 2006 14:31:56 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G7ZOF-0003WJ-Fz for ternli@ietf.org; Mon, 31 Jul 2006 11:09:07 -0400 Received: from dee.erg.abdn.ac.uk ([139.133.204.82] helo=erg.abdn.ac.uk) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1G7ZB4-0001dF-SS for ternli@ietf.org; Mon, 31 Jul 2006 10:55:32 -0400 Received: from [139.133.207.154] (dhcp-207-154.erg.abdn.ac.uk [139.133.207.154]) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id k6VEtKwK020466; Mon, 31 Jul 2006 15:55:20 +0100 (BST) Message-ID: <44CE19D8.9080501@erg.abdn.ac.uk> Date: Mon, 31 Jul 2006 15:55:20 +0100 From: Gorry Fairhurst Organization: University of Aberdeen, UK User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Lars Eggert Subject: Re: [TERNLI] Notes from tonight's ad hoc References: <20060729011430.55D6C4448FF@lawyers.icir.org> <44CAB876.8000405@isi.edu> <3947AF0D-C12A-4052-B790-EE4F74A017D5@netlab.nec.de> In-Reply-To: <3947AF0D-C12A-4052-B790-EE4F74A017D5@netlab.nec.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-ERG-MailScanner: Found to be clean X-ERG-MailScanner-From: gorry@erg.abdn.ac.uk X-Spam-Status: No X-Spam-Score: -2.5 (--) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Cc: ternli@ietf.org, Michael Welzl , Joe Touch X-BeenThere: ternli@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: gorry@erg.abdn.ac.uk List-Id: Transport-Enhancing Refinements to the Network Layer Interface List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ternli-bounces@ietf.org Lars Eggert wrote: > Hi, > > On Jul 29, 2006, at 3:23, Joe Touch wrote: > >> Right. I like the idea of "only give info that you think the next layer >> can use", but not "tell the next layer what you want it to do". Also, >> the information passed ought to be something that makes sense in the >> context of the next layer, e.g., tell the network layer about a path >> property, not about a link technology, etc. > > > this is probably one of the most precise - and concise - descriptions > of the idea we've been kicking around I've see so far. > > Also, we've so far mostly thought about the network/transport interface > and what additional information could be passed across it that would > allow some new response mechanisms at the transport layer to improve > performance. However, the principle of extending interfaces in this way > - as you've summarized above - can also be applied to the link/network > and transport/application interface. The link/network part is to some > degree looked at by mobopts (although maybe not following the approach > identified above). I'm unaware of extensions to the transport/app > interface. > > Finally, this discussion has mostly talked about moving information of > a certain kind up the stack in a certain way. Someone (Mark Handley?) > had pointed out that the reverse direction may also be important to > look at. Your text above can be read to apply to both directions, which > is nice. > > Lars I'm still not yet convinced we understand exactly what the TRANSPORT can usefully utilise, and which it can rely upon to make safe decisions. * One issue that came up time and again in the previuous BoFs - how does the tranport entity KNOW the signal is from a node on the path, and how much do you wish to continue the idea of "fate-sharing" and "alternate paths" - in which it's hard to know if link characteristics really impact flows. * If you know that some of the packets in the flow have been through the device, do you trust it? There's DOS opportunities here, and also issues of trust between ISPs and Core providers. * Finally, in the TrigTran BoFs, I also recall some discussion of time-scales, what seems like a "timely" event at the physical layer, may not be of interest to the transport layer (working on a timescale of several Path RTTs). I and others have said these sorts of things several times (sorry), and it would be really good to capture exactly which signals are trust-worthy and useful to a transport entity. In the other direction: What are the things the transport enities could tell the link/phy? and how will it know to use these? WE already have QoS and QS/XCP type signals, what are the additional features desired? I think if we understand the usefulness, we can make progress. One example of "something that changed" is advice that the link RTT is large (or has just become large) could be useful. For this, it's wise to make transport protocols that don't rely on exact timing (which is good practice and we're doing this), so simply bumping up the stored RTT seems plausible (and then letting the transport reprobe to confirm this). I think Mark (?) queried whether we need to be exact about what changed has... could it be that any path change would sensibly lead to the same sort of re-probe to confirm RTT, MTU, etc? Gorry