From ternli-bounces@ietf.org Tue Aug 01 18:30:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G82l8-0007ve-HD; Tue, 01 Aug 2006 18:30:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G82l7-0007vZ-Hw for ternli@ietf.org; Tue, 01 Aug 2006 18:30:41 -0400 Received: from sccrmhc15.comcast.net ([204.127.200.85]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G82l6-0001vk-AM for ternli@ietf.org; Tue, 01 Aug 2006 18:30:41 -0400 Received: from s73602 (futurewei.com?[65.104.224.98]) by comcast.net (sccrmhc15) with SMTP id <2006080122303901500ktn7he>; Tue, 1 Aug 2006 22:30:40 +0000 Message-ID: <16a401c6b5b9$efe7c940$0400a8c0@china.huawei.com> From: "Spencer Dawkins" To: References: <20060729011430.55D6C4448FF@lawyers.icir.org> <44CAB876.8000405@isi.edu><3947AF0D-C12A-4052-B790-EE4F74A017D5@netlab.nec.de> <44CE19D8.9080501@erg.abdn.ac.uk> Subject: Re: [TERNLI] Notes from tonight's ad hoc Date: Tue, 1 Aug 2006 17:29:21 -0500 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response 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: 5a9a1bd6c2d06a21d748b7d0070ddcb8 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 > 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. Yes, concerns about security morphed TRIGTRAN into ALIAS, IIRC. This was one of the reasons why TRIGTRAN concentrated on first-hop link changes - TTL=254 made it a lot harder to spoof anything there. One other security-related point I remember from TRIGTRAN - if you assume paths with NATs/FWs are interesting, you have to make a decision about whether you use a new protocol for signaling, or hack around using the old protocol (knowing that you can get the old protocol through the NAT/FW, so reusing a TCP segment as a hint would get you through the NAT/FW, too). At this point, I'm assuming TERNLI is willing to consider a new protocol. > * 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). Yes, IIRC, this was a Mark Allman point (shared by others) - reacting five times during one RTT probably isn't helpful. Of course, if you want to do better than what TCP would have done anyway, you have a small number of RTTs to achieve what you're trying to achieve, and if you don't achieve it by that small number of RTTs, you would have done better to let TCP figure the situation out end-to-end. > 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 From ternli-bounces@ietf.org Wed Aug 02 00:35:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G88Rn-0002Iz-1X; Wed, 02 Aug 2006 00:35:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G88Rl-0002Iq-SI for ternli@ietf.org; Wed, 02 Aug 2006 00:35:05 -0400 Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G88Rj-0002pE-Hl for ternli@ietf.org; Wed, 02 Aug 2006 00:35:05 -0400 Received: from [10.0.1.5] (static-71-246-51-26.lsanca.fios.verizon.net [71.246.51.26]) by vapor.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k724XbY29068; Tue, 1 Aug 2006 21:33:37 -0700 (PDT) In-Reply-To: <20060728114353.275FB444296@lawyers.icir.org> References: <20060728114353.275FB444296@lawyers.icir.org> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-6-92356629" Message-Id: <847C30FB-FC4D-4412-8F54-785C9D038C57@isi.edu> Content-Transfer-Encoding: 7bit From: Aaron Falk Subject: Re: [TERNLI] Notes from tonight's ad hoc Date: Tue, 1 Aug 2006 21:33:35 -0700 To: mallman@icir.org X-Pgp-Agent: GPGMail 1.1.2 (Tiger) X-Mailer: Apple Mail (2.752.2) X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: falk@isi.edu 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 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-6-92356629 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed catching up...perhaps this point is made later in the thread... On Jul 28, 2006, at 4:43 AM, Mark Allman wrote: > The real thing to get across is the available > capacity has changed somewhat dramatically. I think you only want to give *hints* when things have gotten *worse*. Giving hints that things have gotten better may mislead a sender to thinking that they know where the bottleneck is, etc. A hint that available capacity may be reduced may encourage a sender to reduce their rate to avoid a packet loss (or something). --aaron --Apple-Mail-6-92356629 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (Darwin) iD8DBQFE0Csh/i95hBY97NERAsMyAKClKrsMIYPVBNo6FkCOY7S6ZXwTWwCdHIct SrGg1tXUIDcMFHbeVxf4jLE= =8rd1 -----END PGP SIGNATURE----- --Apple-Mail-6-92356629-- From ternli-bounces@ietf.org Wed Aug 02 00:38:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G88Ua-0004Ty-Iq; Wed, 02 Aug 2006 00:38:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G88UZ-0004Tl-6L for ternli@ietf.org; Wed, 02 Aug 2006 00:37:59 -0400 Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G88UX-0003JF-Sd for ternli@ietf.org; Wed, 02 Aug 2006 00:37:59 -0400 Received: from [10.0.1.5] (static-71-246-51-26.lsanca.fios.verizon.net [71.246.51.26]) by vapor.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k724bVY29680; Tue, 1 Aug 2006 21:37:31 -0700 (PDT) In-Reply-To: <20060728125608.670AF444391@lawyers.icir.org> References: <20060728125608.670AF444391@lawyers.icir.org> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-7-92593450" Message-Id: <94176DAD-C2FC-4018-8A15-005606394435@isi.edu> Content-Transfer-Encoding: 7bit From: Aaron Falk Subject: Re: [TERNLI] Notes from tonight's ad hoc Date: Tue, 1 Aug 2006 21:37:32 -0700 To: mallman@icir.org X-Pgp-Agent: GPGMail 1.1.2 (Tiger) X-Mailer: Apple Mail (2.752.2) X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: falk@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 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) --Apple-Mail-7-92593450 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed On Jul 28, 2006, at 5:56 AM, Mark Allman wrote: > + 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.). Perhaps the signal should be that congestion state or RTT estimate is no longer valid. I.e., make the signal have transport semantics. --aaron --Apple-Mail-7-92593450 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (Darwin) iD8DBQFE0CwM/i95hBY97NERAlpiAJ0XXAXVs22bIfKrBYUhv7dnyPEM/QCeKCAT 8kmSZFYWEpGrCjA6TEqpmFM= =F6GV -----END PGP SIGNATURE----- --Apple-Mail-7-92593450-- From ternli-bounces@ietf.org Wed Aug 02 10:19:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8HYr-0003zg-Fq; Wed, 02 Aug 2006 10:19:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8HYq-0003zb-VD for ternli@ietf.org; Wed, 02 Aug 2006 10:19:00 -0400 Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G8HYp-0007Yl-KK for ternli@ietf.org; Wed, 02 Aug 2006 10:19:00 -0400 Received: from [192.168.1.42] (pool-71-106-94-15.lsanca.dsl-w.verizon.net [71.106.94.15]) by vapor.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k72EIDY04839; Wed, 2 Aug 2006 07:18:13 -0700 (PDT) Message-ID: <44D0B41F.2010605@isi.edu> Date: Wed, 02 Aug 2006 07:18:07 -0700 From: Joe Touch User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: Aaron Falk Subject: Re: [TERNLI] Notes from tonight's ad hoc References: <20060728114353.275FB444296@lawyers.icir.org> <847C30FB-FC4D-4412-8F54-785C9D038C57@isi.edu> In-Reply-To: <847C30FB-FC4D-4412-8F54-785C9D038C57@isi.edu> X-Enigmail-Version: 0.94.0.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig1A963CAB297D89FEC42D330E" X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 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) --------------enig1A963CAB297D89FEC42D330E Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Aaron Falk wrote: > catching up...perhaps this point is made later in the thread... >=20 > On Jul 28, 2006, at 4:43 AM, Mark Allman wrote: >=20 >> The real thing to get across is the available >> capacity has changed somewhat dramatically. >=20 > I think you only want to give *hints* when things have gotten *worse*. = That presumes knowing what 'worse' is - which requires knowledge of what the other layer is trying to do. > Giving hints that things have gotten better may mislead a sender to > thinking that they know where the bottleneck is, etc.=20 Let's not decide 'worse' or 'better'. "Changed" is enough; let the other layer figure out what the impact is, IMO. Joe --------------enig1A963CAB297D89FEC42D330E 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 iD8DBQFE0LQfE5f5cImnZrsRAotmAJsEWSvuABIVZ4hTXTjLNnTNWoc48wCg50xl 6hkUjCYngoJauLBAWsVyIN8= =DHpg -----END PGP SIGNATURE----- --------------enig1A963CAB297D89FEC42D330E-- From ternli-bounces@ietf.org Wed Aug 02 10:19:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8HZm-0004RP-3x; Wed, 02 Aug 2006 10:19:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8HZk-0004RJ-Uz for ternli@ietf.org; Wed, 02 Aug 2006 10:19:56 -0400 Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G8HZj-0007lE-Kc for ternli@ietf.org; Wed, 02 Aug 2006 10:19:56 -0400 Received: from [192.168.1.42] (pool-71-106-94-15.lsanca.dsl-w.verizon.net [71.106.94.15]) by vapor.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k72EJNY05299; Wed, 2 Aug 2006 07:19:23 -0700 (PDT) Message-ID: <44D0B465.7060902@isi.edu> Date: Wed, 02 Aug 2006 07:19:17 -0700 From: Joe Touch User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: Aaron Falk Subject: Re: [TERNLI] Notes from tonight's ad hoc References: <20060728125608.670AF444391@lawyers.icir.org> <94176DAD-C2FC-4018-8A15-005606394435@isi.edu> In-Reply-To: <94176DAD-C2FC-4018-8A15-005606394435@isi.edu> X-Enigmail-Version: 0.94.0.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig482A1D294854663C886AE5C0" X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 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) --------------enig482A1D294854663C886AE5C0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Aaron Falk wrote: >=20 > On Jul 28, 2006, at 5:56 AM, Mark Allman wrote: >=20 >> + Giving a generic signal that *something* has changed and it likely= >> matters and so the transport should re-init itself (e.g., forget t= he >> SRTT, RTTVAR, cwnd, ssthresh, MTU value, etc.). >=20 > Perhaps the signal should be that congestion state or RTT estimate is n= o > longer valid. I.e., make the signal have transport semantics. That is what I was afraid of - that means that the link knows what the network is doing, e.g., whether it is using the link for CBR or bursty traffic, etc. Joe --------------enig482A1D294854663C886AE5C0 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 iD8DBQFE0LRlE5f5cImnZrsRAtVpAJ4wenfV+A5yjIeswycRlm0q+5EDawCgsvtm fzkJGDq4ge65Sa/e5TZ57do= =SwU9 -----END PGP SIGNATURE----- --------------enig482A1D294854663C886AE5C0-- From ternli-bounces@ietf.org Wed Aug 02 11:07:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8IKF-0003QR-EN; Wed, 02 Aug 2006 11:07:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8IKD-0003QM-Rq for ternli@ietf.org; Wed, 02 Aug 2006 11:07:57 -0400 Received: from [2001:630:241:204:203:baff:fe9a:8c9b] (helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G8IKC-0005aH-BW for ternli@ietf.org; Wed, 02 Aug 2006 11:07:57 -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 k72F7kEr010339; Wed, 2 Aug 2006 16:07:46 +0100 (BST) Message-ID: <44D0BFC3.7040504@erg.abdn.ac.uk> Date: Wed, 02 Aug 2006 16:07:47 +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: Joe Touch Subject: Re: [TERNLI] Notes from tonight's ad hoc References: <20060728125608.670AF444391@lawyers.icir.org> <94176DAD-C2FC-4018-8A15-005606394435@isi.edu> <44D0B465.7060902@isi.edu> In-Reply-To: <44D0B465.7060902@isi.edu> 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.8 (--) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: Aaron Falk , ternli@ietf.org 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 Joe Touch wrote: > > Aaron Falk wrote: > >>On Jul 28, 2006, at 5:56 AM, Mark Allman wrote: >> >> >>> + 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.). >> >>Perhaps the signal should be that congestion state or RTT estimate is no >>longer valid. I.e., make the signal have transport semantics. > > > That is what I was afraid of - that means that the link knows what the > network is doing, e.g., whether it is using the link for CBR or bursty > traffic, etc. > > Joe > It isn't clear to me yet that the idea of transport semantics is useful... If say, the link has a substantial change in RTT: this obviously effects the RTO in TCP (how much depends upon how much the total path RTT changes), the signal could impact what a sender stores to calculate the SRTT - perhaps it also means that you may have to change other things (such as cwnd), but links don't really know the implications on the transport ... Gorry From ternli-bounces@ietf.org Wed Aug 02 11:15:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8IRn-0000q7-9s; Wed, 02 Aug 2006 11:15:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8IRm-0000q0-3U for ternli@ietf.org; Wed, 02 Aug 2006 11:15:46 -0400 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G8IRk-0006Wc-Oq for ternli@ietf.org; Wed, 02 Aug 2006 11:15:46 -0400 Received: from [128.9.168.162] (neo.isi.edu [128.9.168.162]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k72FEFu28153; Wed, 2 Aug 2006 08:14:15 -0700 (PDT) In-Reply-To: <44D0B465.7060902@isi.edu> References: <20060728125608.670AF444391@lawyers.icir.org> <94176DAD-C2FC-4018-8A15-005606394435@isi.edu> <44D0B465.7060902@isi.edu> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-1-130715757" Message-Id: <408642C4-8B8E-4766-A42B-B90D8E508E38@ISI.EDU> Content-Transfer-Encoding: 7bit From: Aaron Falk Subject: Re: [TERNLI] Notes from tonight's ad hoc Date: Wed, 2 Aug 2006 08:12:54 -0700 To: Joe Touch X-Pgp-Agent: GPGMail 1.1.1 (Tiger) X-Mailer: Apple Mail (2.752.2) X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: falk@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 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) --Apple-Mail-1-130715757 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed On Aug 2, 2006, at 7:19 AM, Joe Touch wrote: > > > Aaron Falk wrote: >> >> On Jul 28, 2006, at 5:56 AM, Mark Allman wrote: >> >>> + 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.). >> >> Perhaps the signal should be that congestion state or RTT estimate >> is no >> longer valid. I.e., make the signal have transport semantics. > > That is what I was afraid of - that means that the link knows what the > network is doing, e.g., whether it is using the link for CBR or bursty > traffic, etc. Joe- I agree with you so I must not be making myself clear. What I mean is to select those characteristics of the path which are possibly/ generally of interest to transport. It seems to me as though some of those characteristics will be more clearly visible to the network (e.g., path), some to the link (or subnetwork, really) (e.g., loss rate). I'm not asserting I have an answer here. Just probing the problem. --aaron --Apple-Mail-1-130715757 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (Darwin) iD8DBQFE0MD4/i95hBY97NERAsKIAJ9NB2sexYvDDthsKRpDfXf002vajACgitVj IJ/VQQuKB0BY6rHOdaR9gYs= =/kHo -----END PGP SIGNATURE----- --Apple-Mail-1-130715757-- From ternli-bounces@ietf.org Wed Aug 02 14:52:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8LpV-0001IY-Ja; Wed, 02 Aug 2006 14:52:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8LpT-0001EX-Sl for ternli@ietf.org; Wed, 02 Aug 2006 14:52:27 -0400 Received: from smtp4.smtp.bt.com ([217.32.164.151]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G8LpS-0005Oh-2n for ternli@ietf.org; Wed, 02 Aug 2006 14:52:27 -0400 Received: from i2kc06-ukbr.domain1.systemhost.net ([193.113.197.70]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 2 Aug 2006 19:52:24 +0100 Received: from cbibipnt05.iuser.iroot.adidom.com ([147.149.196.177]) by i2kc06-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.211); Wed, 2 Aug 2006 19:52:24 +0100 Received: From bagheera.jungle.bt.co.uk ([132.146.168.158]) by cbibipnt05.iuser.iroot.adidom.com (WebShield SMTP v4.5 MR1a P0803.399); id 11545447446; Wed, 2 Aug 2006 19:52:24 +0100 Received: from mut.jungle.bt.co.uk ([10.215.130.80]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id k72IqKm6012958 for ; Wed, 2 Aug 2006 19:52:23 +0100 Message-Id: <5.2.1.1.2.20060802190628.02975a28@pop3.jungle.bt.co.uk> X-Sender: rbriscoe@pop3.jungle.bt.co.uk X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Wed, 02 Aug 2006 19:52:03 +0100 To: ternli@ietf.org From: Bob Briscoe Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable X-Spam-Score: -1.201 () ALL_TRUSTED,MIME_QP_LONG_LINE X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 X-OriginalArrivalTime: 02 Aug 2006 18:52:24.0687 (UTC) FILETIME=[CB1677F0:01C6B664] X-Spam-Score: 0.1 (/) X-Scan-Signature: 995b2e24d23b953c94bac5288c432399 Subject: [TERNLI] History of signalling changes in congestion up the layers 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 Folks, I missed the ad hoc TERNLI BoF, but I've just read the jabber session, and= =20 noticed there was a desire to dig up history on this being done before. The= =20 text below might be useful. It: i) gives a history of ICMP source quench (SQ) falling in and out of favour; ii) gives a list of problems found with SQ. It's an extract from one of my "reviews longer than the original paper"=20 written to help the author of a conference submission to understand the=20 problems there would be introducing their proposal for a SQ-like=20 interaction model (router - source). It was written in Aug 2000, so it's=20 history about history now. BTW, in their case, it was for multicast, so it made a bit more sense than= =20 sending congestion notification to all receivers then having to suppress=20 all but one of the responses, but still it had a multi-bottleneck implosion= =20 problem, and DoS vulnerability... /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ The earliest ref I can find on source quench/explicit congestion=20 notification is the RFC famous for introducing the Nagle algorithm, but=20 also including discussion on use of Source Quench for congestion avoidance= =20 or recovery (about 2/3 the way through Nagle=92s RFC896 Jan 84 [15]). This= =20 led to the use of ICMP Source Quench as the mandatory IETF approach to=20 congestion control for a short while (Section 2.2.3 of Postel=92s router=20 requirements RFC1009 in Jun 87 [4]). Even at that time, RFC 1009 allowed=20 active queue management for congestion avoidance rather than recovery.=20 However, it was already admitted in that RFC that SQ wasn=92t the ideal=20 solution and research was continuing. The arguments against use of Source=20 Quench that led to the change of gateway requirements are summarised in=20 RFC1254 (section 3.1, Aug 1991 [14]), which gives an excellent set of=20 further references. The arguments seem to have been more a result of an=20 unfortunate sequence of events. Essentially, there were so many different=20 algorithms for sending source quench that it wasn=92t clear what a source=20 should assume was happening when it got one - congestion onset or a router= =20 had actually run out of buffer. Packet drop, on the other hand, was a=20 clearer indication that resources had run out. By Nov 1994 source quench=20 was a definite =92SHOULD NOT=92 in the draft router requirements RFC=20 (Almquist=92s RFC1716 [1]). The alternative approach to congestion control= =20 was deliberately vague due to ongoing research, but always involved drop of= =20 packets in some form - outlined in Section 5.3.6, referring to papers of=20 this time such as [13, 6, 16, 9]. SQ was described as a weak mechanism,=20 perhaps because of the above arguments, but also perhaps because it was=20 generally only signalled statistically to avoid congestion avalanche. Use=20 of explicit congestion notification first appeared in [10] in the DEC DNA=20 protocol. Other more solid reasons against the use of SQ do exist: =95 SQ violates layering (congestion control is assumed to be end to end in= =20 the Internet Architecture), so it can interact badly with IPsec encryption= =20 and tunneling. If a router decides to send an SQ message in response to a=20 packet, it is meant to include the first 64b of the original packet as an=20 ICMP payload. When this arrives at the sending IP stack, to work out which= =20 socket to pass it to, for most protocol types it can work out which port=20 the original packet came from, which it finds from the original header that= =20 has been returned to it. With IPsec it can use the SPI field [3]. But if=20 IPsec was in tunnel mode, the tunnel ingress hasn't got enough information= =20 to find out the original source in order to forward on (backward on?) the=20 SQ message. =95 ICMP packet creation is normally (always) implemented on the ingress=20 interface of a router. Congestion is detected on the egress, where it is=20 too late, and too expensive wrt. critical processing time, to trigger the=20 creation of an ICMP packet, without hugely re-working the implementation=20 architecture of most routers. =95 SQ creates more data (although admittedly in the other direction) during= =20 congestion, which is generally to be avoided. =95 SQ may get lost, and there=92s no =92end-middle=92 reliable channel= between=20 source and bottleneck to recover losses. =95 SQ messages can be sent to hosts as if they came from an on-path router,= =20 thus creating a DoS vulnerability. References [1] P. Almquist and F. Kastenholz. Towards requirements for IP routers.=20 Request for comments 1716, Internet Engineering Task Force, URL: rfc1716.txt, November 1994. (Obsoleted by=20 RFC1812) (Status: informational). [2] Hari Balakrishnan, Hariharan Rahul, and Srinivasan Seshan. An=20 integrated congestion management architecture for Internet hosts. Proc. ACM SIGCOMM=9299,Computer Communication Review,=20 29(4), October 1999. [3] L. Berger and T. O=92Malley. RSVP extensions for IPSEC data flows.=20 Request for comments 2207, Internet Engineering Task Force, URL: rfc2207.txt, September 1997. [4] R. T. Braden and J. Postel. Requirements for internet gateways. Request= =20 for comments 1009, Internet Engineering Task Force, URL: rfc1009.txt, June 1987. (Obsoleted by RFC1812)= =20 (Status: historic). [5] A. Dracinschi and Serge Fdida. Congestion avoidance for unicast and=20 multicast trac. In Proc. 1st IEEE Conference on Universal Multiservice Networks (ECUMN 2000), Colmar, France,= =20 pages 360=96368, URL: http://www-rp.lip6.fr/publications/files/anca/e_ecumn_linux.ps.gz, October= =20 2000. [6] G. Finn. A connectionless congestion control algorithm. ACM SIGCOMM=20 Computer Communication Review, 19(5), October 1989. [7] M. Fuchs, C. Diot, T. Turletti, and M. Homan. A naming approach for ALF= =20 design. In Proc. HIPPARCH=9298 workshop, London, URL: ftp://ftp.sprintlabs.com/diot/naming-hipparch.ps.gz,= =20 June 1998. [8] Robert Graham. FAQ: Firewall forensics. Web page URL:=20 http://www.robertgraham.com/pubs/ firewall-seen.html\#2.4, February 2001. [9] Van Jacobsen. Congestion avoidance and control. Proc. ACM SIGCOMM=9288,= =20 Computer Communication Review, 18(4):314=96329, 1988. [10] R. Jain, K. Ramakrishnan, and D. Chiu. Congestion avoidance in=20 computer networks with a connectionless network layer. Technical report DEC-TR-506, Digital Equipment Corporation,= =20 1987. [11] Tae Eun Kim, Raghupathy Sivakumar, Kang-Won Lee, and Vaduvur=20 Bharghavan. Multicast service dierentiation in core-stateless networks. In Proc. 1st International COST264 Workshop on= =20 Networked Group Communication (NGC=9299), volume 1736. Springer LNCS, November 1999. 5 [12] Dong Lin and Robert Morris. Dynamics of random early detection. Proc.= =20 ACM SIGCOMM=9297, Computer Communication Review, 27(4), October 1997. [13] A. Mankin, G. Hollingsworth, G. Reichlen, K. Thompson, R. Wilder, and= =20 R. Zahavi. Evaluation of Internet performance =97 FY89. Technical report MTR-89W00216, MITRE Corporation,=20 February 1990. [14] A. Mankin and K. Ramakrishnan. Gateway congestion control survey.=20 Request for comments 1254, Internet Engineering Task Force, URL: rfc1254.txt, July 1991. (Status:= informational). [15] J. Nagle. Congestion control in IP/TCP internetworks. Request for=20 comments 896, Internet Engineering Task Force, URL: rfc896.txt, January 1984. (Status: unknown). [16] J. Nagle. On packet switches with infinite storage. Request for=20 comments 970, Internet Engineering Task Force, URL: rfc970.txt, December 1985. (Status: unknown). ____________________________________________________________________________ Bob Briscoe, Networks Research Centre, BT Research B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK. +44 1473 645196= =20 From ternli-bounces@ietf.org Thu Aug 03 00:47:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8V7M-0005b5-32; Thu, 03 Aug 2006 00:47:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8V7L-0005VP-1C for ternli@ietf.org; Thu, 03 Aug 2006 00:47:31 -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 1G8Nux-0005Hf-8U for ternli@ietf.org; Wed, 02 Aug 2006 17:06:15 -0400 Received: from smtp1.smtp.bt.com ([217.32.164.137]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1G8NMK-00017s-Oj for ternli@ietf.org; Wed, 02 Aug 2006 16:30:30 -0400 Received: from i2kc08-ukbr.domain1.systemhost.net ([193.113.197.71]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 2 Aug 2006 21:29:21 +0100 Received: from cbibipnt08.iuser.iroot.adidom.com ([147.149.100.81]) by i2kc08-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.211); Wed, 2 Aug 2006 21:29:20 +0100 Received: From bagheera.jungle.bt.co.uk ([132.146.168.158]) by cbibipnt08.iuser.iroot.adidom.com (WebShield SMTP v4.5 MR1a P0803.399); id 1154550560140; Wed, 2 Aug 2006 21:29:20 +0100 Received: from mut.jungle.bt.co.uk ([10.215.130.80]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id k72KTDHa014928; Wed, 2 Aug 2006 21:29:17 +0100 Message-Id: <5.2.1.1.2.20060802212808.018d68a0@pop3.jungle.bt.co.uk> X-Sender: rbriscoe@pop3.jungle.bt.co.uk X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Wed, 02 Aug 2006 21:29:14 +0100 To: Aaron Falk From: Bob Briscoe Subject: Re: [TERNLI] Notes from tonight's ad hoc In-Reply-To: <408642C4-8B8E-4766-A42B-B90D8E508E38@ISI.EDU> References: <44D0B465.7060902@isi.edu> <20060728125608.670AF444391@lawyers.icir.org> <94176DAD-C2FC-4018-8A15-005606394435@isi.edu> <44D0B465.7060902@isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: -1.36 () ALL_TRUSTED X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 X-OriginalArrivalTime: 02 Aug 2006 20:29:20.0883 (UTC) FILETIME=[55CF8C30:01C6B672] X-Spam-Score: -2.6 (--) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 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 Aaron, At 16:12 02/08/2006, Aaron Falk wrote: >I agree with you so I must not be making myself clear. What I mean >is to select those characteristics of the path which are possibly/ >generally of interest to transport. It seems to me as though some of >those characteristics will be more clearly visible to the network >(e.g., path), some to the link (or subnetwork, really) (e.g., loss >rate). > >I'm not asserting I have an answer here. Just probing the problem. I prefer to talk specifics (but excuse me if I've missed some shared context - I missed the ad hoc BoF, but I've tried to pick it up from the archive)... We certainly know what info the *congestion control* part of the transport needs: congestion and delay. So for that we merely need to signal the information the transport needs in packets. And if either of these values changes, it's obvious it's changed. Surely the transport doesn't then need a "something's changed" message. Surely the problem is that the netwk layer doesn't signal congestion information with enough precision for the modern transport's needs. My personal preference is to keep the DoS-resistant model where lower layer info is piggy-backed on packets to the receiver, then the receiver deals with feedback. So we would need the following changes to protocols: * a multi-bit netwk layer congestion field within the forwarded packet. * the addition of multi-bit congestion feedback in transport protocols. A drastic change in load at any router would immediately be visible as a change in this higher-precision congestion field (if it's a re-route but the new path has the same congestion, the transport doesn't need to know anything has changed). A multi-bit congestion field would also quickly bootstrap a connection's knowledge of path congestion in the feedback from the very first packet. I'm not just choosing congestion as the signal because we already have it. There is a good argument for why it is right (and other metrics are wrong). Congestion is a probability p in [0,1] which represents the proportion of the load unlikely to be able to be served. IMHO, signalling p with more precision is *better* than signalling explicit rate information (like QS/XCP). p gives as much information as signalling explicit rate infomation without the router having to decide who gets what. For instance, the variable p is the internal variable in the RED algorithm that drives the random dice throw to decide whether to {drop | mark ECN} or not. I'm saying routers should write this number into the multi-bit congestion field of each packet (accumulating it from multiple routers is described later). From p, the source can work out the excess rate it is sending like this: if the local congestion on an interface is p, incoming load is Y and outgoing capacity is X, then p ~ (Y-X)/Y. So if every flow getting signal p reduced its rate by p%, they would all fit through the available capacity. But of course, sources actually do some form of AIMD to allow for new flows etc, but the alg is essentially designed to converge on a rate that is p% lower than the one being used. Essentially, a signal of p can be reverse engineered to get a rate signal. But the important difference is that p is normalised, so it is proportionate to the bit rate sent in each flow but the router doesn't have to understand flows. Basically, the router doesn't have to dish out bandwidth allocations, which saves it understanding who it is dishing out stuff to. If instead the router dishes out rate to flows (like XCP/QS), sources can cheat by splitting one flow into multiple flows. The idea that fairness means that all flows should get equal rate is completely daft and should never have taken hold - it's just soooo vulnerable to cheating by splitting flow IDs. The other strength of using p, is that it can be combined properly when there are multiple bottlenecks. The accumulation algorithm to update the header field h as it passes through a router with local congestion p should use combinatorial probability h <- 1 - (1-h)(1-p) So, for instance, if there are two bottlenecks, with p of 5% and 1%, the header would end up carrying h = 5.95% (= 100% - 95%*99%). This way, the traffic matrix packs into the network most efficiently. It stems from the meaning of congestion as a probability. Finding the minimum bottleneck (like XCP & QS) isn't necessarily the best approach. Basically, I'm saying a) Instead of signalling "something's changed", I believe it is more practical to continuously signal the "something". b) What congestion control needs most is greater precision for the congestion signal c) There are strong but subtle reasons for using probability as a universal congestion signal that lead to overall simplicity when the whole picture is taken into account (which we lose if we adopt QS or XCP). Bob ____________________________________________________________________________ Bob Briscoe, Networks Research Centre, BT Research B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK. +44 1473 645196 From ternli-bounces@ietf.org Thu Aug 03 03:57:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8Y5Q-0003XW-7H; Thu, 03 Aug 2006 03:57:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8Y5P-0003XR-9E for ternli@ietf.org; Thu, 03 Aug 2006 03:57:43 -0400 Received: from smtp0.netlab.nec.de ([195.37.70.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G8Y5N-0007zW-OT for ternli@ietf.org; Thu, 03 Aug 2006 03:57:43 -0400 Received: from localhost (localhost.office [127.0.0.1]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 50B4920031E1; Thu, 3 Aug 2006 09:58:04 +0200 (CEST) Received: from smtp0.netlab.nec.de ([127.0.0.1]) by localhost (atlas1.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 11061-05; Thu, 3 Aug 2006 09:58:04 +0200 (CEST) Received: from venus.office (europa.netlab.nec.de [10.1.1.25]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 30E8B20031DB; Thu, 3 Aug 2006 09:58:04 +0200 (CEST) Received: from n-eggert.office ([10.1.1.112]) by venus.office over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Thu, 3 Aug 2006 09:57:40 +0200 Received: from [127.0.0.1] (localhost [127.0.0.1]) by n-eggert.office (Postfix) with ESMTP id 4B6551704EC; Thu, 3 Aug 2006 09:57:38 +0200 (CEST) In-Reply-To: <5.2.1.1.2.20060802212808.018d68a0@pop3.jungle.bt.co.uk> References: <44D0B465.7060902@isi.edu> <20060728125608.670AF444391@lawyers.icir.org> <94176DAD-C2FC-4018-8A15-005606394435@isi.edu> <44D0B465.7060902@isi.edu> <5.2.1.1.2.20060802212808.018d68a0@pop3.jungle.bt.co.uk> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-30-190997617; protocol="application/pkcs7-signature" Jabber-Id: lars.eggert@jabber.netlab.nec.de Message-Id: <98BAB2D5-E31B-4240-BCE8-D4A3CC56FF0F@netlab.nec.de> From: Lars Eggert Subject: Re: [TERNLI] Notes from tonight's ad hoc Date: Thu, 3 Aug 2006 09:57:36 +0200 To: Bob Briscoe X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 03 Aug 2006 07:57:40.0291 (UTC) FILETIME=[7E2D1930:01C6B6D2] X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas1.office) X-Spam-Score: 0.1 (/) X-Scan-Signature: a1852b4f554b02e7e4548cc7928acc1f Cc: Aaron Falk , 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 --Apple-Mail-30-190997617 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Hi, On Aug 2, 2006, at 22:29, Bob Briscoe wrote: > We certainly know what info the *congestion control* part of the > transport needs: congestion and delay. So for that we merely need > to signal the information the transport needs in packets. And if > either of these values changes, it's obvious it's changed. Surely > the transport doesn't then need a "something's changed" message. actually, it's not that obvious. Yes, the transport eventually learns that things have changed based on its ongoing path probing, but that may be several RTTs later, during which it has transmitted at a rate based on stale state. Furthermore, its reaction to the change may be too conservative (not a big issue) or not conservative enough. > Surely the problem is that the netwk layer doesn't signal > congestion information with enough precision for the modern > transport's needs. It's not only congestion, it's also delay, plus maybe additional information. One work item from the ad hoc meeting was to figure out which kinds of information transports do or could operate on. > My personal preference is to keep the DoS-resistant model... > Basically, I'm saying > a) Instead of signalling "something's changed", I believe it is > more practical to continuously signal the "something". That's an interesting observation. By constantly providing the raw information, it is up to the transports to decide what difference constitutes a "change" vs. having the network layer decide that a "change" has occurred. It also allows transports to process the raw information into events any way they see fit, instead of assuming one specific way at the layer below. > b) What congestion control needs most is greater precision for the > congestion signal > c) There are strong but subtle reasons for using probability as a > universal congestion signal that lead to overall simplicity when > the whole picture is taken into account (which we lose if we adopt > QS or XCP). Lars -- Lars Eggert NEC Network Laboratories --Apple-Mail-30-190997617 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 hkiG9w0BCQUxDxcNMDYwODAzMDc1NzM3WjAjBgkqhkiG9w0BCQQxFgQUH8rX25n/VUByZ8sJOybd BHuHPp4wgdYGCSsGAQQBgjcQBDGByDCBxTCBvzELMAkGA1UEBhMCREUxHDAaBgNVBAgUE0JhZGVu LVfDdWVydHRlbWJlcmcxEzARBgNVBAcTCkhlaWRlbGJlcmcxFzAVBgNVBAoTDk5FQyBFdXJvcGUg THRkMR0wGwYDVQQLExROZXR3b3JrIExhYm9yYXRvcmllczEbMBkGA1UEAxMSa29iZS5uZXRsYWIu bmVjLmRlMSgwJgYJKoZIhvcNAQkBFhlsYXJzLmVnZ2VydEBuZXRsYWIubmVjLmRlAgEAMIHYBgsq hkiG9w0BCRACCzGByKCBxTCBvzELMAkGA1UEBhMCREUxHDAaBgNVBAgUE0JhZGVuLVfDdWVydHRl bWJlcmcxEzARBgNVBAcTCkhlaWRlbGJlcmcxFzAVBgNVBAoTDk5FQyBFdXJvcGUgTHRkMR0wGwYD VQQLExROZXR3b3JrIExhYm9yYXRvcmllczEbMBkGA1UEAxMSa29iZS5uZXRsYWIubmVjLmRlMSgw JgYJKoZIhvcNAQkBFhlsYXJzLmVnZ2VydEBuZXRsYWIubmVjLmRlAgEAMA0GCSqGSIb3DQEBAQUA BIIBAKdR8tVBo0rGW8U0HSy/jQ1yh7MYKx4Klug3a9vtHHcr/aoXg8PfocTN9e9k0Op0bZZv5a8r WHtVZayK+EcLqOOq0QR0tq9JiUtlLuqT0wm6bOnBzARkoBJ6Bwvqo8Bw4LqURrsbqVbKK17UQKkO 8GPlKMV58h71v3DOQnwpHo4Gkf+3YQQZxKUAHmfW93ydMRvyscVNsg2KmfrHXr0at8GTsQ64fSqa 63R0SYSQqccFckPPZjzpqZo8AzhWSW1acbbqTz7iwYnzQl3fhr2wWKj85BukGkD2z7b8+VsBsAMp DZ+n0JOa1P1wOeiBZXuSb02Pn8W3gt+o36nPiHOi1xoAAAAAAAA= --Apple-Mail-30-190997617-- From ternli-bounces@ietf.org Thu Aug 03 13:28:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8gzy-0002SE-93; Thu, 03 Aug 2006 13:28:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8gzw-0002S1-VU for ternli@ietf.org; Thu, 03 Aug 2006 13:28:40 -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 1G8ayF-0008Ha-MC for ternli@ietf.org; Thu, 03 Aug 2006 07:02:31 -0400 Received: from smtp1.smtp.bt.com ([217.32.164.137]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1G8aWp-0001jz-E7 for ternli@ietf.org; Thu, 03 Aug 2006 06:34:16 -0400 Received: from i2kc06-ukbr.domain1.systemhost.net ([193.113.197.70]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 3 Aug 2006 11:34:09 +0100 Received: from cbibipnt05.iuser.iroot.adidom.com ([147.149.196.177]) by i2kc06-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.211); Thu, 3 Aug 2006 11:29:05 +0100 Received: From bagheera.jungle.bt.co.uk ([132.146.168.158]) by cbibipnt05.iuser.iroot.adidom.com (WebShield SMTP v4.5 MR1a P0803.399); id 115460094463; Thu, 3 Aug 2006 11:29:04 +0100 Received: from mut.jungle.bt.co.uk ([10.86.0.202]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id k73ASwj7029928; Thu, 3 Aug 2006 11:29:02 +0100 Message-Id: <5.2.1.1.2.20060803102815.02ca0c68@pop3.jungle.bt.co.uk> X-Sender: rbriscoe@pop3.jungle.bt.co.uk X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Thu, 03 Aug 2006 11:29:01 +0100 To: Lars Eggert From: Bob Briscoe Subject: Re: [TERNLI] Notes from tonight's ad hoc In-Reply-To: <98BAB2D5-E31B-4240-BCE8-D4A3CC56FF0F@netlab.nec.de> References: <5.2.1.1.2.20060802212808.018d68a0@pop3.jungle.bt.co.uk> <44D0B465.7060902@isi.edu> <20060728125608.670AF444391@lawyers.icir.org> <94176DAD-C2FC-4018-8A15-005606394435@isi.edu> <44D0B465.7060902@isi.edu> <5.2.1.1.2.20060802212808.018d68a0@pop3.jungle.bt.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: -1.36 () ALL_TRUSTED X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 X-OriginalArrivalTime: 03 Aug 2006 10:29:05.0501 (UTC) FILETIME=[A56220D0:01C6B6E7] X-Spam-Score: -2.6 (--) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 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 Lars, At 08:57 03/08/2006, Lars Eggert wrote: >It's not only congestion, it's also delay, plus maybe additional >information. One work item from the ad hoc meeting was to figure out >which kinds of information transports do or could operate on. Yes, I said the TSV needs congestion and delay, but I only focused on the NET signalling congestion upwards, because...: i) If you meant specifically RTT delay (= propagation + congestion delay), the TSV can measure that as often as it needs to without explicit signalling. ii) However, if you meant specifically congestion delay I disagree - this is less useful as a congestion metric (implying I don't believe FAST TCP or Vegas are the long term direction - fine as tactical hacks). Arguments against congestion delay as a metric: a) Explicit congestion signalling is a richer way for the NET to signal how much the TSV should change its rate because, if the NET signals (or the TSV measures) congestion delay, in order to signal an equivalent amount of info to the TSV for it to know how to change its rate, the NET would also have to say what the output line rate of each interface was (meaning numerous metrics across a path - yuk). Just signalling congestion does that all in one metric, even when accumulated across a path. b) Measuring congestion delay is fine as a tactical hack to get more precise info from the network than 1-bit drop or 1-bit ECN, but it won't be useful long term as link speeds increase. Then congestion delay becomes so small relative to propagation delay that it becomes a very imprecise metric to do congestion control on (IOW, the equiv no. of bits of info per packet is currently >1, but will become <1 as the net scales). (We're in the early stages of writing up and proving the above argument as a full paper.) BTW, I do agree with FAST & Vegas (and Siris's weighted window-based cc) on another count: Unlike Reno, delay should only determine the second order behaviour, not the first order. Ie the equilibrium rate shouldn't depend on RTT, but how fast it gets there should. >>Basically, I'm saying >>a) Instead of signalling "something's changed", I believe it is >>more practical to continuously signal the "something". > >That's an interesting observation. By constantly providing the raw >information, it is up to the transports to decide what difference >constitutes a "change" vs. having the network layer decide that a >"change" has occurred. It also allows transports to process the raw >information into events any way they see fit, instead of assuming one >specific way at the layer below. If the NET says "something's changed", * 1RTT later the TSV probes. * The TSV has to probe for everything, because it doesn't know what "something" is (unless the NET allows the question "what's changed?" which is silly - it would have been better for the NET to say what changed in the first place otherwise this would take yet another RTT). * 1 more RTT later the TSV finds out the info. That's 2RTTs already. If we can get down to exactly what the "something's" are, we can know how many bits would be needed to continuously repeat them, rather than implement the more complicated probe interfaces necessary above. Additionally, when talking about changes in load/congestion, the NET doesn't know what threshold all the different TSVs would like it to use to decide when a change has been big enough to say "something's changed". Congestion changes all the time. Some changes are bigger than others. So the approach of continuously reporting the current level avoids the NET second guessing what changes TSVs are interested in. Bob ____________________________________________________________________________ Bob Briscoe, Networks Research Centre, BT Research B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK. +44 1473 645196 From ternli-bounces@ietf.org Thu Aug 03 13:41:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8hBy-0001s2-Em; Thu, 03 Aug 2006 13:41:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8hBx-0001rx-Ew for ternli@ietf.org; Thu, 03 Aug 2006 13:41:05 -0400 Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G8hBw-0001dS-3l for ternli@ietf.org; Thu, 03 Aug 2006 13:41:05 -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 k73HeIY25408; Thu, 3 Aug 2006 10:40:18 -0700 (PDT) Message-ID: <44D23573.4070006@isi.edu> Date: Thu, 03 Aug 2006 10:42:11 -0700 From: Joe Touch User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: Lars Eggert Subject: Re: [TERNLI] Notes from tonight's ad hoc References: <44D0B465.7060902@isi.edu> <20060728125608.670AF444391@lawyers.icir.org> <94176DAD-C2FC-4018-8A15-005606394435@isi.edu> <44D0B465.7060902@isi.edu> <5.2.1.1.2.20060802212808.018d68a0@pop3.jungle.bt.co.uk> <98BAB2D5-E31B-4240-BCE8-D4A3CC56FF0F@netlab.nec.de> In-Reply-To: <98BAB2D5-E31B-4240-BCE8-D4A3CC56FF0F@netlab.nec.de> X-Enigmail-Version: 0.94.0.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig4D595E84610FA5B7F3188A44" X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Cc: Aaron Falk , 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) --------------enig4D595E84610FA5B7F3188A44 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Lars Eggert wrote: > Hi, >=20 > On Aug 2, 2006, at 22:29, Bob Briscoe wrote: =2E.. >> Basically, I'm saying >> a) Instead of signalling "something's changed", I believe it is more >> practical to continuously signal the "something". >=20 > That's an interesting observation. By constantly providing the raw > information, it is up to the transports to decide what difference > constitutes a "change" vs. having the network layer decide that a > "change" has occurred. It also allows transports to process the raw > information into events any way they see fit, instead of assuming one > specific way at the layer below. So you have congestion. It affects, e.g., only TCP port 80. The network layer doesn't know that, so it continually tells every transport layer that congestion has occurred. It's blathering that something needs to be done, when in fact only one protocol really sees any change. And congestion can change without affecting latency, and vice-versa. How do you know what to send the transport? How do you know what it cares abo= ut? The network can't measure *transport* latency, which is what the transport layer really cares about. Something specific like "the network layer has lower RTTs right now" assumes that this matters to the transport layer; it really doesn't, e.g., if the transport on the other end has larger latency at the same time (due to transport processing load= ). I don't much care what the network layer tells the transport; it's the transport's obligation to verify whether it sees the same thing, or in fact what it sees anyway. IMO, 'please re-check the network now' is the primary signal of interest. Everything else "goes to intent" and makes the network layer (in this case) recapitulate what it *thinks* the transport layer wants, and that isn't particularly informative. (FWIW, the same is true for link/net interactions) Joe --------------enig4D595E84610FA5B7F3188A44 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 iD8DBQFE0jV2E5f5cImnZrsRAqkqAKC0gQxYcL+V0jfZ39qlSGWNHIOk0wCdERY7 QXy2LJeYBILCkjoLXXIFMxg= =b5MH -----END PGP SIGNATURE----- --------------enig4D595E84610FA5B7F3188A44--