From tsvwg-bounces@ietf.org Fri Jun 01 18:38:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HuFlc-0001KK-Ia; Fri, 01 Jun 2007 18:38:44 -0400 Received: from tsvwg by megatron.ietf.org with local (Exim 4.43) id 1HuFla-00018o-Dg for tsvwg-confirm+ok@megatron.ietf.org; Fri, 01 Jun 2007 18:38:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HuFlZ-000168-V4 for tsvwg@ietf.org; Fri, 01 Jun 2007 18:38:41 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HuFlX-0002II-6C for tsvwg@ietf.org; Fri, 01 Jun 2007 18:38:41 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-2.cisco.com with ESMTP; 01 Jun 2007 15:38:34 -0700 X-IronPort-AV: i="4.16,374,1175497200"; d="scan'208"; a="376920621:sNHT45143430" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l51McYdc001127; Fri, 1 Jun 2007 15:38:34 -0700 Received: from dwingwxp ([10.32.240.194]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l51McXtV016991; Fri, 1 Jun 2007 22:38:33 GMT From: "Dan Wing" To: "'Lars Eggert'" Subject: RE: [Tsvwg] Re: [tcpm] Revision of draft-larsen-tsvwg-port-randomization Date: Fri, 1 Jun 2007 15:38:33 -0700 Message-ID: <0a3a01c7a49d$9670bce0$10676b80@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: Acejkz8/sRFkfZlEQC+zkuidxhflOwBCVC7w In-Reply-To: <0E46EBE9-1C13-44B6-9C04-476D418F5A6D@nokia.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1836; t=1180737514; x=1181601514; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20[Tsvwg]=20Re=3A=20[tcpm]=20Revision=20of=20draft-lars en-tsvwg-port-randomization |Sender:=20; bh=JII5b0TGKGp9SkjROXTSLbPsbFyiUuUOdtlJm7tfDl0=; b=stwRS6HNDq/lVm5lfbo/uc+awzsX4nSweIoUEKQICs9MUOks8uW+54GKdl77kNrRed4AmfwU BtPqRcX/IICyZutt76TMp3IfsSIjv1ibr/fcqnWrRSX1PzRU4z33WD4zC1A63iaz2NwBLjSuJI je3dhpHj/7vwBQ7sWVIcZTWY4=; Authentication-Results: sj-dkim-1; header.From=dwing@cisco.com; dkim=pass (s ig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: 'tsvwg WG' , 'ext Fernando Gont' X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tsvwg-bounces@ietf.org Lars Eggert [mailto:lars.eggert@nokia.com] wrote: > On 2007-2-11, at 17:56, ext Fernando Gont wrote: > > We have published a revision of the port randomization draft > > (draft-larsen-tsvwg-port-randomization). This version addresses > > feedback from Alfred Hoenes and Carlos Pignataro, and comments from > > FreeBSD's Mike Silbersack. The draft is targetted at tsvwg because > > the same stuff can be applied to other protocols. But most (all?) of > > the work on this has been done mainly for TCP. > > The update is at http://tools.ietf.org/html/draft-larsen-tsvwg-port- > randomization. > > The concepts in this draft are likely relevant to most of our > transport protocols, and hence would be in scope for TSVWG. > The TSVWG > chairs are interested in comments on whether there is group interest > in this draft - please comment on tsvwg@ietf.org. The suggestions in this document are equally important for RTP so that attackers are forced to work harder to inject undesired content into RTP media sessions. It would be useful if the document scope were expanded slightly to explicitly include RTP. For example, the Abstract currently says: Recently, awareness has been raised about a number of "blind" attacks that can be performed against the Transmission Control Protocol (TCP) and similar protocols. it is hard to say that RTP is similar to TCP. Thus, I would suggest changing it to something like this: Recently, awareness has been raised about a number of "blind" attacks that can be performed against protocols that reuse ports such as Transmission Control Protocol (TCP) and Real-time Transport Protocol (RTP). with a similar change in the Introduction. Even without this change, I support adopting this document as a TSVWG item. -d From tsvwg-bounces@ietf.org Tue Jun 05 08:03:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvXkq-0006Gi-BK; Tue, 05 Jun 2007 08:03:16 -0400 Received: from tsvwg by megatron.ietf.org with local (Exim 4.43) id 1HvEfy-000734-6t for tsvwg-confirm+ok@megatron.ietf.org; Mon, 04 Jun 2007 11:40:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvEfx-00072u-RA; Mon, 04 Jun 2007 11:40:57 -0400 Received: from elasmtp-scoter.atl.sa.earthlink.net ([209.86.89.67]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvEfx-0007y5-GJ; Mon, 04 Jun 2007 11:40:57 -0400 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=dCaQ+SiinDvJO+plNNc5z61Zee8zUM/E08tdVUj1y+X0L5SgI5EVhyTaxuj6ogSd; h=Received:Message-ID:From:To:Cc:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [64.125.79.23] (helo=gw) by elasmtp-scoter.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1HvEfl-0004Lw-AC; Mon, 04 Jun 2007 11:40:45 -0400 Message-ID: <293101c7a6be$bc97a3c0$174f7d40@home.glassey.com> From: "todd glassey" To: "Erblichs" , References: <20070530122558.F2F0621A837@lawyers.icir.org> <465E0CB8.EA37F26D@earthlink.net> Subject: Re: [Tsvwg] Re: Last Call: draft-ietf-tsvwg-cc-alt (Specifying NewCongestion Control Algorithms) to BCP Date: Mon, 4 Jun 2007 08:40:51 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="ISO-8859-2"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-ELNK-Trace: 01b7a7e171bdf5911aa676d7e74259b7b3291a7d08dfec79f6c7f56d653943b39196c167be2514fd350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 64.125.79.23 X-Spam-Score: 0.0 (/) X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7 X-Mailman-Approved-At: Tue, 05 Jun 2007 08:03:14 -0400 Cc: ietf@ietf.org, tsvwg-chairs@tools.ietf.org, iccrg@cs.ucl.ac.uk, Pekka Savola , tsvwg@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tsvwg-bounces@ietf.org ----- Original Message ----- From: "Erblichs" To: Cc: ; ; "Pekka Savola" ; ; Sent: Wednesday, May 30, 2007 4:46 PM Subject: Re: [Tsvwg] Re: Last Call: draft-ietf-tsvwg-cc-alt (Specifying NewCongestion Control Algorithms) to BCP > Mark Allamn, > > I always have a "internal fight" when I read these > documents as whether they are meant as a BCP type > document or... > > So, if I can add my thoughts.. > > 1) Architecture design and implementation can be two completely > different items for acceptance criteria. Thus, I might propose > the floowing items: > > - two or more implimentations using a new alternate cc algorithm > could be used as interoperability against each other and another > cc algor.. As long as they both use the same CC Alg's then this is OK... > > - if possible, a Linux, xBSD, etc public reference should be > available, This isnt relevant to the Standard Process from the IETF but rather in how its used. > > - experiences using the new cc algorithm should be available, You mean like formal testing or 'use reports' from those involved with the Standards Process? > > - ALL new CC algorithms SHOULD pass through a preliminary > experimental stage.. This means that any implementations that used those Alg's would also be 'Experimental' in nature - how does that fit in with the above rule you proposed on 'that there must be two implementations' - certainly when there is more than one implementation done, that would qualify the protocol as "implemented" and not "experimental" in nature. > > > 2) What is the expected consequences if a private entitity > implements a private/IP CC algorithm that is unfair, etc.. This is a political issue and would embroil the IETF in actions which can get the IETF and those involved sued. I would suggest that there is nothing to say about private entities actions here. > > 3) Classification (ordering) of a CC algorithm that is used > as a TCP option, so two endpoints can determine which > CC algorithm is used at each endpoint, I suggested this to PKIX as part of a "policy negotiation and selection process" and was slammed for it. > > > 4) Support for a CC algorithm in one environment, ie LFN.. > > 5) Well known TCP CC algorithms that may use non-standard options: > ie: 10 Dup-ACKs for a fast re-xmit.. > > 6) Specifiying a minimum inter-packet gap based on recent history > to minimize ANY CC alg from implmenting say a 100 seg burst, > from a non-slow start re-start... > > Mitchell Erblich > ----------------- > > > Mark Allman wrote: >> >> > For other guidelines, i.e., (2), (5), (6), and (7), the author >> > must perform the suggested evaluations and provide recommended >> > analysis. Evidence that >> > the proposed mechanism has significantly more problems than those >> > of >> > TCP should be a cause for concern in approval for widespread >> > deployment in the global Internet. >> >> Looks OK to me. I have incorporated it, modulo comments from Sally. >> >> As for the non-BE stuff: This document is a no-op. But, why is that an >> issue? The IETF would have to grapple with the non-BE case just as it >> does today (i.e., without a set of guidelines). This one document does >> not need to solve all the world's problems. If you want to write a >> document about how the IETF should handle non-BE congestion control >> proposals, I think that'd be fine. And, again, I am not hearing outcry >> on this point so I think the document is fine (even if the consensus on >> this one point is not completely 'smooth'). >> >> Thanks, >> allman >> >> ------------------------------------------------------------------------ >> Part 1.2Type: application/pgp-signature > > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www1.ietf.org/mailman/listinfo/ietf From tsvwg-bounces@ietf.org Wed Jun 06 03:42:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hvq9q-0004IE-M1; Wed, 06 Jun 2007 03:42:18 -0400 Received: from tsvwg by megatron.ietf.org with local (Exim 4.43) id 1Hvq9o-0004Hy-R5 for tsvwg-confirm+ok@megatron.ietf.org; Wed, 06 Jun 2007 03:42:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hvq9l-0004Hl-E0 for tsvwg@ietf.org; Wed, 06 Jun 2007 03:42:13 -0400 Received: from gws04.mail.hcl.in ([203.105.186.20] helo=gws04.hcl.in) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hvq9i-0006Bo-Tn for tsvwg@ietf.org; Wed, 06 Jun 2007 03:42:13 -0400 Received: from gws04.hcl.in (gws04 [10.249.64.135]) by localhost.hcl.in (Postfix) with ESMTP id 20603360B02 for ; Wed, 6 Jun 2007 13:03:06 +0530 (IST) Received: from chn-egw01-out.corp.hcl.in (unknown [10.249.64.37])by gws04.hcl.in (Postfix) with ESMTP id 0188F360B15for ; Wed, 6 Jun 2007 12:49:28 +0530 (IST) Received: from CHN-HCLT-EVS02.HCLT.CORP.HCL.IN ([10.101.26.14]) by chn-egw01-out.corp.hcl.in with Microsoft SMTPSVC(6.0.3790.1830); Wed, 6 Jun 2007 12:50:48 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 6 Jun 2007 12:50:42 +0530 Message-ID: <66E8AEE9980BB44CA5FCAD39EBA56AC6017D4412@CHN-HCLT-EVS02.HCLT.CORP.HCL.IN> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Clarification on sctp library. Thread-Index: AceoCzEJKsx9omGuTVadFz5IrFa9Rw== From: "Balamurugan T, TLS-Chennai" To: X-OriginalArrivalTime: 06 Jun 2007 07:20:48.0863 (UTC) FILETIME=[34E136F0:01C7A80B] X-imss-version: 2.047 X-imss-result: Passed X-imss-scanInfo: M:T L:E SM:1 X-imss-tmaseResult: TT:1 TS:-14.4018 TC:1F TRN:36 TV:3.6.1039(15220.003) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) Content-Type: multipart/mixed; boundary="=_Boundary_KWdoS3Gs3FsDkXCCsTdg" X-Spam-Score: 0.1 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Subject: [Tsvwg] Clarification on sctp library. X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tsvwg-bounces@ietf.org This is a multi-part message in MIME format. --=_Boundary_KWdoS3Gs3FsDkXCCsTdg Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Clarification on sctp library.

Hi All,

     I am new to = sctp protocol and need the below clarifications. I have installed = lksctp-tools-1.0.6 on Suse linux.

      1. How = to get the association id  for a successful connection.?
      2. Is = there any system call available to set a sctp socket as = NON_blocking.
      3. Is = it possible to call sctp_connectx from a 1-to-1 sctp socket (sctp client = ) to 1-to-N socket (sctp server).
      4. How = to set non-blocking on sctp server socket.

Thanks in Advance,
Bala
     

  
  

--=_Boundary_KWdoS3Gs3FsDkXCCsTdg Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit DISCLAIMER: ----------------------------------------------------------------------------------------------------------------------- The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. It shall not attach any liability on the originator or HCL or its affiliates. Any views or opinions presented in this email are solely those of the author and may not necessarily reflect the opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of the author of this e-mail is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any mail and attachments please check them for viruses and defect. ----------------------------------------------------------------------------------------------------------------------- --=_Boundary_KWdoS3Gs3FsDkXCCsTdg-- From tsvwg-bounces@ietf.org Wed Jun 06 11:13:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvxCP-0006iQ-Jz; Wed, 06 Jun 2007 11:13:25 -0400 Received: from tsvwg by megatron.ietf.org with local (Exim 4.43) id 1HvxCO-0006iL-9k for tsvwg-confirm+ok@megatron.ietf.org; Wed, 06 Jun 2007 11:13:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvxCO-0006iD-04 for tsvwg@ietf.org; Wed, 06 Jun 2007 11:13:24 -0400 Received: from smtp1.xmundo.net ([201.216.232.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvxCM-0005Au-Ki for tsvwg@ietf.org; Wed, 06 Jun 2007 11:13:23 -0400 Received: from venus.xmundo.net (venus.xmundo.net [201.216.232.56]) by smtp1.xmundo.net (Postfix) with ESMTP id 634D3F0C496; Wed, 6 Jun 2007 12:13:23 -0300 (ART) Received: from fgont.gont.com.ar (line40.comsat.net.ar [200.47.78.40] (may be forged)) (authenticated bits=0) by venus.xmundo.net (8.13.8/8.13.8) with ESMTP id l56FCjQF032358; Wed, 6 Jun 2007 12:13:19 -0300 Message-Id: <7.0.1.0.0.20070606080948.0436b288@gont.com.ar> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Wed, 06 Jun 2007 10:08:58 -0300 To: "Dan Wing" , "'Lars Eggert'" From: Fernando Gont Subject: RE: [Tsvwg] Re: [tcpm] Revision of draft-larsen-tsvwg-port-randomization In-Reply-To: <0a3a01c7a49d$9670bce0$10676b80@amer.cisco.com> References: <0E46EBE9-1C13-44B6-9C04-476D418F5A6D@nokia.com> <0a3a01c7a49d$9670bce0$10676b80@amer.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (venus.xmundo.net [201.216.232.56]); Wed, 06 Jun 2007 12:13:23 -0300 (ART) X-Spam-Score: 0.1 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: 'tsvwg WG' X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tsvwg-bounces@ietf.org At 19:38 01/06/2007, Dan Wing wrote: > > The concepts in this draft are likely relevant to most of our > > transport protocols, and hence would be in scope for TSVWG. > > The TSVWG > > chairs are interested in comments on whether there is group interest > > in this draft - please comment on tsvwg@ietf.org. > >The suggestions in this document are equally important for RTP >so that attackers are forced to work harder to inject undesired >content into RTP media sessions. It would be useful if the >document scope were expanded slightly to explicitly include RTP. [....] Will do. >Even without this change, I support adopting this document as a TSVWG item. Thanks so much! Kindest regards, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From tsvwg-bounces@ietf.org Wed Jun 06 17:51:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hw3PL-0008Tc-3y; Wed, 06 Jun 2007 17:51:11 -0400 Received: from tsvwg by megatron.ietf.org with local (Exim 4.43) id 1Hw3PJ-0008TW-Tz for tsvwg-confirm+ok@megatron.ietf.org; Wed, 06 Jun 2007 17:51:09 -0400 Received: from tsvwg by megatron.ietf.org with local (Exim 4.43) id 1Hw3PJ-0008TO-Ki for tsvwg@ietf.org; Wed, 06 Jun 2007 17:51:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hw3OW-0008Ok-45 for tsvwg@ietf.org; Wed, 06 Jun 2007 17:50:20 -0400 Received: from ug-out-1314.google.com ([66.249.92.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hw3OU-0003rf-Ru for tsvwg@ietf.org; Wed, 06 Jun 2007 17:50:20 -0400 Received: by ug-out-1314.google.com with SMTP id j30so1426397ugc for ; Wed, 06 Jun 2007 14:50:18 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type; b=DEGUOA0wwOF11pDE0i0+OdB4OlonL27Ml99g06KFxRX+whoUxwQQ9mex/DqHxoL8H2Ns00fbNASoDrR+b/jFIRWcYTJ3vs4dGvGygtCx67XKbFbETq7obIPWBoW0lpbFISrC46TySa7XTp71ycHH1qGABYBC3m2rYl7yh1ETWfc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type; b=SGGWhZIZ3uL+zGtGS6kMEO70J0NV65RkuWzth//eCsz9R5yfqMjL2Ax6g+20Q+5nqSbwxsKF/jbMEKlMxJwjsZCdgUMkoGljcojLFMZbS+XA+qFhg7Ly/oDwCPHizu6bbS4oYyr37+qPnpuLF8Zo3Xm63PNVz2smVlQH6zfS6Ew= Received: by 10.67.27.15 with SMTP id e15mr1517661ugj.1181166617710; Wed, 06 Jun 2007 14:50:17 -0700 (PDT) Received: by 10.66.234.10 with HTTP; Wed, 6 Jun 2007 14:50:17 -0700 (PDT) Message-ID: Date: Wed, 6 Jun 2007 22:50:17 +0100 From: "arif khan" To: tsvwg@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_9050_13624309.1181166617581" X-Spam-Score: 0.5 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 X-TMDA-Confirmed: Wed, 06 Jun 2007 17:51:09 -0400 Subject: [Tsvwg] sctp abort during high traffic load exchange X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tsvwg-bounces@ietf.org ------=_Part_9050_13624309.1181166617581 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline hi, we have around 135 multihomed assoc. and all are exchanging traffic (traffic rate is high) in the mean time server sctp endpoints send abort to the client sctp. ethereal dump ecode of cause 4. how could we check reason of abort? could you suggest how we can verify it over single assoc with changing the rto,rtt,max path retrans or hb interval value. tia -arif ------=_Part_9050_13624309.1181166617581 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
hi,
 
we have around 135 multihomed assoc. and all are exchanging traffic (traffic rate is high) in the mean time server sctp endpoints send abort to the client sctp.
ethereal dump ecode of cause 4.
 
how could we check reason of abort?
could you suggest how we can verify it over single assoc with changing the rto,rtt,max path retrans or hb interval value.
 
tia
-arif
------=_Part_9050_13624309.1181166617581-- From tsvwg-bounces@ietf.org Wed Jun 06 18:27:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hw3yL-0003O7-5b; Wed, 06 Jun 2007 18:27:21 -0400 Received: from tsvwg by megatron.ietf.org with local (Exim 4.43) id 1Hw3yK-0003O2-HW for tsvwg-confirm+ok@megatron.ietf.org; Wed, 06 Jun 2007 18:27:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hw3yK-0003Nu-83 for tsvwg@ietf.org; Wed, 06 Jun 2007 18:27:20 -0400 Received: from drew.ipv6.franken.de ([2001:638:a02:a001:20e:cff:fe4a:feaa] helo=mail-n.franken.de) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hw3yI-0002Ea-P8 for tsvwg@ietf.org; Wed, 06 Jun 2007 18:27:20 -0400 Received: from [192.168.1.2] (p508FD6B9.dip.t-dialin.net [80.143.214.185]) by mail-n.franken.de (Postfix) with ESMTP id 3BAE58000095; Thu, 7 Jun 2007 00:27:17 +0200 (CEST) (KNF-authenticated sender: macmic) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <9BA320DB-9618-483A-9F69-69FCA50392E2@lurchi.franken.de> Content-Transfer-Encoding: 7bit From: Michael Tuexen Subject: Re: [Tsvwg] sctp abort during high traffic load exchange Date: Thu, 7 Jun 2007 00:27:22 +0200 To: arif khan X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 4.3 (++++) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: tsvwg@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tsvwg-bounces@ietf.org Hi Arif, a look at the source code of the SCTP dissector tells me #define OUT_OF_RESOURCE 0x04 so I guess you are running out of resources. Which SCTP implementation are you using? Best regards Michael On Jun 6, 2007, at 11:50 PM, arif khan wrote: > hi, > > we have around 135 multihomed assoc. and all are exchanging traffic > (traffic rate is high) in the mean time server sctp endpoints send > abort to the client sctp. > ethereal dump ecode of cause 4. > > how could we check reason of abort? > could you suggest how we can verify it over single assoc with > changing the rto,rtt,max path retrans or hb interval value. > > tia > -arif From tsvwg-bounces@ietf.org Wed Jun 06 18:43:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hw4E9-0001wn-UO; Wed, 06 Jun 2007 18:43:41 -0400 Received: from tsvwg by megatron.ietf.org with local (Exim 4.43) id 1Hw4E9-0001wi-03 for tsvwg-confirm+ok@megatron.ietf.org; Wed, 06 Jun 2007 18:43:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hw4E8-0001wa-Mn for tsvwg@ietf.org; Wed, 06 Jun 2007 18:43:40 -0400 Received: from drew.ipv6.franken.de ([2001:638:a02:a001:20e:cff:fe4a:feaa] helo=mail-n.franken.de) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hw4E8-0005o7-6A for tsvwg@ietf.org; Wed, 06 Jun 2007 18:43:40 -0400 Received: from [192.168.1.2] (p508FD6B9.dip.t-dialin.net [80.143.214.185]) by mail-n.franken.de (Postfix) with ESMTP id 3727E8000094; Thu, 7 Jun 2007 00:43:39 +0200 (CEST) (KNF-authenticated sender: macmic) In-Reply-To: <66E8AEE9980BB44CA5FCAD39EBA56AC6017D4412@CHN-HCLT-EVS02.HCLT.CORP.HCL.IN> References: <66E8AEE9980BB44CA5FCAD39EBA56AC6017D4412@CHN-HCLT-EVS02.HCLT.CORP.HCL.IN> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <3CD3390C-5DFF-4549-8827-5CC88BDE0BC5@lurchi.franken.de> Content-Transfer-Encoding: 7bit From: Michael Tuexen Subject: Re: [Tsvwg] Clarification on sctp library. Date: Thu, 7 Jun 2007 00:43:44 +0200 To: "Balamurugan T, TLS-Chennai" X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 4.3 (++++) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: tsvwg@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tsvwg-bounces@ietf.org Hi Bala, question regarding the Linux SCTP implementation should be sent to lksctp-developers@lists.sourceforge.net Regarding you questions you might want to open an sctp socket, put it into non blocking mode via a fnctl call and call sctp_connectx(). Please note that the function has recently be extended to provide the assoc_id via a result parameter. This has been implemented in the FreeBSD/MacOS X implementation, but not yet in the Linux one. Best regards Michael On Jun 6, 2007, at 9:20 AM, Balamurugan T, TLS-Chennai wrote: > Hi All, > > I am new to sctp protocol and need the below clarifications. I > have installed lksctp-tools-1.0.6 on Suse linux. > > 1. How to get the association id for a successful connection.? > 2. Is there any system call available to set a sctp socket as > NON_blocking. > 3. Is it possible to call sctp_connectx from a 1-to-1 sctp > socket (sctp client ) to 1-to-N socket (sctp server). > 4. How to set non-blocking on sctp server socket. > > Thanks in Advance, > Bala > > > > > > DISCLAIMER: > ---------------------------------------------------------------------- > ------------------------------------------------- > > The contents of this e-mail and any attachment(s) are confidential > and intended for the named recipient(s) only. > It shall not attach any liability on the originator or HCL or its > affiliates. Any views or opinions presented in > this email are solely those of the author and may not necessarily > reflect the opinions of HCL or its affiliates. > Any form of reproduction, dissemination, copying, disclosure, > modification, distribution and / or publication of > this message without the prior written consent of the author of > this e-mail is strictly prohibited. If you have > received this email in error please delete it and notify the sender > immediately. Before opening any mail and > attachments please check them for viruses and defect. > > ---------------------------------------------------------------------- > ------------------------------------------------- From tsvwg-bounces@ietf.org Thu Jun 07 01:28:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwAXT-0000Vl-DU; Thu, 07 Jun 2007 01:28:03 -0400 Received: from tsvwg by megatron.ietf.org with local (Exim 4.43) id 1HwAXR-0000O7-Kh for tsvwg-confirm+ok@megatron.ietf.org; Thu, 07 Jun 2007 01:28:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwAXO-0000Lo-5n for tsvwg@ietf.org; Thu, 07 Jun 2007 01:27:59 -0400 Received: from bgerelbas02.asiapac.hp.net ([15.219.201.135]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HwAXH-0008Un-PI for tsvwg@ietf.org; Thu, 07 Jun 2007 01:27:58 -0400 Received: from bgeexg12.asiapacific.cpqcorp.net (bgeexg12.asiapacific.cpqcorp.net [16.150.33.53]) by bgerelbas02.asiapac.hp.net (Postfix) with ESMTP id 3321B33084; Thu, 7 Jun 2007 10:57:49 +0530 (IST) Received: from bgeexc04.asiapacific.cpqcorp.net ([16.150.33.49]) by bgeexg12.asiapacific.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 7 Jun 2007 10:57:48 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7A8C4.95A588BF" Subject: RE: [Tsvwg] sctp abort during high traffic load exchange Date: Thu, 7 Jun 2007 10:57:47 +0530 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Tsvwg] sctp abort during high traffic load exchange thread-index: AceohNUqQsKKjqQcTtiVdwkojr47AgAPs4Sw From: "Nemana, Satya Prasad (STSD)" To: "arif khan" , X-OriginalArrivalTime: 07 Jun 2007 05:27:48.0699 (UTC) FILETIME=[96000AB0:01C7A8C4] X-Spam-Score: 0.0 (/) X-Scan-Signature: 73948e4d005645343fd08e813e5615ef Cc: X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tsvwg-bounces@ietf.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C7A8C4.95A588BF Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Arif =20 I guess there are lot of considerations for this. It will be better if you can elaborate on the following =20 1. When you say high traffic rate, what do you mean? 2. Are you observing the CPU usage on the system? You may be out of resources. 3. Ethereal GUI can take significant CPU almost 25%.. try the same without the ethereal GUI Even if you are using Command line capture also. Since it is "high traffic" the logging may take a lot of CPU Also check you don't have traces enabled on any of your programs. :-) 4. Every system defines its own restrictions for the max number of associations . please check your system's considerations. =20 Hope this initial tips help. =20 Regards, Satya Prasad =20 =20 ________________________________ From: arif khan [mailto:arif15jan@gmail.com]=20 Sent: Thursday, June 07, 2007 3:20 AM To: tsvwg@ietf.org Subject: [Tsvwg] sctp abort during high traffic load exchange =20 hi, =20 we have around 135 multihomed assoc. and all are exchanging traffic (traffic rate is high) in the mean time server sctp endpoints send abort to the client sctp. ethereal dump ecode of cause 4. =20 how could we check reason of abort? could you suggest how we can verify it over single assoc with changing the rto,rtt,max path retrans or hb interval value. =20 tia -arif ------_=_NextPart_001_01C7A8C4.95A588BF Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi = Arif

 

I guess there are lot of = considerations for this. It will be better if you can elaborate on the = following

 

  1. When you say high traffic rate, what do you = mean?
  2. Are you observing the CPU usage on the = system?

You may be out of resources.

  1. Ethereal GUI can take significant CPU almost 25%.. try the same without the ethereal GUI

Even if you are using Command line capture also. Since it is “high = traffic” the logging may take a lot of CPU

Also check you don’t have traces enabled on any of your programs. = J

  1. Every system defines its own restrictions for the max number of = associations . please check your system’s = considerations.

 

Hope this initial tips = help.

 

Regards,<= /p>

Satya = Prasad

 

 

From: arif = khan [mailto:arif15jan@gmail.com]
Sent: Thursday, June 07, = 2007 3:20 AM
To: tsvwg@ietf.org
Subject: [Tsvwg] sctp = abort during high traffic load exchange

 

hi,

 

we have around 135 multihomed assoc. and all are exchanging = traffic (traffic rate is high) in the mean time server sctp endpoints send abort = to the client sctp.

ethereal dump ecode of cause 4.

 

how could we check reason of abort?

could you suggest how we can verify it over single assoc with = changing the rto,rtt,max path retrans or hb interval = value.

 

tia

-arif

------_=_NextPart_001_01C7A8C4.95A588BF-- From tsvwg-bounces@ietf.org Thu Jun 07 06:58:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwFh6-0001O8-SV; Thu, 07 Jun 2007 06:58:20 -0400 Received: from tsvwg by megatron.ietf.org with local (Exim 4.43) id 1HwFh4-0001JV-4h for tsvwg-confirm+ok@megatron.ietf.org; Thu, 07 Jun 2007 06:58:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwFh3-0001JI-PC for tsvwg@ietf.org; Thu, 07 Jun 2007 06:58:17 -0400 Received: from smtp2.smtp.bt.com ([217.32.164.150]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HwFh1-0006yR-9Z for tsvwg@ietf.org; Thu, 07 Jun 2007 06:58:17 -0400 Received: from i2kc06-ukbr.domain1.systemhost.net ([193.113.197.70]) by smtp2.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 7 Jun 2007 11:58:14 +0100 Received: from cbibipnt05.iuser.iroot.adidom.com ([147.149.196.177]) by i2kc06-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 7 Jun 2007 11:58:13 +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 1181213892637; Thu, 7 Jun 2007 11:58:12 +0100 Received: from mut.jungle.bt.co.uk ([10.86.0.47]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id l57Aw63i011973; Thu, 7 Jun 2007 11:58:09 +0100 Message-Id: <5.2.1.1.2.20070607110607.0525c8e0@pop3.jungle.bt.co.uk> X-Sender: rbriscoe@pop3.jungle.bt.co.uk X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Thu, 07 Jun 2007 11:58:10 +0100 To: "tsvwg IETF list" , "iccrg IRTF list" , "arch-d list" , "DCCP IETF list" , "tsv-area IETF list" , "e2e IRTF list" , "eme IRTF list" From: Bob Briscoe Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: -3.77 () ALL_TRUSTED,AWL,BAYES_00 X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 X-OriginalArrivalTime: 07 Jun 2007 10:58:13.0878 (UTC) FILETIME=[BEBA4960:01C7A8F2] X-Spam-Score: 0.1 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: Subject: [Tsvwg] Invitation to join new unofficial IETF mailing list: re-ECN X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tsvwg-bounces@ietf.org Folks, You are invited to subscribe to a new unofficial IETF mailing list on re-ECN via Re-ECN is proposed as an extension to explicit congestion notification (ECN) intended to enable enforcement of fairness for congestion control & QoS including mitigation of DDoS and prevention of cheating between both networks & users. Why has this list been created?: At the last IETF in Prague, about 30-40 people got together at an unofficial BoF (Birds of a Feather) to hear about the architectural intent of re-ECN and to discuss how to move forward. It was decided to take an ad hoc approach initially, somewhat along the lines of how HIP got started. If a community hangs together around this work, then it may form an IRTF or IETF working group. The room was unanimous that re-ECN addresses a problem that is interesting, and about 75% were interested in using it, if it was implemented. Half a dozen people expressed interest in implementing the protocol. Full notes, transcript & slides as well as background papers are at: If interested in discussion of design and implementation of the re-ECN protocol, pls subscribe via the link at the start. --------------------------------------------------------------------------- Re-ECN is not an official working group of the IETF or IRTF. But the IETF has agreed to host the list to create a community around this work who may wish to bring it forward for standardisation. As such, if you subscribe, you will be asked to note well the normal IETF rules. This invitation will only be sent to relevant lists once. But apologies if you are on more than one of these lists. Cheers Bob ____________________________________________________________________________ Bob Briscoe, Networks Research Centre, BT Research B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK. +44 1473 645196 From tsvwg-bounces@ietf.org Thu Jun 07 10:19:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwIpG-0006ep-0G; Thu, 07 Jun 2007 10:18:58 -0400 Received: from tsvwg by megatron.ietf.org with local (Exim 4.43) id 1HwIpD-0006bA-Km for tsvwg-confirm+ok@megatron.ietf.org; Thu, 07 Jun 2007 10:18:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwIpD-0006b2-AN for tsvwg@ietf.org; Thu, 07 Jun 2007 10:18:55 -0400 Received: from alnrmhc14.comcast.net ([206.18.177.54]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HwIpC-0004Th-1E for tsvwg@ietf.org; Thu, 07 Jun 2007 10:18:55 -0400 Received: from ajw.com ([24.128.2.183]) by comcast.net (alnrmhc14) with SMTP id <20070607141853b14005ffghe>; Thu, 7 Jun 2007 14:18:53 +0000 Received: from vm-ajw-VCdev.valid8.local ([66.152.245.235]) by ajw.com with hMailServer ; Thu, 7 Jun 2007 10:18:52 -0400 From: Alan Jay Weiner To: "arif khan" Subject: Re: [Tsvwg] sctp abort during high traffic load exchange Date: Thu, 07 Jun 2007 10:18:55 -0400 Organization: Valid8.com Message-ID: References: In-Reply-To: X-Mailer: Forte Agent 4.2/32.1118 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Sender: a.weiner@valid8.com X-Spam-Score: 4.6 (++++) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: tsvwg@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: a.weiner@valid8.com List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tsvwg-bounces@ietf.org Error code 4 is "out of resources" I'd presume that it's caused by whatever has been sent to that endpoint just prior to the abort, or shortly before. Looking at the traces, does that give you any clue as to the cause of the abort? Is the T bit set? if not, are you trying to set up another association? - Al Weiner - (not an SCTP guru, but getting there... :) -- original message -- >hi, > >we have around 135 multihomed assoc. and all are exchanging traffic (traffic >rate is high) in the mean time server sctp endpoints send abort to the >client sctp. >ethereal dump ecode of cause 4. > >how could we check reason of abort? >could you suggest how we can verify it over single assoc with changing the >rto,rtt,max path retrans or hb interval value. > >tia >-arif ---------------------------------------------------------------------------- Alan Jay Weiner / Valid8.com, Inc. - Conform, Perform & Excel(tm) 500 W Cummings Park, Suite #2700, Woburn, MA 01801, USA a.weiner@valid8.com / Tel:+1-781-938-1221 x112, Fax +1-781-207-0550 http://www.VALID8.com From tsvwg-bounces@ietf.org Fri Jun 08 04:34:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwZv9-00074h-Vk; Fri, 08 Jun 2007 04:34:11 -0400 Received: from tsvwg by megatron.ietf.org with local (Exim 4.43) id 1HwZv8-0006xN-5F for tsvwg-confirm+ok@megatron.ietf.org; Fri, 08 Jun 2007 04:34:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwZu1-00062x-43 for tsvwg@ietf.org; Fri, 08 Jun 2007 04:33:01 -0400 Received: from smtp1.xmundo.net ([201.216.232.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HwZt5-0008PD-0a for tsvwg@ietf.org; Fri, 08 Jun 2007 04:32:04 -0400 Received: from venus.xmundo.net (venus.xmundo.net [201.216.232.56]) by smtp1.xmundo.net (Postfix) with ESMTP id 5A26AF0C411 for ; Fri, 8 Jun 2007 05:32:01 -0300 (ART) Received: from fgont.gont.com.ar (237-176-231-201.fibertel.com.ar [201.231.176.237]) (authenticated bits=0) by venus.xmundo.net (8.13.8/8.13.8) with ESMTP id l588Vxl2014359 for ; Fri, 8 Jun 2007 05:32:00 -0300 Message-Id: <200706080832.l588Vxl2014359@venus.xmundo.net> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 08 Jun 2007 05:31:01 -0300 To: tsvwg@ietf.org From: Fernando Gont Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (venus.xmundo.net [201.216.232.56]); Fri, 08 Jun 2007 05:32:00 -0300 (ART) X-Spam-Score: 0.1 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Subject: [Tsvwg] Alfred Hoenes: Fwd: draft-larsen-tsvwg-port-randomization X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tsvwg-bounces@ietf.org >From: Alfred =3D?hp-roman8?B?SM5uZXM=3D?=3D >Subject: draft-larsen-tsvwg-port-randomization >To: tcpm@ietf.org >Date: Fri, 8 Jun 2007 10:01:33 +0200 (MESZ) >X-Mailer: ELM [$Revision: 1.17.214.3 $] >X-Greylist: Delayed for 00:26:52 by=20 >milter-greylist-2.0.2 (venus.xmundo.net=20 >[201.216.232.56]); Fri, 08 Jun 2007 05:01:53 -0300 (ART) > >Hello all, > >On Thu, 31 May 2007, Lars Eggert wrote: > > The concepts in this draft are likely relevant to most of our > > transport protocols, and hence would be in scope for TSVWG. > > The TSVWG chairs are interested in comments on whether there is > > group interest in this draft - please comment on tsvwg@ietf.org. > > > > Lars > >As a sporadic reader of the group list, I already have performed >detailed reviews of the -00 submission and the -01 revision. > >The draft presents an important building block in 'hardening' >transport protocols agains a certain class of attacks; it reports >on, and evaluates, existing implementation practice for the >randomization of ephemeral (client side) transport protocol >multiplexing selectors (port numbers), and it proposes advanced >algorithmic variants, weighing the computational effort and >resources needed. > >The topic is well known in the security business since quite >long a time, but it has not been documented in any precise way >conforming to the IETF quality standards. There are already >a couple of other I-Ds and public security recommendations >quoting this draft as a reference. > >Besides all the intrinsic reasons to optimize implementation >practice in the 'hostile' Internet environment, there's one >important reason why this documentation should be done within, >and with the consensus of, the IETF: to make future standards >developers aware of widespread useful practice that should be >considered in future work, at least to avoid the creation of >new normative clauses making these practices nonconformant. > >I strongly recommend to advance that draft -- and the best way >to do that is to endorse it on the wg agenda. > >Kind regards, > Alfred H=CEnes. > >-- > >+------------------------+--------------------------------------------+ >| TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. | >| Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 | >| D-71254 Ditzingen | E-Mail: ah@TR-Sys.de | >+------------------------+--------------------------------------------+ --=20 Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From tsvwg-bounces@ietf.org Sat Jun 09 06:04:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hwxo0-0005i5-G3; Sat, 09 Jun 2007 06:04:24 -0400 Received: from tsvwg by megatron.ietf.org with local (Exim 4.43) id 1HwZWi-00060r-VZ for tsvwg-confirm+ok@megatron.ietf.org; Fri, 08 Jun 2007 04:08:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwZWi-00060M-BO for tsvwg@ietf.org; Fri, 08 Jun 2007 04:08:56 -0400 Received: from dsl.tr-sys.de ([213.178.172.147] helo=WOTAN.TR-Sys.de) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HwZSy-0004nG-B5 for tsvwg@ietf.org; Fri, 08 Jun 2007 04:05:05 -0400 Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3) id AA237989892; Fri, 8 Jun 2007 10:04:52 +0200 Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id KAA17855 for tsvwg@ietf.org; Fri, 8 Jun 2007 10:04:51 +0200 (MESZ) From: Alfred =?hp-roman8?B?SM5uZXM=?= Message-Id: <200706080804.KAA17855@TR-Sys.de> To: tsvwg@ietf.org Date: Fri, 8 Jun 2007 10:04:51 +0200 (MESZ) X-Mailer: ELM [$Revision: 1.17.214.3 $] Mime-Version: 1.0 Content-Type: text/plain; charset=hp-roman8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 X-Mailman-Approved-At: Sat, 09 Jun 2007 06:04:23 -0400 Subject: [Tsvwg] draft-larsen-tsvwg-port-randomization X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tsvwg-bounces@ietf.org Hello all, On Thu, 31 May 2007, Lars Eggert wrote: > The concepts in this draft are likely relevant to most of our > transport protocols, and hence would be in scope for TSVWG. > The TSVWG chairs are interested in comments on whether there is > group interest in this draft - please comment on tsvwg@ietf.org. > > Lars As a sporadic reader of the group list, I already have performed detailed reviews of the -00 submission and the -01 revision. The draft presents an important building block in 'hardening' transport protocols agains a certain class of attacks; it reports on, and evaluates, existing implementation practice for the randomization of ephemeral (client side) transport protocol multiplexing selectors (port numbers), and it proposes advanced algorithmic variants, weighing the computational effort and resources needed. The topic is well known in the security business since quite long a time, but it has not been documented in any precise way conforming to the IETF quality standards. There are already a couple of other I-Ds and public security recommendations quoting this draft as a reference. Besides all the intrinsic reasons to optimize implementation practice in the 'hostile' Internet environment, there's one important reason why this documentation should be done within, and with the consensus of, the IETF: to make future standards developers aware of widespread useful practice that should be considered in future work, at least to avoid the creation of new normative clauses making these practices nonconformant. I strongly recommend to advance that draft -- and the best way to do that is to endorse it on the wg agenda. Kind regards, Alfred H=CEnes. -- = +------------------------+--------------------------------------------+ | TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. | | Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 | | D-71254 Ditzingen | E-Mail: ah@TR-Sys.de | +------------------------+-------------------------------------------From tsvwg-bounces@ietf.org Sat Jun 09 06:04:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hwxo0-0005i5-G3; Sat, 09 Jun 2007 06:04:24 -0400 Received: from tsvwg by megatron.ietf.org with local (Exim 4.43) id 1HwZWi-00060r-VZ for tsvwg-confirm+ok@megatron.ietf.org; Fri, 08 Jun 2007 04:08:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwZWi-00060M-BO for tsvwg@ietf.org; Fri, 08 Jun 2007 04:08:56 -0400 Received: from dsl.tr-sys.de ([213.178.172.147] helo=WOTAN.TR-Sys.de) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HwZSy-0004nG-B5 for tsvwg@ietf.org; Fri, 08 Jun 2007 04:05:05 -0400 Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3) id AA237989892; Fri, 8 Jun 2007 10:04:52 +0200 Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id KAA17855 for tsvwg@ietf.org; Fri, 8 Jun 2007 10:04:51 +0200 (MESZ) From: Alfred =?hp-roman8?B?SM5uZXM=?= Message-Id: <200706080804.KAA17855@TR-Sys.de> To: tsvwg@ietf.org Date: Fri, 8 Jun 2007 10:04:51 +0200 (MESZ) X-Mailer: ELM [$Revision: 1.17.214.3 $] Mime-Version: 1.0 Content-Type: text/plain; charset=hp-roman8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 X-Mailman-Approved-At: Sat, 09 Jun 2007 06:04:23 -0400 Subject: [Tsvwg] draft-larsen-tsvwg-port-randomization X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tsvwg-bounces@ietf.org Hello all, On Thu, 31 May 2007, Lars Eggert wrote: > The concepts in this draft are likely relevant to most of our > transport protocols, and hence would be in scope for TSVWG. > The TSVWG chairs are interested in comments on whether there is > group interest in this draft - please comment on tsvwg@ietf.org. > > Lars As a sporadic reader of the group list, I already have performed detailed reviews of the -00 submission and the -01 revision. The draft presents an important building block in 'hardening' transport protocols agains a certain class of attacks; it reports on, and evaluates, existing implementation practice for the randomization of ephemeral (client side) transport protocol multiplexing selectors (port numbers), and it proposes advanced algorithmic variants, weighing the computational effort and resources needed. The topic is well known in the security business since quite long a time, but it has not been documented in any precise way conforming to the IETF quality standards. There are already a couple of other I-Ds and public security recommendations quoting this draft as a reference. Besides all the intrinsic reasons to optimize implementation practice in the 'hostile' Internet environment, there's one important reason why this documentation should be done within, and with the consensus of, the IETF: to make future standards developers aware of widespread useful practice that should be considered in future work, at least to avoid the creation of new normative clauses making these practices nonconformant. I strongly recommend to advance that draft -- and the best way to do that is to endorse it on the wg agenda. Kind regards, Alfred H=CEnes. -- = +------------------------+--------------------------------------------+ | TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. | | Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 | | D-71254 Ditzingen | E-Mail: ah@TR-Sys.de | +------------------------+--------------------------------------------+ From tsvwg-bounces@ietf.org Sat Jun 09 06:04:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hwxo0-0005hx-89; Sat, 09 Jun 2007 06:04:24 -0400 Received: from tsvwg by megatron.ietf.org with local (Exim 4.43) id 1HwN4c-00060k-7L for tsvwg-confirm+ok@megatron.ietf.org; Thu, 07 Jun 2007 14:51:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwN4b-0005zA-Sv for tsvwg@ietf.org; Thu, 07 Jun 2007 14:51:05 -0400 Received: from smtp2.linux-foundation.org ([207.189.120.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HwN4Z-0006CY-FL for tsvwg@ietf.org; Thu, 07 Jun 2007 14:51:05 -0400 Received: from localhost.localdomain (069-064-229-129.pdx.net [69.64.229.129]) (authenticated bits=0) by smtp2.linux-foundation.org (8.13.5.20060308/8.13.5/Debian-3ubuntu1.1) with ESMTP id l57Iop8c032648 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 7 Jun 2007 11:50:53 -0700 Date: Thu, 7 Jun 2007 11:47:19 -0700 From: Stephen Hemminger To: Michael Vittrup Larsen , Fernando Gont Message-ID: <20070607114719.6854c9c0@localhost.localdomain> Organization: Linux Foundation X-Mailer: Claws Mail 2.9.2 (GTK+ 2.10.11; x86_64-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-3.151 required=5 tests=AWL,BAYES_00 X-Spam-Checker-Version: SpamAssassin 3.1.0-osdl_revision__1.12__ X-MIMEDefang-Filter: osdl$Revision: 1.180 $ X-Scanned-By: MIMEDefang 2.53 on 207.189.120.14 X-Spam-Score: 0.1 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 X-Mailman-Approved-At: Sat, 09 Jun 2007 06:04:23 -0400 Cc: tsvwg@ietf.org Subject: [Tsvwg] comments on draft-larsen-tsvwg-port-randomization-01 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tsvwg-bounces@ietf.org The document covers the existing port selection algorithms chosen by current Linux kernel. The implementation of these was not difficult and the developers have not received any reports of application problems as a result of the change from linear selection (Algorithm 1) to random selection based on address (Algorithm 3). You could add a note to the Linux section, that various 'security enhancement' packages exist that add port randomization (Algorithm 2). Probably the most common was Grsecurity: http://www.grsecurity.net/ One nit: Linux is not usually referred to as the "Linux Project" and certain individuals (RMS) get upset about using Linux as general term. Therefore I recommend listing the reference [Linux] as: [Linux] Linux Kernel, "http://www.kernel.org". -- Stephen Hemminger -+ From tsvwg-bounces@ietf.org Sat Jun 09 06:04:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hwxo0-0005hx-89; Sat, 09 Jun 2007 06:04:24 -0400 Received: from tsvwg by megatron.ietf.org with local (Exim 4.43) id 1HwN4c-00060k-7L for tsvwg-confirm+ok@megatron.ietf.org; Thu, 07 Jun 2007 14:51:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwN4b-0005zA-Sv for tsvwg@ietf.org; Thu, 07 Jun 2007 14:51:05 -0400 Received: from smtp2.linux-foundation.org ([207.189.120.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HwN4Z-0006CY-FL for tsvwg@ietf.org; Thu, 07 Jun 2007 14:51:05 -0400 Received: from localhost.localdomain (069-064-229-129.pdx.net [69.64.229.129]) (authenticated bits=0) by smtp2.linux-foundation.org (8.13.5.20060308/8.13.5/Debian-3ubuntu1.1) with ESMTP id l57Iop8c032648 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 7 Jun 2007 11:50:53 -0700 Date: Thu, 7 Jun 2007 11:47:19 -0700 From: Stephen Hemminger To: Michael Vittrup Larsen , Fernando Gont Message-ID: <20070607114719.6854c9c0@localhost.localdomain> Organization: Linux Foundation X-Mailer: Claws Mail 2.9.2 (GTK+ 2.10.11; x86_64-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-3.151 required=5 tests=AWL,BAYES_00 X-Spam-Checker-Version: SpamAssassin 3.1.0-osdl_revision__1.12__ X-MIMEDefang-Filter: osdl$Revision: 1.180 $ X-Scanned-By: MIMEDefang 2.53 on 207.189.120.14 X-Spam-Score: 0.1 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 X-Mailman-Approved-At: Sat, 09 Jun 2007 06:04:23 -0400 Cc: tsvwg@ietf.org Subject: [Tsvwg] comments on draft-larsen-tsvwg-port-randomization-01 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tsvwg-bounces@ietf.org The document covers the existing port selection algorithms chosen by current Linux kernel. The implementation of these was not difficult and the developers have not received any reports of application problems as a result of the change from linear selection (Algorithm 1) to random selection based on address (Algorithm 3). You could add a note to the Linux section, that various 'security enhancement' packages exist that add port randomization (Algorithm 2). Probably the most common was Grsecurity: http://www.grsecurity.net/ One nit: Linux is not usually referred to as the "Linux Project" and certain individuals (RMS) get upset about using Linux as general term. Therefore I recommend listing the reference [Linux] as: [Linux] Linux Kernel, "http://www.kernel.org". -- Stephen Hemminger From tsvwg-bounces@ietf.org Sun Jun 10 05:58:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HxKBn-00022c-9C; Sun, 10 Jun 2007 05:58:27 -0400 Received: from tsvwg by megatron.ietf.org with local (Exim 4.43) id 1HxKBl-00022G-Sg for tsvwg-confirm+ok@megatron.ietf.org; Sun, 10 Jun 2007 05:58:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HxKBi-00021N-Dn; Sun, 10 Jun 2007 05:58:22 -0400 Received: from drew.ipv6.franken.de ([2001:638:a02:a001:20e:cff:fe4a:feaa] helo=mail-n.franken.de) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HxKBf-0005kV-3E; Sun, 10 Jun 2007 05:58:22 -0400 Received: from [192.168.1.3] (p5481DA78.dip.t-dialin.net [84.129.218.120]) by mail-n.franken.de (Postfix) with ESMTP id 5E2358006DAA; Sun, 10 Jun 2007 11:58:17 +0200 (CEST) (KNF-authenticated sender: macmic) Mime-Version: 1.0 (Apple Message framework v752.3) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed To: TSWG , SIGTRAN From: Michael Tuexen Date: Sun, 10 Jun 2007 11:58:25 +0200 X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 1.8 (+) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: Subject: [Tsvwg] Registration now open for 9th SCTP Interop X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tsvwg-bounces@ietf.org Dear all, you can now register for the 9th SCTP Interop held Aug 19-25, 2007, at Kyoto University, Japan. More information is available at http://www.interop.sctp.jp/ Please note that this is also the second RSerPool Interop. If you have further questions do not hesitate to contact us using rrs@cisco.com or tuexen@fh-muenster.de Best regards Randall Stewart and Michael Tuexen From tsvwg-bounces@ietf.org Sun Jun 10 08:03:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HxM8m-000693-Ea; Sun, 10 Jun 2007 08:03:28 -0400 Received: from tsvwg by megatron.ietf.org with local (Exim 4.43) id 1HxM8l-00068y-Vb for tsvwg-confirm+ok@megatron.ietf.org; Sun, 10 Jun 2007 08:03:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HxM8l-00068q-M3 for tsvwg@ietf.org; Sun, 10 Jun 2007 08:03:27 -0400 Received: from [2001:240:585:2:203:6dff:fe1a:4ddc] (helo=lakerest.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HxM8k-0007nv-3z for tsvwg@ietf.org; Sun, 10 Jun 2007 08:03:27 -0400 Received: from [10.1.1.11] (ibmlap [10.1.1.11]) by lakerest.net (8.14.1/8.13.8) with ESMTP id l5AC343j004306; Sun, 10 Jun 2007 08:03:05 -0400 (EDT) (envelope-from randall@lakerest.net) Message-ID: <466BE8EE.1020904@lakerest.net> Date: Sun, 10 Jun 2007 08:05:02 -0400 From: Randall Stewart User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.13) Gecko/20070601 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ash kat Subject: Re: [Tsvwg] Re: [Sigtran] SACK from a multihomed endpoint. References: <752428.76026.qm@web37401.mail.mud.yahoo.com> In-Reply-To: <752428.76026.qm@web37401.mail.mud.yahoo.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by lakerest.net id l5AC343j004306 X-Spam-Score: -2.8 (--) X-Scan-Signature: bd8a74b81c71f965ca7918b90d1c49c0 Cc: Salil Agrawal , Michael Tuexen , tsvwg@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tsvwg-bounces@ietf.org Ash: From the BIS: (section 6.4) However, when acknowledging multiple DATA chunks received in packets from different source addresses in a single SACK, the SACK chunk may be transmitted to one of the destination transport addresses from which the DATA or control chunks being acknowledged were received. When a receiver of a duplicate DATA chunk sends a SACK to a multi- homed endpoint it MAY be beneficial to vary the destination address and not use the source address of the DATA chunk. The reason being that receiving a duplicate from a multi-homed endpoint might indicate that the return path (as specified in the source address of the DATA chunk) for the SACK is broken. Furthermore, when its peer is multi-homed, an endpoint SHOULD try to retransmit a chunk that timed out to an active destination transport address that is different from the last destination address to which the DATA chunk was sent. Note that I think your issue is an implementation problem.. I know the BSD implemenation does the following: a) When it receives data it trys to send the sack to where the data came from (source address of data).. per the RFC b) If it sees a duplicate data chunk, it tries to change the src address (if possible) to a alternate. Of course there is advice in the RFC (above) but there is no mandate.. R ash kat wrote: > Hello Michael > =20 > Thanks for correcting me. > =20 > One more doubt. > =20 > let us say if Endpoint-1 has detected a path with the peer endpoint-2 a= s=20 > down. > and after that it starts receiving data on the same path from the=20 > endpoint-2. so it will not mark that path UP until it receives some=20 > HB-ACK or SACK from peer on that path. > So, my question is that - when a path is down, does in that state also=20 > an endpoint-1 can send SACK for the DATA received on that path from=20 > endpoint-2. > =20 > Also reframing my first Qsn. wrt above correction. > =20 > When there are 2 endpoints EP-1 and EP-2 > EP-1 has IP-1 and IP-2. EP-2 has IP-3 > So there are 3 path > PATH-1 ( IP-1 , IP-3 ) > PATH-2 ( IP-2 , IP-3 ) > =20 > EP-2 is sending DATA on PATH_2. But as EP-1 has PATH-1 as primary so it= =20 > will send the SACK via PATH-1 > =3D=3D=3D=3D RFC does not mandate about the source address of the SACK = chunk =3D=3D=3D=3D > =20 > Now let us suppose, the Heartbeats were going fine on both the paths,=20 > from both the Endpoints. > However, just before sending the SACK the PATH-1 faces some problem. > BUT, before the EP-1 detects this problem ( or DOWN PATH-1) via=20 > Heartbeat, the Assoc.Max.retrans of EP-2 are over and it marked the EP-= 2=20 > as DOWN. > So, what could be done in this case?? > =20 > If there is some recommendation in SCTP RFC about changing the source=20 > address of the SACK or sending SACK from the same address on which DATA= =20 > arrives then this problem could be solved. > =20 > I may be missing out something and please correct me where ever I am=20 > wrong. Also provide your valuable suggestions. > =20 > Regards, > Ashwani Kathuria. >=20 > */Michael Tuexen /* wrote: >=20 > Hi, >=20 > please note that you can not conclude from receiving packets from > IP-3 that you are able > to send packets to IP-3. Paths can be asymmetric. Therefore you can > not disable sending > HEARTBEATs. >=20 > Best regards > Michael >=20 > On May 30, 2007, at 4:24 PM, ash kat wrote: >=20 > > Hello Devayya, > > > > As the Endpoint-1 is continuously receiving the DATA from > > endpoint-2 ( IP-3 ), so it will not send the HeartBeats to this > > address (IP-3). > > and as a result of this, the Endpoint-2 will retransmit the data > > assoc.max.retrans times and will ABORT the association. > > > > Regards, > > Ashwani Kathuria. > > > > devayya wrote: > > Ashwani, > > > > I think when the Endpoint-1 detects problem in sending the SACK,= the > > Endpoint-1 should have detected the path failure by retransmitti= ng > > HEARTBEAT and not getting HEARTBEAT ACK and subsequently should = have > > changed the primary path to IP address IP-2. > > > > Best regards. > > > > > > Salil Agrawal wrote: > > > Hi Ashwani, > > > > > > > > > > > > As the RFC 2960 saying > > > > > > =93An endpoint SHOULD transmit reply chunks (e.g., SACK, HEART= BEAT > > ACK, > > > > > > etc.) to the same destination transport address from which it > > > > > > received the DATA or control chunk to which it is replying. Th= is > > > > > > rule should also be followed if the endpoint is bundling DATA > chunks > > > > > > together with the reply chunk.=94 > > > > > > > > > > > > This is for the destination address, but for the source addres= s > > it is > > > silent. My view is the same should also be followed for the so= urce > > > address. The problem of if the peer is multi-homed will not ar= ise > > as RFC > > > is very clear about the destination address. > > > > > > > > > > > > I request to others also to provide their view on the same. > > > > > > > > > > > > Thanks, > > > > > > Salil > > > > > > > > > > > > > > > > > > > > > -------------------------------------------------------------------= --- > > -- > > > > > > From: ash kat [mailto:ashwani_groups@yahoo.com] > > > Sent: Wednesday, May 30, 2007 10:17 AM > > > To: sigtran@ietf.org; tsvwg@ietf.org > > > Subject: [Sigtran] SACK from a multihomed endpoint. > > > > > > > > > > > > Hello All > > > > > > > > > > > > I have a query related to sending the SACK from a multihomed > > endpoint. > > > > > > > > > > > > 1. There is an association between endpoint-1 and endpoint-2. > > > 2. Endpoint-1 has 2 IP address ( IP-1, IP-2) while endpoint-2 = has > > only > > > one IP address (IP-3). > > > 3. IP-1 is the primary IP address of the Endpoint-1. > > > 4. Endpoint-2 sends the DATA from IP-3 to IP-2. > > > 5. As the RFC does not mandate to send the SACK from the > destination > > > address of the DATA so Endpoint-1 is sending the SACK from it'= s > > primary > > > IP ( IP-1). > > > 6. Now due to the problem in IP-1 network, or due to some othe= r > > reasons, > > > the SACK is dropped in the network. > > > 7. Endpoint-2 will retransmit the DATA on both the paths i.e, > > From IP-3 > > > to IP-2 and also from IP-3 to IP-1. > > > 8. But as Endpoint-1 point one is sending the SACK always from > > the IP-1 > > > so it will never reach the Endpoint-2. > > > As SCTP RFC 2960 does not suggest anything related to the sour= ce > > > address of the replay chunks so the above behavior (point-8) i= s > > true. > > > 9. Now, after assoc.max.retrans the Endpoint-2 will send the > > ABORT to > > > Endpoint-1 and the association will be down even there was one= path > > > available. > > > > > > > > > > > > My concerns is that - as RFC does not cover this kind of > > situation so > > > what should be the behavior of stack. > > > > > > > > > IMO either > > > a] The SACK should be sent from the same address from which th= e > > DATA is > > > coming. > > > or > > > b] When the duplicate DATA chunks are received then the source > > address > > > of the SACK should also be changed. > > > > > > > > > > > > Currently RFC recommend to change only the destination address= of > > the > > > SACK in such cases, but as we have only one destination addres= s > > so that > > > wouldn't help. > > > Hence, we have to change the source address also as suggested = in > > point > > > [b] above. > > > > > > > > > > > > The similar problem will appear if the peer also is multihomed. > > > > > > > > > > > > So I would request you to provide your valuable suggestions an= d > > if RFC > > > covers such scenario then please provide the related section > > reference. > > > > > > > > > > > > > > > > > > > > > -------------------------------------------------------------------= --- > > -- > > > > > > Boardwalk for $500? In 2007? Ha! > > > Play Monopoly Here and Now > > > > > > (it's updated for today's economy) at Yahoo! Games. > > > > > > > > > > > > -------------------------------------------------------------------= --- > > -- > > > > > > _______________________________________________ > > > Sigtran mailing list > > > Sigtran@ietf.org > > > https://www1.ietf.org/mailman/listinfo/sigtran > > > > > > Got a little couch potato? > > Check out fun summer activities for kids. >=20 >=20 > -----------------------------------------------------------------------= - > You snooze, you lose. Get messages ASAP with AutoCheck=20 > > in the all-new Yahoo! Mail Beta. --=20 Randall Stewart 803-345-0369 815-342-5222(cell) From tsvwg-bounces@ietf.org Mon Jun 11 03:44:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HxeZZ-00053t-Jv; Mon, 11 Jun 2007 03:44:21 -0400 Received: from tsvwg by megatron.ietf.org with local (Exim 4.43) id 1HxeZY-00053f-9N for tsvwg-confirm+ok@megatron.ietf.org; Mon, 11 Jun 2007 03:44:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HxeZX-00053X-SG for tsvwg@ietf.org; Mon, 11 Jun 2007 03:44:19 -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 1HxeZW-00033i-9S for tsvwg@ietf.org; Mon, 11 Jun 2007 03:44:19 -0400 Received: from [139.133.207.156] (dhcp-207-156.erg.abdn.ac.uk [139.133.207.156]) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id l5B7hgEt021651; Mon, 11 Jun 2007 08:43:43 +0100 (BST) Message-ID: <466CFD2E.7010306@erg.abdn.ac.uk> Date: Mon, 11 Jun 2007 08:43:42 +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: [Tsvwg] Re: [tcpm] Revision of draft-larsen-tsvwg-port-randomization References: <200702111621.l1BGL6mw029875@venus.xmundo.net> <0E46EBE9-1C13-44B6-9C04-476D418F5A6D@nokia.com> In-Reply-To: <0E46EBE9-1C13-44B6-9C04-476D418F5A6D@nokia.com> 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: 50a516d93fd399dc60588708fd9a3002 Cc: ext Fernando Gont , tsvwg WG X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: gorry@erg.abdn.ac.uk List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tsvwg-bounces@ietf.org > The concepts in this draft are likely relevant to most of > our transport protocols, and hence would be in scope for TSVWG. > The TSVWG chairs are interested in comments on whether there is > group interest in this draft - please comment on tsvwg@ietf.org. > I've read the previous revision of the draft, and will read the > current one soon. I have read and commented on previous versions (and will read the current). I agree the concepts are applicable to transports such as DCCP, and the concept is sufficiently simple that it could probably be done for all transports... I think tsvwg could be the right place - as long as there's cross-communication with SCTP, TCP, DCCP, etc. As someone already noted, this really also needs visibility with people USING transport, RTP, apps, signalling, etc. I support adopting this document as a TSVWG item. Gorry Lars Eggert wrote: > On 2007-2-11, at 17:56, ext Fernando Gont wrote: > >> We have published a revision of the port randomization draft >> (draft-larsen-tsvwg-port-randomization). This version addresses >> feedback from Alfred Hoenes and Carlos Pignataro, and comments from >> FreeBSD's Mike Silbersack. The draft is targetted at tsvwg because >> the same stuff can be applied to other protocols. But most (all?) of >> the work on this has been done mainly for TCP. > > > The update is at http://tools.ietf.org/html/draft-larsen-tsvwg-port- > randomization. > > The concepts in this draft are likely relevant to most of our transport > protocols, and hence would be in scope for TSVWG. The TSVWG chairs are > interested in comments on whether there is group interest in this draft > - please comment on tsvwg@ietf.org. > > Lars > > From tsvwg-bounces@ietf.org Mon Jun 11 14:46:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HxouZ-0002EL-SX; Mon, 11 Jun 2007 14:46:43 -0400 Received: from tsvwg by megatron.ietf.org with local (Exim 4.43) id 1HxouX-0002EE-Vv for tsvwg-confirm+ok@megatron.ietf.org; Mon, 11 Jun 2007 14:46:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HxouX-0002E6-MI for tsvwg@ietf.org; Mon, 11 Jun 2007 14:46:41 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HxouX-0004A1-C1 for tsvwg@ietf.org; Mon, 11 Jun 2007 14:46:41 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-2.cisco.com with ESMTP; 11 Jun 2007 11:46:41 -0700 X-IronPort-AV: i="4.16,409,1175497200"; d="scan'208"; a="378462543:sNHT80132586" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l5BIkeOR020074; Mon, 11 Jun 2007 11:46:40 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l5BIkE2Q015200; Mon, 11 Jun 2007 18:46:40 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 11 Jun 2007 11:46:28 -0700 Received: from jmpolk-wxp.cisco.com ([10.21.124.106]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 11 Jun 2007 11:46:27 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 11 Jun 2007 13:46:22 -0500 To: tsvwg@ietf.org From: "James M. Polk" Subject: Re: [Tsvwg] UDP-Lite MIB - ready? In-Reply-To: References: <465C3538.8060707@erg.abdn.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: X-OriginalArrivalTime: 11 Jun 2007 18:46:27.0648 (UTC) FILETIME=[D1926400:01C7AC58] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1491; t=1181587600; x=1182451600; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=20=22James=20M.=20Polk=22=20 |Subject:=20Re=3A=20[Tsvwg]=20UDP-Lite=20MIB=20-=20ready? |Sender:=20; bh=aN+d/BlzmeN+yE48doEXD3+rUQBbbzLJ3SX47wd/+8U=; b=vqIh77scINp5lH4myAL7EmcMrH2PJofNH+8lztoVMWdgyZLmMEsU7In39qQ/695wSt1mfn1e psM2/tYAD2gdxM3JcWQARP3YGHJZnjTtTvXlYoRCqP2unqW6UGHEd9gu; Authentication-Results: sj-dkim-2; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: gorry@erg.abdn.ac.uk, Gerrit Renker X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tsvwg-bounces@ietf.org At 09:30 AM 5/31/2007, Lars Eggert wrote: >On 2007-5-29, at 17:14, ext Gorry Fairhurst wrote: >>http://www.ietf.org/internet-drafts/draft-renker-tsvwg-udplite- mib-02.txt >> >>We think this document is ready to be adopted as a WG document. > >The chairs would like to echo this request and start a consensus call >for WG adoption. Please send comments by June 15. > >(My personal opinion is that we should take this on. UDP-Lite is one >of our transport protocols, and we have some obligation to make sure >it can be managed as part of the overall IETF management framework.) (with my chair hat on) I'd like to ping the WG about adopting this ID as a WG item. Anyone *not* wanting this ID to become a WG item, please comment to the list by this Friday, June 15th. (with my chair hat off) I think this effort is a good thing to have, even if not everyone on this list is interested. That's a reality in this WG, that it is a group of fairly individual projects (or protocols), and not one consensus drive protocol or mechanism (like other WGs enjoy). That said, and as Lars points out, Transport protocols are the charter of this WG, and at least some in this WG should work to ensure a modification to an existing transport protocol or the creation of a new transport protocol is done with consistency within the IETF, with the opportunity for peer review by other community members of similar focus. I believe this is one such case. >Lars From tsvwg-bounces@ietf.org Mon Jun 11 14:54:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hxp2R-0001DN-BJ; Mon, 11 Jun 2007 14:54:51 -0400 Received: from tsvwg by megatron.ietf.org with local (Exim 4.43) id 1Hxp2P-0001DI-Fs for tsvwg-confirm+ok@megatron.ietf.org; Mon, 11 Jun 2007 14:54:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hxp2P-0001DA-6D for tsvwg@ietf.org; Mon, 11 Jun 2007 14:54:49 -0400 Received: from smtp1.smtp.bt.com ([217.32.164.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hxp2N-0005Jj-Gv for tsvwg@ietf.org; Mon, 11 Jun 2007 14:54:49 -0400 Received: from i2kc06-ukbr.domain1.systemhost.net ([193.113.197.70]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 11 Jun 2007 19:54:46 +0100 Received: from cbibipnt05.iuser.iroot.adidom.com ([147.149.196.177]) by i2kc06-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.1830); Mon, 11 Jun 2007 19:54:46 +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 1181588085665; Mon, 11 Jun 2007 19:54:45 +0100 Received: from mut.jungle.bt.co.uk ([10.86.0.34]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id l5BIsdQY031842; Mon, 11 Jun 2007 19:54:41 +0100 Message-Id: <5.2.1.1.2.20070611192017.03888b98@pop3.jungle.bt.co.uk> X-Sender: rbriscoe@pop3.jungle.bt.co.uk X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Mon, 11 Jun 2007 19:54:40 +0100 To: "WESTERLUND, Magnus" , "EGGERT, Lars" From: Bob Briscoe Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: -3.688 () ALL_TRUSTED,AWL,BAYES_00 X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 X-OriginalArrivalTime: 11 Jun 2007 18:54:46.0335 (UTC) FILETIME=[FACFFCF0:01C7AC59] X-Spam-Score: 0.1 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: tsvwg IETF list Subject: [Tsvwg] IETF process concerning missed RFC dependencies? X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tsvwg-bounces@ietf.org Magnus, Lars, I'm preparing an initial I-D to tidy up the contradictions between different RFCs concerning ECN tunnelling (I mentioned I planned to do this some time ago on the list). My question: If an RFC has been published in the past that updates another RFC, but the dependency wasn't noticed at the time, can the dependency 'just' be added to the RFC index? Specifically, the question is about RFC4301 (IPsec architecture) which updates RFC3168 (ECN) but the RFC Index doesn't flag this. Unfortunately the new IPsec architecture referenced ECN as only informative, even though it updated it. This is also a cross-area question - if the cross-area dependency had been identified at the time, should the transport area have been consulted about the change to ECN? (which it might have been? tho I can't find any evidence from a careful search) And if it wasn't consulted what happens? It's actually more complicated because RFC4301 hasn't been written so that it is clear exactly which parts of RFC3168 it updates and which it doesn't. But that's the rats' nest that my proposed I-D is designed to unpick. So let's leave aside that question for now. BTW, I'm not trying point the finger - we're all trying to do the best we can - these things happen. Bob ____________________________________________________________________________ Notice: This contribution is the personal view of the author and does not necessarily reflect the technical nor commercial direction of BT plc. ____________________________________________________________________________ Bob Briscoe, Networks Research Centre, BT Research B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK. +44 1473 645196 From tsvwg-bounces@ietf.org Mon Jun 11 15:51:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hxpuq-0003t3-1y; Mon, 11 Jun 2007 15:51:04 -0400 Received: from tsvwg by megatron.ietf.org with local (Exim 4.43) id 1Hxptt-000170-2c for tsvwg-confirm+ok@megatron.ietf.org; Mon, 11 Jun 2007 15:50:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hxptr-00012J-IL; Mon, 11 Jun 2007 15:50:03 -0400 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hxptr-0007Vx-43; Mon, 11 Jun 2007 15:50:03 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id E24C026EC4; Mon, 11 Jun 2007 19:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1Hxptq-00057Q-Ie; Mon, 11 Jun 2007 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Mon, 11 Jun 2007 15:50:02 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Cc: tsvwg@ietf.org Subject: [Tsvwg] I-D ACTION:draft-ietf-tsvwg-cc-alt-04.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tsvwg-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Area Working Group Working Group of the IETF. Title : Specifying New Congestion Control Algorithms Author(s) : S. Floyd, M. Allman Filename : draft-ietf-tsvwg-cc-alt-04.txt Pages : 11 Date : 2007-6-11 The IETF's standard congestion control schemes have been widely shown to be inadequate for various environments (e.g., high-speed networks). Recent research has yielded many alternate congestion control schemes that significantly differ from the IETF's congestion control principles. Using these new congestion control schemes in the global Internet has possible ramifications to both the traffic using the new congestion control and to traffic using the currently standardized congestion control. Therefore, the IETF must proceed with caution when dealing with alternate congestion control proposals. The goal of this document is to provide guidance for considering alternate congestion control algorithms within the IETF. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-cc-alt-04.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-tsvwg-cc-alt-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-tsvwg-cc-alt-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-6-11123508.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-tsvwg-cc-alt-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-tsvwg-cc-alt-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-6-11123508.I-D@ietf.org> --OtherAccess-- --NextPart-- From tsvwg-bounces@ietf.org Mon Jun 11 15:51:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HxpvE-0004om-K1; Mon, 11 Jun 2007 15:51:28 -0400 Received: from tsvwg by megatron.ietf.org with local (Exim 4.43) id 1HxpuP-0002q6-Fl for tsvwg-confirm+ok@megatron.ietf.org; Mon, 11 Jun 2007 15:50:38 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HxpuL-0002l8-SS; Mon, 11 Jun 2007 15:50:34 -0400 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HxpuK-0007rD-Fi; Mon, 11 Jun 2007 15:50:33 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id 693B32AC7B; Mon, 11 Jun 2007 19:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1Hxptq-00056d-5d; Mon, 11 Jun 2007 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Mon, 11 Jun 2007 15:50:02 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: tsvwg@ietf.org Subject: [Tsvwg] I-D ACTION:draft-ietf-tsvwg-sctpthreat-04.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tsvwg-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Area Working Group Working Group of the IETF. Title : Security Attacks Found Against SCTP and Current Countermeasures Author(s) : R. Stewart, et al. Filename : draft-ietf-tsvwg-sctpthreat-04.txt Pages : 15 Date : 2007-6-11 This document describes certain security threats to SCTP. It also describes ways to mitigate these threats, in particular by using techniques from the SCTP Specification Errata and Issues memo (RFC 4460). These techniques are included in RFC 2960bis, which obsoletes RFC 2960. It is hoped that this information will provide some useful background information for many of the newest requirements spelled out in the SCTP Specification Errata and Issues and included in RFC 2960bis. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-sctpthreat-04.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-tsvwg-sctpthreat-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-tsvwg-sctpthreat-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-6-11102430.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-tsvwg-sctpthreat-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-tsvwg-sctpthreat-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-6-11102430.I-D@ietf.org> --OtherAccess-- --NextPart-- From tsvwg-bounces@ietf.org Mon Jun 11 15:51:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HxpvS-0005Ne-A8; Mon, 11 Jun 2007 15:51:42 -0400 Received: from tsvwg by megatron.ietf.org with local (Exim 4.43) id 1Hxpuq-0003uP-Ma for tsvwg-confirm+ok@megatron.ietf.org; Mon, 11 Jun 2007 15:51:04 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hxpup-0003si-Pu; Mon, 11 Jun 2007 15:51:03 -0400 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Hxpup-0007sL-FX; Mon, 11 Jun 2007 15:51:03 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id EE6BB2AC92; Mon, 11 Jun 2007 19:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1Hxptq-00057f-M6; Mon, 11 Jun 2007 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Mon, 11 Jun 2007 15:50:02 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Cc: tsvwg@ietf.org Subject: [Tsvwg] I-D ACTION:draft-ietf-tsvwg-udp-guidelines-01.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tsvwg-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Area Working Group Working Group of the IETF. Title : UDP Usage Guidelines for Application Designers Author(s) : L. Eggert, G. Fairhurst Filename : draft-ietf-tsvwg-udp-guidelines-01.txt Pages : 15 Date : 2007-6-11 The User Datagram Protocol (UDP) provides a minimal, message-passing transport that has no inherent congestion control mechanisms. Because congestion control is critical to the stable operation of the Internet, applications and upper-layer protocols that choose to use UDP as an Internet transport must employ mechanisms to prevent congestion collapse and establish some degree of fairness with concurrent traffic. This document provides guidelines on the use of UDP for the designers of such applications and upper-layer protocols that cover congestion-control and other topics, including message sizes and reliability. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-udp-guidelines-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-tsvwg-udp-guidelines-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-tsvwg-udp-guidelines-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-6-11124729.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-tsvwg-udp-guidelines-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-tsvwg-udp-guidelines-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-6-11124729.I-D@ietf.org> --OtherAccess-- --NextPart-- From tsvwg-bounces@ietf.org Mon Jun 11 23:40:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HxxF7-0002YS-Eg; Mon, 11 Jun 2007 23:40:29 -0400 Received: from tsvwg by megatron.ietf.org with local (Exim 4.43) id 1HxxF5-0002R6-J3 for tsvwg-confirm+ok@megatron.ietf.org; Mon, 11 Jun 2007 23:40:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HxxF5-0002P1-8G for tsvwg@ietf.org; Mon, 11 Jun 2007 23:40:27 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HxxF3-00049k-Uk for tsvwg@ietf.org; Mon, 11 Jun 2007 23:40:27 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-3.cisco.com with ESMTP; 11 Jun 2007 20:40:25 -0700 X-IronPort-AV: i="4.16,409,1175497200"; d="scan'208"; a="492755723:sNHT44402618" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l5C3ePTk012249 for ; Mon, 11 Jun 2007 20:40:25 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l5C3eP20026308 for ; Tue, 12 Jun 2007 03:40:25 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 11 Jun 2007 20:40:24 -0700 Received: from jmpolk-wxp.cisco.com ([10.21.124.106]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 11 Jun 2007 20:40:24 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 11 Jun 2007 22:40:31 -0500 To: tsvwg From: "James M. Polk" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: X-OriginalArrivalTime: 12 Jun 2007 03:40:24.0874 (UTC) FILETIME=[693F20A0:01C7ACA3] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1461; t=1181619625; x=1182483625; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=20=22James=20M.=20Polk=22=20 |Subject:=20Building=20the=20TSVWG=20agenda=20for=20Chicago=20IETF |Sender:=20; bh=8j/1RY1Ka6npUA/w6GvBtgy6FyRnLAUl6/flCDP0p2s=; b=mhoz24VnqXMLRIovnFVQsAOj4qzJ+DfU7IE4XQ4UdqFvqqHAte76TBSBiA9hvtEbh8S+5GYk zBVmM6TbYPIRzvGXctEBkjAQd1GasUCdj1toleXUDYCB9mj5/7RBl3Oq; Authentication-Results: sj-dkim-4; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Subject: [Tsvwg] Building the TSVWG agenda for Chicago IETF X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tsvwg-bounces@ietf.org Hey TSVWG I'm starting to build our agenda for the upcoming IETF in Chicago. I will be running the agenda again this meeting, so send me your agenda requests. Something's new this meeting - we (meaning I) have almost zero time to do this in. Here's what I mean: - submission cut-off for -00 IDs is July 2nd. Draft agendas are due July 2nd. - revised ID cut-off is July 9th, and FINAL agendas are due July 9th. Every meeting I get a request (or two ... or three) for session time after an ID is announced, meaning around the 12th or 13th. This is too late this meeting. So, everyone that wants TSVWG agenda time to discuss a submitted Internet Draft needs to let me know about the time request EARLY. I need the following for every ID: - Presenter's name (point of contact about presentation) - ID filename - ID itself (if not submitted to me when ID was submitted to the Secretary) - the amount of time requested to present WG items will get precedence over non-WG items for time. Like topics are generally grouped together where possible. If you don't request time early, and there is no time remaining within the allotted timeslot (because others beat you to me), well..... there's always next meeting ;-) [that last part is only half joking] Cheers, James IETF TSVWG co-chair *********************************** "It should NEVER be inconvenient to do the right thing" From tsvwg-bounces@ietf.org Tue Jun 12 04:01:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hy1JU-0001Ov-OU; Tue, 12 Jun 2007 04:01:16 -0400 Received: from tsvwg by megatron.ietf.org with local (Exim 4.43) id 1Hy1JS-0001OW-Oy for tsvwg-confirm+ok@megatron.ietf.org; Tue, 12 Jun 2007 04:01:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hy1JS-0001OL-8z; Tue, 12 Jun 2007 04:01:14 -0400 Received: from smtp.nokia.com ([131.228.20.172] helo=mgw-ext13.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hy1JQ-0007HB-It; Tue, 12 Jun 2007 04:01:14 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext13.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l5C80i90007537; Tue, 12 Jun 2007 11:01:10 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 12 Jun 2007 11:01:08 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 12 Jun 2007 11:01:08 +0300 Received: from mgw-int02.ntc.nokia.com ([172.21.143.97]) by esebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Tue, 12 Jun 2007 11:01:08 +0300 Received: from [172.21.35.94] (esdhcp03594.research.nokia.com [172.21.35.94]) by mgw-int02.ntc.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l5C816jm023828; Tue, 12 Jun 2007 11:01:07 +0300 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-9--682882164; protocol="application/pkcs7-signature" Message-Id: From: Lars Eggert Date: Tue, 12 Jun 2007 11:01:04 +0300 To: tsvwg WG X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 12 Jun 2007 08:01:08.0418 (UTC) FILETIME=[D5868220:01C7ACC7] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Cc: Behave WG , IETF AVT WG , mmusic Subject: [Tsvwg] draft-ietf-tsvwg-udp-guidelines-01 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: tsvwg WG List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tsvwg-bounces@ietf.org --Apple-Mail-9--682882164 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Hi, Gorry and me just submitted a new -01 version of the "UDP Usage Guidelines for Application Designers" draft that TSVWG is putting together as a BCP. Compared to the -00 version, this draft adds a new Section 3.5 that gives middlebox traversal guidelines. (I'm cross-posting to AVT, MMUSIC and BEHAVE, because this addition was triggered by the recent discussion around draft-marjou-behave-app- rtp-keepalive. Please discuss draft-ietf-tsvwg-udp-guidelines on the TSVWG list; I'm setting the reply-to accordingly.) We'd be interested in comments, both from TSV folks but especially from RAI people, who might not have had this on their radar. Lars --Apple-Mail-9--682882164 Content-Transfer-Encoding: base64 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGQDCCAvkw ggJioAMCAQICEGtxkLFHQu1g67hlmYfwPuIwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDEwNDE2MTE1NFoXDTA4MDEwNDE2MTE1 NFowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEA26hjntVPZMiwh4d8tyuk9KiucvG92BVUGArk5zO1jhmq7tLFgU1mqcIg VGumfQqjkAzIuh83kxIiqBrB05Wvxp85apwt4sUCvzMe8mQWzZZZYp0rBzwpOj+VC5pxsMRYtYW+ BaTFBEmvFr7D7C7roZUk0lDppS5SZFs4SQbEe9ykB9aeUf1iTiw2+ikyP2+JEYto14WYCoxFWbms FbQ1uaaK+yn1WH2YHhyMfi0IOxuT0jtbsngjHJMpWIqq334zBhj+rPSUug47YBHr41FCDMHbbbjv WbyTyDYneOW3WY8LY8bGWVlAknQGB7lgduShe6e0RI/7SL/VE6X27lM9LwIDAQABozIwMDAgBgNV HREEGTAXgRVsYXJzLmVnZ2VydEBub2tpYS5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUF AAOBgQCx3nxxTg/WowobVTRXBiXUEEZj4LBiunWbuAnR0UbJIgijvq3JbiJvZo2gUGiW9LPaHSBz 4oxT1VR/S/6O0a4e87oV5cOQm6ReB68o9rDfUzxHTwoCfv2wwMwBrXyzQMjyQK4Lt8siV41gmZpm rSXMhjTJdd9uYYNoZKQLq+VM+TCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJ BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgG A1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMg RGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3 DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3 MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9 fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+ uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMB Af8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3 dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgG A1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcP f6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH 2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8x ggMQMIIDDAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAo UHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ a3GQsUdC7WDruGWZh/A+4jAJBgUrDgMCGgUAoIIBbzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw0wNzA2MTIwODAxMDRaMCMGCSqGSIb3DQEJBDEWBBTioSuoUwcZjUaQ E3XWTcgn3290IzCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIwgYcGCyqGSIb3DQEJEAILMXigdjBiMQsw CQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIw DQYJKoZIhvcNAQEBBQAEggEAyElFq8OXQqqtH/+fJytFT+6ri6pRz9Ze1P+nXrBA2Qhk6TZ8QvLN TJC21TB4NrgZ696G002aUbwLNB0/6J/pGmOtGdWANUyNU5hn/kbs3a5JfDUMLDAZsDm/EZ5QiaE5 eQs+u0qI1GeHWzJuEmgdnx8RVP8Pup/sqMkyX+2QIS4ZCpZRFlAIEpGwZhswpcA5CO9Ag0hENMg7 kZp2sGkZD5zLzNBCd2MnmklRuSsn2D7c1wOcUdffSJ1p8Gy7jVk7ZxtYcGm5m8wLJpQSDBpxC1zI kJyhXvgedxXFpZU+yfYjtxCsQLmG0bpF+uPVLYGtnHWIUSzD8zQu2QiHYW4geAAAAAAAAA== --Apple-Mail-9--682882164-- From tsvwg-bounces@ietf.org Tue Jun 12 09:55:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hy6qN-0001S4-2R; Tue, 12 Jun 2007 09:55:35 -0400 Received: from tsvwg by megatron.ietf.org with local (Exim 4.43) id 1Hy6qM-0001Ry-Fs for tsvwg-confirm+ok@megatron.ietf.org; Tue, 12 Jun 2007 09:55:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hy6qM-0001Rq-6H for tsvwg@ietf.org; Tue, 12 Jun 2007 09:55:34 -0400 Received: from smtp.nokia.com ([131.228.20.173] helo=mgw-ext14.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hy6qK-0007OR-JE for tsvwg@ietf.org; Tue, 12 Jun 2007 09:55:34 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext14.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l5CDtPwW014408; Tue, 12 Jun 2007 16:55:26 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 12 Jun 2007 16:55:15 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 12 Jun 2007 16:55:15 +0300 Received: from mgw-int01.ntc.nokia.com ([172.21.143.96]) by esebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Tue, 12 Jun 2007 16:55:15 +0300 Received: from [172.21.35.94] (esdhcp03594.research.nokia.com [172.21.35.94]) by mgw-int01.ntc.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l5CDt9le003665; Tue, 12 Jun 2007 16:55:09 +0300 In-Reply-To: <5.2.1.1.2.20070611192017.03888b98@pop3.jungle.bt.co.uk> References: <5.2.1.1.2.20070611192017.03888b98@pop3.jungle.bt.co.uk> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-41--661639382; protocol="application/pkcs7-signature" Message-Id: <3C1525E2-D55D-4098-A90D-2A19A87FC762@nokia.com> From: Lars Eggert Date: Tue, 12 Jun 2007 16:55:06 +0300 To: ext Bob Briscoe X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 12 Jun 2007 13:55:15.0067 (UTC) FILETIME=[4D83DCB0:01C7ACF9] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 7fa173a723009a6ca8ce575a65a5d813 Cc: "WESTERLUND, Magnus" , tsvwg IETF list Subject: [Tsvwg] Re: IETF process concerning missed RFC dependencies? X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tsvwg-bounces@ietf.org --Apple-Mail-41--661639382 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Hi, On 2007-6-11, at 21:54, ext Bob Briscoe wrote: > I'm preparing an initial I-D to tidy up the contradictions between > different RFCs concerning ECN tunnelling (I mentioned I planned to > do this some time ago on the list). > > My question: If an RFC has been published in the past that updates > another RFC, but the dependency wasn't noticed at the time, can the > dependency 'just' be added to the RFC index? I don't think so. That information is simply extracted out of the "Updates" or "Obsoletes" header in the RFC itself. So you'd need to change the content of the RFC itself to change this data, which typically means a revision. (Hm, I wonder if this could be done with an errata? Not clear. But an errata of this magnitude would need some consensus. IMO this is not something that the RFC Editor can just do on its own.) Another way forward would be a new RFC that updates both RFC4301 and RFC3168 and contains the corrections. That will flag both of these RFCs with an "updated by" in the database and on the RFC Editor web page (but unfortunately not in the published RFC text). > Specifically, the question is about RFC4301 (IPsec architecture) > which updates RFC3168 (ECN) but the RFC Index doesn't flag this. > Unfortunately the new IPsec architecture referenced ECN as only > informative, even though it updated it. > > This is also a cross-area question - if the cross-area dependency > had been identified at the time, should the transport area have > been consulted about the change to ECN? (which it might have been? > tho I can't find any evidence from a careful search) And if it > wasn't consulted what happens? Yes, TSV should have been consulted. > It's actually more complicated because RFC4301 hasn't been written > so that it is clear exactly which parts of RFC3168 it updates and > which it doesn't. But that's the rats' nest that my proposed I-D is > designed to unpick. So let's leave aside that question for now. A TSV review would have probably caught that. > BTW, I'm not trying point the finger - we're all trying to do the > best we can - these things happen. Understood, and it is never too late to correct past mistakes. Lars --Apple-Mail-41--661639382 Content-Transfer-Encoding: base64 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGQDCCAvkw ggJioAMCAQICEGtxkLFHQu1g67hlmYfwPuIwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDEwNDE2MTE1NFoXDTA4MDEwNDE2MTE1 NFowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEA26hjntVPZMiwh4d8tyuk9KiucvG92BVUGArk5zO1jhmq7tLFgU1mqcIg VGumfQqjkAzIuh83kxIiqBrB05Wvxp85apwt4sUCvzMe8mQWzZZZYp0rBzwpOj+VC5pxsMRYtYW+ BaTFBEmvFr7D7C7roZUk0lDppS5SZFs4SQbEe9ykB9aeUf1iTiw2+ikyP2+JEYto14WYCoxFWbms FbQ1uaaK+yn1WH2YHhyMfi0IOxuT0jtbsngjHJMpWIqq334zBhj+rPSUug47YBHr41FCDMHbbbjv WbyTyDYneOW3WY8LY8bGWVlAknQGB7lgduShe6e0RI/7SL/VE6X27lM9LwIDAQABozIwMDAgBgNV HREEGTAXgRVsYXJzLmVnZ2VydEBub2tpYS5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUF AAOBgQCx3nxxTg/WowobVTRXBiXUEEZj4LBiunWbuAnR0UbJIgijvq3JbiJvZo2gUGiW9LPaHSBz 4oxT1VR/S/6O0a4e87oV5cOQm6ReB68o9rDfUzxHTwoCfv2wwMwBrXyzQMjyQK4Lt8siV41gmZpm rSXMhjTJdd9uYYNoZKQLq+VM+TCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJ BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgG A1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMg RGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3 DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3 MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9 fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+ uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMB Af8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3 dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgG A1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcP f6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH 2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8x ggMQMIIDDAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAo UHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ a3GQsUdC7WDruGWZh/A+4jAJBgUrDgMCGgUAoIIBbzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw0wNzA2MTIxMzU1MDdaMCMGCSqGSIb3DQEJBDEWBBTOj61V0B01AW28 oOoTsukRBv1GqjCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIwgYcGCyqGSIb3DQEJEAILMXigdjBiMQsw CQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIw DQYJKoZIhvcNAQEBBQAEggEASx8z2BPXOJsi/oDdcqCkbXc5zhRRvCQYV0pGm5byOS0MxyUs9+P3 I8zz7wUJR7jQTxKvyUg7nIif7afLAt3gdkIqzedXTE/1470coqyukPH1uC3AqSVHYD73QuoXOk2E NXnnK9f5yAUhNt/xLonGSBOWuVps8LnLiNgtzNaX43ZmwutBW3waH41/dnOy6+GizcjVjpxE6k13 rj9qMiXyTOFXtokLHqlp86vFhdiivzZQyv9poetP6eGdby9UW8eCD+wF4w4CFPGWJJDMfKo0EK7a FKg67wYlBtUr0J7sXOhUv3G1ps4DlYoDES7gYNOQocqZKelB6fh6450YBv9wtgAAAAAAAA== --Apple-Mail-41--661639382-- From tsvwg-bounces@ietf.org Tue Jun 12 10:06:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hy70p-00084n-5t; Tue, 12 Jun 2007 10:06:23 -0400 Received: from tsvwg by megatron.ietf.org with local (Exim 4.43) id 1Hy70o-00084a-DK for tsvwg-confirm+ok@megatron.ietf.org; Tue, 12 Jun 2007 10:06:22 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hy70o-00084S-3H; Tue, 12 Jun 2007 10:06:22 -0400 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Hy70m-0001f7-DO; Tue, 12 Jun 2007 10:06:22 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id 5452D2AC84; Tue, 12 Jun 2007 14:05:50 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1Hy70I-0003nf-3R; Tue, 12 Jun 2007 10:05:50 -0400 X-test-idtracker: no From: The IESG To: IETF-Announce Message-Id: Date: Tue, 12 Jun 2007 10:05:50 -0400 X-Spam-Score: -2.8 (--) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: tsvwg chair , Internet Architecture Board , tsvwg mailing list , RFC Editor Subject: [Tsvwg] Protocol Action: 'Specifying New Congestion Control Algorithms' to BCP X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tsvwg-bounces@ietf.org The IESG has approved the following document: - 'Specifying New Congestion Control Algorithms ' as a BCP This document is the product of the Transport Area Working Group. The IESG contact persons are Lars Eggert and Magnus Westerlund. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-cc-alt-04.txt Technical Summary The IETF's standard congestion control schemes have been widely shown to be inadequate for various environments (e.g., high-speed networks). Recent research has yielded many alternate congestion control schemes. Using these new congestion control schemes in the global Internet has possible ramifications to both the traffic using the new congestion control and to traffic using the currently standardized congestion control. Therefore, the IETF must proceed with caution when dealing with alternate congestion control proposals. The goal of this document is to provide guidance for considering alternate congestion control algorithms within the IETF. Working Group Summary The WG consensus on this document was clear, but not overwhelmingly strong. Protocol Quality The document has been presented to the WG during several IETF meetings and has been reviewed by a number of key WG members. It has also been discussed in the IRTF's ICCRG and the wider research community. Personnel Lars Eggert (lars.eggert@nokia.com) was the document shepherd and also reviewed this document for the IESG. From tsvwg-bounces@ietf.org Tue Jun 12 12:03:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hy8q9-0000vN-6N; Tue, 12 Jun 2007 12:03:29 -0400 Received: from tsvwg by megatron.ietf.org with local (Exim 4.43) id 1Hy8q7-0000tH-SF for tsvwg-confirm+ok@megatron.ietf.org; Tue, 12 Jun 2007 12:03:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hy8q7-0000sh-HS for tsvwg@ietf.org; Tue, 12 Jun 2007 12:03:27 -0400 Received: from smtp1.smtp.bt.com ([217.32.164.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hy8q5-0008Nf-RA for tsvwg@ietf.org; Tue, 12 Jun 2007 12:03:27 -0400 Received: from i2kc08-ukbr.domain1.systemhost.net ([193.113.197.71]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 12 Jun 2007 17:03:25 +0100 Received: from cbibipnt08.iuser.iroot.adidom.com ([147.149.100.81]) by i2kc08-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 12 Jun 2007 17:03:24 +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 1181664203704; Tue, 12 Jun 2007 17:03:23 +0100 Received: from mut.jungle.bt.co.uk ([10.215.130.87]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id l5CG3IiB013015; Tue, 12 Jun 2007 17:03:21 +0100 Message-Id: <5.2.1.1.2.20070612165100.040faa58@pop3.jungle.bt.co.uk> X-Sender: rbriscoe@pop3.jungle.bt.co.uk X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Tue, 12 Jun 2007 17:03:20 +0100 To: Lars Eggert From: Bob Briscoe In-Reply-To: <3C1525E2-D55D-4098-A90D-2A19A87FC762@nokia.com> References: <5.2.1.1.2.20070611192017.03888b98@pop3.jungle.bt.co.uk> <5.2.1.1.2.20070611192017.03888b98@pop3.jungle.bt.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: -3.721 () ALL_TRUSTED,AWL,BAYES_00 X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 X-OriginalArrivalTime: 12 Jun 2007 16:03:24.0707 (UTC) FILETIME=[34E5CF30:01C7AD0B] X-Spam-Score: 0.1 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: "WESTERLUND, Magnus" , tsvwg IETF list Subject: [Tsvwg] Re: IETF process concerning missed RFC dependencies? X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tsvwg-bounces@ietf.org Lars, At 14:55 12/06/2007, Lars Eggert wrote: >Hi, > >On 2007-6-11, at 21:54, ext Bob Briscoe wrote: >>My question: If an RFC has been published in the past that updates >>another RFC, but the dependency wasn't noticed at the time, can the >>dependency 'just' be added to the RFC index? > >I don't think so. That information is simply extracted out of the >"Updates" or "Obsoletes" header in the RFC itself. So you'd need to >change the content of the RFC itself to change this data, which >typically means a revision. I assume (by parsing your para below as well), when you say "Updates" or "Obsoletes" headers in the RFC itself, you don't mean in the visible published RFC text, but in the RFC database. >Another way forward would be a new RFC that updates both RFC4301 and >RFC3168 and contains the corrections. That will flag both of these >RFCs with an "updated by" in the database and on the RFC Editor web >page (but unfortunately not in the published RFC text). Tx for clarification. I've now done a 'quick' I-D to update both which I'm getting reviewed before posting. By 'quick' I mean I've tried to write it in such a way that it doesn't raise any new security concerns or backward compatibility issues. Given it updates IPsec and ECN that's a tough call! I may be wrong and quick may turn into slow. But so far it doesn't update any security feature of IPsec, it just points out exceptions to the new ECN processing rules they set, which they hadn't noticed. However, it does materially update RFC3168 (given IPsec now contradicts it, something had to move). Bob ____________________________________________________________________________ Bob Briscoe, Networks Research Centre, BT Research B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK. +44 1473 645196 From tsvwg-bounces@ietf.org Tue Jun 12 12:19:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hy95f-0003Ai-6B; Tue, 12 Jun 2007 12:19:31 -0400 Received: from tsvwg by megatron.ietf.org with local (Exim 4.43) id 1Hy95e-00036L-52 for tsvwg-confirm+ok@megatron.ietf.org; Tue, 12 Jun 2007 12:19:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hy95d-000348-Pn for tsvwg@ietf.org; Tue, 12 Jun 2007 12:19:29 -0400 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hy95d-0004W9-DX for tsvwg@ietf.org; Tue, 12 Jun 2007 12:19:29 -0400 Received: from ewe.isi.edu (ewe.isi.edu [128.9.160.219]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l5CGIoab007669; Tue, 12 Jun 2007 09:18:52 -0700 (PDT) Message-Id: <5.2.1.1.2.20070612091735.00abace0@boreas.isi.edu> X-Sender: braden@boreas.isi.edu (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Tue, 12 Jun 2007 09:23:00 -0700 To: Lars Eggert From: Bob Braden Subject: Re: [Tsvwg] Re: IETF process concerning missed RFC dependencies? In-Reply-To: <3C1525E2-D55D-4098-A90D-2A19A87FC762@nokia.com> References: <5.2.1.1.2.20070611192017.03888b98@pop3.jungle.bt.co.uk> <5.2.1.1.2.20070611192017.03888b98@pop3.jungle.bt.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: braden@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: "WESTERLUND, Magnus" , tsvwg IETF list X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tsvwg-bounces@ietf.org >> >> >>My question: If an RFC has been published in the past that updates >>another RFC, but the dependency wasn't noticed at the time, can the >>dependency 'just' be added to the RFC index? > >I don't think so. That information is simply extracted out of the >"Updates" or "Obsoletes" header in the RFC itself. So you'd need to >change the content of the RFC itself to change this data, which >typically means a revision. Actually, the information in the RFC index is NOT extracted from the RFC headers, it is maintained separately. In the case of "obsoleted by", for example, the information can ONLY be in the index, since published RFCs are never changed. The intent is to keep the most current and correct information in the index, so the answer to the question is "yes", a dependency noted later can and should be added to the index. Just send email to the RFC Editor. And yes, there could also be an erratum, since it is in effect a later correction to a published RFC. >(Hm, I wonder if this could be done with an errata? Not clear. But an >errata of this magnitude would need some consensus. IMO this is not >something that the RFC Editor can just do on its own.) > > >Understood, and it is never too late to correct past mistakes. Amen. Bob Braden >Lars > From tsvwg-bounces@ietf.org Tue Jun 12 13:17:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hy9zV-0007f1-2K; Tue, 12 Jun 2007 13:17:13 -0400 Received: from tsvwg by megatron.ietf.org with local (Exim 4.43) id 1Hy9zT-0007ev-GD for tsvwg-confirm+ok@megatron.ietf.org; Tue, 12 Jun 2007 13:17:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hy9zT-0007en-6Z for tsvwg@ietf.org; Tue, 12 Jun 2007 13:17:11 -0400 Received: from smtp2.smtp.bt.com ([217.32.164.150]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hy9zR-0003eW-73 for tsvwg@ietf.org; Tue, 12 Jun 2007 13:17:10 -0400 Received: from i2kc06-ukbr.domain1.systemhost.net ([193.113.197.70]) by smtp2.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 12 Jun 2007 18:17:08 +0100 Received: from cbibipnt05.iuser.iroot.adidom.com ([147.149.196.177]) by i2kc06-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 12 Jun 2007 18:17:08 +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 1181668626730; Tue, 12 Jun 2007 18:17:06 +0100 Received: from mut.jungle.bt.co.uk ([10.215.130.87]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id l5CHH3W5015970; Tue, 12 Jun 2007 18:17:05 +0100 Message-Id: <5.2.1.1.2.20070612180739.0415cc78@pop3.jungle.bt.co.uk> X-Sender: rbriscoe@pop3.jungle.bt.co.uk X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Tue, 12 Jun 2007 18:17:04 +0100 To: Bob Braden From: Bob Briscoe Subject: Re: [Tsvwg] Re: IETF process concerning missed RFC dependencies? In-Reply-To: <5.2.1.1.2.20070612091735.00abace0@boreas.isi.edu> References: <3C1525E2-D55D-4098-A90D-2A19A87FC762@nokia.com> <5.2.1.1.2.20070611192017.03888b98@pop3.jungle.bt.co.uk> <5.2.1.1.2.20070611192017.03888b98@pop3.jungle.bt.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: -3.743 () ALL_TRUSTED,AWL,BAYES_00 X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 X-OriginalArrivalTime: 12 Jun 2007 17:17:08.0364 (UTC) FILETIME=[819A4CC0:01C7AD15] X-Spam-Score: 0.1 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: "WESTERLUND, Magnus" , tsvwg IETF list X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tsvwg-bounces@ietf.org Bob, At 17:23 12/06/2007, Bob Braden wrote: >>>Bob Briscoe: >>>My question: If an RFC has been published in the past that updates >>>another RFC, but the dependency wasn't noticed at the time, can the >>>dependency 'just' be added to the RFC index? > > >The intent is to keep the most current and correct information in the >index, so the answer to the question is "yes", a dependency noted >later can and should be added to the index. Just send email to >the RFC Editor. That's useful to know. It will possibly complicate matters even further to just baldly say RFC4301 (IPsec) updates RFC3168 (ECN), as RFC4301 doesn't clarify what bits of RFC3168 it updates and what it doesn't. So, rather than emailing the RFC Editor to say this right now, I'll post the I-D describing the contradiction between the two RFCs first, then we can have a discussion on the list about what to do, and also in Chicago. However, we could certainly tell the RFC Editor that both RFC3168 and RFC4301 update RFC2003 (IP in IP tunneling), a dependency which I also noticed isn't identified in the RFC Index. Anyone see any objection to that? Two Bob ____________________________________________________________________________ Bob Briscoe, Networks Research Centre, BT Research B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK. +44 1473 645196 From tsvwg-bounces@ietf.org Tue Jun 12 15:50:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyCNk-0007TM-Hb; Tue, 12 Jun 2007 15:50:24 -0400 Received: from tsvwg by megatron.ietf.org with local (Exim 4.43) id 1HyCNQ-0006ot-Hn for tsvwg-confirm+ok@megatron.ietf.org; Tue, 12 Jun 2007 15:50:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyCNQ-0006oX-0Z; Tue, 12 Jun 2007 15:50:04 -0400 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HyCNP-0004it-Lx; Tue, 12 Jun 2007 15:50:03 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id DA99C26ECC; Tue, 12 Jun 2007 19:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HyCNO-0005mC-M7; Tue, 12 Jun 2007 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Tue, 12 Jun 2007 15:50:02 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Cc: tsvwg@ietf.org Subject: [Tsvwg] I-D ACTION:draft-ietf-tsvwg-addip-sctp-21.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tsvwg-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Area Working Group Working Group of the IETF. Title : Stream Control Transmission Protocol (SCTP) Dynamic Address Reconfiguration Author(s) : R. Stewart, et al. Filename : draft-ietf-tsvwg-addip-sctp-21.txt Pages : 40 Date : 2007-6-12 A local host may have multiple points of attachment to the Internet, giving it a degree of fault tolerance from hardware failures. Stream Control Transmission Protocol (SCTP) SCTP-BIS [I-D.ietf-tsvwg-2960bis] was developed to take full advantage of such a multi-homed host to provide a fast failover and association survivability in the face of such hardware failures. This document describes an extension to SCTP that will allow an SCTP stack to dynamically add an IP Addresses to an SCTP association, dynamically delete an IP addresses from an SCTP association, and to request to set the primary address the peer will use when sending to an endpoint. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-addip-sctp-21.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-tsvwg-addip-sctp-21.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-tsvwg-addip-sctp-21.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-6-12135440.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-tsvwg-addip-sctp-21.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-tsvwg-addip-sctp-21.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-6-12135440.I-D@ietf.org> --OtherAccess-- --NextPart-- From tsvwg-bounces@ietf.org Tue Jun 12 15:50:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyCNm-0007Xq-RG; Tue, 12 Jun 2007 15:50:26 -0400 Received: from tsvwg by megatron.ietf.org with local (Exim 4.43) id 1HyCNQ-0006p3-Rz for tsvwg-confirm+ok@megatron.ietf.org; Tue, 12 Jun 2007 15:50:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyCNQ-0006oi-7I; Tue, 12 Jun 2007 15:50:04 -0400 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HyCNP-0004iw-Ud; Tue, 12 Jun 2007 15:50:04 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id D1FAD26EC9; Tue, 12 Jun 2007 19:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HyCNO-0005m6-Kk; Tue, 12 Jun 2007 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Tue, 12 Jun 2007 15:50:02 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 Cc: tsvwg@ietf.org Subject: [Tsvwg] I-D ACTION:draft-ietf-tsvwg-2960bis-05.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tsvwg-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Area Working Group Working Group of the IETF. Title : Stream Control Transmission Protocol Author(s) : R. Stewart Filename : draft-ietf-tsvwg-2960bis-05.txt Pages : 150 Date : 2007-6-12 This document obsoletes RFC2960 [RFC2960] and RFC3309 [RFC3309] it describes the Stream Control Transmission Protocol (SCTP). SCTP is designed to transport PSTN signaling messages over IP networks, but is capable of broader applications. SCTP is a reliable transport protocol operating on top of a connectionless packet network such as IP. It offers the following services to its users: -- acknowledged error-free non-duplicated transfer of user data, -- data fragmentation to conform to discovered path MTU size, -- sequenced delivery of user messages within multiple streams, with an option for order-of-arrival delivery of individual user messages, -- optional bundling of multiple user messages into a single SCTP packet, and -- network-level fault tolerance through supporting of multi- homing at either or both ends of an association. The design of SCTP includes appropriate congestion avoidance behavior and resistance to flooding and masquerade attacks. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-2960bis-05.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-tsvwg-2960bis-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-tsvwg-2960bis-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-6-12134833.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-tsvwg-2960bis-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-tsvwg-2960bis-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-6-12134833.I-D@ietf.org> --OtherAccess-- --NextPart-- From tsvwg-bounces@ietf.org Wed Jun 13 03:29:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyNHr-0004rC-DG; Wed, 13 Jun 2007 03:29:03 -0400 Received: from tsvwg by megatron.ietf.org with local (Exim 4.43) id 1HyNHp-0004r7-NZ for tsvwg-confirm+ok@megatron.ietf.org; Wed, 13 Jun 2007 03:29:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyNHp-0004qz-2A for tsvwg@ietf.org; Wed, 13 Jun 2007 03:29:01 -0400 Received: from smtp.nokia.com ([131.228.20.173] helo=mgw-ext14.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HyNHn-0005kr-5q for tsvwg@ietf.org; Wed, 13 Jun 2007 03:29:01 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext14.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l5D7SacK024164; Wed, 13 Jun 2007 10:28:51 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 13 Jun 2007 10:28:49 +0300 Received: from esmgw001.ext.nokia.com ([147.243.42.25]) by esebh103.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Wed, 13 Jun 2007 10:28:49 +0300 Received: from espmg001.ext.nokia.com (espmg001.ext.nokia.com [147.243.46.49]) by esmgw001.ext.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l5D7SgmW003296; Wed, 13 Jun 2007 10:28:42 +0300 Message-ID: <1079947.1181719729630.JavaMail.root@espmg001.ext.nokia.com> Date: Wed, 13 Jun 2007 10:28:41 +0300 (EEST) From: Lars Eggert To: rbriscoe@jungle.bt.co.uk, braden@ISI.EDU, floyd@icir.org Subject: RE: [Tsvwg] Re: IETF process concerning missed RFC dependencies? Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-OriginalArrivalTime: 13 Jun 2007 07:28:49.0598 (UTC) FILETIME=[7C4FCDE0:01C7AD8C] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: magnus.westerlund@ericsson.com, tsvwg@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tsvwg-bounces@ietf.org Hi, before we move forward with anything, let's figure out what exactly the inconsistency is and what the history is. Is the change to ECN in RFC4301 technically correct, or does it cause incorrect ECN processing? In other words, are we talking about a missing "updates" dependency, or are we talking about a technical error in the ECN handling in RFC4301? What we need to do depends on which case we're talking about. Lars > -----Original Message----- > From: ext Bob Briscoe > Received: Tue Jun 12 20:17:14 EEST 2007 > To: Bob Braden > Cc: Lars Eggert, WESTERLUND, Magnus, tsvwg IETF list > Subject: Re: [Tsvwg] Re: IETF process concerning missed RFC dependencies? > > Bob, > > At 17:23 12/06/2007, Bob Braden wrote: > >>>Bob Briscoe: > >>>My question: If an RFC has been published in the past that updates > >>>another RFC, but the dependency wasn't noticed at the time, can the > >>>dependency 'just' be added to the RFC index? > > > > > >The intent is to keep the most current and correct information in the > >index, so the answer to the question is "yes", a dependency noted > >later can and should be added to the index. Just send email to > >the RFC Editor. > > That's useful to know. > > It will possibly complicate matters even further to just baldly say RFC4301 > (IPsec) updates RFC3168 (ECN), as RFC4301 doesn't clarify what bits of > RFC3168 it updates and what it doesn't. > > So, rather than emailing the RFC Editor to say this right now, I'll post > the I-D describing the contradiction between the two RFCs first, then we > can have a discussion on the list about what to do, and also in Chicago. > > However, we could certainly tell the RFC Editor that both RFC3168 and > RFC4301 update RFC2003 (IP in IP tunneling), a dependency which I also > noticed isn't identified in the RFC Index. Anyone see any objection to that? > > > Two Bob > > > > ____________________________________________________________________________ > Bob Briscoe, Networks Research Centre, BT Research > B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK. +44 1473 645196 > > > > > From tsvwg-bounces@ietf.org Wed Jun 13 04:07:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyNsi-0004ae-C6; Wed, 13 Jun 2007 04:07:08 -0400 Received: from tsvwg by megatron.ietf.org with local (Exim 4.43) id 1HyNsg-0004Zu-G7 for tsvwg-confirm+ok@megatron.ietf.org; Wed, 13 Jun 2007 04:07:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyNsg-0004Zi-4P for tsvwg@ietf.org; Wed, 13 Jun 2007 04:07:06 -0400 Received: from smtp4.smtp.bt.com ([217.32.164.151]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HyNsf-0006zO-B0 for tsvwg@ietf.org; Wed, 13 Jun 2007 04:07:06 -0400 Received: from i2kc08-ukbr.domain1.systemhost.net ([193.113.197.71]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 13 Jun 2007 09:07:04 +0100 Received: from cbibipnt08.iuser.iroot.adidom.com ([147.149.100.81]) by i2kc08-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.1830); Wed, 13 Jun 2007 09:07:04 +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 1181722023280; Wed, 13 Jun 2007 09:07:03 +0100 Received: from mut.jungle.bt.co.uk ([10.215.130.87]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id l5D86wKf011137; Wed, 13 Jun 2007 09:07:00 +0100 Message-Id: <5.2.1.1.2.20070613084305.02a3ddd0@pop3.jungle.bt.co.uk> X-Sender: rbriscoe@pop3.jungle.bt.co.uk X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Wed, 13 Jun 2007 09:07:00 +0100 To: Lars Eggert From: Bob Briscoe Subject: RE: [Tsvwg] Re: IETF process concerning missed RFC dependencies? In-Reply-To: <1079947.1181719729630.JavaMail.root@espmg001.ext.nokia.com > Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: -3.703 () ALL_TRUSTED,AWL,BAYES_00 X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 X-OriginalArrivalTime: 13 Jun 2007 08:07:04.0227 (UTC) FILETIME=[D4046730:01C7AD91] X-Spam-Score: 0.1 (/) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 Cc: magnus.westerlund@ericsson.com, braden@ISI.EDU, floyd@icir.org, tsvwg@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tsvwg-bounces@ietf.org Lars, At 08:28 13/06/2007, Lars Eggert wrote: >Hi, > >before we move forward with anything, let's figure out what exactly the >inconsistency is and what the history is. > >Is the change to ECN in RFC4301 technically correct, or does it cause >incorrect ECN processing? In other words, are we talking about a missing >"updates" dependency, or are we talking about a technical error in the ECN >handling in RFC4301? Two separate issues: 1/ Whatever the answer to Q2, I believe there would be no harm in adding two /other/ dependencies to the RFC index that I've noticed. RFC3168 (ECN) updates RFC2003 (IP in IP tunnelling) RFC4301 (IPsec) updates RFC2003 (") Anyone object to adding these right now? 2/ As I said and you said, I don't believe the contradictions between 3168 & 4301 can or should be solved by just updating the RFC index. That's why I've written a draft-I-D (to be posted as an I-D by end of this week when my co-authors have had a chance to refine it). If that became RFCXXXX, then we would add further dependencies: RFCXXXX updates RFC3168 RFCXXXX updates RFC4301 Whatever ends up being done, even if not what is planned here, RFC2003 will inherit the updates to things that already update it. Let's stop this thread on Q2 until we post the draft, but answers to Q1 are welcome pls... Bob >What we need to do depends on which case we're talking about. > >Lars > > > -----Original Message----- > > From: ext Bob Briscoe > > Received: Tue Jun 12 20:17:14 EEST 2007 > > To: Bob Braden > > Cc: Lars Eggert, WESTERLUND, Magnus, tsvwg IETF list > > Subject: Re: [Tsvwg] Re: IETF process concerning missed RFC dependencies? > > > > Bob, > > > > At 17:23 12/06/2007, Bob Braden wrote: > > >>>Bob Briscoe: > > >>>My question: If an RFC has been published in the past that updates > > >>>another RFC, but the dependency wasn't noticed at the time, can the > > >>>dependency 'just' be added to the RFC index? > > > > > > > > >The intent is to keep the most current and correct information in the > > >index, so the answer to the question is "yes", a dependency noted > > >later can and should be added to the index. Just send email to > > >the RFC Editor. > > > > That's useful to know. > > > > It will possibly complicate matters even further to just baldly say > RFC4301 > > (IPsec) updates RFC3168 (ECN), as RFC4301 doesn't clarify what bits of > > RFC3168 it updates and what it doesn't. > > > > So, rather than emailing the RFC Editor to say this right now, I'll post > > the I-D describing the contradiction between the two RFCs first, then we > > can have a discussion on the list about what to do, and also in Chicago. > > > > However, we could certainly tell the RFC Editor that both RFC3168 and > > RFC4301 update RFC2003 (IP in IP tunneling), a dependency which I also > > noticed isn't identified in the RFC Index. Anyone see any objection to > that? > > > > > > Two Bob > > > > > > > > > ____________________________________________________________________________ > > Bob Briscoe, Networks Research Centre, BT > Research > > B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK. +44 1473 > 645196 > > > > > > > > > > ____________________________________________________________________________ Bob Briscoe, Networks Research Centre, BT Research B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK. +44 1473 645196 From tsvwg-bounces@ietf.org Wed Jun 13 16:06:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyZ6g-0007z4-Dl; Wed, 13 Jun 2007 16:06:18 -0400 Received: from tsvwg by megatron.ietf.org with local (Exim 4.43) id 1HyZ6f-0007yz-MO for tsvwg-confirm+ok@megatron.ietf.org; Wed, 13 Jun 2007 16:06:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyZ6f-0007yr-Cz for tsvwg@ietf.org; Wed, 13 Jun 2007 16:06:17 -0400 Received: from smtpout.mac.com ([17.250.248.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HyZ6e-0006vE-2o for tsvwg@ietf.org; Wed, 13 Jun 2007 16:06:17 -0400 Received: from mac.com (smtpin03-en2 [10.13.10.148]) by smtpout.mac.com (Xserve/smtpout01/MantshX 4.0) with ESMTP id l5DK5xAj005762; Wed, 13 Jun 2007 13:06:07 -0700 (PDT) Received: from [192.150.186.170] (laptop170.icsi.berkeley.edu [192.150.186.170]) (authenticated bits=0) by mac.com (Xserve/smtpin03/MantshX 4.0) with ESMTP id l5DK5UAJ009142; Wed, 13 Jun 2007 13:05:39 -0700 (PDT) In-Reply-To: <5.2.1.1.2.20070613084305.02a3ddd0@pop3.jungle.bt.co.uk> References: <5.2.1.1.2.20070613084305.02a3ddd0@pop3.jungle.bt.co.uk> Mime-Version: 1.0 (Apple Message framework v624) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <674e58d79c622bbc5f9019832e4623ab@mac.com> Content-Transfer-Encoding: 7bit From: Sally Floyd Subject: Re: [Tsvwg] Re: IETF process concerning missed RFC dependencies? Date: Wed, 13 Jun 2007 13:05:27 -0700 To: Bob Briscoe X-Mailer: Apple Mail (2.624) X-Brightmail-Tracker: AAAAAA== X-Brightmail-scanned: yes X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: Magnus Westerlund , Bob Braden , tsvwg WG X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tsvwg-bounces@ietf.org Bob - > 1/ Whatever the answer to Q2, I believe there would be no harm in > adding two /other/ dependencies to the RFC index that I've noticed. > > RFC3168 (ECN) updates RFC2003 (IP in IP tunnelling) ... > Anyone object to adding these right now? That sounds good to me. - Sally http://www.icir.org/floyd/ From tsvwg-bounces@ietf.org Thu Jun 14 08:42:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hyoer-0006h6-5P; Thu, 14 Jun 2007 08:42:37 -0400 Received: from tsvwg by megatron.ietf.org with local (Exim 4.43) id 1Hyoeq-0006h1-6R for tsvwg-confirm+ok@megatron.ietf.org; Thu, 14 Jun 2007 08:42:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hyoep-0006gm-Sc for tsvwg@ietf.org; Thu, 14 Jun 2007 08:42:35 -0400 Received: from smtp5.smtp.bt.com ([217.32.164.139]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hyoeo-0005po-4y for tsvwg@ietf.org; Thu, 14 Jun 2007 08:42:35 -0400 Received: from i2kc08-ukbr.domain1.systemhost.net ([193.113.197.71]) by smtp5.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 14 Jun 2007 13:42:33 +0100 Received: from cbibipnt08.iuser.iroot.adidom.com ([147.149.100.81]) by i2kc08-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 14 Jun 2007 13:42:32 +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 1181824951555; Thu, 14 Jun 2007 13:42:31 +0100 Received: from mut.jungle.bt.co.uk ([10.86.0.156]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id l5ECgQSP005224 for ; Thu, 14 Jun 2007 13:42:29 +0100 Message-Id: <5.2.1.1.2.20070614124951.041b0978@pop3.jungle.bt.co.uk> X-Sender: rbriscoe@pop3.jungle.bt.co.uk X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Thu, 14 Jun 2007 13:42:28 +0100 To: "tsvwg IETF list" From: Bob Briscoe Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: -3.724 () ALL_TRUSTED,AWL,BAYES_00 X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 X-OriginalArrivalTime: 14 Jun 2007 12:42:32.0837 (UTC) FILETIME=[7A3FE350:01C7AE81] X-Spam-Score: 0.1 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Subject: [Tsvwg] What body is qualified to decide on Internet fairness? X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tsvwg-bounces@ietf.org TSVWG, I believe most of you will now have had time to read my contribution to the fairness debate either the I-D or the paper in ACM CCR with similar words: First I want to get a debate going around the meta-question of what body is qualified to decide on what the fairness goals of the Internet's resource sharing protocols should be. My proposal was essentially that the IETF shouldn't decide on resource sharing, but it needs to decide who/what can have control through our protocol designs. This prompted some to respond that the TSVWG, or indeed the IETF as a whole, isn't really qualified to decide on questions with such big economic implications. My response to start this debate is: The TSVWG has made many pronouncements on TCP-fairness in the past (always with the caveat that fairnes is an amorphous subject), so the TWSVWG is holding the baby. Now I'm asking the TSVWG the question "Who or what should be should be able to have policy control of fair resource allocation in our protocols?" Put another way, if the IETF doesn't want to decide on this, it should make the decision not to decide quickly and formally, as this issue is fundamental to many of the problems with the Internet Architecture. But that would leave a vacuum open for "some other body" to decide. I actually believe that the IETF is better structured than nearly any other body to ensure it reaches answers based on technical merit. However, I accept that the IETF doesn't have, and isn't expected to have, expertise when decisions require expertise in political economy. One possible answer is that we trust in our own ability to be able to intelligently consult with people we trust on economics. Then the individuals that have always made up the IETF can come to rough consensus on what the TSVWG should engineer its protocols for. The alternative is to accept "kings and voting", quoting Dave Clark. Bob Brief summary of the position I suggested in the I-D (but pls read it if you haven't): =========================================================================== My contribution was to say that the IETF shouldn't decide on resource sharing, but instead it should develop protocols to reveal the true costs of each user's actions - ie congestion caused to others on the same network and on other networks. So that each network operator can decide how much and whether to limit the share of these costs that each of its users causes. Then, the share allocated to each user of each network could effectively be decided by 'the invisible hand of the global market' but it could be overridden by social/regulatory control (e.g. universal service usage obligations, etc) in each jurisdiction. Jurisdictions could be countries or private networks connected to the Internet (e.g. "this University decrees that all users get equal rights to cause congestion to others"). All this is in the I-D. And there's proper protocol design behind it all (in referenced I-Ds). ____________________________________________________________________________ Notice: This contribution is the personal view of the author and does not necessarily reflect the technical nor commercial direction of BT plc. ____________________________________________________________________________ Bob Briscoe, Networks Research Centre, BT Research B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK. +44 1473 645196 From tsvwg-bounces@ietf.org Thu Jun 14 08:45:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyohC-0003lI-JW; Thu, 14 Jun 2007 08:45:02 -0400 Received: from tsvwg by megatron.ietf.org with local (Exim 4.43) id 1HyohB-0003l8-Nl for tsvwg-confirm+ok@megatron.ietf.org; Thu, 14 Jun 2007 08:45:01 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyohB-0003l0-Cv for tsvwg@ietf.org; Thu, 14 Jun 2007 08:45:01 -0400 Received: from smtp4.smtp.bt.com ([217.32.164.151]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Hyoh9-00060m-L2 for tsvwg@ietf.org; Thu, 14 Jun 2007 08:45:01 -0400 Received: from i2kc06-ukbr.domain1.systemhost.net ([193.113.197.70]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 14 Jun 2007 13:44:58 +0100 Received: from cbibipnt05.iuser.iroot.adidom.com ([147.149.196.177]) by i2kc06-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 14 Jun 2007 13:44:57 +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 1181825096801; Thu, 14 Jun 2007 13:44:56 +0100 Received: from mut.jungle.bt.co.uk ([10.86.0.156]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id l5ECipum005291; Thu, 14 Jun 2007 13:44:54 +0100 Message-Id: <5.2.1.1.2.20070612181819.04160d38@pop3.jungle.bt.co.uk> X-Sender: rbriscoe@pop3.jungle.bt.co.uk X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Thu, 14 Jun 2007 13:44:53 +0100 To: "James M. Polk" From: Bob Briscoe Subject: Re: [Tsvwg] Building the TSVWG agenda for Chicago IETF In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: -3.728 () ALL_TRUSTED,AWL,BAYES_00 X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 X-OriginalArrivalTime: 14 Jun 2007 12:44:57.0903 (UTC) FILETIME=[D0B733F0:01C7AE81] X-Spam-Score: 0.1 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Cc: tsvwg X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tsvwg-bounces@ietf.org James, My tsvwg slot requests: 1/ "Layered Encapsulation of Congestion Notification" Presenter: Bob Briscoe draft-briscoe-tsvwg-ecn-tunnel-00 New initial I-D (tba shortly) 10mins 2/ "Byte and Packet Congestion Notification" Presenter: Bob Briscoe draft-briscoe-tsvwg-byte-pkt-mark-00 New initial I-D (tba shortly) 10mins 3/ "Flow Rate Fairness: Dismantling a Religion" Presenter: Bob Briscoe draft-briscoe-tsvarea-fair-02.pdf (-01 is currently up there) 10mins I'm happy with the new early arrangements. I've always thought it's unfair on small outfits to expect them to have to arrange travel before they know whether they are on the agenda. Bob At 04:40 12/06/2007, James M. Polk wrote: >Hey TSVWG > >I'm starting to build our agenda for the upcoming IETF in Chicago. I will >be running the agenda again this meeting, so send me your agenda requests. > >Something's new this meeting - we (meaning I) have almost zero time to do >this in. Here's what I mean: > >- submission cut-off for -00 IDs is July 2nd. Draft agendas are due July 2nd. > >- revised ID cut-off is July 9th, and FINAL agendas are due July 9th. > >Every meeting I get a request (or two ... or three) for session time after >an ID is announced, meaning around the 12th or 13th. This is too late >this meeting. > >So, everyone that wants TSVWG agenda time to discuss a submitted Internet >Draft needs to let me know about the time request EARLY. > >I need the following for every ID: > >- Presenter's name (point of contact about presentation) >- ID filename >- ID itself (if not submitted to me when ID was submitted to the Secretary) >- the amount of time requested to present > >WG items will get precedence over non-WG items for time. Like topics are >generally grouped together where possible. > >If you don't request time early, and there is no time remaining within the >allotted timeslot (because others beat you to me), well..... there's >always next meeting ;-) > >[that last part is only half joking] > > > > >Cheers, >James >IETF TSVWG co-chair > > *********************************** > "It should NEVER be inconvenient to do the right thing" ____________________________________________________________________________ Bob Briscoe, Networks Research Centre, BT Research B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK. +44 1473 645196 From tsvwg-bounces@ietf.org Thu Jun 14 09:59:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyprR-0005SO-51; Thu, 14 Jun 2007 09:59:41 -0400 Received: from tsvwg by megatron.ietf.org with local (Exim 4.43) id 1HyprQ-0005Nd-8g for tsvwg-confirm+ok@megatron.ietf.org; Thu, 14 Jun 2007 09:59:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyprP-0005MF-TT for tsvwg@ietf.org; Thu, 14 Jun 2007 09:59:39 -0400 Received: from mx1.grc.nasa.gov ([128.156.11.68]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HyprP-0004th-HY for tsvwg@ietf.org; Thu, 14 Jun 2007 09:59:39 -0400 Received: from lombok-fi.grc.nasa.gov (seraph.grc.nasa.gov [128.156.10.10]) by mx1.grc.nasa.gov (Postfix) with ESMTP id 3BC0EC312 for ; Thu, 14 Jun 2007 09:59:38 -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 l5EDxZKO017524; Thu, 14 Jun 2007 09:59:37 -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 l5EDxX0u029508; Thu, 14 Jun 2007 09:59:33 -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 KdNVmIlJRhrX; Thu, 14 Jun 2007 09:59:33 -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 l5EDxLMJ029416;Thu, 14 Jun 2007 09:59:32 -0400 (EDT) Received: by drpepper.grc.nasa.gov (Postfix, from userid 501)id 791874FEA3; Thu, 14 Jun 2007 09:57:31 -0400 (EDT) Date: Thu, 14 Jun 2007 09:57:31 -0400 From: Wesley Eddy To: Bob Briscoe Subject: Re: [Tsvwg] What body is qualified to decide on Internet fairness? Message-ID: <20070614135731.GD18790@grc.nasa.gov> References: <5.2.1.1.2.20070614124951.041b0978@pop3.jungle.bt.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5.2.1.1.2.20070614124951.041b0978@pop3.jungle.bt.co.uk> User-Agent: Mutt/1.5.5.1i X-imss-version: 2.046 X-imss-result: Passed X-imss-scores: Clean:55.79550 C:2 M:3 S:5 R:5 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: tsvwg IETF list X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: weddy@grc.nasa.gov List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tsvwg-bounces@ietf.org On Thu, Jun 14, 2007 at 01:42:28PM +0100, Bob Briscoe wrote: > > My proposal was essentially that the IETF shouldn't decide on resource > sharing, but it needs to decide who/what can have control through our > protocol designs. This prompted some to respond that the TSVWG, or indeed > the IETF as a whole, isn't really qualified to decide on questions with > such big economic implications. > When I think about all the work people have done on fairness mechanisms, nearly all of it resides outside the IETF in either academic work or products (e.g. AQMs, BW caps, etc.). OF course, the TCP and TFRC congestion control algorithms affect fairness, but from the IETF's perspective it seems like we focus more on making sure they attain some sustainable level of performance that's reasonably efficient, rather than focusing on meeting some particular fairness concept. Certainly with TFRC's design fairness was more of a consideration than with TCP's design, but the 'F' does stand for 'friendly' and is wrapped up in the notion of TCP-compatible, which isn't quite the same as 'fair'. So my opinion (that might be wrong) is that the IETF's goal has implicitly been (and should continue to be) to produce efficient protocols that don't melt down the network, but have no explicit design goal of meeting any particular notion of fairness. If, based on some particular concept of fairness, obtaining a fair allocation requires protocol mechanisms that need interoperability (i.e. *not* just AQMs, rate-limits, or other "within-a-router" goop), then that could be work that the IETF does. This seems like where re-ECN falls in, maybe. But, the IETF has not, and probably should not, endorse or mandate that transports conform to specific fairness concepts, as we have null ability to predict how the network and its usage evolve. Does this agree or disagree with what your position is? -- Wesley M. Eddy Verizon Federal Network Systems From tsvwg-bounces@ietf.org Thu Jun 14 10:30:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyqKq-0002HC-HU; Thu, 14 Jun 2007 10:30:04 -0400 Received: from tsvwg by megatron.ietf.org with local (Exim 4.43) id 1HyqKo-0002Gu-KT for tsvwg-confirm+ok@megatron.ietf.org; Thu, 14 Jun 2007 10:30:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyqKo-0002Gm-Ak for tsvwg@ietf.org; Thu, 14 Jun 2007 10:30:02 -0400 Received: from smtp2.smtp.bt.com ([217.32.164.150]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HyqKm-00049p-L6 for tsvwg@ietf.org; Thu, 14 Jun 2007 10:30:02 -0400 Received: from i2kc08-ukbr.domain1.systemhost.net ([193.113.197.71]) by smtp2.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 14 Jun 2007 15:29:59 +0100 Received: from cbibipnt08.iuser.iroot.adidom.com ([147.149.100.81]) by i2kc08-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 14 Jun 2007 15:29:59 +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 1181831398433; Thu, 14 Jun 2007 15:29:58 +0100 Received: from mut.jungle.bt.co.uk ([10.86.0.156]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id l5EETqQr009501; Thu, 14 Jun 2007 15:29:55 +0100 Message-Id: <5.2.1.1.2.20070614151944.041b0c58@pop3.jungle.bt.co.uk> X-Sender: rbriscoe@pop3.jungle.bt.co.uk X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Thu, 14 Jun 2007 15:29:54 +0100 To: weddy@grc.nasa.gov From: Bob Briscoe Subject: Re: [Tsvwg] What body is qualified to decide on Internet fairness? In-Reply-To: <20070614135731.GD18790@grc.nasa.gov> References: <5.2.1.1.2.20070614124951.041b0978@pop3.jungle.bt.co.uk> <5.2.1.1.2.20070614124951.041b0978@pop3.jungle.bt.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: -3.75 () ALL_TRUSTED,AWL,BAYES_00 X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 X-OriginalArrivalTime: 14 Jun 2007 14:29:59.0581 (UTC) FILETIME=[7CCEF4D0:01C7AE90] X-Spam-Score: 0.1 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: tsvwg IETF list X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tsvwg-bounces@ietf.org Wes, At 14:57 14/06/2007, Wesley Eddy wrote: >So my opinion (that might be wrong) is that the IETF's goal has >implicitly been (and should continue to be) to produce efficient >protocols that don't melt down the network, but have no explicit design >goal of meeting any particular notion of fairness. > >If, based on some particular concept of fairness, obtaining a fair allocation >requires protocol mechanisms that need interoperability (i.e. *not* just >AQMs, rate-limits, or other "within-a-router" goop), then that could be >work that the IETF does. This seems like where re-ECN falls in, maybe. >But, the IETF has not, and probably should not, endorse or mandate that >transports conform to specific fairness concepts, as we have null >ability to predict how the network and its usage evolve. > >Does this agree or disagree with what your position is? Well, this sort-of agrees with what I'm saying, but only by side-stepping the biggest issue... I think you're heavily underplaying the sway that the implicit assumption of flow-rate fairness has had over everything the IETF has done. That has led the outcome (in terms of shares of resources) to a very distorted place (mainly because it ensures instantaneous equality which hugely favours long-running flows). The question can be put most pointedly as: once we take that flow rate fairness consensus away, what fairness control do we put in TCP, which after all still accounts for over 90% of all traffic globally? TCP's cc algo is unquestionably the TSV-AREA's baby. Bob ____________________________________________________________________________ Bob Briscoe, Networks Research Centre, BT Research B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK. +44 1473 645196 From tsvwg-bounces@ietf.org Thu Jun 14 11:03:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hyqr6-0005FL-3b; Thu, 14 Jun 2007 11:03:24 -0400 Received: from tsvwg by megatron.ietf.org with local (Exim 4.43) id 1Hyqr4-0005Df-Bd for tsvwg-confirm+ok@megatron.ietf.org; Thu, 14 Jun 2007 11:03:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hyqr3-0005Cw-Ks; Thu, 14 Jun 2007 11:03:21 -0400 Received: from smtp.nokia.com ([131.228.20.170] helo=mgw-ext11.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hyqqx-0007AT-BG; Thu, 14 Jun 2007 11:03:21 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext11.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l5EF2wiP027639; Thu, 14 Jun 2007 18:03:08 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 14 Jun 2007 18:02:58 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 14 Jun 2007 18:02:58 +0300 Received: from mgw-int02.ntc.nokia.com ([172.21.143.97]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Thu, 14 Jun 2007 18:02:57 +0300 Received: from [172.21.35.101] (esdhcp035101.research.nokia.com [172.21.35.101]) by mgw-int02.ntc.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l5EF2uBR006926; Thu, 14 Jun 2007 18:02:56 +0300 In-Reply-To: <36B3B805-BCD5-4490-9F5F-87BC56FC5453@nokia.com> References: <26B285A9-3D4C-43B1-9C32-37EBC4AF39BE@nokia.com><0260FF1D-E29B-4D91-991D-612E77F53970@nokia.com> <36B3B805-BCD5-4490-9F5F-87BC56FC5453@nokia.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-36--484772557; protocol="application/pkcs7-signature" Message-Id: <7C820D53-0415-4A29-856E-624E643D2A2E@nokia.com> From: Lars Eggert Subject: Re: [Tsvwg] Re: [tsv-area] consensus call: bringing new congestion control to the IETF Date: Thu, 14 Jun 2007 18:02:53 +0300 To: "TSV Area" X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 14 Jun 2007 15:02:57.0448 (UTC) FILETIME=[17B58280:01C7AE95] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: a1dc446dc7ac353b90b60743d0e479e3 Cc: iccrg@cs.ucl.ac.uk, tsvwg WG X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tsvwg-bounces@ietf.org --Apple-Mail-36--484772557 Content-Type: multipart/mixed; boundary=Apple-Mail-35--484773202 --Apple-Mail-35--484773202 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed On 2007-4-20, at 12:57, ext Lars Eggert wrote: > On 2007-4-6, at 11:01, ext Lars Eggert wrote: >> after the presentation at TSVAREA, there was strong consensus in >> the room for the presented process to bring new congestion control >> to the IETF. I'd like to confirm that the community as a whole has >> consensus on this. >> >> Please take a look at the following draft ION, which describes the >> process from the presentation: http://www.ietf.org/IESG/content/ >> ions/drafts/ion-tsv-alt-cc.txt >> >> The consensus call will run until April 18, 2007. Please review >> the draft ION and send comments by the deadline. > > I have seen very few comments during this consensus call, but all > where positive. Together with the strong positive feedback from > Prague, my take is that we have community consensus on this > procedure. If you think I'm misjudging the consensus, please yell. This ION has since been discussed by the IESG and several changes have been suggested that I have rolled into a new revision. Mostly, these changes clarify that the expert review in the ICCRG that the ION describes is a mechanism that the transport ADs are free to employ anyway for documents that the area produces. It only clarifies that for new congestion control schemes, the ADs _will_ request such an expert review. I'd like to double-check that the area still has consensus on the revised ION, before I bring it back to the IESG for final approval. Please send comments by next Friday, June 22. (Eventually, the new revision should be accessible at the URL above; for now, it is in the svn repository at http://www3.tools.ietf.org/ group/iesg/trac/browser/ions/drafts/ion-tsv-alt-cc.txt?format=txt - make sure you're reviewing the version dated June 14. I'm attaching a diff below.) Lars --Apple-Mail-35--484773202 Content-Transfer-Encoding: 7bit Content-Type: text/html; x-unix-mode=0644; name=ion-tsv-alt-cc.txt-from-.diff.html Content-Disposition: attachment; filename=ion-tsv-alt-cc.txt-from-.diff.html Diff: ion-tsv-alt-cc.txt - ion-tsv-alt-cc.txt
 ion-tsv-alt-cc.txt   ion-tsv-alt-cc.txt 
skipping to change at page 1, line 17 skipping to change at page 1, line 17
Name: ion-tsv-alt-cc Name: ion-tsv-alt-cc
Title: Experimental Specification of New Congestion Control Title: Experimental Specification of New Congestion Control
Algorithms Algorithms
To be approved by: IESG To be approved by: IESG
Editor: Lars Eggert Editor: Lars Eggert
Discussion forum: tsv-area@ietf.org Discussion forum: tsv-area@ietf.org
Abstract Abstract
This document describes the approach for bringing new congestion This document describes the process that the IETF transport area
control algorithms to the IRTF and IETF for specification and directors employ when new congestion control algorithms that differ
publication as Experimental RFCs. significantly from currently-published IETF standards are brought to
the IETF for specification and publication as Experimental RFCs.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Experimental Specification of New Congestion Control 2. Experimental Specification of New Congestion Control
Algorithms . . . . . . . . . . . . . . . . . . . . . . . . . . 3 Algorithms . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 4
4. References . . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5
Appendix A. Informational Documentation of Implementation Appendix A. Informational Documentation of Implementation
Choices . . . . . . . . . . . . . . . . . . . . . . . 5 Choices . . . . . . . . . . . . . . . . . . . . . . . 5
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 5 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 5
1. Introduction 1. Introduction
For a number of years, there has been considerable interest in the For a number of years, there has been considerable interest in the
research community on new congestion control algorithms that diverge research community on new congestion control algorithms that diverge
from the congestion control standards specified in the IETF. from the congestion control standards specified in the IETF, for
which [RFC2914] outlines the principles.
One main current motivation for such new congestion control One current motivation for such new congestion control algorithms
algorithms [I-D.ietf-tsvwg-cc-alt] is better support for high-speed [I-D.ietf-tsvwg-cc-alt] is better support for high-speed paths.
paths. Research in this area has resulted in a number of promising Research in this area has resulted in a number of promising
congestion control variants. Bandwidths that have been considered congestion control variants. Bandwidths that have been considered
"high-speed" years ago are now readily available to consumers in many "high-speed" years ago are now readily available to consumers in many
countries, resulting in a corresponding interest by the operating countries, resulting in a corresponding interest by the operating
system community to deliver mechanisms to the users that can system community to deliver mechanisms to the users that can
efficiently use these kinds of network paths. Several widely- efficiently use these kinds of network paths. Several widely-
deployed operating systems already implement non-RFC-compliant deployed operating systems already implement non-RFC-compliant
congestion control mechanisms for this purpose. This is happening congestion control mechanisms for this purpose. This is happening
without much community review and often without a publicly available without much community review and often without a publicly available
technical specification, which is troubling. technical specification, which is troubling.
The IETF and IRTF offer to be a venue for community discussion and The IETF transport area offers to be a venue for community discussion
review, followed by an eventual technical specification, of new and review, followed by an eventual technical specification, of new
congestion control variants. congestion control variants that go beyond the IETF's general
congestion control principles [RFC2914].
Section 2 describes the approach for bringing new congestion control Section 2 describes the process that the IETF transport area
algorithms to the IETF's transport area for specification and directors employ when new congestion control algorithms are brought
publication as Experimental RFCs, following a review phase in the to the Transport Area for specification and publication as
IRTF's Internet Congestion Control Research Group (ICCRG). After Experimental RFCs. The main feature of this process is an expert
presentation and discussion during the ICCRG meeting in February 2007 review phase performed by the IRTF's Internet Congestion Control
and the TSV area meeting during IETF-68 in March 2007, the community Research Group (ICCRG). The decision of whether a specific new
established consensus on the process described in this document. At congestion control schemes goes beyond the principles of [RFC2914]
the time of writing, there are at least three congestion control and hence will undergo the process described in this document lies
with the transport area directors, who will use the expertise of the
transport area directorate and other congestion control experts to
aid their decision.
The wider transport community established consensus on this process
after the presentation and discussion during the ICCRG meeting in
February 2007 and the TSV area meeting during IETF-68 in March 2007.
At the time of writing, there are at least three congestion control
algorithms that have been proposed for Experimental specification algorithms that have been proposed for Experimental specification
through this process. through this process.
2. Experimental Specification of New Congestion Control Algorithms 2. Experimental Specification of New Congestion Control Algorithms
The main goal of this process is to publish a number of thoroughly- The main goal of this process is to publish a number of thoroughly-
analyzed congestion control variants as Experimental RFCs. These analyzed congestion control variants as Experimental RFCs. These
documents will be published with statements that indicate that the documents will be published with statements that indicate that the
IETF believes them to be safe for experimentation on the Internet, or IETF believes them to be safe for experimentation on the Internet, or
safe for experimentation in certain more restricted network safe for experimentation in certain more restricted network
environments. This is similar, for example, to the statements the environments. This is similar, for example, to the statements the
IETF made for QuickStart [RFC4782] or HighSpeed TCP [RFC3649]. IETF made for QuickStart [RFC4782] or HighSpeed TCP [RFC3649].
To be able to make such statements about Experimental congestion To be able to make such statements about Experimental congestion
control variants, a review phase needs to occur in the community. control variants, a review phase needs to occur in the community.
The proposal is to use the expertise in the IRTF's Internet The transport area directors will use the expertise in the IRTF's
Congestion Control Research Group (ICCRG) during the initial phase of Internet Congestion Control Research Group (ICCRG) to perform an
this review. The proposers of high-speed congestion control variants expert review during the initial phase of this process. The
will present their mechanism and results to the ICCRG, which will proposers of high-speed congestion control variants will present
analyze and discuss these variants with the goal of determining their mechanism and results to the ICCRG, which will analyze and
whether they can be declared safe for experimentation, and under discuss these variants with the goal of determining whether they can
which conditions. [I-D.irtf-tmrg-metrics] defines some metrics that be declared safe for experimentation, and under which conditions.
will be useful during this review. [I-D.ietf-tsvwg-cc-alt] describes [I-D.irtf-tmrg-metrics] defines some metrics that will be useful
the consensus of the IETF transport area on the best current practice during this expert review. [I-D.ietf-tsvwg-cc-alt] describes the
in evaluating new congestion control algorithms, which the ICCRG consensus of the IETF transport area on the best current practice in
review should consider. evaluating new congestion control algorithms, which the ICCRG review
should consider.
The ICCRG will document the results of their review in a write-up, The ICCRG will document the results of their expert review in a
which will accompany a new congestion control algorithm when it is write-up, which will accompany a new congestion control algorithm
proposed for follow-on technical specification in the IETF's when it is proposed for follow-on technical specification in the
transport area. Current consensus is to add a work item to the IETF's transport area. Current consensus is to add a work item to
charter of the TCP Maintenance and Minor Extensions (TCPM) working the charter of the TCP Maintenance and Minor Extensions (TCPM)
group for the Experimental standardization of such ICCRG-reviewed working group for the Experimental standardization of such ICCRG-
congestion control variants. reviewed congestion control variants, because all current proposals
in this space are TCP modifications. In the future, new congestion
control variants for other protocols may become work items of other
working groups.
When new congestion control algorithms are brought to the IETF When new congestion control algorithms that significantly differ from
without prior review by the ICCRG, it will redirect the proposers to the general congestion control principles outlined in [RFC2914] are
the ICCRG. The RFC Editor is encouraged to do the same for brought to the IETF transport area without a prior expert review by
independent submissions [I-D.iab-rfc-independent]. the ICCRG, the transport area directors will request the ICCRG to
perform such a review as an initial step. The RFC Editor is
encouraged to do the same for independent submissions
[I-D.iab-rfc-independent].
3. Acknowledgments 3. Acknowledgments
Thanks to Mark Allman, Brian Carpenter, Ted Faber, Sally Floyd and Thanks to Mark Allman, Brian Carpenter, Ted Faber, Sally Floyd,
Michael Welzl for their comments on this document. Cullen Jennings and Michael Welzl for their comments on this
document.
4. References 4. References
[I-D.iab-rfc-independent] [I-D.iab-rfc-independent]
Klensin, J. and D. Thaler, "Independent Submissions to the Klensin, J. and D. Thaler, "Independent Submissions to the
RFC Editor", draft-iab-rfc-independent-00 (work in RFC Editor", draft-iab-rfc-independent-00 (work in
progress), March 2007. progress), March 2007.
[I-D.ietf-tsvwg-cc-alt] [I-D.ietf-tsvwg-cc-alt]
Floyd, S. and M. Allman, "Specifying New Congestion Floyd, S. and M. Allman, "Specifying New Congestion
Control Algorithms", draft-ietf-tsvwg-cc-alt-00 (work in Control Algorithms", draft-ietf-tsvwg-cc-alt-02 (work in
progress), March 2007. progress), April 2007.
[I-D.irtf-tmrg-metrics] [I-D.irtf-tmrg-metrics]
Floyd, S., "Metrics for the Evaluation of Congestion Floyd, S., "Metrics for the Evaluation of Congestion
Control Mechanisms", draft-irtf-tmrg-metrics-08 (work in Control Mechanisms", draft-irtf-tmrg-metrics-09 (work in
progress), March 2007. progress), March 2007.
[RFC2914] Floyd, S., "Congestion Control Principles", BCP 41,
RFC 2914, September 2000.
[RFC3649] Floyd, S., "HighSpeed TCP for Large Congestion Windows", [RFC3649] Floyd, S., "HighSpeed TCP for Large Congestion Windows",
RFC 3649, December 2003. RFC 3649, December 2003.
[RFC4782] Floyd, S., Allman, M., Jain, A., and P. Sarolahti, "Quick- [RFC4782] Floyd, S., Allman, M., Jain, A., and P. Sarolahti, "Quick-
Start for TCP and IP", RFC 4782, January 2007. Start for TCP and IP", RFC 4782, January 2007.
Appendix A. Informational Documentation of Implementation Choices Appendix A. Informational Documentation of Implementation Choices
The IETF encourages vendors of network stacks to describe their The IETF encourages vendors of network stacks to describe their
implementation choices for the information of the community, and implementation choices for the information of the community, and
 End of changes. 13 change blocks. 
46 lines changed or deleted 68 lines changed or added

This html diff was produced by rfcdiff 1.33. The latest version is available from http://tools.ietf.org/tools/rfcdiff/
--Apple-Mail-35--484773202-- --Apple-Mail-36--484772557 Content-Transfer-Encoding: base64 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGQDCCAvkw ggJioAMCAQICEGtxkLFHQu1g67hlmYfwPuIwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDEwNDE2MTE1NFoXDTA4MDEwNDE2MTE1 NFowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEA26hjntVPZMiwh4d8tyuk9KiucvG92BVUGArk5zO1jhmq7tLFgU1mqcIg VGumfQqjkAzIuh83kxIiqBrB05Wvxp85apwt4sUCvzMe8mQWzZZZYp0rBzwpOj+VC5pxsMRYtYW+ BaTFBEmvFr7D7C7roZUk0lDppS5SZFs4SQbEe9ykB9aeUf1iTiw2+ikyP2+JEYto14WYCoxFWbms FbQ1uaaK+yn1WH2YHhyMfi0IOxuT0jtbsngjHJMpWIqq334zBhj+rPSUug47YBHr41FCDMHbbbjv WbyTyDYneOW3WY8LY8bGWVlAknQGB7lgduShe6e0RI/7SL/VE6X27lM9LwIDAQABozIwMDAgBgNV HREEGTAXgRVsYXJzLmVnZ2VydEBub2tpYS5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUF AAOBgQCx3nxxTg/WowobVTRXBiXUEEZj4LBiunWbuAnR0UbJIgijvq3JbiJvZo2gUGiW9LPaHSBz 4oxT1VR/S/6O0a4e87oV5cOQm6ReB68o9rDfUzxHTwoCfv2wwMwBrXyzQMjyQK4Lt8siV41gmZpm rSXMhjTJdd9uYYNoZKQLq+VM+TCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJ BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgG A1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMg RGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3 DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3 MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9 fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+ uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMB Af8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3 dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgG A1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcP f6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH 2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8x ggMQMIIDDAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAo UHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ a3GQsUdC7WDruGWZh/A+4jAJBgUrDgMCGgUAoIIBbzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw0wNzA2MTQxNTAyNTRaMCMGCSqGSIb3DQEJBDEWBBQmRinlw4okB+Jz MNOrVdORPAc5TjCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIwgYcGCyqGSIb3DQEJEAILMXigdjBiMQsw CQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIw DQYJKoZIhvcNAQEBBQAEggEAF1vlicCFDjiI5zAmxr9+puBhGMsq/Ky06Hl8t6A9x0XXlPFZPa85 vtasLXYV1u+b+KwwC2WClqBtfCnJPb+VugZ6EMKZjTQV/rM6SbNLpU6czTrPIB/BFsbNmVATD0eZ iTguwNxMZmWj2G7+ZIebHPX4YitkohVrJYNowzMSOOR4d3fPhHWJw9z2BO3bI11GJDpT2tf8iCVk Q7ihgiEqNUT3QNq7K3vqS9qen+i6q1pK7JHrEu1/EzfPp8TPUSw5U7WaUd/f9aCLqkopgA3Q0W6L hfFHiZe2TQ5/njzoL7fvWxDp9VszRBr0RXsnd6ItaQA9oNEQhsWsZ5Jwd0LF/gAAAAAAAA== --Apple-Mail-36--484772557-- From tsvwg-bounces@ietf.org Thu Jun 14 13:13:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyssP-0002FS-F7; Thu, 14 Jun 2007 13:12:53 -0400 Received: from tsvwg by megatron.ietf.org with local (Exim 4.43) id 1HyssN-0002Eq-V3 for tsvwg-confirm+ok@megatron.ietf.org; Thu, 14 Jun 2007 13:12:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyssN-0002EV-Bf; Thu, 14 Jun 2007 13:12:51 -0400 Received: from smtpout.mac.com ([17.250.248.185]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HyssL-0001kt-0q; Thu, 14 Jun 2007 13:12:51 -0400 Received: from mac.com (smtpin02-en2 [10.13.10.147]) by smtpout.mac.com (Xserve/smtpout15/MantshX 4.0) with ESMTP id l5EHCgQe021983; Thu, 14 Jun 2007 10:12:42 -0700 (PDT) Received: from [192.168.1.64] (adsl-70-132-2-141.dsl.snfc21.sbcglobal.net [70.132.2.141]) (authenticated bits=0) by mac.com (Xserve/smtpin02/MantshX 4.0) with ESMTP id l5EHCC2A002654; Thu, 14 Jun 2007 10:12:27 -0700 (PDT) In-Reply-To: <7C820D53-0415-4A29-856E-624E643D2A2E@nokia.com> References: <26B285A9-3D4C-43B1-9C32-37EBC4AF39BE@nokia.com> <0260FF1D-E29B-4D91-991D-612E77F53970@nokia.com> <36B3B805-BCD5-4490-9F5F-87BC56FC5453@nokia.com> <7C820D53-0415-4A29-856E-624E643D2A2E@nokia.com> Mime-Version: 1.0 (Apple Message framework v624) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <178a4a9c4c6789ea63ff086b009314b7@mac.com> Content-Transfer-Encoding: 7bit From: Sally Floyd Subject: Re: [Tsvwg] Re: [tsv-area] consensus call: bringing new congestion control to the IETF Date: Thu, 14 Jun 2007 10:12:11 -0700 To: Lars Eggert X-Mailer: Apple Mail (2.624) X-Brightmail-Tracker: AAAAAA== X-Brightmail-scanned: yes X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: iccrg@cs.ucl.ac.uk, TSV Area , tsvwg WG X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tsvwg-bounces@ietf.org > I'd like to double-check that the area still has consensus on the > revised ION, before I bring it back to the IESG for final approval. > Please send comments by next Friday, June 22. I looked over the changes, and I support this document moving to the IESG for final approval. - Sally http://www.icir.org/floyd/ From tsvwg-bounces@ietf.org Thu Jun 14 13:48:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HytQR-0000Vy-O7; Thu, 14 Jun 2007 13:48:03 -0400 Received: from tsvwg by megatron.ietf.org with local (Exim 4.43) id 1HytQQ-0000SX-7Y for tsvwg-confirm+ok@megatron.ietf.org; Thu, 14 Jun 2007 13:48:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HytQP-0000QS-Sv for tsvwg@ietf.org; Thu, 14 Jun 2007 13:48:01 -0400 Received: from mx1.grc.nasa.gov ([128.156.11.68]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HytQP-0002vY-Cj for tsvwg@ietf.org; Thu, 14 Jun 2007 13:48:01 -0400 Received: from lombok-fi.grc.nasa.gov (seraph.grc.nasa.gov [128.156.10.10]) by mx1.grc.nasa.gov (Postfix) with ESMTP id 2F7B9C313 for ; Thu, 14 Jun 2007 13:47:59 -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 l5EHlCV3029454; Thu, 14 Jun 2007 13:47:12 -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 l5EHkKSI025882; Thu, 14 Jun 2007 13:47:12 -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 uj+kh0C97ZUu; Thu, 14 Jun 2007 13:46:20 -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 l5EHkIG7025872;Thu, 14 Jun 2007 13:46:18 -0400 (EDT) Received: by drpepper.grc.nasa.gov (Postfix, from userid 501)id B78674FEA3; Thu, 14 Jun 2007 13:44:27 -0400 (EDT) Date: Thu, 14 Jun 2007 13:44:27 -0400 From: Wesley Eddy To: Bob Briscoe Subject: Re: [Tsvwg] What body is qualified to decide on Internet fairness? Message-ID: <20070614174427.GN18790@grc.nasa.gov> References: <20070614135731.GD18790@grc.nasa.gov> <5.2.1.1.2.20070614151944.041b0c58@pop3.jungle.bt.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5.2.1.1.2.20070614151944.041b0c58@pop3.jungle.bt.co.uk> User-Agent: Mutt/1.5.5.1i X-imss-version: 2.046 X-imss-result: Passed X-imss-scores: Clean:99.90000 C:2 M:3 S:5 R:5 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: tsvwg IETF list X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: weddy@grc.nasa.gov List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tsvwg-bounces@ietf.org On Thu, Jun 14, 2007 at 03:29:54PM +0100, Bob Briscoe wrote: > > > >Does this agree or disagree with what your position is? > > Well, this sort-of agrees with what I'm saying, but only by side-stepping > the biggest issue... That's what I expected :). > I think you're heavily underplaying the sway that the implicit assumption > of flow-rate fairness has had over everything the IETF has done. That has > led the outcome (in terms of shares of resources) to a very distorted place > (mainly because it ensures instantaneous equality which hugely favours > long-running flows). This is the part I'm not sure about, and maybe this is because I wasn't around in 1988 when some of these decisions started to be made. I'm not quite convinced (yet) that flow-rate fairness is the basis of all that we've done. It doesn't seem completely evident from the original sources, nor is it what was achieved! As you've pointed out, our mechanisms have pretty bad RTT unfairness, when evaluated in the flow-rate paradigm. To me, it seems like this is clear evidence that flow-rate fairness wasn't a primary goal, or it would've been better acheived, but maybe someone with a longer beard can either verify or correct that. It would be interesting to hear. > The question can be put most pointedly as: once we take that flow rate > fairness consensus away, what fairness control do we put in TCP, which > after all still accounts for over 90% of all traffic globally? TCP's cc > algo is unquestionably the TSV-AREA's baby. That would be the right question if there was definite consensus that there was both (1) a TCP basis in flow-rate fairness, and (2) a need to remove that basis. I'm not totally convinced of (1); in fact I fully disagree with it, based on my understanding of source material. In the 1988 Jacobson and Karels paper, the end-host congestion control design is done without any attempt at fairness. Fairness is mentioned mainly in the section on gateway-mechanisms, NOT end-host mechanisms. The discovery that this design resulted in flow-rate fairness seems to have come later in history, and been a happy side-effect. As for (2), if there isn't a basis, how can we remove it? I think our disagreement is whether flow-rate fairness is a basis or a side-effect in TCP congestion control. Do we agree on that? -- Wesley M. Eddy Verizon Federal Network Systems From tsvwg-bounces@ietf.org Thu Jun 14 18:51:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hyy9f-0007hl-OU; Thu, 14 Jun 2007 18:51:03 -0400 Received: from tsvwg by megatron.ietf.org with local (Exim 4.43) id 1Hyy9D-0006hs-37 for tsvwg-confirm+ok@megatron.ietf.org; Thu, 14 Jun 2007 18:50:35 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hyy9B-0006do-Gt; Thu, 14 Jun 2007 18:50:33 -0400 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Hyy9B-0004I3-6s; Thu, 14 Jun 2007 18:50:33 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id A5EC9175D5; Thu, 14 Jun 2007 22:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1Hyy8g-0005Hr-DT; Thu, 14 Jun 2007 18:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Thu, 14 Jun 2007 18:50:02 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: tsvwg@ietf.org Subject: [Tsvwg] I-D ACTION:draft-ietf-tsvwg-sctpthreat-05.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tsvwg-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Area Working Group Working Group of the IETF. Title : Security Attacks Found Against SCTP and Current Countermeasures Author(s) : R. Stewart, et al. Filename : draft-ietf-tsvwg-sctpthreat-05.txt Pages : 16 Date : 2007-6-14 This document describes certain security threats to SCTP. It also describes ways to mitigate these threats, in particular by using techniques from the SCTP Specification Errata and Issues memo (RFC 4460). These techniques are included in RFC 4960, which obsoletes RFC 2960. It is hoped that this information will provide some useful background information for many of the newest requirements spelled out in the SCTP Specification Errata and Issues and included in RFC 4960. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-sctpthreat-05.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-tsvwg-sctpthreat-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-tsvwg-sctpthreat-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-6-14151953.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-tsvwg-sctpthreat-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-tsvwg-sctpthreat-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-6-14151953.I-D@ietf.org> --OtherAccess-- --NextPart-- From tsvwg-bounces@ietf.org Thu Jun 14 19:32:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hyynr-0006T0-Jq; Thu, 14 Jun 2007 19:32:35 -0400 Received: from tsvwg by megatron.ietf.org with local (Exim 4.43) id 1Hyynr-0006Sv-6n for tsvwg-confirm+ok@megatron.ietf.org; Thu, 14 Jun 2007 19:32:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hyynq-0006Sn-Qz for tsvwg@ietf.org; Thu, 14 Jun 2007 19:32:34 -0400 Received: from smtp4.smtp.bt.com ([217.32.164.151]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hyynp-00080F-08 for tsvwg@ietf.org; Thu, 14 Jun 2007 19:32:34 -0400 Received: from i2kc06-ukbr.domain1.systemhost.net ([193.113.197.70]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 15 Jun 2007 00:32:32 +0100 Received: from cbibipnt05.iuser.iroot.adidom.com ([147.149.196.177]) by i2kc06-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.1830); Fri, 15 Jun 2007 00:32:32 +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 118186395172; Fri, 15 Jun 2007 00:32:31 +0100 Received: from mut.jungle.bt.co.uk ([10.86.0.17]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id l5ENWORJ030733; Fri, 15 Jun 2007 00:32:26 +0100 Message-Id: <5.2.1.1.2.20070614214201.0405ec80@pop3.jungle.bt.co.uk> X-Sender: rbriscoe@pop3.jungle.bt.co.uk X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Fri, 15 Jun 2007 00:32:26 +0100 To: weddy@grc.nasa.gov From: Bob Briscoe Subject: Re: [Tsvwg] What body is qualified to decide on Internet fairness? In-Reply-To: <20070614174427.GN18790@grc.nasa.gov> References: <5.2.1.1.2.20070614151944.041b0c58@pop3.jungle.bt.co.uk> <20070614135731.GD18790@grc.nasa.gov> <5.2.1.1.2.20070614151944.041b0c58@pop3.jungle.bt.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: -3.76 () ALL_TRUSTED,AWL,BAYES_00 X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 X-OriginalArrivalTime: 14 Jun 2007 23:32:32.0027 (UTC) FILETIME=[479406B0:01C7AEDC] X-Spam-Score: 0.1 (/) X-Scan-Signature: 2a76bcd37b1c8a21336eb0a1ea6bbf48 Cc: tsvwg IETF list X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tsvwg-bounces@ietf.org Wes, At 18:44 14/06/2007, Wesley Eddy wrote: >On Thu, Jun 14, 2007 at 03:29:54PM +0100, Bob Briscoe wrote: > > I think you're heavily underplaying the sway that the implicit assumption > > of flow-rate fairness has had over everything the IETF has done. That has > > led the outcome (in terms of shares of resources) to a very distorted > place > > (mainly because it ensures instantaneous equality which hugely favours > > long-running flows). > > >This is the part I'm not sure about, and maybe this is because I wasn't >around in 1988 when some of these decisions started to be made. You make it sound as if people explicitly decided to do fairness based on equal flow rates. I don't think there was any explicit acknowledgement that there was ever any other option. From my reading of the literature trail (see below) it was just 'obvious' at the time. >I'm not >quite convinced (yet) that flow-rate fairness is the basis of all that >we've done. It doesn't seem completely evident from the original >sources, nor is it what was achieved! Let's first correct your reading of Jacobson & Karels (1988) that is the nub of your argument. The part about end-host mechanisms (top p10) says the gateway is stateless therefore it cannot know about fair shares. And it talks about two connections that converge to windows that each have half the available bandwidth. Then the part on future work on gateways seems to contradict that, saying transport endpoints cannot insure [= ensure] fair sharing of capacity. "Only at the gateways is there enough information to control sharing and fair allocation." But this and the next para are talking about future work being needed on /enforcement/ of fair sharing - nothing to do with whether the endpoint algorithms /can/ reach a fair share, but to do with whether they can be /made/ to. That's what the terms insuring fair sharing and controlling fair sharing mean here when you read it in context. >As you've pointed out, our >mechanisms have pretty bad RTT unfairness, when evaluated in the >flow-rate paradigm. To me, it seems like this is clear evidence that >flow-rate fairness wasn't a primary goal, or it would've been better >acheived, I think you're missing the wood for the trees. The precision of the fairness wasn't particularly important at the time. I don't think you can reverse engineer what the fairness goal was from whether it was exactly achieved. You have to read the passing references to fairness being about flow rate equality (as above). The wood (not the trees) is the thousands of papers written on mechanisms with network fairness goals that assume equal flow rates at a bottleneck are fair, without question. Whether they ignore segment sizes or RTT issues is NOT the issue... The point at issue is that this whole tradition is completely broken, as fairness is nothing to do with rates at all. And certainly nothing to do with flows. You're very quickly getting the big issue lost in some side detail. >but maybe someone with a longer beard can either verify or >correct that. It would be interesting to hear. I guess Raj Jain, KK Ramakrishnan and Dah-Ming Chiu are still around to ask - and a number of others. --------------------------------------------------------------------------- All the rest of the mail below this line is detail to convince you I've done my homework. But, honestly, this really is indulging in fiddling while Rome burns. I checked the sources v carefully before writing "flow rate fairness...". Not all are described in the potted history in my section "The Seminal Literature", but a lot are. VJ's algorithm was strongly influenced by the work in Jain, KK & Chiu's famous DEC-TR-506 from 1987. You can trace back from that to Jain's fairness index (originally a 1984 DEC Tech Report): which deliberately abstracts away from the metric being allocated (mentioning throughput, delay, power, throughput-hop product, even income distribution etc). In hindsight Jain's fairness index would be orthogonal to whether the metric is integrated over time or not, but there's no evidence that anyone was thinking of anything but instantaneous metrics - indeed the example of variable window flow control in SNA that they used only found the minimum instantaneous fairness. And certainly, equality of any metric was considered fair without question. In general, fairness was described among users, although there was a free shifting between flows and users as if they were broadly the same thing. Jain's fairness index paper has a good set of refs from around 1980-1982, none of which take a radically different view. That's the way people were thinking by the time we get to Jacobson & Karels (1988). As I explained above. I think you must have searched for "fair" through the text and read a bit either side of each hit. You need to read pp10-12 in context to find that there was no question of anything other than rate equality between flows at a bottleneck being the fair thing to do. Like all good religions, by then it wasn't even recognised as a belief. It was a hegemony. One of Sally's papers written 3 years after that (1991), titled "Connections with Multiple Congested Gateways in Packet-Switched Networks" aimed to get flows to have equal rates even if one went through multiple bottlenecks and the other didn't, or if they had different RTTs. Removing RTT 'unfairness' has been quite a common goal in many many papers since, despite VJ's original arguments that it was a design feature. The place where I saw the most explicitly stated shift from per-user to per-flow fairness was in the classic fair queuing paper (Demers, Keshav, Shenker). But this was 1989, after VJ. But it was in a different tradition starting from the edge of a network where rate fairness was evolving from the notion that all the outgoing shares from an access router should be proportional to the sizes of the incoming access links. They explicitly argued that per-flow was a good approximation that biased about right towards larger servers, which got a higher share because they served more clients. They recognised this might encourage clients to fake multiple flows, but like most incentive problems, that was set aside and forgotten by engineers who were happy to pick up the core idea and ignore the security problems. > > The question can be put most pointedly as: once we take that flow rate > > fairness consensus away, what fairness control do we put in TCP, which > > after all still accounts for over 90% of all traffic globally? TCP's cc > > algo is unquestionably the TSV-AREA's baby. > > >That would be the right question if there was definite consensus that >there was both (1) a TCP basis in flow-rate fairness, and (2) a need to >remove that basis. > >I'm not totally convinced of (1); in fact I fully disagree with it, >based on my understanding of source material. In the 1988 Jacobson and >Karels paper, the end-host congestion control design is done without any >attempt at fairness. Fairness is mentioned mainly in the section on >gateway-mechanisms, NOT end-host mechanisms. The discovery that this >design resulted in flow-rate fairness seems to have come later in history, >and been a happy side-effect. Well I hope my response above convinced you you've read it wrongly. >As for (2), if there isn't a basis, how can we remove it? I think our >disagreement is whether flow-rate fairness is a basis or a side-effect >in TCP congestion control. Do we agree on that? I'm afraid I believe you've gone completely wrong here. There's decades of evidence to show that the fairness goal was assumed to be about flow rate equality, including in Jacobson & Karels. Very much so. Can we get back to the question? What body should decide on Internet fairness? Please. This is important. Bob >-- >Wesley M. Eddy >Verizon Federal Network Systems ____________________________________________________________________________ Bob Briscoe, Networks Research Centre, BT Research B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK. +44 1473 645196 From tsvwg-bounces@ietf.org Fri Jun 15 03:26:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hz6CX-0002yj-Vy; Fri, 15 Jun 2007 03:26:33 -0400 Received: from tsvwg by megatron.ietf.org with local (Exim 4.43) id 1Hz6CW-0002yb-QX for tsvwg-confirm+ok@megatron.ietf.org; Fri, 15 Jun 2007 03:26:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hz6CT-0002y5-0Z for tsvwg@ietf.org; Fri, 15 Jun 2007 03:26:29 -0400 Received: from smtp.nokia.com ([131.228.20.171] helo=mgw-ext12.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hz6CR-0008Pi-Hk for tsvwg@ietf.org; Fri, 15 Jun 2007 03:26:28 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext12.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l5F7Q4C0009989; Fri, 15 Jun 2007 10:26:17 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 15 Jun 2007 10:26:05 +0300 Received: from mgw-int01.ntc.nokia.com ([172.21.143.96]) by esebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Fri, 15 Jun 2007 10:25:53 +0300 Received: from [172.21.37.151] (esdhcp037151.research.nokia.com [172.21.37.151]) by mgw-int01.ntc.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l5F7Plld003890; Fri, 15 Jun 2007 10:25:48 +0300 In-Reply-To: <5.2.1.1.2.20070614214201.0405ec80@pop3.jungle.bt.co.uk> References: <5.2.1.1.2.20070614151944.041b0c58@pop3.jungle.bt.co.uk> <20070614135731.GD18790@grc.nasa.gov> <5.2.1.1.2.20070614151944.041b0c58@pop3.jungle.bt.co.uk> <5.2.1.1.2.20070614214201.0405ec80@pop3.jungle.bt.co.uk> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-7--425804273; protocol="application/pkcs7-signature" Message-Id: <6B929209-681F-44D1-9698-254E157E4169@nokia.com> From: Lars Eggert Subject: Re: [Tsvwg] What body is qualified to decide on Internet fairness? Date: Fri, 15 Jun 2007 10:25:42 +0300 To: ext Bob Briscoe X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 15 Jun 2007 07:25:53.0865 (UTC) FILETIME=[68649390:01C7AF1E] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: tsvwg IETF list X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tsvwg-bounces@ietf.org --Apple-Mail-7--425804273 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Hi, On 2007-6-15, at 2:32, ext Bob Briscoe wrote: > Can we get back to the question? What body should decide on > Internet fairness? Please. This is important. it very much depends on what you mean by "decides." If folks want to propose modifications to the Internet's existing protocols or new Internet protocols that are establishing a different fairness point, IMO the IETF is venue. (After consensus forming, discussion on interactions with existing protocols and traffic, etc., etc.) It's a difficult chunk of work, because it touches many pieces of the existing system, but with sufficient motivation, the IETF could decide to take on this work. However, the results will be IETF _recommendations_, as usual. And as usual, deployment of IETF recommendations is a different matter. In the end, vendors and operators need to be sufficiently convinced such that they decide to implement and roll out any new stuff. Applicability statements and similar documents by the IETF can help, but to get such broader architectural changes deployed, you'd IMO need an educational/informational campaign that the IETF doesn't have the expertise or the cycles for. (One key question of that campaign will be: how does the new fairness stuff interact with the old fairness stuff, since we can't have a flag day.) Lars --Apple-Mail-7--425804273 Content-Transfer-Encoding: base64 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGQDCCAvkw ggJioAMCAQICEGtxkLFHQu1g67hlmYfwPuIwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDEwNDE2MTE1NFoXDTA4MDEwNDE2MTE1 NFowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEA26hjntVPZMiwh4d8tyuk9KiucvG92BVUGArk5zO1jhmq7tLFgU1mqcIg VGumfQqjkAzIuh83kxIiqBrB05Wvxp85apwt4sUCvzMe8mQWzZZZYp0rBzwpOj+VC5pxsMRYtYW+ BaTFBEmvFr7D7C7roZUk0lDppS5SZFs4SQbEe9ykB9aeUf1iTiw2+ikyP2+JEYto14WYCoxFWbms FbQ1uaaK+yn1WH2YHhyMfi0IOxuT0jtbsngjHJMpWIqq334zBhj+rPSUug47YBHr41FCDMHbbbjv WbyTyDYneOW3WY8LY8bGWVlAknQGB7lgduShe6e0RI/7SL/VE6X27lM9LwIDAQABozIwMDAgBgNV HREEGTAXgRVsYXJzLmVnZ2VydEBub2tpYS5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUF AAOBgQCx3nxxTg/WowobVTRXBiXUEEZj4LBiunWbuAnR0UbJIgijvq3JbiJvZo2gUGiW9LPaHSBz 4oxT1VR/S/6O0a4e87oV5cOQm6ReB68o9rDfUzxHTwoCfv2wwMwBrXyzQMjyQK4Lt8siV41gmZpm rSXMhjTJdd9uYYNoZKQLq+VM+TCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJ BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgG A1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMg RGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3 DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3 MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9 fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+ uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMB Af8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3 dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgG A1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcP f6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH 2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8x ggMQMIIDDAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAo UHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ a3GQsUdC7WDruGWZh/A+4jAJBgUrDgMCGgUAoIIBbzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw0wNzA2MTUwNzI1NDJaMCMGCSqGSIb3DQEJBDEWBBSIeoaQUFu5tepv tH78q9ISN6f2VTCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIwgYcGCyqGSIb3DQEJEAILMXigdjBiMQsw CQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIw DQYJKoZIhvcNAQEBBQAEggEAQGQoK0QcdrGoWaNMnFFsEChAYfDyybhYu0brcYD7/APP1wQ4r3Z1 06lndClyvEMdOL62jqShSF/zk1NXkU8Y9mUIV5b0lcwe5sVLSdXd09mbJ1wRS04bvmB9aD9Blosc +cJ+JLA8i63jtq7QudeL/cvi9odmhiH2X3A5OxcQIrkMeg/hQRVdtsUmjWk5AYgZ6/UkLt/SbZWD a63XgyWWWHJJi5ZnTqx0p4BN+VV7cR1hkjJyqsPwmhixeFhw/m9oUBdeJD5vtQZDbjx6QijAcZiD /ryGYWamiMsSjaItEeuZ2gAcG32d8EFC+OdGw0bu81/2+XIAUlXDIQrBqGYMqAAAAAAAAA== --Apple-Mail-7--425804273-- From tsvwg-bounces@ietf.org Fri Jun 15 15:31:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzHW6-0004CA-8y; Fri, 15 Jun 2007 15:31:30 -0400 Received: from tsvwg by megatron.ietf.org with local (Exim 4.43) id 1HzHW4-0004C3-Oa for tsvwg-confirm+ok@megatron.ietf.org; Fri, 15 Jun 2007 15:31:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzHW4-0004Bv-F4 for tsvwg@ietf.org; Fri, 15 Jun 2007 15:31:28 -0400 Received: from smtp2.smtp.bt.com ([217.32.164.150]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HzHW0-00080Q-N9 for tsvwg@ietf.org; Fri, 15 Jun 2007 15:31:28 -0400 Received: from i2kc06-ukbr.domain1.systemhost.net ([193.113.197.70]) by smtp2.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 15 Jun 2007 20:31:23 +0100 Received: from cbibipnt05.iuser.iroot.adidom.com ([147.149.196.177]) by i2kc06-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.1830); Fri, 15 Jun 2007 20:31:23 +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 1181935882419; Fri, 15 Jun 2007 20:31:22 +0100 Received: from mut.jungle.bt.co.uk ([10.215.130.87]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id l5FJVF7e008206; Fri, 15 Jun 2007 20:31:19 +0100 Message-Id: <5.2.1.1.2.20070615202802.0298cb10@pop3.jungle.bt.co.uk> X-Sender: rbriscoe@pop3.jungle.bt.co.uk X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Fri, 15 Jun 2007 20:31:18 +0100 To: Lars Eggert From: Bob Briscoe Subject: Re: [Tsvwg] What body is qualified to decide on Internet fairness? In-Reply-To: <6B929209-681F-44D1-9698-254E157E4169@nokia.com> References: <5.2.1.1.2.20070614214201.0405ec80@pop3.jungle.bt.co.uk> <5.2.1.1.2.20070614151944.041b0c58@pop3.jungle.bt.co.uk> <20070614135731.GD18790@grc.nasa.gov> <5.2.1.1.2.20070614151944.041b0c58@pop3.jungle.bt.co.uk> <5.2.1.1.2.20070614214201.0405ec80@pop3.jungle.bt.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: -3.759 () ALL_TRUSTED,AWL,BAYES_00 X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 X-OriginalArrivalTime: 15 Jun 2007 19:31:23.0839 (UTC) FILETIME=[C2477CF0:01C7AF83] X-Spam-Score: 0.1 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b Cc: tsvwg IETF list X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tsvwg-bounces@ietf.org Lars, At 08:25 15/06/2007, Lars Eggert wrote: >Hi, > >On 2007-6-15, at 2:32, ext Bob Briscoe wrote: >>Can we get back to the question? What body should decide on >>Internet fairness? Please. This is important. > >it very much depends on what you mean by "decides." Well, the full 'question within a question' that I asked in the original posting is what I mean: Which body should decide the question: "In the design of IETF protocols, who or what should be able to have policy control of fair resource allocation?"? The problem is that any IETF decision that gives (or fails to give) someone or something control of resource allocation is a political decision. The solution I proposed at least allows control over who has control to be decided by market selection, local government regulation or similar. Actually, Lars, I'm glad you've come in on this thread, as this question was in part prompted by the chat you & I had after my talk in Prague, after I said I intended the I-D on fairness to become a WG item (intent: informational) once it had gone through another round of toning down. You said the IETF would probably have trouble endorsing a change of this magnitude as it wouldn't feel competent to make a decision (correct me if I'm paraphrasing wrongly). So I was left thinking that what you said was true, but the IETF would be somehow abdicating it's responsibility if it didn't make a decision. So it is good to hear what you're saying below, which essentially says the IETF could and should handle this subject (not deciding on what is fair, but deciding on a policy control architecture to allow various actors to determine what fairness outcome we get). >If folks want to propose modifications to the Internet's existing >protocols or new Internet protocols that are establishing a different >fairness point, IMO the IETF is venue. (After consensus forming, >discussion on interactions with existing protocols and traffic, etc., >etc.) It's a difficult chunk of work, because it touches many pieces >of the existing system, but with sufficient motivation, the IETF >could decide to take on this work. Good. Under the category of "proposed modifications to existing protocols", I guess we have the re-ECN work, and we've got a temporary home for that in an informal gathering that plans to meet via a list and to meet co-located at IETFs (a bit like HIP started out). Under the category of "sufficient motivation", I intended the I-D on fairness to be the start of that. Now, it's clearer that this is a subject TSVWG ought to tackle, see the next mail thread I'm about to start "Does anyone have a defence in favour of flow rate fairness?" >However, the results will be IETF _recommendations_, as usual. And as >usual, deployment of IETF recommendations is a different matter. In >the end, vendors and operators need to be sufficiently convinced such >that they decide to implement and roll out any new stuff. Of course. I get healthy interest when I talk about it to vendors and operators, but I'm aware that has to transform into more than interest. >Applicability statements and similar documents by the IETF can help, >but to get such broader architectural changes deployed, you'd IMO >need an educational/informational campaign that the IETF doesn't have >the expertise or the cycles for. Yup. I'm well aware of that, and in my own small way I'm trying to get that started - and some influential people are stepping up to help too. >(One key question of that campaign >will be: how does the new fairness stuff interact with the old >fairness stuff, since we can't have a flag day.) Yes, there's already a section added to the 01 version of the draft in internet-drafts and linked above on transition. I recall discussing this on the list too (I think with Sally or Mark A?). I'm about to go off-list for a week... Thanks Bob ____________________________________________________________________________ Notice: This contribution is the personal view of the author and does not necessarily reflect the technical nor commercial direction of BT plc. ____________________________________________________________________________ Bob Briscoe, Networks Research Centre, BT Research B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK. +44 1473 645196 From tsvwg-bounces@ietf.org Fri Jun 15 15:32:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzHWi-0004u8-V8; Fri, 15 Jun 2007 15:32:08 -0400 Received: from tsvwg by megatron.ietf.org with local (Exim 4.43) id 1HzHWh-0004u3-MY for tsvwg-confirm+ok@megatron.ietf.org; Fri, 15 Jun 2007 15:32:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzHWh-0004tv-D1 for tsvwg@ietf.org; Fri, 15 Jun 2007 15:32:07 -0400 Received: from smtp4.smtp.bt.com ([217.32.164.151]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HzHWf-00084p-Ul for tsvwg@ietf.org; Fri, 15 Jun 2007 15:32:07 -0400 Received: from i2kc06-ukbr.domain1.systemhost.net ([193.113.197.70]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 15 Jun 2007 20:32:05 +0100 Received: from cbibipnt05.iuser.iroot.adidom.com ([147.149.196.177]) by i2kc06-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.1830); Fri, 15 Jun 2007 20:32: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 118193592411; Fri, 15 Jun 2007 20:32:04 +0100 Received: from mut.jungle.bt.co.uk ([10.215.130.87]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id l5FJVwOa008240; Fri, 15 Jun 2007 20:32:01 +0100 Message-Id: <5.2.1.1.2.20070615191706.0405ec80@pop3.jungle.bt.co.uk> X-Sender: rbriscoe@pop3.jungle.bt.co.uk X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Fri, 15 Jun 2007 20:32:01 +0100 To: "tsvwg IETF list" From: Bob Briscoe Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: -3.761 () ALL_TRUSTED,AWL,BAYES_00 X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 X-OriginalArrivalTime: 15 Jun 2007 19:32:05.0090 (UTC) FILETIME=[DADDE420:01C7AF83] X-Spam-Score: 0.1 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: Gorry Fairhurst Subject: [Tsvwg] Does anyone have a defence in favour of flow rate fairness? X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tsvwg-bounces@ietf.org TSVWG, At the Prague IETF, I asked for the ideas discussed in the I-D below to be considered as a WG item (but written more diplomatically than I did). "Flow Rate Fairness: Dismantling a Religion" or via: Gorry Fairhurst voiced concern that the consensus was unlikely to have shifted so quickly away from TCP fairness for this to be a feasible WG item. But I'd like to hear someone argue against cost-fairness or for flow rate fairness (or specifically for TCP-fairness), so we can actually debate this issue. From the show of hands in Prague, more than half of a big room had read the I-D. Given the I-D provocatively challenges anyone who wants to continue to use flow rate fairness to either defend it against the arguments or stop promoting it, I'm assuming that a lack of defence implies surrender. :) It would also be good to hear from anyone who believes what I said is the right direction. Particularly anyone who is willing to say it changed their mind. More specifically, does the TSVWG want to take on as a WG item the production of an informational RFC that would give a plan for the evolution of fairness control from where we are now, to a future where fairness policy can be controlled and enforced (or not) by more than just endpoints? - stating that we have a problem and what the problem is - stating what a good solution might look like (who/what might take control etc). - stating which fairness metrics are valid and which aren't - stating what implications the approach will have for evolution from where we are - etc I'm about to go off list for a week, so I hope there's a debate on this in my absence, and I'll join in on my return, or I'll provoke the discussion again if it hasn't happened :) Bob ____________________________________________________________________________ Notice: This contribution is the personal view of the author and does not necessarily reflect the technical nor commercial direction of BT plc. ____________________________________________________________________________ Bob Briscoe, Networks Research Centre, BT Research B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK. +44 1473 645196 From tsvwg-bounces@ietf.org Fri Jun 15 23:01:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzOXw-0007vr-Ef; Fri, 15 Jun 2007 23:01:52 -0400 Received: from tsvwg by megatron.ietf.org with local (Exim 4.43) id 1HzOXv-0007vi-5I for tsvwg-confirm+ok@megatron.ietf.org; Fri, 15 Jun 2007 23:01:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzOXu-0007vZ-MX for tsvwg@ietf.org; Fri, 15 Jun 2007 23:01:50 -0400 Received: from mx1.grc.nasa.gov ([128.156.11.68]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HzOXu-0001Su-5x for tsvwg@ietf.org; Fri, 15 Jun 2007 23:01:50 -0400 Received: from lombok-fi.grc.nasa.gov (seraph.grc.nasa.gov [128.156.10.10]) by mx1.grc.nasa.gov (Postfix) with ESMTP id 08F98C216 for ; Fri, 15 Jun 2007 23:01:49 -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 l5G311PH010759; Fri, 15 Jun 2007 23:01:01 -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 l5G3091p011522; Fri, 15 Jun 2007 23:01:01 -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 8DjY8vyG48Lf; Fri, 15 Jun 2007 23:00:09 -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 l5G30721011512;Fri, 15 Jun 2007 23:00:07 -0400 (EDT) Received: by drpepper.grc.nasa.gov (Postfix, from userid 501)id CB5404FEA8; Fri, 15 Jun 2007 22:58:14 -0400 (EDT) Date: Fri, 15 Jun 2007 22:58:14 -0400 From: Wesley Eddy To: Bob Briscoe Subject: Re: [Tsvwg] What body is qualified to decide on Internet fairness? Message-ID: <20070616025814.GB29831@grc.nasa.gov> References: <20070614174427.GN18790@grc.nasa.gov> <5.2.1.1.2.20070614214201.0405ec80@pop3.jungle.bt.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5.2.1.1.2.20070614214201.0405ec80@pop3.jungle.bt.co.uk> User-Agent: Mutt/1.5.5.1i X-imss-version: 2.046 X-imss-result: Passed X-imss-scores: Clean:99.90000 C:2 M:3 S:5 R:5 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: tsvwg IETF list X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: weddy@grc.nasa.gov List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tsvwg-bounces@ietf.org Bob: thanks for bearing with me. It looks like we've both been through a similar literature trail, but differed ever-so-slightly in context and interpretation. On Fri, Jun 15, 2007 at 12:32:26AM +0100, Bob Briscoe wrote: > > The wood (not the trees) is the thousands of papers written on mechanisms > with network fairness goals that assume equal flow rates at a bottleneck > are fair, without question. Whether they ignore segment sizes or RTT issues > is NOT the issue... > > The point at issue is that this whole tradition is completely broken, as > fairness is nothing to do with rates at all. And certainly nothing to do > with flows. You're very quickly getting the big issue lost in some side > detail. I fully agree with this, but the side issue is significant because the IETF's forest of RFCs and tools only shares a few trees with all that academic stuff! My tack is simply that, *within the IETF* (not within another forest -- and a dumpster -- of somewhat-related academic papers), I don't think we've had as much of an obsession with equal flow-rates. On the contrary, we've conciously developed a number of things that support or create unequal rates. We believe in congestion control, but not based on any religion, only based on keeping the network usable for all legitimate purposes. What I mean is that rather than being disciples of the flow-rate religion in the IETF, I think we have a lot of "unitarians" who see the merits in other ideas, and simply build protocol toolboxes that can be used flexibly by our employers/customers/selves. As an individual contributor, I certainly support work on mechanisms to enable cost-fairness, but I don't at all support trying to make it into our single religion (not yet, at least). We don't have RFCs that say "do flow-rate fairness, it's the end-all be-all metric to be met, and death to all others". Speaking as just another individual contributor, I don't believe we should (or even need to) be so bold as to make a statement like this about cost-fairness. It seems like this is what you're wrangling at. > All the rest of the mail below this line is detail to convince you I've > done my homework. I never doubted it, and your sharing of it is certainly appreciated. I imagine it will happen a few more times as the related work progresses, and hope your keyboard holds up! Thanks immensely. -- Wesley M. Eddy Verizon Federal Network Systems From tsvwg-bounces@ietf.org Sat Jun 16 04:30:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzTfQ-0006mQ-Q2; Sat, 16 Jun 2007 04:29:56 -0400 Received: from tsvwg by megatron.ietf.org with local (Exim 4.43) id 1HzTfQ-0006mC-9b for tsvwg-confirm+ok@megatron.ietf.org; Sat, 16 Jun 2007 04:29:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzTfM-0006lX-OI for tsvwg@ietf.org; Sat, 16 Jun 2007 04:29:52 -0400 Received: from smtp.nokia.com ([131.228.20.170] helo=mgw-ext11.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HzTfK-0000Sw-KG for tsvwg@ietf.org; Sat, 16 Jun 2007 04:29:52 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext11.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l5G8TanV032668; Sat, 16 Jun 2007 11:29:37 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 16 Jun 2007 11:29:36 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 16 Jun 2007 11:29:35 +0300 Received: from mgw-int02.ntc.nokia.com ([172.21.143.97]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Sat, 16 Jun 2007 11:29:34 +0300 Received: from [192.168.255.2] (essapo-nirac25210.europe.nokia.com [10.162.252.10]) by mgw-int02.ntc.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l5G8TSWv005669; Sat, 16 Jun 2007 11:29:29 +0300 In-Reply-To: <5.2.1.1.2.20070615202802.0298cb10@pop3.jungle.bt.co.uk> References: <5.2.1.1.2.20070614214201.0405ec80@pop3.jungle.bt.co.uk> <5.2.1.1.2.20070614151944.041b0c58@pop3.jungle.bt.co.uk> <20070614135731.GD18790@grc.nasa.gov> <5.2.1.1.2.20070614151944.041b0c58@pop3.jungle.bt.co.uk> <5.2.1.1.2.20070614214201.0405ec80@pop3.jungle.bt.co.uk> <5.2.1.1.2.20070615202802.0298cb10@pop3.jungle.bt.co.uk> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-1--335583962; protocol="application/pkcs7-signature" Message-Id: From: Lars Eggert Subject: Re: [Tsvwg] What body is qualified to decide on Internet fairness? Date: Sat, 16 Jun 2007 11:29:22 +0300 To: ext Bob Briscoe X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 16 Jun 2007 08:29:35.0121 (UTC) FILETIME=[7873B810:01C7AFF0] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b66a1e94d7d92973ece9e5da449ff80 Cc: tsvwg IETF list X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tsvwg-bounces@ietf.org --Apple-Mail-1--335583962 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Hi, On 2007-6-15, at 22:31, ext Bob Briscoe wrote: > At 08:25 15/06/2007, Lars Eggert wrote: >> On 2007-6-15, at 2:32, ext Bob Briscoe wrote: >>> Can we get back to the question? What body should decide on >>> Internet fairness? Please. This is important. >> >> it very much depends on what you mean by "decides." > > Well, the full 'question within a question' that I asked in the > original posting is what I mean: > > Which body should decide the question: "In the design of IETF > protocols, who or what should be able to have policy control of > fair resource allocation?"? Understood. That original question is actually much broader - bandwidth is obviously only one of the resources involved in transmitting across a network. Your existing drafts focus on bandwidth, is this still the focus are are you broadening it to any resource? > The problem is that any IETF decision that gives (or fails to give) > someone or something control of resource allocation is a political > decision. The solution I proposed at least allows control over who > has control to be decided by market selection, local government > regulation or similar. Designing a distributed algorithm that controls access to and use of a shared resource is hard, especially for the "dumb" Internet where the intelligence is only at the edge. Our current, end-system-driven congestion control mechanisms by and large result in a shared use of the network that is at least not grossly unfair. Sure, maybe it can be driven to the point of complete unfairness if a sufficient number of end systems in one region of the network decide to cheat, but that's because the network has little ways to enforce any sort of fairness. Your proposal (which you know I find interesting) changes that very fundamentally. There is a policing function in the network that drives shared resource use towards a (market- or provider-defined) fairness point. That makes the problem of designing this distributed control system easier, because it doesn't need to be completely end- system-driven anymore. (Actually, it completely removes the need to do anything at the end system, because the policer will mangle the traffic an end system sends until it conforms to its current allotment.) But all this also means that the network absolutely needs to have this new policing function, which is something the Internet has never required. That's a pretty big architectural change. (Aside: For some resources - think router queues, we actually have designed multiple different algorithms that manage the resource. But that's a local resource under the control of one entity.) > Actually, Lars, I'm glad you've come in on this thread, as this > question was in part prompted by the chat you & I had after my talk > in Prague, after I said I intended the I-D on fairness to become a > WG item (intent: informational) once it had gone through another > round of toning down. You said the IETF would probably have trouble > endorsing a change of this magnitude as it wouldn't feel competent > to make a decision (correct me if I'm paraphrasing wrongly). My IETF week is a complete haze and I can never remember what I said :-) but this sounds pretty close to what I probably have said. Basically, having this document come out of TSVWG means that the WG has consensus on wanting to make this sort of informational statement on fairness to the wider community. I don't think we have that consensus yet. > So I was left thinking that what you said was true, but the IETF > would be somehow abdicating it's responsibility if it didn't make a > decision. Not adopting this draft *would be* a decision, too. It'd indicate that the WG did not have consensus to issue the informational statement in the draft as a WG statement. > So it is good to hear what you're saying below, which essentially > says the IETF could and should handle this subject (not deciding on > what is fair, but deciding on a policy control architecture to > allow various actors to determine what fairness outcome we get). Right. I do believe that this topic is in scope for the IETF, meaning probably mostly the transport area, but other areas impacted by an architectural change of this magnitude need to have a say as well. >> If folks want to propose modifications to the Internet's existing >> protocols or new Internet protocols that are establishing a different >> fairness point, IMO the IETF is venue. (After consensus forming, >> discussion on interactions with existing protocols and traffic, etc., >> etc.) It's a difficult chunk of work, because it touches many pieces >> of the existing system, but with sufficient motivation, the IETF >> could decide to take on this work. > > Good. > > Under the category of "proposed modifications to existing > protocols", I guess we have the re-ECN work, and we've got a > temporary home for that in an informal gathering that plans to meet > via a list and to meet co-located at IETFs (a bit like HIP started > out). Yep, I'm glad you got that set up, and as I've told you off-list, I'm happy to help you get a room for the informal bar-BOF meetings. > Under the category of "sufficient motivation", I intended the I-D > on fairness to be the start of that. > > Now, it's clearer that this is a subject TSVWG ought to tackle, see > the next mail thread I'm about to start "Does anyone have a defence > in favour of flow rate fairness?" That's a pretty confrontational way to start a consensus discussion. You may get the desired silence this way, but you may also generate silence this way when the time comes to hum for adoption. There are probably more productive ways of building consensus. But let me give you the start of a defense: What we currently have is not ideal or optimal, but it has worked OK for a long time for many different network scenarios, in the sense that congestion collapse has been prevented and end systems can generally get a share of the network for their use. It's a best-effort sort of resource sharing that is mostly based on end-system mechanisms, which let the network stay dumb. >> However, the results will be IETF _recommendations_, as usual. And as >> usual, deployment of IETF recommendations is a different matter. In >> the end, vendors and operators need to be sufficiently convinced such >> that they decide to implement and roll out any new stuff. > > Of course. I get healthy interest when I talk about it to vendors > and operators, but I'm aware that has to transform into more than > interest. It'd be interesting to determine if this is because re-ECN is a much cheaper way to do policing? I mean, operators can police the traffic that an end system generates now already, but with re-ECN, the infrastructure cost for this should go down a lot, due to the use of congestion marking. What's the main features that operators like? >> Applicability statements and similar documents by the IETF can help, >> but to get such broader architectural changes deployed, you'd IMO >> need an educational/informational campaign that the IETF doesn't have >> the expertise or the cycles for. > > Yup. I'm well aware of that, and in my own small way I'm trying to > get that started - and some influential people are stepping up to > help too. > >> (One key question of that campaign >> will be: how does the new fairness stuff interact with the old >> fairness stuff, since we can't have a flag day.) > > Yes, there's already a section added to the 01 version of the draft > in internet-drafts and linked above on transition. I recall > discussing this on the list too (I think with Sally or Mark A?). Lars PS: I'm very much agreeing with what Wes writes in his thread of responses - my understanding of the history in this space pretty much matches his. --Apple-Mail-1--335583962 Content-Transfer-Encoding: base64 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGQDCCAvkw ggJioAMCAQICEGtxkLFHQu1g67hlmYfwPuIwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDEwNDE2MTE1NFoXDTA4MDEwNDE2MTE1 NFowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEA26hjntVPZMiwh4d8tyuk9KiucvG92BVUGArk5zO1jhmq7tLFgU1mqcIg VGumfQqjkAzIuh83kxIiqBrB05Wvxp85apwt4sUCvzMe8mQWzZZZYp0rBzwpOj+VC5pxsMRYtYW+ BaTFBEmvFr7D7C7roZUk0lDppS5SZFs4SQbEe9ykB9aeUf1iTiw2+ikyP2+JEYto14WYCoxFWbms FbQ1uaaK+yn1WH2YHhyMfi0IOxuT0jtbsngjHJMpWIqq334zBhj+rPSUug47YBHr41FCDMHbbbjv WbyTyDYneOW3WY8LY8bGWVlAknQGB7lgduShe6e0RI/7SL/VE6X27lM9LwIDAQABozIwMDAgBgNV HREEGTAXgRVsYXJzLmVnZ2VydEBub2tpYS5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUF AAOBgQCx3nxxTg/WowobVTRXBiXUEEZj4LBiunWbuAnR0UbJIgijvq3JbiJvZo2gUGiW9LPaHSBz 4oxT1VR/S/6O0a4e87oV5cOQm6ReB68o9rDfUzxHTwoCfv2wwMwBrXyzQMjyQK4Lt8siV41gmZpm rSXMhjTJdd9uYYNoZKQLq+VM+TCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJ BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgG A1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMg RGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3 DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3 MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9 fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+ uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMB Af8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3 dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgG A1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcP f6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH 2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8x ggMQMIIDDAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAo UHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ a3GQsUdC7WDruGWZh/A+4jAJBgUrDgMCGgUAoIIBbzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw0wNzA2MTYwODI5MjJaMCMGCSqGSIb3DQEJBDEWBBTe/sW/JENcUw7S ko+YwCZbMS4CSDCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIwgYcGCyqGSIb3DQEJEAILMXigdjBiMQsw CQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIw DQYJKoZIhvcNAQEBBQAEggEA04ZvPxIndpHObJFwRiwgZf2NAy4ImWE8ruUAlLqE9bIZdCkL9Elt 8QQWSZXqsO6gp5aDTXhAdwJgrRhKJPnqFS1tvlrCzRZ9q3Uj+CKpeKALfnsifIs3/Muo6RFUI8p5 28sA1yBuSyU8JZRxtdl6LIgJMdsp4qpWnTtyytDBEtrLyyU7KFC2OEWo4b6/eGMUkKpnYl9rc/hO dOCzrTgC8V5W4E6elaT5qyXlvwQ476u7iwP//sUTmREpJFZacix4cDVzOt9k6P2o2dobvS74UoqI 6VkFHH5qRUZK6MXy5OusJuwxj5yR3MA+1jJ3DH6NDQ7jwVQdW5GwicYzZS7r1gAAAAAAAA== --Apple-Mail-1--335583962-- From tsvwg-bounces@ietf.org Sat Jun 16 18:32:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hzgoe-0007X5-FU; Sat, 16 Jun 2007 18:32:20 -0400 Received: from tsvwg by megatron.ietf.org with local (Exim 4.43) id 1Hzgoc-0007X0-Hm for tsvwg-confirm+ok@megatron.ietf.org; Sat, 16 Jun 2007 18:32:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hzgoc-0007Ws-8F for tsvwg@ietf.org; Sat, 16 Jun 2007 18:32:18 -0400 Received: from smtp3.smtp.bt.com ([217.32.164.138]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HzgoZ-0005Ed-DK for tsvwg@ietf.org; Sat, 16 Jun 2007 18:32:18 -0400 Received: from i2kc08-ukbr.domain1.systemhost.net ([193.113.197.71]) by smtp3.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 16 Jun 2007 23:32:14 +0100 Received: from cbibipnt08.iuser.iroot.adidom.com ([147.149.100.81]) by i2kc08-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.1830); Sat, 16 Jun 2007 23:32:14 +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 1182033132648; Sat, 16 Jun 2007 23:32:12 +0100 Received: from mut.jungle.bt.co.uk ([10.86.0.10]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id l5GMW84t026056; Sat, 16 Jun 2007 23:32:10 +0100 Message-Id: <5.2.1.1.2.20070616232253.0446a148@pop3.jungle.bt.co.uk> X-Sender: rbriscoe@pop3.jungle.bt.co.uk X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Sat, 16 Jun 2007 23:32:10 +0100 To: Lars Eggert From: Bob Briscoe Subject: Fwd: RE: [Tsvwg] Re: IETF process concerning missed RFC dependencies? Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: -3.77 () ALL_TRUSTED,AWL,BAYES_00 X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 X-OriginalArrivalTime: 16 Jun 2007 22:32:14.0101 (UTC) FILETIME=[2FF3D450:01C7B066] X-Spam-Score: 0.1 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: "BLACK, David" , tsvwg IETF list X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tsvwg-bounces@ietf.org Lars, Status update... >Date: Wed, 13 Jun 2007 09:07:00 +0100 >To: Lars Eggert >From: Bob Briscoe >Subject: RE: [Tsvwg] Re: IETF process concerning missed RFC dependencies? >Cc: braden@ISI.EDU, floyd@icir.org, tsvwg@ietf.org, >magnus.westerlund@ericsson.com > >>2/ As I said and you said, I don't believe the contradictions between >>3168 & 4301 can or should be solved by just updating the RFC index. >>That's why I've written a draft-I-D (to be posted as an I-D by end of >>this week when my co-authors have had a chance to refine it). David Black (co-author) needs more time. Prob another week, but definitely before -00 cut-off in fortnight. I've made a huge effort to make sure there are no changes to the security of the protocol, but David wants to make sure that message is put so unambiguously that the security community won't get unnecessarily concerned. Bob ____________________________________________________________________________ Notice: This contribution is the personal view of the author and does not necessarily reflect the technical nor commercial direction of BT plc. ____________________________________________________________________________ Bob Briscoe, Networks Research Centre, BT Research B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK. +44 1473 645196 From tsvwg-bounces@ietf.org Sat Jun 16 19:25:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzhdP-0007te-Q7; Sat, 16 Jun 2007 19:24:47 -0400 Received: from tsvwg by megatron.ietf.org with local (Exim 4.43) id 1HzhdO-0007tZ-1a for tsvwg-confirm+ok@megatron.ietf.org; Sat, 16 Jun 2007 19:24:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzhdN-0007tR-O8 for tsvwg@ietf.org; Sat, 16 Jun 2007 19:24:45 -0400 Received: from smtp2.smtp.bt.com ([217.32.164.150]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HzhdM-0006Cr-U1 for tsvwg@ietf.org; Sat, 16 Jun 2007 19:24:45 -0400 Received: from i2kc08-ukbr.domain1.systemhost.net ([193.113.197.71]) by smtp2.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 17 Jun 2007 00:24:44 +0100 Received: from cbibipnt08.iuser.iroot.adidom.com ([147.149.100.81]) by i2kc08-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.1830); Sun, 17 Jun 2007 00:24:43 +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 1182036282918; Sun, 17 Jun 2007 00:24:42 +0100 Received: from mut.jungle.bt.co.uk ([10.86.0.10]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id l5GNOb3T027458; Sun, 17 Jun 2007 00:24:39 +0100 Message-Id: <5.2.1.1.2.20070616234539.043beb88@pop3.jungle.bt.co.uk> X-Sender: rbriscoe@pop3.jungle.bt.co.uk X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Sun, 17 Jun 2007 00:24:40 +0100 To: weddy@grc.nasa.gov From: Bob Briscoe Subject: Re: [Tsvwg] What body is qualified to decide on Internet fairness? In-Reply-To: <20070616025814.GB29831@grc.nasa.gov> References: <5.2.1.1.2.20070614214201.0405ec80@pop3.jungle.bt.co.uk> <20070614174427.GN18790@grc.nasa.gov> <5.2.1.1.2.20070614214201.0405ec80@pop3.jungle.bt.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: -3.777 () ALL_TRUSTED,AWL,BAYES_00 X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 X-OriginalArrivalTime: 16 Jun 2007 23:24:43.0637 (UTC) FILETIME=[8538E250:01C7B06D] X-Spam-Score: 0.1 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Cc: tsvwg IETF list X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tsvwg-bounces@ietf.org Wes, At 03:58 16/06/2007, Wesley Eddy wrote: >Bob: thanks for bearing with me. It looks like we've both been through a >similar literature trail, but differed ever-so-slightly in context and >interpretation. > > >On Fri, Jun 15, 2007 at 12:32:26AM +0100, Bob Briscoe wrote: > > > > The wood (not the trees) is the thousands of papers written on mechanisms > > with network fairness goals that assume equal flow rates at a bottleneck > > are fair, without question. Whether they ignore segment sizes or RTT > issues > > is NOT the issue... > > > > The point at issue is that this whole tradition is completely broken, as > > fairness is nothing to do with rates at all. And certainly nothing to do > > with flows. You're very quickly getting the big issue lost in some side > > detail. > > >I fully agree with this, but the side issue is significant because the >IETF's forest of RFCs and tools only shares a few trees with all that >academic stuff! My tack is simply that, *within the IETF* (not within another >forest -- and a dumpster -- of somewhat-related academic papers), I >don't think we've had as much of an obsession with equal flow-rates. On >the contrary, we've conciously developed a number of things that support >or create unequal rates. We believe in congestion control, but not >based on any religion, only based on keeping the network usable for all >legitimate purposes. > >What I mean is that rather than being disciples of the flow-rate >religion in the IETF, I think we have a lot of "unitarians" who see the >merits in other ideas, and simply build protocol toolboxes that can be >used flexibly by our employers/customers/selves. Yes, in the IETF I definitely recognise more desire (and need) to allow a broad church than in most specific research papers. But actually the whole forest of research has much more diversity, and some examples have it within one paper. However, over recent years, there has been a tendency for flow rate equality to become more of a touchstone in the IETF (esp. in DCCP profile work - perhaps because this w-g is more heavily populated from the academic community). Thing is, when you're doing wire protocols and frameworks (like DCCP), you can allow for different goals. But when you're doing algos (e.g. a DCCP profile itself) you're making fairness decisions. And I don't think it can be denied that TCP fairness had been creeping in more and more as a goal to converge on (approximately) in the IETF. I think to say anything else would be revisionist re-writing of the last few year's at the IETF - the sort of re-write people might want to do in hindsight now we realise it was getting a bit like a bunch of people all clutching at the only belief system they had, no matter how flakey. You only have to look at the concerns over hi-speed cc, which were all framed in terms of TCP-fairness. >As an individual >contributor, I certainly support work on mechanisms to enable >cost-fairness, but I don't at all support trying to make it into our >single religion (not yet, at least). > >We don't have RFCs that say "do flow-rate fairness, it's the end-all >be-all metric to be met, and death to all others". Speaking as just >another individual contributor, I don't believe we should (or even need >to) be so bold as to make a statement like this about cost-fairness. It >seems like this is what you're wrangling at. Let's be clear here. Cost fairness and flow rate fairness are not in the same set (a point made in the paper about prop fairness & weighted prop fairness). So making out they are alternatives is misguided. Cost fairness isn't a set of flow rates that you can predict like flow rate fairness is. It is merely visibility of the costs of any particular set of rates. That's why I'm trying to frame this debate not about what the commandments are, but about who the IETF enables to write them (ie the market, operators, regulators etc, vs the IETF). It's eventually about putting a policy control parameter into TCP/CCID2/CCID4 etc, so the code author (and the standards author) is no longer in control of the outcome. But before that, it has to be about putting in a framework to make the costs visible, so once you give app-writers and users that parameter, there's someone there who can push back to make sure they use it responsibly. Bob ____________________________________________________________________________ Bob Briscoe, Networks Research Centre, BT Research B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK. +44 1473 645196 From tsvwg-bounces@ietf.org Sat Jun 16 20:51:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hziz5-0000nJ-5M; Sat, 16 Jun 2007 20:51:15 -0400 Received: from tsvwg by megatron.ietf.org with local (Exim 4.43) id 1Hziz4-0000nE-0T for tsvwg-confirm+ok@megatron.ietf.org; Sat, 16 Jun 2007 20:51:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hziz3-0000n6-N8 for tsvwg@ietf.org; Sat, 16 Jun 2007 20:51:13 -0400 Received: from smtp5.smtp.bt.com ([217.32.164.139]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hziz1-0000lM-GR for tsvwg@ietf.org; Sat, 16 Jun 2007 20:51:13 -0400 Received: from i2kc08-ukbr.domain1.systemhost.net ([193.113.197.71]) by smtp5.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 17 Jun 2007 01:51:10 +0100 Received: from cbibipnt08.iuser.iroot.adidom.com ([147.149.100.81]) by i2kc08-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.1830); Sun, 17 Jun 2007 01:51:10 +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 1182041469312; Sun, 17 Jun 2007 01:51:09 +0100 Received: from mut.jungle.bt.co.uk ([10.86.0.10]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id l5H0p31q029716; Sun, 17 Jun 2007 01:51:05 +0100 Message-Id: <5.2.1.1.2.20070617002448.043becc8@pop3.jungle.bt.co.uk> X-Sender: rbriscoe@pop3.jungle.bt.co.uk X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Sun, 17 Jun 2007 01:51:05 +0100 To: Lars Eggert From: Bob Briscoe Subject: Re: [Tsvwg] What body is qualified to decide on Internet fairness? In-Reply-To: References: <5.2.1.1.2.20070615202802.0298cb10@pop3.jungle.bt.co.uk> <5.2.1.1.2.20070614214201.0405ec80@pop3.jungle.bt.co.uk> <5.2.1.1.2.20070614151944.041b0c58@pop3.jungle.bt.co.uk> <20070614135731.GD18790@grc.nasa.gov> <5.2.1.1.2.20070614151944.041b0c58@pop3.jungle.bt.co.uk> <5.2.1.1.2.20070614214201.0405ec80@pop3.jungle.bt.co.uk> <5.2.1.1.2.20070615202802.0298cb10@pop3.jungle.bt.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: -3.497 () ALL_TRUSTED,AWL,BAYES_00,NO_COST X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 X-OriginalArrivalTime: 17 Jun 2007 00:51:10.0467 (UTC) FILETIME=[98D05530:01C7B079] X-Spam-Score: 0.1 (/) X-Scan-Signature: 918f4bd8440e8de4700bcf6d658bc801 Cc: tsvwg IETF list X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tsvwg-bounces@ietf.org Lars, At 09:29 16/06/2007, Lars Eggert wrote: >On 2007-6-15, at 22:31, ext Bob Briscoe wrote: > >>Which body should decide the question: "In the design of IETF >>protocols, who or what should be able to have policy control of >>fair resource allocation?"? > >Understood. That original question is actually much broader - >bandwidth is obviously only one of the resources involved in >transmitting across a network. Your existing drafts focus on >bandwidth, is this still the focus are are you broadening it to any >resource? I can't quite parse the question... bandwidth isn't a resource, it's a property of any particular resource. So you might mean: i) either "broadening to any other property of resources" (like e.g. delay) ii) or "broadening to any other resource [than wireline]" (like spectrum) * If you meant i) other properties like delay etc, the fairness religion I-D has a para explaining why it's sensible to focus on bandwidth: "While on the subject of assumptions, we should add that the benefit of a real-time application depends on jitter, not just transfer rate. But simple scaling arguments show that it will be possible for network operators to minimise congestion delay as networks increase in capacity ([SelfMan] S.2), an argument supported by recent research showing that router buffers are often significantly oversized [BufSizUp]." * If you meant ii) other types of resource, see Vasilios Siris's 2002 Mobicom paper linked from I thought I had ref'd it, but I hadn't - I will in -02. This explains how to combine congestion of different resources on different links into a unified ECN signal at the IP layer across them. Meaning "how to" both technically and how to in terms of the relative weights that economics tells you they should have. A sentence from the abstract: "An important feature of the framework is that it incorporates both the congestion for shared resources in wireless and wired networks, and the cost for battery power at mobile hosts." * Or you may have meant iii) packet-congestible as well as bit-congestible resources. In which case, if you wait an hour or so, I'll have posted the I-D on that that I've been promising James (& Steve Blake because it's also relevant to PCN). Nearly every resource serving the Internet layer that we see getting congested, whether spectrum, radio transmitter power, line capacity or whatever tends to be bit congestible. Resources that are packet congestible tend to be designed as part of a system protected by a bit congestible resource. The I-D is actually about where to make allowance for packet size - network layer or transport. Answer: Transport. >>The problem is that any IETF decision that gives (or fails to give) >>someone or something control of resource allocation is a political >>decision. The solution I proposed at least allows control over who >>has control to be decided by market selection, local government >>regulation or similar. > >Designing a distributed algorithm that controls access to and use of >a shared resource is hard, especially for the "dumb" Internet where >the intelligence is only at the edge. Our current, end-system-driven >congestion control mechanisms by and large result in a shared use of >the network that is at least not grossly unfair. I fundamentally beg to differ. If we're talking about comparing how much congestion two flows cause, TCP gives a user who runs one 10sec flow in two days the same rate as another user who runs one flow for 48hr while they are competing for the same bottleneck. Over its lifetime, the longer one might cause 20,000 times more congestion than the short flow. Is it not grossly unfair to only allow the 10sec flow an equal instantaneous rate (aside from the question of whether we can be fair to flows, not users, of course)? What I'm getting at is that TCP /is/ turning out to be driving the system to gross unfairness, as certain apps have evolved to exploit the fact that TCP favours apps with lots of flows and apps with long running flows. >Sure, maybe it can >be driven to the point of complete unfairness if a sufficient number >of end systems in one region of the network decide to cheat, but >that's because the network has little ways to enforce any sort of >fairness. All known p2p filesharing uses TCP, but it's still grossly unfair in terms of the amount of congestion users cause who've paid the same as other users who are using TCP for Web & email, say. I'm not whinging that it's unfair personally, I'm just saying you can't say TCP is keeping things anywhere near fair. It's orders of magnitude more unfair than it needs to be (e.g. if we used Jain's fairness index with total user utility as the metric). >Your proposal (which you know I find interesting) changes that very >fundamentally. There is a policing function in the network that >drives shared resource use towards a (market- or provider-defined) >fairness point. That makes the problem of designing this distributed >control system easier, because it doesn't need to be completely end- >system-driven anymore. Yup. >(Actually, it completely removes the need to >do anything at the end system, because the policer will mangle the >traffic an end system sends until it conforms to its current >allotment.) It could do theoretically, but that's not actually what I'd recommend or expect. I'd recommend that a network-based policer only polices the envelope for the whole user, not each flow, 'cos it's not best placed to. Such a bulk policer merely encourages the user (or app authors) to push down the weight in the endpoint algo of costly (harmful) apps and push up the weight in the algo of cheap (benign) ones. >But all this also means that the network absolutely needs >to have this new policing function, which is something the Internet >has never required. > >That's a pretty big architectural change. Yup. >(Aside: For some resources - think router queues, we actually have >designed multiple different algorithms that manage the resource. But >that's a local resource under the control of one entity.) You're talking WFQ etc, I guess. >>Actually, Lars, I'm glad you've come in on this thread, as this >>question was in part prompted by the chat you & I had after my talk >>in Prague, after I said I intended the I-D on fairness to become a >>WG item (intent: informational) once it had gone through another >>round of toning down. You said the IETF would probably have trouble >>endorsing a change of this magnitude as it wouldn't feel competent >>to make a decision (correct me if I'm paraphrasing wrongly). > >My IETF week is a complete haze and I can never remember what I >said :-) but this sounds pretty close to what I probably have said. >Basically, having this document come out of TSVWG means that the WG >has consensus on wanting to make this sort of informational statement >on fairness to the wider community. I don't think we have that >consensus yet. See new thread I started, trying to see whether /how much people's opinions have moved. >>So I was left thinking that what you said was true, but the IETF >>would be somehow abdicating it's responsibility if it didn't make a >>decision. > >Not adopting this draft *would be* a decision, too. It'd indicate >that the WG did not have consensus to issue the informational >statement in the draft as a WG statement. Understood. >>So it is good to hear what you're saying below, which essentially >>says the IETF could and should handle this subject (not deciding on >>what is fair, but deciding on a policy control architecture to >>allow various actors to determine what fairness outcome we get). > >Right. I do believe that this topic is in scope for the IETF, meaning >probably mostly the transport area, but other areas impacted by an >architectural change of this magnitude need to have a say as well. Definitely int-area, given I'm proposing a field to police congestion in the net layer. But we need to get consensus sorted in the transport area that understands the issues, long before we approach the area that owns the bit fields :) >>>If folks want to propose modifications to the Internet's existing >>>protocols or new Internet protocols that are establishing a different >>>fairness point, IMO the IETF is venue. (After consensus forming, >>>discussion on interactions with existing protocols and traffic, etc., >>>etc.) It's a difficult chunk of work, because it touches many pieces >>>of the existing system, but with sufficient motivation, the IETF >>>could decide to take on this work. >> >>Good. >> >>Under the category of "proposed modifications to existing >>protocols", I guess we have the re-ECN work, and we've got a >>temporary home for that in an informal gathering that plans to meet >>via a list and to meet co-located at IETFs (a bit like HIP started >>out). > >Yep, I'm glad you got that set up, and as I've told you off-list, I'm >happy to help you get a room for the informal bar-BOF meetings. Cool >>Under the category of "sufficient motivation", I intended the I-D >>on fairness to be the start of that. >> >>Now, it's clearer that this is a subject TSVWG ought to tackle, see >>the next mail thread I'm about to start "Does anyone have a defence >>in favour of flow rate fairness?" > >That's a pretty confrontational way to start a consensus discussion. >You may get the desired silence this way, but you may also generate >silence this way when the time comes to hum for adoption. There are >probably more productive ways of building consensus. I certainly don't desire silence. But I certainly do need advice on diplomacy ;) >But let me give you the start of a defense: What we currently have is >not ideal or optimal, but it has worked OK for a long time for many >different network scenarios, in the sense that congestion collapse >has been prevented and end systems can generally get a share of the >network for their use. It's a best-effort sort of resource sharing >that is mostly based on end-system mechanisms, which let the network >stay dumb. In those two senses it's worked (stability and you get /a/ share). And it's fairly efficient at using the capacity there is. But sharing out the usage 'properly' is actually a fairly important part of what the resource control system should be doing. And it's not. Big time. I want to try to get people to understand what problems we would NOT have if we also had a resource control framework that wasn't orders of magnitude off an economic fairness optimum. I don't think we'd have deep packet inspection boxes inferring which apps are overusing the Internet and throttling/blocking them. So we wouldn't have solely today's apps frozen into the Internet, with a block on anything new for tomorrow. We'd have fibre installed everywhere by now, lots more wireless infrastructure, etc etc, 'cos the investment incentives wouldn't be blown away by other businesses coming in and grabbing neaarly all the capacity at no cost to them. We'd have apple pie, motherhood, sweetness and light. I can't prove any of this, but we're kicking off some economics work to try to start putting some meat on these arguments. >>>However, the results will be IETF _recommendations_, as usual. And as >>>usual, deployment of IETF recommendations is a different matter. In >>>the end, vendors and operators need to be sufficiently convinced such >>>that they decide to implement and roll out any new stuff. >> >>Of course. I get healthy interest when I talk about it to vendors >>and operators, but I'm aware that has to transform into more than >>interest. > >It'd be interesting to determine if this is because re-ECN is a much >cheaper way to do policing? I mean, operators can police the traffic >that an end system generates now already, but with re-ECN, the >infrastructure cost for this should go down a lot, due to the use of >congestion marking. What's the main features that operators like? It's not cheapness. DPI is actually fairly cheap in box terms. It's more the ability to control the thing they really want to control, rather than having to control a load of higher layer knobs and keep running an arms race and keep arguing over the validity of what they're doing - they don't want to be fighting their customers I guess. They want to have a nice clean deal. So you could put all that into management cost terms. But I don't think that's really it. It's not that they would have more control - they feel they've got that with DPI. I think it's about control of something bigger. >>>Applicability statements and similar documents by the IETF can help, >>>but to get such broader architectural changes deployed, you'd IMO >>>need an educational/informational campaign that the IETF doesn't have >>>the expertise or the cycles for. >> >>Yup. I'm well aware of that, and in my own small way I'm trying to >>get that started - and some influential people are stepping up to >>help too. >> >>>(One key question of that campaign >>>will be: how does the new fairness stuff interact with the old >>>fairness stuff, since we can't have a flag day.) >> >>Yes, there's already a section added to the 01 version of the draft >>in internet-drafts and linked above on transition. I recall >>discussing this on the list too (I think with Sally or Mark A?). > >Lars > >PS: I'm very much agreeing with what Wes writes in his thread of >responses - my understanding of the history in this space pretty much >matches his. Well, you'll see I'm still disagreeing. I think he is (so you too are) underplaying the guiding influence TCP-fairness has grown into as an organising principle over people's thoughts. You surely can't deny that in, say, discussions on goals for hi-speed cc, or in the DCCP w-g. Bob ____________________________________________________________________________ Bob Briscoe, Networks Research Centre, BT Research B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK. +44 1473 645196 From tsvwg-bounces@ietf.org Sat Jun 16 23:29:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzlRf-00037w-4F; Sat, 16 Jun 2007 23:28:55 -0400 Received: from tsvwg by megatron.ietf.org with local (Exim 4.43) id 1HzlRd-00037Z-H6 for tsvwg-confirm+ok@megatron.ietf.org; Sat, 16 Jun 2007 23:28:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzlRd-00037N-7C for tsvwg@ietf.org; Sat, 16 Jun 2007 23:28:53 -0400 Received: from smtp4.smtp.bt.com ([217.32.164.151]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HzlRb-0003g0-GG for tsvwg@ietf.org; Sat, 16 Jun 2007 23:28:53 -0400 Received: from i2kc06-ukbr.domain1.systemhost.net ([193.113.197.70]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 17 Jun 2007 04:28:51 +0100 Received: from cbibipnt05.iuser.iroot.adidom.com ([147.149.196.177]) by i2kc06-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.1830); Sun, 17 Jun 2007 04:28:50 +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 1182050929643; Sun, 17 Jun 2007 04:28:49 +0100 Received: from mut.jungle.bt.co.uk ([10.86.0.2]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id l5H3Sib5007852; Sun, 17 Jun 2007 04:28:47 +0100 Message-Id: <5.2.1.1.2.20070617041232.04188110@pop3.jungle.bt.co.uk> X-Sender: rbriscoe@pop3.jungle.bt.co.uk X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Sun, 17 Jun 2007 04:28:45 +0100 To: "tsvwg IETF list" From: Bob Briscoe Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: -3.782 () ALL_TRUSTED,AWL,BAYES_00 X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 X-OriginalArrivalTime: 17 Jun 2007 03:28:50.0448 (UTC) FILETIME=[9F66E100:01C7B08F] X-Spam-Score: 0.1 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: PCN IETF list , DCCP IETF list Subject: [Tsvwg] Initial I-D: draft-briscoe-tsvwg-byte-pkt-mark-00 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tsvwg-bounces@ietf.org James & everyone, I've just posted this. It will appear in internet-drafts shortly, but for now, you can get it from the link to my page below: Byte and Packet Congestion Notification Header block & abstract below. It is motivated at this time by the need to define whether to take packet size into account for the marking algo in the PCN w-g. But it's generalised to give strong advice (unlike my usual style ;) on RED for diff size pkts, and also relevant to TFRC-SP in DCCP, but it's aimed primarily at tsvwg as a general transport-area-wide subject. It includes a survey of >100 vendors asking if they implemented the byte-mode packet drop variant of RED. With ~10% responses in, they've all said no. Cheers Bob ============================================================================= Transport Area Working Group B. Briscoe Internet-Draft BT & UCL Intended status: Informational June 17, 2007 Expires: December 19, 2007 Byte and Packet Congestion Notification draft-briscoe-tsvwg-byte-pkt-mark-00 Abstract This memo was written to clarify how (and whether) to take packet size into account when notifying congestion using active queue management (AQM) such as random early detection (RED). The scope includes resource congestion by bytes and by packet processing, even though the latter is less common. It answers the question of whether packet size should be taken into account when network equipment writes congestion notification, or when transports read it. The primary conclusion is that RED's byte-mode packet drop should not be used because it creates a perverse incentive for transports to use tiny segments. TCP's lack of attention to packet size should be fixed in TCP, not by reverse engineering network forwarding to fix transport protocols. ============================================================================= ____________________________________________________________________________ Notice: This contribution is the personal view of the author and does not necessarily reflect the technical nor commercial direction of BT plc. ____________________________________________________________________________ Bob Briscoe, Networks Research Centre, BT Research B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK. +44 1473 645196 From tsvwg-bounces@ietf.org Mon Jun 18 01:28:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I09mg-00017S-DG; Mon, 18 Jun 2007 01:28:14 -0400 Received: from tsvwg by megatron.ietf.org with local (Exim 4.43) id 1HzYAb-0001NP-Ey for tsvwg-confirm+ok@megatron.ietf.org; Sat, 16 Jun 2007 09:18:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzYAb-0001NH-4p for tsvwg@ietf.org; Sat, 16 Jun 2007 09:18:25 -0400 Received: from eng.ie.cuhk.edu.hk ([137.189.96.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HzYAY-0000qt-J5 for tsvwg@ietf.org; Sat, 16 Jun 2007 09:18:25 -0400 Received: from viruswall2.ie.cuhk.edu.hk (IDENT:U2FsdGVkX1/sGgUJrRlZbdKpZfPlMA+IkZ0a280/avg@viruswall2 [137.189.96.53]) by eng.ie.cuhk.edu.hk (8.13.6/8.13.6) with ESMTP id l5GDIJkp017292 for ; Sat, 16 Jun 2007 21:18:21 +0800 Received: from IESTP19 (iestp19 [137.189.96.219]) by viruswall2.ie.cuhk.edu.hk (8.13.6/8.13.6) with SMTP id l5GDIGlV012358; Sat, 16 Jun 2007 21:18:16 +0800 Message-ID: <045201c7b019$12380280$db60bd89@IESTP19> From: "Dah Ming Chiu" To: "Bob Briscoe" References: <5.2.1.1.2.20070615003454.041c1910@pop3.jungle.bt.co.uk> Date: Sat, 16 Jun 2007 21:20:07 +0800 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_044F_01C7B05C.1CE46B40" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Milter: Spamilter (Reciever: viruswall2.ie.cuhk.edu.hk; Sender-ip: 137.189.96.219; Sender-helo: iestp19; ) X-Spam-Score: 0.0 (/) X-Scan-Signature: 680445c3afe8c9e96925f2dfef141924 X-Mailman-Approved-At: Mon, 18 Jun 2007 01:28:11 -0400 Cc: tsvwg@ietf.org Subject: [Tsvwg] Re: What body is qualified to decide on Internet fairness X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tsvwg-bounces@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_044F_01C7B05C.1CE46B40 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit Let me give my thoughts to your question. 1) I think Internet (IETF) did well by not imposing only one way to make connections - we have TCP and UDP - which was to keep the options open. There was no mandate of a single form of fairness. 2) The subsequent push for making everything "flow rate fair" (TCP-friendly) is well-intentioned, but in my humble opinion, ill-advised and futile. I wrote a short paper on this (see attached) and submitted it to HotNets two years ago. I made some similar arguments as Briscoe's "Dismantling..." article, although not as blunt. Instead of cost-fairness, I proposed some other ideas for thought and discussion. Unfortunately, it was rejected. 3) In principle, I agree with Briscoe's "Dismantling..." article. Internet resource allocation should be tied to the market, and policies, not dictated by IETF. 4) Without having read about all the work on cost-fairness, I may not be doing it justice by saying that I doubt it is as simple as Briscoe claims (re-ECN stuff) to do the right thing (even assuming cost-fairness is what you want to implement). I want to take a little more care (and time) to give all my comments on that proposal, perhaps as another submission to HotNets - so keep your eye open for that. 5) My feeling is that this issue requires a broader discussion by all the people (academics and industry) who work on Internet's architecture. In the end, it will not be only a transport issue, but also affects accounting, billing, network access, ISP peering, routing, and maybe more. Hopefully, all this noise will lead to a period of "renaissance" when different traffic controls are experimented. I don't think we are in danger of any "congestion collapse" worse than what p2p and ddos traffic are already inflicting on us. In the end, we will evolve to something more sensible for tsvwg to specify into protocols. Dah Ming Chiu http://personal.ie.cuhk.edu.hk/~dmchiu ------=_NextPart_000_044F_01C7B05C.1CE46B40 Content-Type: application/pdf; name="hotnets4.pdf" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="hotnets4.pdf" JVBERi0xLjQNJeLjz9MNCjE2IDAgb2JqPDwvSFs2OTYgMTkzXS9MaW5lYXJpemVkIDEvRSA5NTA5 L0wgMjQyNjQvTiA0L08gMTkvVCAyMzg5Nz4+DWVuZG9iag0gICAgICAgICAgICAgICAgICAgICAg DQp4cmVmDQoxNiAyMA0KMDAwMDAwMDAxNiAwMDAwMCBuDQowMDAwMDAwODg5IDAwMDAwIG4NCjAw MDAwMDA2OTYgMDAwMDAgbg0KMDAwMDAwMDk2OSAwMDAwMCBuDQowMDAwMDAxMTQ4IDAwMDAwIG4N CjAwMDAwMDEyNTEgMDAwMDAgbg0KMDAwMDAwMjA4OSAwMDAwMCBuDQowMDAwMDAyOTQ0IDAwMDAw IG4NCjAwMDAwMDM0OTggMDAwMDAgbg0KMDAwMDAwMzY4NCAwMDAwMCBuDQowMDAwMDAzODY1IDAw MDAwIG4NCjAwMDAwMDQwNTEgMDAwMDAgbg0KMDAwMDAwNDEyNyAwMDAwMCBuDQowMDAwMDA0ODUy IDAwMDAwIG4NCjAwMDAwMDU1NjcgMDAwMDAgbg0KMDAwMDAwNjIzMyAwMDAwMCBuDQowMDAwMDA2 OTMyIDAwMDAwIG4NCjAwMDAwMDc1ODAgMDAwMDAgbg0KMDAwMDAwODI2MCAwMDAwMCBuDQowMDAw MDA4OTI0IDAwMDAwIG4NCnRyYWlsZXINCjw8L1NpemUgMzYvUHJldiAyMzg4Ni9Sb290IDE3IDAg Ui9JbmZvIDE1IDAgUi9JRFs8ZDBjOGMwM2E2M2EyYmIyYWE2M2Q4MTE1YWQ1NGI1YTU+PGU4ZDJj NWQ2ODk1Yzc1NDU4OTdmYmEwOWVjOTI0NzBhPl0+Pg0Kc3RhcnR4cmVmDQowDQolJUVPRg0KICAg ICAgICAgICAgIA0KMTggMCBvYmo8PC9MZW5ndGggMTEzL0ZpbHRlci9GbGF0ZURlY29kZS9MIDEy OS9TIDgwPj5zdHJlYW0NCnjaYmBgYAYiDgYWIPmUgZcBAXiBMixAyPGQ4fUegdsSDAz/LwCF2SxK gpJb1d0sSsCqBEMZmJQUGFygSpCAIBQzMPgwcEke3P2au7zt4ZI8Bo2Z//xmPz5Z5FPvAFHIzcDg +whIMwGxNUCAAQBSmxpaDQplbmRzdHJlYW0NZW5kb2JqDTE3IDAgb2JqPDwvUGFnZXMgMTMgMCBS L1R5cGUvQ2F0YWxvZy9QYWdlTGFiZWxzIDExIDAgUi9NZXRhZGF0YSAxNCAwIFI+Pg1lbmRvYmoN MTkgMCBvYmo8PC9Db250ZW50c1syOCAwIFIgMjkgMCBSIDMwIDAgUiAzMSAwIFIgMzIgMCBSIDMz IDAgUiAzNCAwIFIgMzUgMCBSXS9UeXBlL1BhZ2UvUGFyZW50IDEzIDAgUi9Sb3RhdGUgMC9NZWRp YUJveFswIDAgNjEyIDc5Ml0vQ3JvcEJveFswIDAgNjEyIDc5Ml0vUmVzb3VyY2VzIDIwIDAgUj4+ DWVuZG9iag0yMCAwIG9iajw8L0ZvbnQ8PC9GMSAyMSAwIFIvRjIgMjIgMCBSL0YzIDIzIDAgUj4+ L1Byb2NTZXRbL1BERi9UZXh0XS9FeHRHU3RhdGU8PC9HUzEgMjcgMCBSPj4+Pg1lbmRvYmoNMjEg MCBvYmo8PC9UeXBlL0ZvbnQvRW5jb2RpbmcvTWFjUm9tYW5FbmNvZGluZy9CYXNlRm9udC9UaW1l cy1Cb2xkL0ZpcnN0Q2hhciA0NS9MYXN0Q2hhciAyMjMvU3VidHlwZS9UeXBlMS9Gb250RGVzY3Jp cHRvciAyNCAwIFIvV2lkdGhzWzMzMyAyNTAgMjc4IDUwMCA1MDAgNTAwIDUwMCA1MDAgNTAwIDUw MCA1MDAgNTAwIDUwMCAzMzMgMzMzIDU3MCA1NzAgNTcwIDUwMCA5MzAgNzIyIDY2NyA3MjIgNzIy IDY2NyA2MTEgNzc4IDc3OCAzODkgNTAwIDc3OCA2NjcgOTQ0IDcyMiA3NzggNjExIDc3OCA3MjIg NTU2IDY2NyA3MjIgNzIyIDEwMDAgNzIyIDcyMiA2NjcgMzMzIDI3OCAzMzMgNTgxIDUwMCAzMzMg NTAwIDU1NiA0NDQgNTU2IDQ0NCAzMzMgNTAwIDU1NiAyNzggMzMzIDU1NiAyNzggODMzIDU1NiA1 MDAgNTU2IDU1NiA0NDQgMzg5IDMzMyA1NTYgNTAwIDcyMiA1MDAgNTAwIDQ0NCAzOTQgMjIwIDM5 NCA1MjAgMCA3MjIgNzIyIDcyMiA2NjcgNzIyIDc3OCA3MjIgNTAwIDUwMCA1MDAgNTAwIDUwMCA1 MDAgNDQ0IDQ0NCA0NDQgNDQ0IDQ0NCAyNzggMjc4IDI3OCAyNzggNTU2IDUwMCA1MDAgNTAwIDUw MCA1MDAgNTU2IDU1NiA1NTYgNTU2IDUwMCA0MDAgNTAwIDUwMCA1MDAgMzUwIDU0MCA1NTYgNzQ3 IDc0NyAxMDAwIDMzMyAzMzMgMCAxMDAwIDc3OCAwIDU3MCAwIDAgNTAwIDU1NiAwIDAgMCAwIDAg MzAwIDMzMCAwIDcyMiA1MDAgNTAwIDMzMyA1NzAgMCA1MDAgMCAwIDUwMCA1MDAgMTAwMCAyNTAg NzIyIDcyMiA3NzggMTAwMCA3MjIgNTAwIDEwMDAgNTAwIDUwMCAzMzMgMzMzIDU3MCAwIDUwMCA3 MjIgMTY3IDUwMCAzMzMgMzMzIDU1NiA1NTZdPj4NZW5kb2JqDTIyIDAgb2JqPDwvVHlwZS9Gb250 L0VuY29kaW5nL01hY1JvbWFuRW5jb2RpbmcvQmFzZUZvbnQvVGltZXMtUm9tYW4vRmlyc3RDaGFy IDQwL0xhc3RDaGFyIDIyMy9TdWJ0eXBlL1R5cGUxL0ZvbnREZXNjcmlwdG9yIDI1IDAgUi9XaWR0 aHNbMzMzIDMzMyA1MDAgNTY0IDI1MCAzMzMgMjUwIDI3OCA1MDAgNTAwIDUwMCA1MDAgNTAwIDUw MCA1MDAgNTAwIDUwMCA1MDAgMjc4IDI3OCA1NjQgNTY0IDU2NCA0NDQgOTIxIDcyMiA2NjcgNjY3 IDcyMiA2MTEgNTU2IDcyMiA3MjIgMzMzIDM4OSA3MjIgNjExIDg4OSA3MjIgNzIyIDU1NiA3MjIg NjY3IDU1NiA2MTEgNzIyIDcyMiA5NDQgNzIyIDcyMiA2MTEgMzMzIDI3OCAzMzMgNDY5IDUwMCAz MzMgNDQ0IDUwMCA0NDQgNTAwIDQ0NCAzMzMgNTAwIDUwMCAyNzggMjc4IDUwMCAyNzggNzc4IDUw MCA1MDAgNTAwIDUwMCAzMzMgMzg5IDI3OCA1MDAgNTAwIDcyMiA1MDAgNTAwIDQ0NCA0ODAgMjAw IDQ4MCA1NDEgMCA3MjIgNzIyIDY2NyA2MTEgNzIyIDcyMiA3MjIgNDQ0IDQ0NCA0NDQgNDQ0IDQ0 NCA0NDQgNDQ0IDQ0NCA0NDQgNDQ0IDQ0NCAyNzggMjc4IDI3OCAyNzggNTAwIDUwMCA1MDAgNTAw IDUwMCA1MDAgNTAwIDUwMCA1MDAgNTAwIDUwMCA0MDAgNTAwIDUwMCA1MDAgMzUwIDQ1MyA1MDAg NzYwIDc2MCA5ODAgMzMzIDMzMyAwIDg4OSA3MjIgMCA1NjQgMCAwIDUwMCA1MDAgMCAwIDAgMCAw IDI3NiAzMTAgMCA2NjcgNTAwIDQ0NCAzMzMgNTY0IDAgNTAwIDAgMCA1MDAgNTAwIDEwMDAgMjUw IDcyMiA3MjIgNzIyIDg4OSA3MjIgNTAwIDEwMDAgNDQ0IDQ0NCAzMzMgMzMzIDU2NCAwIDUwMCA3 MjIgMTY3IDUwMCAzMzMgMzMzIDU1NiA1NTZdPj4NZW5kb2JqDTIzIDAgb2JqPDwvVHlwZS9Gb250 L0VuY29kaW5nL1dpbkFuc2lFbmNvZGluZy9CYXNlRm9udC9UaW1lcy1JdGFsaWMvRmlyc3RDaGFy IDQ1L0xhc3RDaGFyIDE0Ni9TdWJ0eXBlL1R5cGUxL0ZvbnREZXNjcmlwdG9yIDI2IDAgUi9XaWR0 aHNbMzMzIDI1MCAyNzggNTAwIDUwMCA1MDAgNTAwIDUwMCA1MDAgNTAwIDUwMCA1MDAgNTAwIDMz MyAzMzMgNjc1IDY3NSA2NzUgNTAwIDkyMCA2MTEgNjExIDY2NyA3MjIgNjExIDYxMSA3MjIgNzIy IDMzMyA0NDQgNjY3IDU1NiA4MzMgNjY3IDcyMiA2MTEgNzIyIDYxMSA1MDAgNTU2IDcyMiA2MTEg ODMzIDYxMSA1NTYgNTU2IDM4OSAyNzggMzg5IDQyMiA1MDAgMzMzIDUwMCA1MDAgNDQ0IDUwMCA0 NDQgMjc4IDUwMCA1MDAgMjc4IDI3OCA0NDQgMjc4IDcyMiA1MDAgNTAwIDUwMCA1MDAgMzg5IDM4 OSAyNzggNTAwIDQ0NCA2NjcgNDQ0IDQ0NCAzODkgNDAwIDI3NSA0MDAgNTQxIDM1MCAwIDM1MCAz MzMgNTAwIDU1NiA4ODkgNTAwIDUwMCAzMzMgMTAwMCA1MDAgMzMzIDk0NCAzNTAgNTU2IDM1MCAz NTAgMzMzIDMzM10+Pg1lbmRvYmoNMjQgMCBvYmo8PC9UeXBlL0ZvbnREZXNjcmlwdG9yL0ZvbnRC Qm94Wy0xNjggLTIxOCAxMDAwIDkzNV0vRm9udE5hbWUvVGltZXMtQm9sZC9GbGFncyAyNjIxNzgv U3RlbVYgMTM5L1N0ZW1IIDEzOS9DYXBIZWlnaHQgNjc2L1hIZWlnaHQgNDYxL0FzY2VudCA2OTkv RGVzY2VudCAtMjA1L0l0YWxpY0FuZ2xlIDA+Pg1lbmRvYmoNMjUgMCBvYmo8PC9UeXBlL0ZvbnRE ZXNjcmlwdG9yL0ZvbnRCQm94Wy0xNjggLTIxOCAxMDAwIDg5OF0vRm9udE5hbWUvVGltZXMtUm9t YW4vRmxhZ3MgMzQvU3RlbVYgODQvU3RlbUggODQvQ2FwSGVpZ2h0IDY2Mi9YSGVpZ2h0IDQ1MC9B c2NlbnQgNjk5L0Rlc2NlbnQgLTIxNy9JdGFsaWNBbmdsZSAwPj4NZW5kb2JqDTI2IDAgb2JqPDwv VHlwZS9Gb250RGVzY3JpcHRvci9Gb250QkJveFstMTY5IC0yMTcgMTAxMCA4ODNdL0ZvbnROYW1l L1RpbWVzLUl0YWxpYy9GbGFncyA5OC9TdGVtViA3Ni9TdGVtSCA3Ni9DYXBIZWlnaHQgNjUzL1hI ZWlnaHQgNDQxL0FzY2VudCA2OTkvRGVzY2VudCAtMjA1L0l0YWxpY0FuZ2xlIC0xNS41Pj4NZW5k b2JqDTI3IDAgb2JqPDwvVHlwZS9FeHRHU3RhdGUvU0EgZmFsc2UvT1AgZmFsc2UvU00gMC4wMi9v cCBmYWxzZS9PUE0gMT4+DWVuZG9iag0yOCAwIG9iajw8L0xlbmd0aCA2NTYvRmlsdGVyL0ZsYXRl RGVjb2RlPj5zdHJlYW0NCkiJbFTBbtswDL3nK3SUh1q1ZFm2j1uLbuvWYlg97FDsoDpKotWxAktp tp/dfmWUJSVtMRhxKJIiHx9Jn7+/o2htF++6xfkVRRR1qwXlpOSCoQKeJNOSE9Yg0bak4qjbLgq0 hl/X+9dhcY9v1SHLWVWQFl9s5DCoca2s17SkxHpM0lXGKkKx1FPyvlXukDWEYzM9Jt1XZc1+yqgg Ne5VunsjR7lWWzW67Ed3DXhZxEtJW1URb5RZyUglkKgaAugB7z2+lJsU/0aPa5B5QKv3Z8lwbTbj 0UDuSNJ/3uuYsww584IIykqUU0IFL1F3CRkg1KisSpe+jfpJQRUFttr9TmHNKtk/mBOKTxn8Uew1 IU/sRU4ZaWjdorwinBbMJ8JvH6ybZO+y7ueJhZa0gomZhCjWDFWiIFyE+j/6ylgDydxG25TYbszk kmEndwC4FIDEUwL8N/iQFVgl7618zCibzzHS0dRLe5RXZkoeMumWepUxDpFXavItjOGftArqw1x4 4RllBa8Co86AX9OCeTDGj0ddY+mSrrv4kq8mrcbl4OkVFQZaYpY/ffDuzegmM1hoJS9geIEG65Rc BuvcjDkWQO7zEwTasghhHpWyAfqxkj2MUFmXIP81CXY0OuDJpANkDTQ+BboKPHlhHbgsuR/nFxdk EqAmENsakK78lXlTgmmSTp2lMg4que0mk/+Pu53xDSkFhVyDci4UAkcONalBWqf7VI0cl8n2ynKs 0yZNZGGOq7e74bSR3ZsF1s6GsYyLAoiYX80Z0ijdfiZCDi9XuATCYcij26suQl9jF/3mMD9UHm7Q 58rH+6WtIwng96yBr9Y8pNDipbL9pB9UuLAxz6cNoZwTzp43HP0TYADr5kFLDQplbmRzdHJlYW0N ZW5kb2JqDTI5IDAgb2JqPDwvTGVuZ3RoIDY0Ni9GaWx0ZXIvRmxhdGVEZWNvZGU+PnN0cmVhbQ0K SIlsVE2PmzAQvedXcIRq44KBAOdWK22lSj0g9bDqwQETrAUb2WbT/Nn2r3T8BbvbKIeMh5k34zdv /BxfaXLEVRWrUSS4QFl8dWc9MgVW3YBrt85UayrhdCohgvAQ60G6VUrKtfvefvlxHCSjvJ9u4Ckx amKyHJNf7bdDGh0zhNOijNqvh+d4kYJ0I0qOZVUjHP9M6gLlMYDmpwwVBh8q5biEb4tgpkCeVxAh 1s0kYBQNGK9JhmMqbyGhG8k0UX5h/AKuLAeXpIoS2Y22lfaTa+A80RnaTAtUx8xcDNfQMKf6agCF fAFXdoKPkC1W2dFwBnjREc0ED5493TFjzZ0bW+KJv2Eia7BnAtiFksBE3lSojL8DxVD95hjlSQqk bFMCD1mWibniynlW5Wcxr5Nmy0SduxOc087F3RkAfPb9waxOKXBkWqhyIL91QjBjFhruenOHdVFU qw/zF5IBzz7IVCWSDqs53rlqJ8mgaR+kcSYT4ZZVexRDUJnHvkBzlE7hu4ZsR8WfzkX+DQJWW++7 kJx8Z6GZC3p1f0TTe3Rcx1uQk9sDB2etugTLKN9pk82LkJpYTdqETUpel7wPoT1T3ao2tEUoxSB0 V2HPZJiRF80gzLIVqbkw6V4mK+IgLTsXS4aviSzU58csyqJ2OGQZasoSRyn8gl3hKAdOqjpqZ6iY JcemyVEFctQywSlQIvrV9uCxsMNqUHPCJwvlTYME1yod0NO7p8CSvRClHzbmV1g3J1l4QbjfFkgY yZvHhXrnQlgfNPcf7mA2gjDYE6Xu6coox3H/bnmda19e9zrMhJMLnaGj7fV5tCmwajIkUeP5TWbY pocwZrPjQSEwwij6J8AAUb5sCQ0KZW5kc3RyZWFtDWVuZG9iag0zMCAwIG9iajw8L0xlbmd0aCA1 OTcvRmlsdGVyL0ZsYXRlRGVjb2RlPj5zdHJlYW0NCkiJbFQ9j9swDN3zKzLKRWL42/FY9JYWLdDB W5BBZzOxerKUSvKl+bX9K6Uky+ciGQyQIkU+Pj55237bJNt9GmdJUW7bl82R9KDZRUT7vErjgsgz WnWOVvvlZzA7KS6gDZNLGp4YJfkO/UOJ/g2W3EFq8Gk5MTIcs/HKYR+dQv+0yeb+IwgT7bO6Jp+/ /njx1jGN0oycvKOjhEhvmoHOuePEDcOS3vsro6yIU3LT3u/keAXDxAXdMosbB8QGJsR2euTADLZQ UsQHoumINsKLayLA3CwQqd7C0as0hoOAzp4cEjzxGRPvQwpyE+UVonm3EUD0yhoXNGzlsoorYuaZ XMuzDVOmFggDVX4eT1j7CSH6YXAEJgIX8/DaAO3vwaYG4mhfZCl2+Y6O8lh2Pv7u61LF5GS5qkoi sZCaSYVuoILpUT9b1EPj/+jxPJ+l8lVHyoTBb7WD1Zh4WYGWk+ogRO3QmLzz122dJ3sCW+IPHd3i vcQ+qnpl/p5gAtc1LxqMHzMnJaxbJE1ckoF6CublzLco1zJo+RVg0bk2U8+gD82o6MNGvKKteKGP o/bXJombpqkd3iKpPN52AKlQiB3l/B5VSZyFRTAUgJXyoUEsA8Vd5AmSPTd3qxyCqMVa/D5txaWr sGIT2aPcC2e/wrRwyGVH56fsxh3pm6NCB4YABSxH1oWnq0Foq6n6YPfU2u3nTY2JVyVfkYJQyP06 XACF8fSpf6hlZhr5vLHeDAu/fIXONXdXKJK1wENp4ONHZffL8nRoTIMxGcaZuT9qaPtPgAEAw5hQ eA0KZW5kc3RyZWFtDWVuZG9iag0zMSAwIG9iajw8L0xlbmd0aCA2MzAvRmlsdGVyL0ZsYXRlRGVj b2RlPj5zdHJlYW0NCkiJdFQ9k5wwDO3vV1BC5nD4XKC8SSZFqhR0e1t4wSyeGMzY5jabP5u/EtnC 3G7m0kmWJT09PTsIjqFcDJ/4b2q4nKM4KxLShIuSZ8EmcLMa3GMepVn4DO6hDAtrn0gU50VD8vAF Tzs5TXIWN5+yataDXWZgz8xcbZJUP6NT+/2p/fR0DAd7QrmamdZQKytJFnaKG6YAB7TK8wqqT/RX PHHAlScpSR+Snj0CV5tGSah9lh5llBVw/zr70kbuTaTCYOzAJEEMlZusDNqvAEsxvcjZQq8qTHKN zci86fiiAm7UDbhainWjzvly8BfPdO6vvDcjFqNCyA5Z3vtmSbH1pVqvMOjFJ1MPd6HK8G4VVPkQ UGvtNIcotBbc3Lx7LP1yyrQC5l8E8DlDU5z4zUYZLOmQELfPrZf+kAoPCOf64ynVvhlVzJtMUA0o vfsavq8MmOPqP5TMjPX6NdpxAO8fUdNbyi2StE5IZamBIKnvNIeBTXMuJuQFxDROFtQW9VThhWGd O9wbhgeQxS7O93mcwno2AbZdlCgGZ+5i2IS3iwGX9yBNV0qxgSllcd7p0uVS7fp//pYHadAO/25j UVFRQ4JcpLItQE63LSHDhANJiyoLErzvnwruGhRRFQcYux25xVKXpLBaX4Xx3kRNNzpgVQ7ulQk7 VlORMrxyuzG07fC2bby1e1gVmxZ4v50jxBWVZxDrGypn+2HyQwoBM1LjS7Zffnizk/OF6e2iwwEn Rsm94OAZRclC4bxJ06AoSVOVNaLY+klHM35H8CMo43+3eynjD4UDYlTDPoV9Yegquc69UXyBg9Qy 2IM4bp7VUxD8FWAABbNo2g0KZW5kc3RyZWFtDWVuZG9iag0zMiAwIG9iajw8L0xlbmd0aCA1Nzkv RmlsdGVyL0ZsYXRlRGVjb2RlPj5zdHJlYW0NCkiJdFTLktsgELz7K3SUqiJWQrIex2wSV20uyUE3 1x6whC3WGFyA4vLPbn4lgxDYm/KeNPQwM03TKOp+rjLUtm0dpTnCTdNE3ffVNn4mmg5JWmQ5ymMp khQ3LURmpB48E218rKe+p1pT7QEihgclEEpFDesJh2xdx3s5iTR5BQ7pjUTe4rUjMRDDpPgC5WWL iriflKLC8CsAeYHw0rqoIXdWNMElzPjjPoRxJg63jUwc3RqvYc20rzMjMb4/4TzAiuwdsWzWJSsX Su99kpY4R1WsRzlxK1FbozWooeBc7EwMUCqzFiAmfNRLcaDansVvB8Qoyf3ytpXMQ582RZRH3X6F M1TkDY4yOz3uvv1Ok+5tlXr4jlq8V4yKAcSBDU8b7OoLVBRt68q38SXJMUzI4mtSZSAD8nf0VdjM VQogDw1RE19GCWFeQcilPGq/YMLYBG5QC52WQEDLRf5L2DjQkN9L5eGbsOnC7cONW3kdgaAQJFHt qDvBHcDZ0ULUusEhu0CeaJcLmy8jBa8ov5x940Jxx/vD3Ad3P7umysEe9iKC3l7KKsOQ+mUH6WAp RX24c4MmffUm8wjjg/PmjGoDj4eoIVgUzBHI3JR6+dFtvL7OxLjMbKyuAZYepEJPlonDTxM37EQH Rvyt/JWLCtpX3OntinahfHbhA3n+F+T1k1/Li3CPHx6l9gY8kzNcT1FBCM8dV2sgYD21pHtO2MlX zWedYc0Ogr33RBiX60diH5prMJ8+/IE++cdE0Tb6J8AAZrJJLw0KZW5kc3RyZWFtDWVuZG9iag0z MyAwIG9iajw8L0xlbmd0aCA2MTEvRmlsdGVyL0ZsYXRlRGVjb2RlPj5zdHJlYW0NCkiJbFS9btsw EN7zFB6pIhIk6n9uUKCdOhjoUGRgJdoiSpEqScfNy7av0iPPlJxUk473+913dyKfleNGcZekZdlm JWFqjKJwFsS2zCrClkWKgTmhldfROqOEGQ5iU4B50Vaoc4xTPKFVVpArKKoeFMPEpOTqzG3yfPzy kB/SIqN5VR+OTw/fyUmbmBJwXJOCEm1+RpXhVl/MwNeqUmoEkiVp3XagOk7c8r3iQfGu+PEDlLwK KZOUti2k/3URvhFa06y/j6ZNTRZu7MIHJ1D74rHxJCc2+ge2dkNnPXJpUXYav9AICiefiEGidCOk 6OmNkBdMpI1wHliVQ/bF6B+Sz/Asmqwj+hQNbyijtAPVRhm+7ykL5bK+79swhK7rsOa3pKuALIhp yg4m+sdYF2VmfIHzxRsL7+Um5o20CfIaw73bb2Fd2AV0VdrXjS8PG8OOH79i7+kdmm0ljOBqlEJx ax9hkHnhiZ3EMEFPXQ+P29wsTpEzb0G3v3pbgKBwwLOOcWxki1stmxpURenXjQHnOzOxYhaSmegf IqFw6B5Vg54Xjq3jQkCL/2Hy3aC7sBuKWzLFjFnBNzmggRUv+zaryZM4pbu3ww1XLoJ3r4tnBB+e a5TeHW8oOrPXaJ7Ym+2OuSYuzJorosqJihkUcxfD5B5Z17jer1uCnKx4Rs4k/i5wrsJN0TRof6i3 6676Elb9U9huiDcxAPeMzYvkjzEQVkUyCBz2WNroT1JAmbXYftHlIF78vwO1bJyFtWFf0QZwnNHw qyiaLmvC1G+ekTK8VDHeRWwN4B6sp/V8OPwTYABvUG0yDQplbmRzdHJlYW0NZW5kb2JqDTM0IDAg b2JqPDwvTGVuZ3RoIDU5NS9GaWx0ZXIvRmxhdGVEZWNvZGU+PnN0cmVhbQ0KSIlsVLuW2yAU7P0V KqWciIDQs8xJTooUOSncxSmwhdYkMiiA7eyHpt5fyQUMWu9uB2LuvTPDoGz7dbN9t/mRL5obLm1R VrhGfW7Uicc1L6oakfwiRi4P8JX0GHW5VXBOWoc9qoC4xgp7ZKmTsBEnTFztubVcJ3TqNHO7tgA+ xU+gh7OSIDJUTbb9DERHMYVpE9eOsIN8+EIzkm2nDUUtIW2GA/Rwnu1ZF7QFNDc3ZBWRdMArUpW8 IFX+VxhgAMNAoGbAQT+TJON6Utr74GEAOr1Wwka1BG5lhzCuqBMBoJsIBrgaoyE3Qj7M/KUIiqv+ TREvNeCq6QIwL4vtr7UHRk1Hh9hj0UXdoypXB26M0mn4kWmYf9+0QzUemli5y69HcThCRdVDhb9C X+vdCKu9sZodbmpJjSghw73ci+BrQnyRKnA+xc320/dy0oLLcX5cQ+W57QoUQoCGYeh8167tQ9dv 4crs+8juylP7veH64o55bHjLpAfCncXlqE5CMplCypZlFgdmhZIpriJptaoMMp/xSSpH9vivaDH4 DJWUUFhIbq+OhdK/4ROGHOdniHVJqwZOT3C1Ypl5RION0ixK24id49MLSnA+R+gTbNKr8zNRUTak c25Cann51tOB3HIwi9YDoiDKQNjd9d/YKFBJaQdHkxvHhJaQlnjqzAuFLMIWeB2eQfm0/gACenen JTCOmF2xclvN2zMj0rB19ecsbPJnL5jhY9wxOUafTpxJ/5CMcTbgBmz4ONujOj+46PaDm5tsH5Un 4H57WfZfgAEAnVpHzQ0KZW5kc3RyZWFtDWVuZG9iag0zNSAwIG9iajw8L0xlbmd0aCA1MTYvRmls dGVyL0ZsYXRlRGVjb2RlPj5zdHJlYW0NCkiJbFPLjtwgELzPV3C0pTUx4Od1k6yUHFYrxbcoB2Iz YxQbRoAz2q/Nr6TbmMlDqzlM0RTd1d1lkhkb8qKqatpms8x5RVn2M2c8UxCtW4jKBLxdtqCtSfSz dQmGWftEuzr7fVHrA5w7Rrvsds80aT9u/k60m8u/DZ9PJSkYZT2vyfDh9BVy2e0yB6BBDOubKS84 ayDV1XpIxssKcCzJeUf7TPrEkAnEHtxrouv1al2QJqS0Tnkl3TgnAsou/uiB4KEHegFOVUKdveMI w6wSNCrcsJp1P7S5JAGjXdfN6PCaNyXlGd1Tv3tihJHhfGKM9nXNSQm/hAWrCesEbRoyrFCY50Xf C5A6vH8pzk4rMy3YT41Fn5WakoBnXCEXCB/vqp5yXsIupUbJALsMNxdZMoGXSFIur/A/9s9o1dfN vpSmEnEIv2zOyuyWqj9KD9OPHfHYUU/7hjd7Qwfc+wF7dEc/A45MVD0VaLrdSEK0cLJnQA2U/a9T wWuY3GjNRfm/+RAJzi7pOOP643s5FW9ZatVOgidRPQf1FysXT+FNK+DNF21GvGrqY6kAzrjPODo4 +Vm64wIEAmjbf1TFgUPkTf8cUksQlCWfoF+7HgNquV/u7oowCtkZn0xQDiz2kO7i97Dfadi7YAKG hN/Ccb14m6J+u6LrwSmo6+NwIoT8FmAAugcCDw0KZW5kc3RyZWFtDWVuZG9iag0xIDAgb2JqPDwv Q29udGVudHMgMyAwIFIvVHlwZS9QYWdlL1BhcmVudCAxMyAwIFIvUm90YXRlIDAvTWVkaWFCb3hb MCAwIDYxMiA3OTJdL0Nyb3BCb3hbMCAwIDYxMiA3OTJdL1Jlc291cmNlcyAyIDAgUj4+DWVuZG9i ag0yIDAgb2JqPDwvRm9udDw8L0YxIDIxIDAgUi9GMiAyMiAwIFIvRjMgMjMgMCBSPj4vWE9iamVj dDw8L0ltMSA0IDAgUj4+L1Byb2NTZXRbL1BERi9UZXh0L0ltYWdlQl0vRXh0R1N0YXRlPDwvR1Mx IDI3IDAgUj4+Pj4NZW5kb2JqDTMgMCBvYmo8PC9MZW5ndGggNDcwNy9GaWx0ZXIvRmxhdGVEZWNv ZGU+PnN0cmVhbQ0KSImUV9uS27gRffdX6HGUGtEiqeuTy2vHiVO1la2yUnkY+wESIREbXrQEudrJ xzq/kkY3ugFqOE6lXLYhAAQa3adPn377ly/p7GLf/HR48/ZTNktnh/ObfbLfZJvZEv744TabbTfL ZJnNDvWb5ewCfw8n98/tzdPD8Xm+yLd5snroSw3D3ZqGbfc8h4+yh0eY3G+T9YOZLx963mG1ri2v nOdp9qBMJye1vE3Zf8mwqnj/f9p5tkrSh5uFw1fLvTu8OVVDYZrL/Nvhb2DbIk2y5Wo9O3wEG//x 8RfYt9knu+hTnnGX0ahwo/U22dJTaNKqWifzxX6TJ5uHzw1PH7W7a7FarWH7qW2sKXSnes1TcKoY ku6z2JB8k8JzYkNo5utDe+413JDn2yR/sMP12nY9XpNna/BkPVS9qXVhFO9R12tlTsr0YMDX+ePU 2/Ep2W4PVx0+/LI4d0Y3RQVBy7Zo+EXb3rSN/O67tqIfxlmW5nAxuJ6t1QWf5vxGI1Woa493H/7k bmzp+0b3NxfYtoMYZuss2Y/vw5m67Zx9m/XDRTd9FTDjphQgxtJhVev8gJN+xvT0vzK1n5n2Odw5 zzdg5u/OGA1Hdm5wgYG7eblyGIAfzurVEkwij6F1Lvg8bXutiufwC4NN2yjwtIDm4Sy4m4ch2AmZ mOz3+y0GarvZkZ2HUsy5du2x0vV8ke6WCQUiy3Zomup5E74/3biR5VHTynKnlW0bBefAMfuMIOnX lLVDLbcBrBZo1SIyK+BHEIcYHMGWMOgCSIuUoqs9zOpKQZxPskm2o1doGHtlsd7u4ISfA8QnQhlf To7Fy2loGn9nwrAFjzpOobj8NqjK9BK/9iyR1N3v5hRCPpzpkrPuLO+ph1M5lVwevZgFtxJzd5m6 3IBYAsaeRxniXrnapeDxT0MHOzr39aOkExlL30epx4PK1C7i/vxJpPMRFAt3paGn/O4ejonlHL1c w4s+A+LPvJeYG4fIEYGOcY7gTWYYCeRRCynwYnRObRqzmHTZILimcwmcLh40UjyI6Y4+kPgLS9BO I6ivzaXs5STLo5t2yKQtR7mz0I0BPvPEBR6rjbXATcn88GucopvVlmx/74lN9UOnKkYMkpyjqmci qHPbvcAkfTjCL+xkpiw0ngYzN9OXNCKq/GFits0ILzjCcowj29aCTTCp5jEi36PSP5g/8fSfcBE7 lOFgqG8quk7Y/igp1QiD1lo1kjuNHgUt4UM+9+ylUsnmo3ZJROPC2NNgLVYcnDBSNZ5y5/Nvj0ID TcEUiSk5kRydPlGB4Zue5bCNO0zO2kIk5ccu/rH/lgiLlRHv9LpzRQ0LlOcaKXJkuI83UsRETtwC F5s/GJ0BOcTZ7om+HjR3azGuPPRxNw4rLdmB+Tl5enSCRHawAT/CCPTblkS89xKCcBskBMVlOzYZ TxilAs646ybiFoMUK4tcQJFArYgLlEWkpSiP5AOxkL6BcF31SdgRdUGQHhMBKgPTkb+KVkvRJb2A w9YdRed1KlCOfQbxUPMmFkXv+OXjckDxeXkjSpQJB90kpqe2vmJc0s0OxKp1ReueVEeijODkPOgV QsDHeB+eB+jtZB0D6uI54a1RbPHJBCUcjkUoGx4iJDMuyO8IPR9UI86TVIEtiwBWp/5lqW2CsuuU r+ffT3yGIMg/Rcw86h5yOcQVr/XZ17oQiaPGp47tua/KlA2BwUh1YHA8XULSO8gIh90dTx8AfanO tPbdjxSk8/M63UYcZLniIzL8sCggBZBZacLZRZ+1Q8eTxJj8S9DwakG6lQbfhJj+3llRK9ClaLi9 IIJAH7Dk4S1fzAXQW1O431sjpeaf890KMhYutmV7pXWoYBN+zpbLNUP1KV1igUj8gSIpUK8R7F22 ADdKukQEO1wLkCYFr1zVFUMvYpxTgEdPaeqvm8iGnyONKEWI9Qs98ka9iPdWZVsZ8+DStp5JSdfz PGkNPNu459RwvCtEzo63n/JZOjucKUHumj9EeMStguG+m6+cEgfQ0iEZHZJmyS7Ns9nSBxsIth2k BQE4ca8aNRsI5qE33F/wGaO4kSjHJxCBGXifffQFxAbXXeGGlyB6SjMO9SrPIVp/1VyabuL3tuGO 9zIi/al4Kf7oCN4601fQLtWq8/ouCKge9ZHf3Rbxurte+DOUQopUL1/VCl9CdXSCPhyvuQDZe00q Se8TRFPly6W3o9oX1V2aGPVvWCpPSkqrQCg0EQyQV7M+1HsEglOdZXuv+NwDf4Z7fE+EuMCsks4W Wt5rS1qPyp2xfWeOdNDQB2409STLesNVECIchhjk221kL+w5KrrSkYpfB0OOJOWcQC8nITIqjpSI T2nuVSS1Qimk9AqBCYOE2fWnQVx7VUiQuPn+sAbkOsgHkfIU0yJus6TwjW1BeWOHq8sVy2H9DArV bbl0xGpkwBfqe12m5dscgOCohD74aHz5OUMuAaHgZxNO5yPG3Uypq6vPUttWSnJ21ApROmAmj+bj 0pewZYLxqXT1eF8t9wkFbLHKUuCB6GC/NqqqNGcd5J/5FwCSOqV8t4ZrX2JQvB6rUoxJUKUUUaZH n0cMfVodxwyn4Blw2yMnpeM9CqYR1ToCYwjCSVnpRRDzKBeA7nlypNBjAZS8qiTuSaV3jYsHB2o5 Gipet317Kkc8A2kEwBAIfoX0h8e6N5NE9o75UAIBfp1HYv5VoqnbQouQIs2Nw1O7QHT/Af7TzUkz UQRfBIBFzaLXY2GNzp1QXsO0riuCUizG+fI/VKJzvU24AvxZoWgisfp8Da3E+UVvxkulEsWq+LVW XxeT6eFyXnik66T84X8KyKmSCgs7XRXd7J1ML6V4hgqCSB1VEDy2VKOaeq9dvleav7Xm31oo0sVh Si+XEsIX4Rl1FrhF8VLZVgXxNrnS1O4xZMEhHBl1suQ338niD8qUST/69pEqJsVQiDMmA0yH+w0k dHGJsof49hwdaHuFZRez5Wj6QDUUQNYxJ838+TI8+NYYLaQ2IMaiN5ypfc81T/enAA25hBpXkicu 56a5PyizF+inNAP0N9aEeuzeYele1jwUatQGY3Jw+/HuhLmYepuJwOA20eQg6EPPKe3gsVdBrNOl uACEoVC1+V/kafxx1IJqgz0Rqf+QldExQOdRJxrJPgQmFihCJoLspbuo25xgnkAWd0S9WW19y+fb o4Bgp6CFRKJcujs/rgMotnHipiOrzaWJNTzpdEqioTktXmdq33ZihNv/o/aPsjveF15FyMJXoeLo FbUp8F2+T9PZZpUsoQ0gO+wzBLjmuIc3YNCGpghN3UsCx8aPQ1m1qkDGhjv/3uhpfqe5sYyPfELi AHPNNQ1U/lziG7BDS29w1JCeHe/sSyWtnmpaeLi0e+PL70SIz/wzL3g+uVcOoNVDkmAzh0NVQlrw g76iLvTFq2ptwFYbcmX0pSvn9K1pxkAkx4/jAEZMOsw3gnzUOVhB/ER4jQPEW0OOGhC+0Jn2UmyB RToJX5Qnvw0mpL6Sd8U0jGyNgSg00Ekl1c+IBizvqbcH6m1DcOrr0OuI+Whe/EHH0UN9e6mtbIsh SoNJVRIxSkinR0nc4MVbaVB4ROHBYQcRpL6MnBGqY6fhaoSqh3878bnv6iYCejJUd4hejp7qUTG4 Duk1hnsP7l3nS4klMul6uSZ6PFUDFV6acZm1XrkOSfXccyn6noQ9TblY0ghk8g+I7NwZ3RTYH+Q5 8EFU6FerdRI1k7Tu+wfLvzmZaTMlM43l3rvwhRt9rxqUO/Ig5/d2GwMl5lGcCKF3gm69dTcGQQch nkw5TLcIhR7f0CHp2rWBWMMQvEbQ7x4SGS0iw7uJJoQUMZM8FaLyAVGAnEa6x9MddUDSMuFSG+/z TRoKKsxL6kZekWG8buwrcrNhsP86gBO/I0o9f/DoKc3AHHjKfxmvkuW2jSB651fwKFaJMECAC8on O4krqhzilFXli3wYApCIGMDAWMzwQ/M/6eme7hmQkJ3SQcPZ0NPL6/e+CDiA7JKNWjb6SohmQAlB XgxlMQNQE0l3I3WoRzgpiRLJ+YWUpWEXre24duroKU+HLnjadG7cHLh4PLjKghjuQjgFgJGksfEA 1OYzawIsc8omL+Noze/dNIPIYQ9qzQfVywt8qy8nimEmLGXjh3Wg5OMsKeq+qOhszy97crlEUpJy iU50FzrPItPm2FGU7LQebxHgaXXPGEMJkxwi8oh75bk0jYn8dpTZWrsdKsvGeqwUAiH5Q9jiLBjo +mcsXwqR8Rx3kym0UPiuboYR2qeFl2Ols6+O6jsFUM5zGAcySMMmdA1Rnark7ssNmu93B7riQTAB 0rZWncs3Y9AZss3JEGePKSHdE/4ADKrXlQesmv7TFpDlNynmYfxVoqEe89o3Tdxcb7Pp0mLaORFH Im9KyHCuVhen8daFMeWfEvnI7rCDBvHQoASZczaCBPikK4CcdPR2Zr+1R67JV1BRdVl5SpG4s9Fa DN+WMrPk6lU9W3g/0AmMWk/Gx5aD+HITF6cNQUixOY9FZJFVWIpq20LNMwZpn2EabPG1NEKRl2wi cCA5g6Z9D4PX0z3MFcoUBa1PGxnJynLo+Sp5SHjXOHBs1DB2qhLsmAYZ51ybQcR9AsAEK1Qp7ao/ YS7LbunpIgL886b1zhG7/6WUrtoxJozfjickAleJRqAY+0nRY4m7Lz+tAoaYz6RCRaAdi6qcwI5H FB2fpALHW+ELSOrxRy0tjg75zE/i8m0kJ/ZyW6WxRvAKYig0rspGDMOiwlm4ENIuOxFUvfkQLaPl 4/MiioJ0u90sQ/jjcRxtl0m4CZLN8rGGT8erdQogv7/7UAGJDT38Q76wNaOPq01osBfSNzGD9aDX bUHqLbp7R6ttW5WZoleQFRuyIg3S3WaHRtihsSHeH4L9gWz4jATXirueR/Vosp1i4uO5qlRXE4RY fOcTg87V5V8CYWklTTFIW+IT8g2k1hIGfBMhgfdC7CdjBWmjejHTwCaPtSjTORkL/ImL4VgYkcqG HS+85ZnYmIJina2WwbHdXMPTFeIf4af3xXvx0MCjqiCbRdshWKIR0peMffSDUVpg9aXSR4CLmUJC mgWuFUb+nhgkfclRbz2KD6FUV/HOVpFJp65XnPSmXQIz5FMQYROyFzHz4dNHX6JKxH6nMsHK+oNu 92YISLCgfjmB20Q5vgcOprvOk5feVkvOaZ46UcdrXobMBoqzZraJEkb3jObZiBZU0lTR7bTmwkzk f+4mzB8cfaclXc1g3t0IwX78e7EL0n18wCq0wzjeBBv4F4XBDsHgLjIbZ8rV+BWQI9wHoUWNgKnh ByotjhOQ+14S/HzSPBybHMI9SB/32QlumESEWB9lCZRtf0+EB35GaXpFeAaBKwFPoBiD4HIGJSDR xHJniOWDts5xAyHFWOU8AWqn4bEH5dj2IaGbInOId1UisOyHWNqh7aM5u6CptMoBz+55ZWztjFNJ Oa9lpyL7OukdVKy28UB/72/bA2e0pHB/w2l3yZ6sfudwfF2pCzKWOAZG4UEg8f9SxFGjB4YBUlU4 qxvzbpoGk0UkgF1X/NX5bBaBmVmxXdKpPxGQ4WvHxhpHT1Z+O5JWfJkrWlX1kqeD+sotnuAxt7UF tagQjoBboGMZ0myIaQV9tG6VQTLkp51q+lZ3Q/92LkP47q7UGDZ86AtQWUllpNw0HHuJM33GTz+b kUreei6qSvz0J8bftTk9GN6ohKTV2jD3TtoU5Nu5zBGOsT/Bl0DgQNrwxJoz8+oFdF5T5RJZ+hFc Vvg6St2i+15mRX8vE62qeZwDB+7KI900oqU2yg61z1TaOA35+LpoezxJ42512bju2Ast9ujINaXA yQmloNO5LtyyluMnNSWOtBmayvp1DQe8no9Ps5gOkwiwzAPRye7lgZGWeAUGY8ZWlzhzSYnF4MiR HZ/lQlKBeBEItbEu3PbCwqNdrSTBXnUD9VY6PwJtLgchRSa2krJShzpDWUiQ5KRJkmwDoy574BtZ wSIILNDkPT5hCsQHKjyWF3QRVBXvm/RbY8Vvj4tvizTEtghRS0zfTIL0cAjD/TJKoH2HMNwus3rx 5qGOlr/qxV+L94+LLfTaPXVTOzQeOSyjOAk2Xtfdw2IY4T47jDdpkMA+uHpnafJqvyVhQv5rK2Wi Dzs2qCdjwA8gTeUqDsnXW5MuvINYH+1R2TAq7ErJDm5sxvpoq9usls88IuVB41a1CBF4mZt2Hz7K 9e14tPkdBYdwR/l9SBPkI1XZn4o8eIVqhLHxbQr4gb7ZmG3g+/8GAMiYrtIKDQplbmRzdHJlYW0N ZW5kb2JqDTQgMCBvYmo8PC9MZW5ndGggMi9XaWR0aCAxL0hlaWdodCAxL0JpdHNQZXJDb21wb25l bnQgMS9JbWFnZU1hc2sgdHJ1ZS9UeXBlL1hPYmplY3QvU3VidHlwZS9JbWFnZT4+c3RyZWFtDQoA Cg0KZW5kc3RyZWFtDWVuZG9iag01IDAgb2JqPDwvQ29udGVudHMgNyAwIFIvVHlwZS9QYWdlL1Bh cmVudCAxMyAwIFIvUm90YXRlIDAvTWVkaWFCb3hbMCAwIDYxMiA3OTJdL0Nyb3BCb3hbMCAwIDYx MiA3OTJdL1Jlc291cmNlcyA2IDAgUj4+DWVuZG9iag02IDAgb2JqPDwvRm9udDw8L0YxIDIxIDAg Ui9GMiAyMiAwIFIvRjMgMjMgMCBSPj4vUHJvY1NldFsvUERGL1RleHRdL0V4dEdTdGF0ZTw8L0dT MSAyNyAwIFI+Pj4+DWVuZG9iag03IDAgb2JqPDwvTGVuZ3RoIDQxNjgvRmlsdGVyL0ZsYXRlRGVj b2RlPj5zdHJlYW0NCkiJjFdNk9u4Eb3Pr9BRSkm0SEnUKDk5djk1m4rt2lFlK2vvASIhERmSUBGg tfqbyX3zV9LoRgOUwsm6pmYGxGej+/Xrhzd/eU4nJ/Pw5/3Dmw/ZJJ3sjw+7ZJdn+WQJP765zSbb fJkss8m+eVhOTvC7L9yfy8OXaSNacZKNbO1skS3XyeO0kUUlWmWaBHoed0k63VfaSPjIHpPdtFbW 1u5rk8HXf/QsW8OUi4Ge9RJ6vk5lI1Q95/kXeZjPftn/AAcu0gSO2Ez27+Hgv8/SVZZspvrp89fZ bLFabZMVWHOFZrZJsulBVoL2/jZLs6nk/mOnZFvWYd5F2YqXS1FU3K9tJTseUC23Oml03xUympTu Mm9Sb8AVzvB8Mz3Q2f1sObXUA/upjpqisEq37srb7fTeTHJMJ2th1XDEmUxjwYWw2qhTq34rRDs0 KXrJGU5+heN5/akTbQkfaQ7hMkUF4eNZ+sitVtqLO1d3LxyKcHf/LepaF8JdJaGzk91ut3UGbNLt lgz4BBuudlsIVAFrjXPPOkuTnOyhkXOnD7Vs4HO7StYQcZiz3MGA6OIcrVqr2hNP0r3lIWW4pVtw krNkEU2JvvCRxujCVc6ysPxpdWhVESnu+kJ1rTQmoOLIrRv/rNIVber9Q9/kn8UYVJzT5nzNVlu+ VqHbkzRuFHrWOwAc9NhO15BM+WMOfnt2pj5uYC6ZistujclTB1nD8wbbAxxGQCJat/bKZpcCbOj4 K974xjYcK3Rdi7ORYNxm45D6UYMllazBY/OQOza0DLfEmE864VMOTQ3ADsafK9nqxv3epOXAF9g8 glHMKgQY9IeRrZF/HL0+8scSTJk+Hbl11T3TF6EQey+dIhD6Ee4/i7Oz3PceEJz0QYbhpDs8YZ8O Bxq4Glq3/wPYNPQ1eCjZMg748xvdUHQKPDRn7r1UwnJi4w1oMt6Aem2l2he8Ag0hY9LiwyipIXqI v3DvIef470I3ZziiDFSjqf8SVrjIkz8K0Ruc6TjyGpjRjLJX09dWLUKNYCCK87lWRDzmTxTf9fQQ q8DTLeIwjWr1EliUdomcTjHyiLIS0jhsAPEJMSEGxRs+uWkA9eBVzSOFbgI/9udQxJB6aIYZzMCk FVdz4zlsUV2NUbvx0CA6MvjGn18LY6Rhqo98PnTa63T9jMbBt19LLTp+sVktpwcoHRdV2moBgDR9 g1Bab7YOStABbjG8yqHuVTKWwiisaHi/ThYaMGXEwdW19HEJ24EQSE4J4afsJaMUXcRO4c4zoE8V 1i9HYJ91FyRJ2zeLGMcD2ui2dTsQ8zkYAjC/zhKuJU8tz2EQFwLLF+H46fmz4W4/s5QWS4rf2fgK bTtxpCD9VoyFEGsx2VzKQpXhBj59wq39HB101QekfFAYHQ/idX4Vzbl2llIf4Y3a3mp0n8ckbl+r ZjEqHyzmKtEDR36EOm4NjyE6QAF84W5lEya7T47pTWAtsgRXCBZO7W3dXJNBJZEOInpgEGUTGUTq RYdpBbEfJYHlxBjIocYVFRsE551yw3VyKMRa2486C8r9lUJOhgCkKL9bZlDPiy4VA+Yoyx0bikCM IKA7t/JEteaGVD0xBDQra7hADhziy+xAoC3yzRLmOFhTQbTdlcoj8iMqICRS7dF6xFpMg4RmX0h1 3b+qaVzZR+qXDFJT6b4uB+4gQZk7tRazcJBApIxIJoNmRNU351i5ZBlx/Vkbow7oVIyhE3dK1Pxp Oymsf6NgB9IiDflEJR8PU9VPuFfQ2DnQW69z6WfZVaCO2ImCHdzoLtQbkL7uMXD3UKHgnXEwSFYV 4nzUITKQ0LwtRhA7iQUAv4vX+fdcoxXr1Qo0JUNe1SXxOSr0g7TWYYDmmP5MlEqDaAONnCXMwg0W Vi/wy0/yNef/ooWMNzpizSUptVVsBTe6wjFAZlhXKlNod3HvRWRFkqnOpHgUeY+8L5GFvArQY8iC KtcSqw8SmN6JiGGSrJjVrUe5qYhxoI9fBCZhdfp0D/pGinZQnKxqZEA7TYItMczUR+WGkqF2bnPj JxFhymHz01k2Dt53/oEZHnM40puRME2BapLZ/p+j+H4KR4IOaER3neVL8PY8FBiIQSDZAQnHp5xP xj7wrAhbilp0zWASvxFfBXR8C9w+hjBjBi8z/CYSdYwAgdmmTm78NFvlAGF6I6ICGLwpAKq16E+V jYGKyr2QnUX/E9pAXZcj+l6cTmCFuU91ej6MZBAXCtZs89EkipJU1+VCduKG4XDgBLeUMnAhCNSm b5UN2ivOvHEcDQbtHRSlMhFBo2XwXIsCCxlV01CS6c335sNqkk72x4d1ss3X28mSFh2w3olvMtri OoKsveiuLv0GGW2QJ7tNHja4QB4GetZdiS4kAg8GX2UAWhTah3Ck9BmwSNNkm6XrO1eDuFSmkmVI 5Z9mj2tkW1/pDrJW8ja89LpR5v4VJLx0rKBCy9aXebRxKOhhMUBGig7YZsTRpeqoXPJNRbjpRdZ1 4t2VkrvgUrvNJgN/LSfc3maTDKT7YzbZN7DherbY7VaQC+90W9S9cVvfuHyX7PIsxy180+2Q7ZLc 7xDZje98FmcIBabWnEUA0QIMHjq6OfQCK1vPqf6BBONDZ7i9gK3P8r5cLqfh2qwOMEEHiyle7G0Z CmnkDOUks+MDkkQodI4ISdV9D6+EU28kFxWcTy0DQbLw8Y0KDJ7HmFGncoRd9kWkTupv0W9DcJC6 hG4vJi009ThNqPaF1bY4EOHix/7d58WxU7ItnXjy8v1WBSEP+DIyKtm9MnCeG0FpI22lS13rkztg k7N28GcRUPwjpA0POkdK/vli+9JXFv8Y/ATXbOMGcQ3VYno9etf6l5Qc8wrWoUCf/djTAHRjzW2u QD7ZvAdwKCKFk3hIpLj/oNxSrtaj5Mng4WWRvJCx6L1CLwDeaFAjoqiND53exIdOX1sFOI+lYKg8 WiKTULpgtOi7DnKijv5fA11sp29riCmUQ6YzB10qfqXm5fgCo2Ylxoqe4DXBjLv4FB28B5gS6t67 hRzuEDQgV2j58PxPOjU68gX+E/SmvRVYkP+aS/BYXKxoo1SKFdMff4cPzAoyEWcd+87LRBxhTv8O gl6lm8kWfL/0/Lphhn5bvLSgdpfTSy3LkyMu83tUjXsBEefZMqXd9u72lC6ih4g6LUyfACBHGPTx tuyUE2Zp/gjJu6eqJ9DTmHf/mKWrDPRS8i7hwWvY14liSsKfK7WoFQ/8DCecIvgG3lKtUaC0jn2Q LE7a98aVI/OdPst3aahJP0r3ks2WEFoJQfx9P8HU5XqSw20zv8WX9BeA/mMKl32f8HvsbwkD+F2l eu7FCxPAf0z4afEDyMM5f/yLfPS2FfXV4LsGN0GliFuQ7sRO1UISCEP0BVfKwaKbHKHjcN9S+rls SX3SHZBUY7hn8PKBnIM6SCnlp98kiVYlIn4kFVzRXK83EEOQkufexufegPZArm4zOOfft6IPlHa6 3QXR9i5ugC/Jj7CBW8w8w/V8wetuDHl6fv+RQfN8NVY2d7HdAAYed3zYnOfyFeuEe9JtGEx3wGh0 6DbJdmk6WWQJDK1pky9ZQMLbhP3wHpQDPjBp4DkM/JVOkiYyID+R1vnO1WIXPrp7XPVcSUg+R5VR ONH0IXQWr2Liv3xXW27jRhD8z00WkBm+ho/82Vo56+wKWVgOAgTIBy2NLQYSxYgiNrlGTubVAXav kp7u6eYMTfmP5DxITnVVV2FRpWEJlKTywDTT1SD/trfQE6w4vKp4vmN5cODvXveaLBH6HakpD16v QEx9QGAcIA+iLEkZhM/Hd2lhqn2t9QY2FiuGH4M2y4ld13Rqc2j4S362uvt5/uty+V9R+mCDtKoo TB206ZdWuj1ZQKM8yPKk9L6W8IYPvuKj9OBO/nRRNZ1iCh1qAOfbvtlURovRNGA5bTSImfV/ddf1 2tpi0ju/Bz31Y0yd/tObdJOkJRw6uBZ9BK5NU0wFZRrLMdwtFgtRIVv3/bExH0gPsRxw25XegQPQ oifX9v+0iRX8ZjpI+w6n6gyVTaxkI4IVIEEtzwuXhdgFJ1iYCAsJNKFkqSyCRZCm4RijVDC6JX7A SgVYl8K/HTsYeIHKzE+d59sKIydlL1pObIT+Cj26MtZDhYpskvG+NGS9B43oXQUaur6MmuOkp9FK QNcKQWvRMz1a7XZc/Hb83KrpKrZp1FYNgNRSH96VGRDEwMhg2EBr3+LWPQqBi1IUKJW9rZXYjAsZ a1uBKEleklygBcDygN8cR8UYMCWA/RKw0iwPTHDSLBSFYfh3ayx2R/L11HDOt6OIBjnm6nS40rgF luyXugFPSqnpMr0eoW/CEpXGXmekKrL4X+hoUWAkxaHbj6xaIFkqCV/DZ0GxK/2gZl082UxJAbYv csISzIogLJPiFWhw/oU9/zLIAVX/+DM5/k9iYW7AlO6qfsb3Cxn52Bg35hCIzM0KNFnmTGkijdzZ abTmdICanLlW6RIgHwLOFmgUZ6Sa50Wz4dQGgllt9jXaQhq1OP0k3QM8dn3SayfjgIwa6aPOwHpM tUTkx4FWH4Hke2OABHQ7q8bs6VcAgF2G6q0Ox+2WcLfzPeBtV2ME4zAMfaiBVyr0vAyy0UwUbVRR QnZFxYx17mGdqRDOZVl1kEV3teYH+Ot0aRgHaCDjUE3k/v7wqI8n43JyVRgvcgPLvtSb0/ayEQGN RXlVZcjWOIuQxwNyNCYam4XmvFFj6ZI11q40kjqZ0C4pLKQCME98cBMaeZICYhNpyzVSI4cBx5Ao l25U46iDdkmhXiBezQTptIhzr08SYCO/MeBVTPQy82mfIesVBAfRYqq1GU64E2HdDfHPX2OY6q9C aPAI7Lo/qjWA50wih/O+7k7H+pH26Y1ZuBhMBoTplN5U0SKI0jIamRYUibFpwWMeUotjWvAtYFpw /hVzAvf1CoX8DFISowxSfmRfRhExK7NXvtLtjLRbZFojmXkqCXwaZ1H+EkMQmbEim93cVjxZEoNc l1ISLrbI/guA4tgnmSV8l7FrGbuhZEqqQ1WALdypPhyaLDfcgTMJzwRjejmacDzkivzOrZmR3R82 esejZJLxcl//YyywcNPEBRr5ttMMPmhD0z1BFOMx7jAjqYAa1tUelYn+YdKn2f+ZUHzAICqSNwSf dsVvxD3uHuZMoagYF1cY5upVC4eaSDi1QLWVxih4VRGFUhbvA2bDUq7m27p3+yzTI2B3v5Kpg9DT yIO1WvsZe6iz8R+CHO3ESbHRHdElhpxXjKhGAIKcbDVElsOzbvSh7/goqrbdMeOcU0fkpvtsXMSi 5KNsSAajfjayLuqL870vuu7qis/Y/jj8VLc9tD4s4O7zCVhudP1XTXYE7+GYm0rurtsjkSNwYByi S5S+smJRJCh+/WrCSW4q6XyvN/pbQ8kE44h32jZ81GJQMUHSw+7Ub/7lG1OAdHVat1cjlAZSPh1r MMxAbOtxXDawoFn1dnCCpgofNv/tw0fnWaowh+C9Xm+NoO5423s92bfbw/E0CFP/PHV2SZDEaWrO rizLGEUzMYK5ePjh/wEA98zkBQoNCmVuZHN0cmVhbQ1lbmRvYmoNOCAwIG9iajw8L0NvbnRlbnRz IDEwIDAgUi9UeXBlL1BhZ2UvUGFyZW50IDEzIDAgUi9Sb3RhdGUgMC9NZWRpYUJveFswIDAgNjEy IDc5Ml0vQ3JvcEJveFswIDAgNjEyIDc5Ml0vUmVzb3VyY2VzIDkgMCBSPj4NZW5kb2JqDTkgMCBv Ymo8PC9Gb250PDwvRjIgMjIgMCBSL0YzIDIzIDAgUj4+L1Byb2NTZXRbL1BERi9UZXh0XS9FeHRH U3RhdGU8PC9HUzEgMjcgMCBSPj4+Pg1lbmRvYmoNMTAgMCBvYmo8PC9MZW5ndGggNzA5L0ZpbHRl ci9GbGF0ZURlY29kZT4+c3RyZWFtDQpIiXRUyW7bMBC9+yt0pACLERctPCZOszZNmqgoCiMHVlZs FTbpiFIK/2b6Qx2KopSgKQwZw+Gs783w6PyBBGszOylmR2c0IEHxNBNYpDQNYvgNYkaDLI1xTINi N4uDNXxFaf9+z5ZoSehjGPGc4Bwd4zBiMcEEPYzS91CkmCN7JgxTVIQ5xwzJ3dxrTkfbm1FabOpu NLganRcfJPjc1aOlVKsworkA9Y+QMIoT9Nb3sbiaUUzSnAQRwTTmSVCcQg++pjBGhxA6pQgicp7g DL26q2M4U4JTVEpTgRwLCP2kGy+25T56aupKrbYHSJgn0LJc7Wpjaq1AITIwKrVqG72dhxmFkH/6 cmJbCRF0qAT6VpXNwFICNt9UHVIO3byEhKKqMXVrw3MBd/rJW11otfba65ClYA+aMU3EMgblFO5c lRvnx9F9tddNO5/qmBC56mwflMdYIBrHicMumsATQgymS8LGATgHtGmWoZNaqnJjeXFkHA/6hdxr Vc3dwZFltdjb3VVtU+vt5PhabBrdrTfRf7nbd603lkpuD6Y2fjJ6hHoJeIlaHVV9xjRBu0qarql2 lWqjn8DooJar6CNSRho5Y3YEHI2e+nq8qPcT5g6PGiZK9SGPzphbL0JwLKiA7epj3zUhz2HgdFlV q1qtjR80W7wLe/nl7NbVFXnnNwigxe1NWPya9pdiSqkPb4FMqCMxHkiEeRbxPyTy9yQCGtey2Rqj 1dwdLwf1jTSDRno4L4arz51aPb/Uph3Tvn7Vxt3tV8/vBn/i0gNtkewb8UhhkhDuOyncYjZ2EaQy smyBEuNHuae6H/N2U3nxXh/k1i/JpTJt3XbteDu5FO6JqoCs0obfKL31gLsa3uAdwUNIqH0Al0jD 2oH9YWCY+ro5GwiInZ2Fg+aOBeZYIAKnjOdBlEAFnGU9ANz2/6mY/RVgAApRVfIKDQplbmRzdHJl YW0NZW5kb2JqDTExIDAgb2JqPDwvTnVtc1swIDEyIDAgUl0+Pg1lbmRvYmoNMTIgMCBvYmo8PC9T L0Q+Pg1lbmRvYmoNMTMgMCBvYmo8PC9Db3VudCA0L0tpZHNbMTkgMCBSIDEgMCBSIDUgMCBSIDgg MCBSXS9UeXBlL1BhZ2VzPj4NZW5kb2JqDTE0IDAgb2JqPDwvTGVuZ3RoIDMzMzIvVHlwZS9NZXRh ZGF0YS9TdWJ0eXBlL1hNTD4+c3RyZWFtDQo8P3hwYWNrZXQgYmVnaW49J++7vycgaWQ9J1c1TTBN cENlaGlIenJlU3pOVGN6a2M5ZCc/Pgo8P2Fkb2JlLXhhcC1maWx0ZXJzIGVzYz0iQ1JMRiI/Pg0K PHg6eG1wbWV0YSB4bWxuczp4PSdhZG9iZTpuczptZXRhLycgeDp4bXB0az0nWE1QIHRvb2xraXQg Mi45LjEtMTMsIGZyYW1ld29yayAxLjYnPg0KPHJkZjpSREYgeG1sbnM6cmRmPSdodHRwOi8vd3d3 LnczLm9yZy8xOTk5LzAyLzIyLXJkZi1zeW50YXgtbnMjJyB4bWxuczppWD0naHR0cDovL25zLmFk b2JlLmNvbS9pWC8xLjAvJz4NCjxyZGY6RGVzY3JpcHRpb24gcmRmOmFib3V0PSd1dWlkOmE1NDZi ZmI0LTE4ZDUtNGZkYi05YjY3LTQxMGE3ODk1NTgxNScgeG1sbnM6cGRmPSdodHRwOi8vbnMuYWRv YmUuY29tL3BkZi8xLjMvJyBwZGY6UHJvZHVjZXI9J0Fjcm9iYXQgRGlzdGlsbGVyIDYuMCAoV2lu ZG93cyknPjwvcmRmOkRlc2NyaXB0aW9uPg0KPHJkZjpEZXNjcmlwdGlvbiByZGY6YWJvdXQ9J3V1 aWQ6YTU0NmJmYjQtMThkNS00ZmRiLTliNjctNDEwYTc4OTU1ODE1JyB4bWxuczp4YXA9J2h0dHA6 Ly9ucy5hZG9iZS5jb20veGFwLzEuMC8nIHhhcDpDcmVhdGVEYXRlPScyMDA3LTA2LTE2VDE4OjU1 OjI5KzA4OjAwJyB4YXA6TW9kaWZ5RGF0ZT0nMjAwNy0wNi0xNlQxODo1NjoxOCswODowMCcgeGFw Ok1ldGFkYXRhRGF0ZT0nMjAwNy0wNi0xNlQxODo1NjoxOCswODowMCc+PHhhcDpDcmVhdG9yVG9v bD5kdmlwcyhrKSA1Ljk0YSBDb3B5cmlnaHQgMjAwMyBSYWRpY2FsIEV5ZSBTb2Z0d2FyZTwveGFw OkNyZWF0b3JUb29sPjwvcmRmOkRlc2NyaXB0aW9uPg0KPHJkZjpEZXNjcmlwdGlvbiByZGY6YWJv dXQ9J3V1aWQ6YTU0NmJmYjQtMThkNS00ZmRiLTliNjctNDEwYTc4OTU1ODE1JyB4bWxuczp4YXBN TT0naHR0cDovL25zLmFkb2JlLmNvbS94YXAvMS4wL21tLycgeGFwTU06RG9jdW1lbnRJRD0ndXVp ZDpkMGI3OTg4Ni0xMjc1LTQ5ZjEtOTFiNy02MmE3MDQxMDhiNTgnLz4NCjxyZGY6RGVzY3JpcHRp b24gcmRmOmFib3V0PSd1dWlkOmE1NDZiZmI0LTE4ZDUtNGZkYi05YjY3LTQxMGE3ODk1NTgxNScg eG1sbnM6ZGM9J2h0dHA6Ly9wdXJsLm9yZy9kYy9lbGVtZW50cy8xLjEvJyBkYzpmb3JtYXQ9J2Fw cGxpY2F0aW9uL3BkZic+PGRjOnRpdGxlPjxyZGY6QWx0PjxyZGY6bGkgeG1sOmxhbmc9J3gtZGVm YXVsdCc+aG90bmV0czQuZHZpPC9yZGY6bGk+PC9yZGY6QWx0PjwvZGM6dGl0bGU+PC9yZGY6RGVz Y3JpcHRpb24+DQo8L3JkZjpSREY+DQo8L3g6eG1wbWV0YT4NCiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAK ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAKPD94cGFja2V0IGVuZD0ndyc/Pg0KZW5k c3RyZWFtDWVuZG9iag0xNSAwIG9iajw8L01vZERhdGUoRDoyMDA3MDYxNjE4NTYxOCswOCcwMCcp L0NyZWF0aW9uRGF0ZShEOjIwMDcwNjE2MTg1NTI5KzA4JzAwJykvVGl0bGUoaG90bmV0czQuZHZp KS9DcmVhdG9yKGR2aXBzXChrXCkgNS45NGEgQ29weXJpZ2h0IDIwMDMgUmFkaWNhbCBFeWUgU29m dHdhcmUpL1Byb2R1Y2VyKEFjcm9iYXQgRGlzdGlsbGVyIDYuMCBcKFdpbmRvd3NcKSk+Pg1lbmRv YmoNeHJlZg0KMCAxNg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDA5NTA5IDAwMDAwIG4NCjAw MDAwMDk2MzUgMDAwMDAgbg0KMDAwMDAwOTc2NiAwMDAwMCBuDQowMDAwMDE0NTQyIDAwMDAwIG4N CjAwMDAwMTQ2NjkgMDAwMDAgbg0KMDAwMDAxNDc5NSAwMDAwMCBuDQowMDAwMDE0ODk3IDAwMDAw IG4NCjAwMDAwMTkxMzQgMDAwMDAgbg0KMDAwMDAxOTI2MSAwMDAwMCBuDQowMDAwMDE5MzUzIDAw MDAwIG4NCjAwMDAwMjAxMzEgMDAwMDAgbg0KMDAwMDAyMDE2NiAwMDAwMCBuDQowMDAwMDIwMTkw IDAwMDAwIG4NCjAwMDAwMjAyNjAgMDAwMDAgbg0KMDAwMDAyMzY2OSAwMDAwMCBuDQp0cmFpbGVy DQo8PC9TaXplIDE2Pj4NCnN0YXJ0eHJlZg0KMTE2DQolJUVPRg0K ------=_NextPart_000_044F_01C7B05C.1CE46B40-- From tsvwg-bounces@ietf.org Mon Jun 18 01:28:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I09mf-00017M-W4; Mon, 18 Jun 2007 01:28:13 -0400 Received: from tsvwg by megatron.ietf.org with local (Exim 4.43) id 1HzXCi-0002UN-9A for tsvwg-confirm+ok@megatron.ietf.org; Sat, 16 Jun 2007 08:16:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzXCh-0002U6-Vo for tsvwg@ietf.org; Sat, 16 Jun 2007 08:16:31 -0400 Received: from eng.ie.cuhk.edu.hk ([137.189.96.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HzXCe-0004nc-Te for tsvwg@ietf.org; Sat, 16 Jun 2007 08:16:31 -0400 Received: from viruswall2.ie.cuhk.edu.hk (IDENT:U2FsdGVkX1913I4/9tPk91cQwTWhrb1D/HqJkPAhSaw@viruswall2 [137.189.96.53]) by eng.ie.cuhk.edu.hk (8.13.6/8.13.6) with ESMTP id l5GCGPCc015484 for ; Sat, 16 Jun 2007 20:16:25 +0800 Received: from IESTP19 (iestp19 [137.189.96.219]) by viruswall2.ie.cuhk.edu.hk (8.13.6/8.13.6) with SMTP id l5GCGMu5004440; Sat, 16 Jun 2007 20:16:22 +0800 Message-ID: <044601c7b010$6cdda9a0$db60bd89@IESTP19> From: "Dah Ming Chiu" To: , "Bob Briscoe" References: <5.2.1.1.2.20070615003454.041c1910@pop3.jungle.bt.co.uk> Date: Sat, 16 Jun 2007 20:18:13 +0800 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.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Milter: Spamilter (Reciever: viruswall2.ie.cuhk.edu.hk; Sender-ip: 137.189.96.219; Sender-helo: iestp19; ) X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac X-Mailman-Approved-At: Mon, 18 Jun 2007 01:28:11 -0400 Cc: tsvwg@ietf.org Subject: [Tsvwg] Re: Your knowledge of CC history is needed on the tsvwg list X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tsvwg-bounces@ietf.org Dear Bob, Let me give a short answer (to see if it will also make to the list). I think in 1988 or earlier, congestion control was discussed almost entirely from an engineering perspective. Any sensible engineer would soon realize that congestion control was allocating contended resources to different users, and that was when "fairness" came up. The biggest influence on the thinking probably came from computer science (how to schedule computer processes) rather than economics. A couple of notes: 1) In the "fairness" paper that I co-authored with Raj Jain and Bill Hawe, we did try to search for the meaning of fairness (axioms), which touched on some simple economic reasoning. 2) The more visible and sophisticated discourse on the economic implications came later, e.g. Shenker wrote about maximizing user utility functions in the mid 90s, and Kelly formulated the problem of congestion control as a problem of optimizing social welfare. 3) In the 80's, we did understand congestion control was not about allocating a single resource to users (as in the AIMD paper). We did understand different users may be using different resources, and the notion of max-min fairness and how to compute that. We did not publish any paper on that because we noticed Gallager had done that work ealier. Regarding your current proposal about a) dismantling... b) cost-fairness I think (a) should be discussed and practised in TSVWG; but (b) needs a broader discussion among other people collectively working on the Internet architecture nowadays. I will have more to say about these issues in follow-on emails. Regards Dah Ming Chiu http://personal.ie.cuhk.edu.hk/~dmchiu/ ----- Original Message ----- From: "Bob Briscoe" To: "Dah Ming Chiu" ; Sent: Friday, June 15, 2007 8:34 AM Subject: Your knowledge of CC history is needed on the tsvwg list > Dah-Ming, KK, > > Could one of you enlighten the IETF tsvwg list (if you're not subscribed, > I can forward your comments) with your knowledge of how fairness was > thought about in 1988? > > See Wes Eddy's attempt to re-write history in the thread > "What body is qualified to decide on Internet fairness?" at > > > You may also want to contribute to the debate about the question of > fairness itself (I'd appreciate someone bringing the thread back on > topic!). > > Cheers > > > > Bob > > > ____________________________________________________________________________ > Bob Briscoe, Networks Research Centre, BT > Research > B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK. +44 1473 > 645196 From tsvwg-bounces@ietf.org Mon Jun 18 01:41:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I09zq-0006zk-9y; Mon, 18 Jun 2007 01:41:50 -0400 Received: from tsvwg by megatron.ietf.org with local (Exim 4.43) id 1I09zo-0006vZ-TJ for tsvwg-confirm+ok@megatron.ietf.org; Mon, 18 Jun 2007 01:41:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I09zo-0006tg-Gl; Mon, 18 Jun 2007 01:41:48 -0400 Received: from smtp.nokia.com ([131.228.20.171] helo=mgw-ext12.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I09zn-0001jD-QR; Mon, 18 Jun 2007 01:41:48 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext12.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l5I5fMDO001689; Mon, 18 Jun 2007 08:41:46 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 18 Jun 2007 08:41:41 +0300 Received: from mgw-int02.ntc.nokia.com ([172.21.143.97]) by esebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Mon, 18 Jun 2007 08:41:40 +0300 Received: from [192.168.255.2] (essapo-nirac2533.europe.nokia.com [10.162.253.3]) by mgw-int02.ntc.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l5I5fdqR002530; Mon, 18 Jun 2007 08:41:39 +0300 Mime-Version: 1.0 (Apple Message framework v752.3) To: TSV Area , tsvwg IETF list Message-Id: Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-4--172855683; protocol="application/pkcs7-signature" References: <4673383E.70908@qualcomm.com> From: Lars Eggert Date: Mon, 18 Jun 2007 08:41:30 +0300 X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 18 Jun 2007 05:41:40.0732 (UTC) FILETIME=[587973C0:01C7B16B] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 21be852dc93f0971708678c18d38c096 Cc: Subject: [Tsvwg] Fwd: Nomcom 2007-8: Interim list of volunteers X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tsvwg-bounces@ietf.org --Apple-Mail-4--172855683 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Forwarded on behalf of the NomCom chair - please volunteer. On 2007-6-16, at 19:55, ext Lakshminath Dondeti wrote: > We have around 50 volunteers so far for Nomcom 2007-8 voting member > selection. We need a lot more! Not everyone subscribes to the > IETF-Announce list. Could you please forward the announcement > https://datatracker.ietf.org/public/show_nomcom_message.cgi?id=1234 > to WG, RG, BoF, Area lists that you manage? Begin forwarded message: > From: "ext Lakshminath Dondeti" > Date: June 16, 2007 4:09:18 GMT+03:00 > To: ietf-announce@ietf.org > Subject: Nomcom 2007-8: Interim list of volunteers > > Folks, > > As a followup to my note titled "Nomcom 2007-8: Email issues?" I > have decided to publish snapshots of the list of volunteers from > time to time. If you have volunteered, you should find your name > and affiliation in the list. If anything is amiss, please let me > know. > > On affiliations, BCP 10 says the following: > "No more than two volunteers with the same primary affiliation may > be selected for the nominating committee. " > > There are no precise rules to enforcing this and our documented > tradition, also from BCP 10, is as follows: "Rather > than defining precise rules for how to define "affiliation", > the > IETF community depends on the honor and integrity of the > participants to make the process work." > > During the selection, I will use the declared primary affiliation > and current email address in making a determination; when in doubt > I will request the volunteer for clarification, and based on all > the available information make a decision. > > Any subsequent issues are to be resolved by the challenge process. > > If you have already volunteered, thank you. If not, please > volunteer now. See > https://datatracker.ietf.org/public/show_nomcom_message.cgi?id=1234. > > thanks, > Lakshminath > Nomcom 2007-8 Chair > Eric Gray Ericsson > Bill Fenner AT&T Labs - Research > Kurt Zeilenga Isode > Spencer Dawkins Huawei Technologies > Henk Uijterwaal RIPE NCC > Kari Laihonen TeliaSonera > dimitri papadimitriou alcatel-lucent bell > Miguel A. Garcia Nokia Siemens Networks > Christian Schmidt Nokia Siemens Networks > Tina TSOU Huawei Technologies. Co. Ltd > Simon Leinen SWITCH > Tom Phelan Sonus Networks > John Drake Boeing Satellite Systems > Henrik Levkowetz Ericsson > Paul Hoffman VPN Consortium & Cybersecurity > Association > Eliot Lear Cisco Systems GmbH > Robert Jaksa Huawei > Olle Viktorsson Ericsson > David Meyer University of Oregon/Cisco Systems > Mary Barnes Nortel > Richard Barnes BBN Technologies > JP Vasseur Cisco Systems > Pekka Nikander Ericsson Research Nomadic Lab > Stephen Kent BBN Technologies > Vijay Devarapalli Azaire Networks > Shinta Sugimoto (Nippon )Ericsson K.K. > Pete Resnick QUALCOMM > Samuel Weiler SPARTA > Enrico Marocco Telecom Italia > Christopher Boulton Ubiquity Software Corporation > Suresh Krishnan Ericsson Research > Stephen Hanna Juniper Networks, Inc. > Wassim Haddad Ericsson Research > Marcelo Bagnulo Braun Huawei Labs at UC3M > Karen O'Donoghue NSWCDD (US Navy) > Zafar Ali Cisco Systems > Thomas D. Nadeau Cisco Systems, Inc. > Ole Jacobsen Cisco Systems > Attila Takacs Ericsson > Lou Berger LabN Consulting > Derek Atkins PGP Corportation > Chandra Appanna Cisco > Dan Wing Cisco > Donald Eastlake 3rd Motorola > Luca Martini Cisco > Randall Gellens Qualcomm > Jani Hautakorpi Ericsson > Joel M. Halpern Independent Consultant > Petri Jokela Ericsson > Oscar Novo Ericsson > Salvatore Loreto Ericsson > Don Fedyk Nortel Networks > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@ietf.org > https://www1.ietf.org/mailman/listinfo/ietf-announce --Apple-Mail-4--172855683 Content-Transfer-Encoding: base64 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGQDCCAvkw ggJioAMCAQICEGtxkLFHQu1g67hlmYfwPuIwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDEwNDE2MTE1NFoXDTA4MDEwNDE2MTE1 NFowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEA26hjntVPZMiwh4d8tyuk9KiucvG92BVUGArk5zO1jhmq7tLFgU1mqcIg VGumfQqjkAzIuh83kxIiqBrB05Wvxp85apwt4sUCvzMe8mQWzZZZYp0rBzwpOj+VC5pxsMRYtYW+ BaTFBEmvFr7D7C7roZUk0lDppS5SZFs4SQbEe9ykB9aeUf1iTiw2+ikyP2+JEYto14WYCoxFWbms FbQ1uaaK+yn1WH2YHhyMfi0IOxuT0jtbsngjHJMpWIqq334zBhj+rPSUug47YBHr41FCDMHbbbjv WbyTyDYneOW3WY8LY8bGWVlAknQGB7lgduShe6e0RI/7SL/VE6X27lM9LwIDAQABozIwMDAgBgNV HREEGTAXgRVsYXJzLmVnZ2VydEBub2tpYS5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUF AAOBgQCx3nxxTg/WowobVTRXBiXUEEZj4LBiunWbuAnR0UbJIgijvq3JbiJvZo2gUGiW9LPaHSBz 4oxT1VR/S/6O0a4e87oV5cOQm6ReB68o9rDfUzxHTwoCfv2wwMwBrXyzQMjyQK4Lt8siV41gmZpm rSXMhjTJdd9uYYNoZKQLq+VM+TCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJ BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgG A1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMg RGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3 DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3 MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9 fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+ uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMB Af8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3 dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgG A1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcP f6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH 2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8x ggMQMIIDDAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAo UHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ a3GQsUdC7WDruGWZh/A+4jAJBgUrDgMCGgUAoIIBbzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw0wNzA2MTgwNTQxMzFaMCMGCSqGSIb3DQEJBDEWBBRZVraBgutqNCRR WZtgeXejMCBwHDCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIwgYcGCyqGSIb3DQEJEAILMXigdjBiMQsw CQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIw DQYJKoZIhvcNAQEBBQAEggEA0MeTUoj8k0iTBFdvt6/5Psg28x5S9fZBpEA7bd9shZ7mfAvxihy5 wvK+TcZzIyhbs9pvXa0NXfsQ4sqW6NzwYEK+mTXVK46gEZRmoTMQNif08Jy71+nD70Y7qTtx7J1e WZ2Vs8e2QSZYDTHeeL3xr10smEZ5p0IKrBe8PTfmrAbzeaDFBzru99+o7/39pqxXz7zFVMK1xQIy 9wTNL42lZ38bpiR9UyFELRR14jXLC522+9sU6fMuy2GmreXKBldlVSrjRreImfaiFn7/ObXZKC3Q /SZdvTjvQi3PgaQ4V/QG/N62Cs1oCNnhZwTWLtDZyX3l/TlOJc2A+ZDRH2IofAAAAAAAAA== --Apple-Mail-4--172855683-- From tsvwg-bounces@ietf.org Mon Jun 18 10:09:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0Huh-0002pm-HL; Mon, 18 Jun 2007 10:09:03 -0400 Received: from tsvwg by megatron.ietf.org with local (Exim 4.43) id 1I0Huf-0002pd-FR for tsvwg-confirm+ok@megatron.ietf.org; Mon, 18 Jun 2007 10:09:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0Huf-0002pV-5r for tsvwg@ietf.org; Mon, 18 Jun 2007 10:09:01 -0400 Received: from mx1.grc.nasa.gov ([128.156.11.68]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0Hud-0000uX-QP for tsvwg@ietf.org; Mon, 18 Jun 2007 10:09:01 -0400 Received: from lombok-fi.grc.nasa.gov (seraph.grc.nasa.gov [128.156.10.10]) by mx1.grc.nasa.gov (Postfix) with ESMTP id 8F927C222 for ; Mon, 18 Jun 2007 10:08:58 -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 l5IE8uMY009668; Mon, 18 Jun 2007 10:08:56 -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 l5IE8rxI019315; Mon, 18 Jun 2007 10:08:53 -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 6Wtl2wUZ39lQ; Mon, 18 Jun 2007 10:08:53 -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 l5IE8nFq019265;Mon, 18 Jun 2007 10:08:49 -0400 (EDT) Received: by drpepper.grc.nasa.gov (Postfix, from userid 501)id 35FAA4FEA8; Mon, 18 Jun 2007 10:05:53 -0400 (EDT) Date: Mon, 18 Jun 2007 10:05:53 -0400 From: Wesley Eddy To: Bob Briscoe Subject: Re: [Tsvwg] What body is qualified to decide on Internet fairness? Message-ID: <20070618140553.GA2891@grc.nasa.gov> References: <5.2.1.1.2.20070617002448.043becc8@pop3.jungle.bt.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5.2.1.1.2.20070617002448.043becc8@pop3.jungle.bt.co.uk> User-Agent: Mutt/1.5.5.1i X-imss-version: 2.046 X-imss-result: Passed X-imss-scores: Clean:64.49754 C:2 M:6 S:5 R:5 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: tsvwg IETF list X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: weddy@grc.nasa.gov List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tsvwg-bounces@ietf.org On Sun, Jun 17, 2007 at 01:51:05AM +0100, Bob Briscoe wrote: > > > >Lars > > > >PS: I'm very much agreeing with what Wes writes in his thread of > >responses - my understanding of the history in this space pretty much > >matches his. > > Well, you'll see I'm still disagreeing. I think he is (so you too are) > underplaying the guiding influence TCP-fairness has grown into as an > organising principle over people's thoughts. You surely can't deny that in, > say, discussions on goals for hi-speed cc, or in the DCCP w-g. > I think the organizing principle is rather "do no harm": It was recognized that best-effort service was not going to allow widespread voice, video, and other services to easily and usably coexist on the Internet. Architectures for QoS were developed in the IETF in order to allow these applications to fruitfully blossom. For whatever reasons, best-effort is still predominantly the only service available for a lot of end users, so the high-rate applications need to be deployed side-by-side with existing applications. In high-speed congestion control, a rule-of-thumb has been to "do no harm" when competing against legacy TCP flows on a best-effort network (evident in RFC 3649). This way we don't need a flag day, and we can safely deploy some classes of high-rate applications within the existing mix of applications on best-effort networks. In such heterogeneous deployment it is not a goal to be flow-rate fair with TCP when there is ample capacity, and never has been. However, in a homogeneous deployment of congestion controllers on a best-effort network, absent of malicious/devious users, flow-rate fairness is a perfectly reasonable goal, but but this may be more appropriate to explain in your parallel thread on defending this notion. -- Wesley M. Eddy Verizon Federal Network Systems From tsvwg-bounces@ietf.org Mon Jun 18 10:13:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0HzJ-0003NP-51; Mon, 18 Jun 2007 10:13:49 -0400 Received: from tsvwg by megatron.ietf.org with local (Exim 4.43) id 1I0HzI-0003NK-Ow for tsvwg-confirm+ok@megatron.ietf.org; Mon, 18 Jun 2007 10:13:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0HzI-0003NC-FM for tsvwg@ietf.org; Mon, 18 Jun 2007 10:13:48 -0400 Received: from mx1.grc.nasa.gov ([128.156.11.68]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0HzH-0002nB-3a for tsvwg@ietf.org; Mon, 18 Jun 2007 10:13:48 -0400 Received: from lombok-fi.grc.nasa.gov (seraph.grc.nasa.gov [128.156.10.10]) by mx1.grc.nasa.gov (Postfix) with ESMTP id 836C6C22F for ; Mon, 18 Jun 2007 10:13:46 -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 l5IEDjek010297; Mon, 18 Jun 2007 10:13:45 -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 l5IEDiD3021497; Mon, 18 Jun 2007 10:13:45 -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 gH+9LuI0qDXC; Mon, 18 Jun 2007 10:13:44 -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 l5IEDiYM021493;Mon, 18 Jun 2007 10:13:44 -0400 (EDT) Received: by drpepper.grc.nasa.gov (Postfix, from userid 501)id 170184FEA8; Mon, 18 Jun 2007 10:10:43 -0400 (EDT) Date: Mon, 18 Jun 2007 10:10:43 -0400 From: Wesley Eddy To: Dah Ming Chiu Subject: Re: [Tsvwg] Re: Your knowledge of CC history is needed on the tsvwg list Message-ID: <20070618141043.GB2891@grc.nasa.gov> References: <5.2.1.1.2.20070615003454.041c1910@pop3.jungle.bt.co.uk> <044601c7b010$6cdda9a0$db60bd89@IESTP19> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <044601c7b010$6cdda9a0$db60bd89@IESTP19> User-Agent: Mutt/1.5.5.1i X-imss-version: 2.046 X-imss-result: Passed X-imss-scores: Clean:88.46435 C:2 M:3 S:5 R:5 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: kkrama@research.att.com, tsvwg@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: weddy@grc.nasa.gov List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tsvwg-bounces@ietf.org On Sat, Jun 16, 2007 at 08:18:13PM +0800, Dah Ming Chiu wrote: > > > >See Wes Eddy's attempt to re-write history in the thread > >"What body is qualified to decide on Internet fairness?" at > > > > That's a pretty hilarious accusation, given that the thread shows I suggested we get clarification/verification from some of the original designers ... thanks for the chuckle :). -- Wesley M. Eddy Verizon Federal Network Systems From tsvwg-bounces@ietf.org Mon Jun 18 13:25:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0KyN-000492-Vb; Mon, 18 Jun 2007 13:25:03 -0400 Received: from tsvwg by megatron.ietf.org with local (Exim 4.43) id 1I0KyM-0003xy-Jr for tsvwg-confirm+ok@megatron.ietf.org; Mon, 18 Jun 2007 13:25:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0KyM-0003ue-3a; Mon, 18 Jun 2007 13:25:02 -0400 Received: from [202.99.23.227] (helo=people.com.cn) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1I0KyL-0006jO-75; Mon, 18 Jun 2007 13:25:02 -0400 Received: from people.com.cn([127.0.0.1]) by people.com.cn(AIMC 2.9.5.8) with SMTP id jm3846773c92; Tue, 19 Jun 2007 01:36:27 +0800 Received: from megatron.ietf.org([156.154.16.145]) by people.com.cn(AIMC 2.9.5.8) with SMTP id jmb34672419c; Fri, 15 Jun 2007 07:36:26 +0800 Received: from megatron.ietf.org([156.154.16.145]) by people.com.cn(AIMC 2.9.5.8) with SMTP id AISP action; Fri, 15 Jun 2007 07:36:26 +0800 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hyy9k-0007ir-Io; Thu, 14 Jun 2007 18:51:08 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hyy9B-0006do-Gt; Thu, 14 Jun 2007 18:50:33 -0400 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Hyy9B-0004I3-6s; Thu, 14 Jun 2007 18:50:33 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id A5EC9175D5; Thu, 14 Jun 2007 22:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1Hyy8g-0005Hr-DT; Thu, 14 Jun 2007 18:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Thu, 14 Jun 2007 18:50:02 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 X-BeenThere: i-d-announce@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Archive: X-AIMC-AUTH: (null) X-AIMC-MAILFROM: i-d-announce-bounces@ietf.org X-AIMC-AUTH: (null) X-AIMC-MAILFROM: Internet-Drafts@ietf.org X-Auto-Forward: jaglee@people.com.cn jag@kw.com.cn X-Spam-Score: 2.2 (++) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Cc: tsvwg@ietf.org Subject: [Tsvwg] I-D ACTION:draft-ietf-tsvwg-sctpthreat-05.txt X-BeenThere: tsvwg@ietf.org Reply-To: internet-drafts@ietf.org List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tsvwg-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Area Working Group Working Group of the IETF. Title : Security Attacks Found Against SCTP and Current Countermeasures Author(s) : R. Stewart, et al. Filename : draft-ietf-tsvwg-sctpthreat-05.txt Pages : 16 Date : 2007-6-14 This document describes certain security threats to SCTP. It also describes ways to mitigate these threats, in particular by using techniques from the SCTP Specification Errata and Issues memo (RFC 4460). These techniques are included in RFC 4960, which obsoletes RFC 2960. It is hoped that this information will provide some useful background information for many of the newest requirements spelled out in the SCTP Specification Errata and Issues and included in RFC 4960. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-sctpthreat-05.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-tsvwg-sctpthreat-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-tsvwg-sctpthreat-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-6-14151953.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-tsvwg-sctpthreat-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-tsvwg-sctpthreat-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-6-14151953.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce --NextPart-- From tsvwg-bounces@ietf.org Tue Jun 19 11:24:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0fZW-0002MN-Ku; Tue, 19 Jun 2007 11:24:46 -0400 Received: from tsvwg by megatron.ietf.org with local (Exim 4.43) id 1I0fZU-0002KG-O7 for tsvwg-confirm+ok@megatron.ietf.org; Tue, 19 Jun 2007 11:24:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0fZU-0002Jy-4h for tsvwg@ietf.org; Tue, 19 Jun 2007 11:24:44 -0400 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0fZR-0008AW-Qo for tsvwg@ietf.org; Tue, 19 Jun 2007 11:24:44 -0400 Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 19 Jun 2007 17:24:39 +0200 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l5JFOcvt030507; Tue, 19 Jun 2007 17:24:38 +0200 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l5JFOYDZ025944; Tue, 19 Jun 2007 15:24:38 GMT Received: from xfe-ams-332.cisco.com ([144.254.231.73]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 19 Jun 2007 17:24:35 +0200 Received: from [144.254.53.188] ([144.254.53.188]) by xfe-ams-332.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 19 Jun 2007 17:24:34 +0200 In-Reply-To: <46E7B21EF4A45749B2432ABDCDE6FEA1018C68B9@MCLNEXVS12.resource.ds.bah.com> References: <37BDD2FAF2AEAE459C6C70FDC2892E4E01BC635C@MCLNEXVS05.resource.ds.bah.com> <46E7B21EF4A45749B2432ABDCDE6FEA1018C68B9@MCLNEXVS12.resource.ds.bah.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: multipart/alternative; boundary=Apple-Mail-3--51636608 Message-Id: <0FDADD89-EB64-4952-96EB-C64942D5ECD3@cisco.com> From: Francois Le Faucheur IMAP Subject: Re: [Tsvwg] RSVP proxy approaches Date: Tue, 19 Jun 2007 17:21:49 +0200 To: "Christou, Christos" X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 19 Jun 2007 15:24:34.0950 (UTC) FILETIME=[F1255A60:01C7B285] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=26253; t=1182266678; x=1183130678; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=flefauch@cisco.com; z=From:=20Francois=20Le=20Faucheur=20IMAP=20 |Subject:=20Re=3A=20[Tsvwg]=20RSVP=20proxy=20approaches |Sender:=20; bh=2VGaV4m5tWqGTwGZucUCeFOjyZp7Ux/vF5F4xNDI9/U=; b=oLhXQB3iidbilydXatHQOqjK4KnCYWflDBqvSVQ2JfvHtS9nGd20+ETM2j7zy7ehxiE4y8JG yDkyAmdYLsFz11qM4OYLbpCwfOPRcOPGE1HH+vEm01eDn027EkYWsY5r; Authentication-Results: ams-dkim-2; header.From=flefauch@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 680445c3afe8c9e96925f2dfef141924 Cc: tsvwg@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tsvwg-bounces@ietf.org --Apple-Mail-3--51636608 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=WINDOWS-1252; delsp=yes; format=flowed Chris and all, I'm started editing rsvp-proxy-approaches to reflect all discussed =20 changes. Regarding the input below, I would propose that we incorporate it as =20 a new section under Appendix A (eg "A.5 RSVP-based Voice/Video CAC in =20= IPsec environments"). This seems reasonable since: * Appendix A is dedicated to describing use cases for the RSVP = Proxy =20 approaches described in the main sections of the I-D . * the fundamental approach used in this scenario is already =20 described in the main sections of the I-D. The text below focuses on =20 some details specific to when the approach is used in the presence of =20= IPsec. Does that work? Thanks Francois On 23 Mar 2007, at 00:41, Christou, Christos wrote: > All, > > As Francois stated during the TSVWG meeting, below are inputs into =20 > the RSVP Proxy Approach draft. > > > ------------------------ > This option is very similar to the "Application-Signaling-Triggered =20= > On-Path Proxy" approach mentioned in section 4.5. As with that =20 > approach, the solution for synchronising RSVP signaling with =20 > application-level signaling is to rely on an application-level =20 > signaling device which controls an on-path RSVP Proxy function. =20 > However, in this approach, the RSVP proxy device is a component of =20 > a Cipher Text network where all user (bearer) traffic is IPsec =20 > encrypted. Network nodes within the CT core can only classify =20 > traffic based on IP address and DiffServ Code Points (DSCPs). As a =20= > result, only RSVP reservations based on "Generic Aggregate RSVP =20 > Reservations" can be used since it will allow resources to be =20 > reserved across a CT-based DiffServ network. > > > There are a few important considerations for this solution due to =20 > the use of an ARSVP proxy within a CT core: > > > 1) To understand which source/sender ARSVP proxy should initiate =20 > the reservation, the SIP server will need to be configured with the =20= > CT-side ARSVP proxy device that is fronting the source IPsec =20 > device. To reduce complexity, only one ARSVP proxy node should be =20 > associated with any given IPsec device. > > > 2) To discover the address of the destination ARSVP proxy, the SIP =20 > server will need to maintain a network management interface to =20 > either the source IPsec device or a server managing that IPsec =20 > device. Assuming a scenario where only one IPsec device is =20 > fronting an edge network, the SIP server will need to receive =20 > information from the source IPsec device regarding the destination =20 > IPsec device for the flow that the SIP session is signaling. > > > 3) Once the SIP Server understands the source ARSVP proxy and the =20 > destination CT IPsec device address for a given call or calls, it =20 > will configure the source ARSVP proxy to initiate a reservation. =20 > Since the originating SIP server will only have knowledge of the =20 > destination IPsec device address, it cannot configure the ARSVP =20 > reservation with the destination ARSVP proxy address. Therefore, =20 > the destination ARSVP proxy will need to be configured to respond =20 > to the ARSVP signaling that is destined for the IPsec device=92s IP =20= > address. > > Due to the ability to reserve resources for aggregate flows, =20 > different configuration options are available. For example, the =20 > SIP server can initiate an aggregate reservations a priori, keep =20 > count of the calls, and re-size the reservation if additional calls =20= > that are categorized using the same DSCP. Alternatively, the =20 > reservation can be re-sized on a call by call basis. > > > |-------| |-------| > > ////////////////|SIP |///////\\\\\\|SIP |\\\\\\\\\\\\=20= > \\\ > > / ^ |Server/| |Server/| =20 > ^ \ > > / ^ |Proxy | |Proxy | =20 > ^ \ > > / ^ || || =20 > ^ \ > > / ^ || || =20 > ^ \ > > |---| |------| |---------| *** |---------| =20 > |------| |---| > > | E |----|IPSec |----| ARSVP |----*r*----| ARSVP |----|IPSec =20= > |----| E | > > |---| |Device| | Proxy | *** | Proxy | |=20 > Device| |---| > > |------| | + | | + | |------| > > | On Path | | On Path | > > | Entity | | Entity | > > |---------| |---------| > > > <*** PT ***><********************* CT =20 > *********************><*** PT ***> > > > <=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3DRSVP=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D> > > > |---| > > | E | End system (sender, or receiver, or both) > > |---| > > > *** > > *r* Regular RSVP router > > *** > > > <***> media flow > > > <=3D=3D> segment of flow path protected by RSVP reservation > > > / \ SIP signaling > > > ^ Network management interface between Application Level Signaling > > device and IPSec device > > > || control interface between Application Level Signaling device =20 > and ARSVP Proxy > > > PT Plaintext Network > > > CT Cyphertext Network > > > --Apple-Mail-3--51636608 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=WINDOWS-1252 Chris and all,

I'm started editing = rsvp-proxy-approaches to reflect all discussed changes.

Regarding the input below, = I would propose that we incorporate it as a new section under Appendix A = (eg "A.5 RSVP-based Voice/Video CAC in IPsec environments"). This seems = reasonable since:
*=A0Appendix A is dedicated to = describing use cases for the RSVP Proxy approaches described in the main = sections of the I-D .
* the fundamental approach used = in this scenario is already described in the main sections of the I-D. = The text below focuses on some details specific to when the approach is = used in the presence of IPsec.=A0

Does that = work?

Thanks

Francois


On 23 Mar = 2007, at 00:41, Christou, Christos wrote:

All,
=A0
As Francois stated during the TSVWG meeting, below are inputs = into the RSVP Proxy Approach draft.=A0
=A0
=A0
------------------------

This option = is very similar to the "Application-Signaling-Triggered On-Path Proxy" = approach mentioned in section 4.5.=A0 As with that approach, the = solution for synchronising RSVP signaling with application-level = signaling is to rely on an application-level signaling device which = controls an on-path RSVP Proxy function.=A0 However, in this approach, = the RSVP proxy device is a component of a Cipher Text network where all = user (bearer) traffic is IPsec encrypted. Network nodes within the CT = core can only classify traffic based on IP address and DiffServ Code = Points (DSCPs).=A0 As a result, only RSVP reservations based on "Generic = Aggregate RSVP Reservations" can be used since it will allow resources = to be reserved across a CT-based DiffServ = network.=A0

=A0

There are a = few important considerations for this solution due to the use of an = ARSVP proxy within a CT core:

=A0

1) To understand which = source/sender ARSVP proxy should initiate the reservation, the SIP = server will need to be configured with the CT-side ARSVP proxy device = that is fronting the source IPsec device.=A0 To reduce complexity, only = one ARSVP proxy node should be associated with any given IPsec = device.

=A0

2) To = discover the address of the destination ARSVP proxy, the SIP server will = need to maintain a network management interface to either the source = IPsec device or a server managing that IPsec device.=A0 Assuming a = scenario where only one IPsec device is fronting an edge network, the = SIP server will need to receive information from the source IPsec device = regarding the destination IPsec device for the flow that the SIP session = is signaling.

=A0 =A0=A0=A0=A0=A0

3) Once the SIP Server understands = the source ARSVP proxy and the destination CT IPsec device address for a = given call or calls, it will configure the source ARSVP proxy to = initiate a reservation.=A0 Since the originating SIP server will only = have knowledge of the destination IPsec device address, it cannot = configure the ARSVP reservation with the destination ARSVP proxy = address.=A0 Therefore, the destination ARSVP proxy will need to be = configured to respond to the ARSVP signaling that is destined for the = IPsec device=92s IP address.=A0=A0

Due to the = ability to reserve resources for aggregate flows, different = configuration options are available.=A0 For example, the SIP server can = initiate an aggregate reservations a priori, keep count of the calls, = and re-size the reservation if additional calls that are=A0categorized = using the same DSCP.=A0 Alternatively, the reservation can be re-sized = on a call by call basis.

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0<= /SPAN>

=A0=A0=A0=A0=A0= =A0=A0=A0 ////////////////|SIP=A0=A0=A0 |///////\\\\\\|SIP=A0=A0=A0 = |\\\\\\\\\\\\\\\=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0

=A0=A0=A0=A0=A0= =A0=A0 /=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 ^ |Server/|=A0=A0=A0=A0 = =A0=A0=A0=A0=A0=A0=A0=A0|Server/| ^=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = \

=A0=A0=A0=A0=A0=A0 /=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = ^=A0 |Proxy=A0 |=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |Proxy=A0 |=A0 = ^=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 \=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0

=A0=A0=A0=A0=A0 /=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = ^=A0=A0=A0=A0=A0=A0 ||=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= ||=A0=A0=A0=A0=A0=A0 ^=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = \

=A0=A0=A0=A0 /=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = ^=A0=A0=A0=A0=A0=A0=A0 ||=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0 ||=A0=A0=A0=A0=A0=A0=A0 ^ =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0\=

=A0=A0 |---|=A0=A0=A0 |------|=A0=A0=A0 |---------|=A0=A0=A0 = ***=A0=A0=A0 |---------|=A0=A0=A0 |------|=A0=A0=A0 = |---|

=A0=A0 | E |----|IPSec |----|=A0 ARSVP=A0 |----*r*----|=A0 = ARSVP=A0 |----|IPSec |----| E |

=A0=A0 = |---|=A0=A0=A0 |Device|=A0=A0=A0 |=A0 Proxy=A0 |=A0=A0=A0 ***=A0=A0=A0 = |=A0 Proxy=A0 |=A0=A0=A0 |Device|=A0=A0=A0 |---|

=A0=A0=A0=A0 = =A0=A0=A0=A0=A0=A0=A0|------|=A0=A0=A0 |=A0=A0=A0 +=A0=A0=A0 |=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0 |=A0=A0=A0 +=A0=A0=A0 |=A0=A0=A0 = |------|

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0 | On Path |=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 | On Path = |

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0 | Entity=A0 |=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 | Entity=A0 = |

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0 |---------|=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = |---------|

=A0

=A0=A0=A0=A0 = <*** PT ***><********************* CT = *********************><*** PT ***>

=A0

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = <=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3DRSVP=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= >

=A0

| E | End system (sender, or receiver, or = both)

|---|

=A0

*r*=A0=A0 Regular RSVP router

=A0

<***> = media flow

=A0

<=3D=3D>=A0= segment of flow path protected by RSVP = reservation

=A0

/ \=A0=A0 SIP = signaling

=A0

=A0^=A0=A0=A0 = Network management interface between Application Level = Signaling

=A0=A0=A0=A0=A0 device and IPSec = device

=A0

||=A0=A0=A0 = control interface between Application Level Signaling device and ARSVP = Proxy

=A0

PT=A0=A0=A0 = Plaintext Network

=A0

CT=A0=A0=A0 = Cyphertext Network

=A0


= --Apple-Mail-3--51636608-- From tsvwg-bounces@ietf.org Tue Jun 19 14:40:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0icc-0004yd-8M; Tue, 19 Jun 2007 14:40:10 -0400 Received: from tsvwg by megatron.ietf.org with local (Exim 4.43) id 1I0ica-0004xZ-QZ for tsvwg-confirm+ok@megatron.ietf.org; Tue, 19 Jun 2007 14:40:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0ica-0004xM-GV for tsvwg@ietf.org; Tue, 19 Jun 2007 14:40:08 -0400 Received: from mclniron02-ext.bah.com ([156.80.1.73]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0icX-0002pk-OB for tsvwg@ietf.org; Tue, 19 Jun 2007 14:40:08 -0400 x-SBRS: None X-REMOTE-IP: 156.80.7.153 X-IronPort-AV: E=Sophos;i="4.16,439,1175486400"; d="scan'208,217";a="205194594" Received: from mclnexbh03.resource.ds.bah.com ([156.80.7.153]) by mclniron02-int.bah.com with ESMTP; 19 Jun 2007 14:40:05 -0400 Received: from MCLNEXVS12.resource.ds.bah.com ([156.80.7.214]) by mclnexbh03.resource.ds.bah.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 19 Jun 2007 14:40:05 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7B2A1.409E29A8" Subject: RE: [Tsvwg] RSVP proxy approaches Date: Tue, 19 Jun 2007 14:40:04 -0400 Message-ID: <46E7B21EF4A45749B2432ABDCDE6FEA101D83790@MCLNEXVS12.resource.ds.bah.com> In-Reply-To: <0FDADD89-EB64-4952-96EB-C64942D5ECD3@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Tsvwg] RSVP proxy approaches thread-index: AceyhfXzZNOJRKKjSy6Rr1jVouAc+AAG0QYw From: "Christou, Christos" To: "Francois Le Faucheur IMAP" X-OriginalArrivalTime: 19 Jun 2007 18:40:05.0134 (UTC) FILETIME=[40E162E0:01C7B2A1] X-Spam-Score: 0.0 (/) X-Scan-Signature: 6f7d7d4126a03a70c87b926ff3be4cd9 Cc: tsvwg@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tsvwg-bounces@ietf.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C7B2A1.409E29A8 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Francois, =20 Yes, I do think this works. =20 Thanks, =20 Chris ________________________________ From: Francois Le Faucheur IMAP [mailto:flefauch@cisco.com]=20 Sent: Tuesday, June 19, 2007 11:22 AM To: Christou, Christos Cc: Francois Le Faucheur IMAP; tsvwg@ietf.org Subject: Re: [Tsvwg] RSVP proxy approaches Chris and all,=20 I'm started editing rsvp-proxy-approaches to reflect all discussed changes. Regarding the input below, I would propose that we incorporate it as a new section under Appendix A (eg "A.5 RSVP-based Voice/Video CAC in IPsec environments"). This seems reasonable since: * Appendix A is dedicated to describing use cases for the RSVP Proxy approaches described in the main sections of the I-D . * the fundamental approach used in this scenario is already described in the main sections of the I-D. The text below focuses on some details specific to when the approach is used in the presence of IPsec.=20 Does that work? Thanks Francois On 23 Mar 2007, at 00:41, Christou, Christos wrote: =09 All, =20 As Francois stated during the TSVWG meeting, below are inputs into the RSVP Proxy Approach draft.=20 =20 =20 ------------------------ This option is very similar to the "Application-Signaling-Triggered On-Path Proxy" approach mentioned in section 4.5. As with that approach, the solution for synchronising RSVP signaling with application-level signaling is to rely on an application-level signaling device which controls an on-path RSVP Proxy function. However, in this approach, the RSVP proxy device is a component of a Cipher Text network where all user (bearer) traffic is IPsec encrypted. Network nodes within the CT core can only classify traffic based on IP address and DiffServ Code Points (DSCPs). As a result, only RSVP reservations based on "Generic Aggregate RSVP Reservations" can be used since it will allow resources to be reserved across a CT-based DiffServ network.=20 =09 =20 There are a few important considerations for this solution due to the use of an ARSVP proxy within a CT core: =09 =20 1) To understand which source/sender ARSVP proxy should initiate the reservation, the SIP server will need to be configured with the CT-side ARSVP proxy device that is fronting the source IPsec device. To reduce complexity, only one ARSVP proxy node should be associated with any given IPsec device. =09 =20 2) To discover the address of the destination ARSVP proxy, the SIP server will need to maintain a network management interface to either the source IPsec device or a server managing that IPsec device. Assuming a scenario where only one IPsec device is fronting an edge network, the SIP server will need to receive information from the source IPsec device regarding the destination IPsec device for the flow that the SIP session is signaling. =20 =09 3) Once the SIP Server understands the source ARSVP proxy and the destination CT IPsec device address for a given call or calls, it will configure the source ARSVP proxy to initiate a reservation. Since the originating SIP server will only have knowledge of the destination IPsec device address, it cannot configure the ARSVP reservation with the destination ARSVP proxy address. Therefore, the destination ARSVP proxy will need to be configured to respond to the ARSVP signaling that is destined for the IPsec device's IP address. =20 Due to the ability to reserve resources for aggregate flows, different configuration options are available. For example, the SIP server can initiate an aggregate reservations a priori, keep count of the calls, and re-size the reservation if additional calls that are categorized using the same DSCP. Alternatively, the reservation can be re-sized on a call by call basis. =20 =09 |-------| |-------| ////////////////|SIP |///////\\\\\\|SIP |\\\\\\\\\\\\\\\ =20 / ^ |Server/| |Server/| ^ \ / ^ |Proxy | |Proxy | ^ \ =20 / ^ || || ^ \ / ^ || || ^ \ |---| |------| |---------| *** |---------| |------| |---| | E |----|IPSec |----| ARSVP |----*r*----| ARSVP |----|IPSec |----| E | |---| |Device| | Proxy | *** | Proxy | |Device| |---| |------| | + | | + | |------| | On Path | | On Path | | Entity | | Entity | |---------| |---------| =09 =20 <*** PT ***><********************* CT *********************><*** PT ***> =09 =20 = <=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3DRSVP=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D> =09 =20 |---| | E | End system (sender, or receiver, or both) |---| =09 =20 *** *r* Regular RSVP router *** =09 =20 <***> media flow =09 =20 <=3D=3D> segment of flow path protected by RSVP reservation =09 =20 / \ SIP signaling =09 =20 ^ Network management interface between Application Level Signaling device and IPSec device =09 =20 || control interface between Application Level Signaling device and ARSVP Proxy =09 =20 PT Plaintext Network =09 =20 CT Cyphertext Network =09 =20 ------_=_NextPart_001_01C7B2A1.409E29A8 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Francois,
 
Yes, I do think this works.
 
Thanks,
 
Chris

From: Francois Le Faucheur IMAP=20 [mailto:flefauch@cisco.com]
Sent: Tuesday, June 19, 2007 = 11:22=20 AM
To: Christou, Christos
Cc: Francois Le Faucheur = IMAP;=20 tsvwg@ietf.org
Subject: Re: [Tsvwg] RSVP proxy=20 approaches

Chris and all,

I'm started editing rsvp-proxy-approaches to reflect all discussed=20 changes.

Regarding the input below, I would propose that we incorporate it = as a new=20 section under Appendix A (eg "A.5 RSVP-based Voice/Video CAC in IPsec=20 environments"). This seems reasonable since:
* Appendix=20 A is dedicated to describing use cases for the RSVP Proxy approaches = described=20 in the main sections of the I-D .
* = the=20 fundamental approach used in this scenario is already described in the = main=20 sections of the I-D. The text below focuses on some details specific to = when the=20 approach is used in the presence of IPsec. 

Does that work?

Thanks

Francois


On 23 Mar 2007, at 00:41, Christou, Christos wrote:
All,
 
As Francois=20 stated during the TSVWG meeting, below are inputs into the RSVP Proxy = Approach=20 draft. 
 
 
------------------------

This=20 option is very similar to the "Application-Signaling-Triggered On-Path = Proxy"=20 approach mentioned in section 4.5.  As with that approach, the = solution=20 for synchronising RSVP signaling with application-level signaling is = to rely=20 on an application-level signaling device which controls an on-path = RSVP Proxy=20 function.  However, in this approach, the RSVP proxy device is a=20 component of a Cipher Text network where all user (bearer) traffic is = IPsec=20 encrypted. Network nodes within the CT core can only classify traffic = based on=20 IP address and DiffServ Code Points (DSCPs).  As a result, only = RSVP=20 reservations based on "Generic Aggregate RSVP Reservations" can be = used since=20 it will allow resources to be reserved across a CT-based DiffServ=20 network. 

 

There=20 are a few important considerations for this solution due to the use of = an=20 ARSVP proxy within a CT core:

 

1) To=20 understand which source/sender ARSVP proxy should initiate the = reservation,=20 the SIP server will need to be configured with the CT-side ARSVP proxy = device=20 that is fronting the source IPsec device.  To reduce complexity, = only one=20 ARSVP proxy node should be associated with any given IPsec=20 device.

 

2) To=20 discover the address of the destination ARSVP proxy, the SIP server = will need=20 to maintain a network management interface to either the source IPsec = device=20 or a server managing that IPsec device.  Assuming a scenario = where only=20 one IPsec device is fronting an edge network, the SIP server will need = to=20 receive information from the source IPsec device regarding the = destination=20 IPsec device for the flow that the SIP session is = signaling.

 =20      

3)=20 Once the SIP Server understands the source ARSVP proxy and the = destination CT=20 IPsec device address for a given call or calls, it will configure the = source=20 ARSVP proxy to initiate a reservation.  Since the originating SIP = server=20 will only have knowledge of the destination IPsec device address, it = cannot=20 configure the ARSVP reservation with the destination ARSVP proxy=20 address.  Therefore, the destination ARSVP proxy will need to be=20 configured to respond to the ARSVP signaling that is destined for the = IPsec=20 device’s IP address.  

Due=20 to the ability to reserve resources for aggregate flows, different=20 configuration options are available.  For example, the SIP server = can=20 initiate an aggregate reservations a priori, keep count of the calls, = and=20 re-size the reservation if additional calls that are categorized = using=20 the same DSCP.  Alternatively, the reservation can be re-sized on = a call=20 by call basis.

           &n= bsp;        

           &n= bsp;           &nb= sp;=20 = |-------|          &nbs= p; =20 = |-------|          &nbs= p;   

        =20 ////////////////|SIP    = |///////\\\\\\|SIP   =20 = |\\\\\\\\\\\\\\\         &nb= sp;  

       =20 = /            =  =20 ^ |Server/|    =20         |Server/|=20 = ^            = =20 \

      =20 = /            =  =20 ^  |Proxy =20 = |            = =20 |Proxy  | =20 = ^            = =20 = \          

     =20 = /            =  =20 ^      =20 = ||            = ;      =20 ||      =20 = ^            = =20 \

    =20 = /            =  =20 ^       =20 = ||            = ;      =20 ||        ^=20 =             \=

  =20 |---|    |------|   =20 |---------|    ***   =20 |---------|    |------|   =20 |---|

   | E = |----|IPSec=20 |----|  ARSVP  |----*r*----|  ARSVP  |----|IPSec = |----| E=20 |

  =20 |---|    |Device|    |  Proxy  = |    ***    |  Proxy =20 |    |Device|    |---|

    =20        |------|   =20 |    +   =20 |          =20 |    +    |   =20 |------|

           &n= bsp;           =20 | On Path = |           | On=20 Path |

           &n= bsp;           =20 | Entity  = |           |=20 Entity  |

           &n= bsp;           =20 = |---------|          =20 |---------|

 

    =20 <*** PT ***><********************* CT=20 *********************><*** PT ***>

 

           &n= bsp;           &nb= sp;  =20 = <=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3DRSVP=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= >

 

|---|

| E |=20 End system (sender, or receiver, or both)

|---|

 

***

*r*   = Regular RSVP=20 router

***

 

<***> media=20 flow

 

<=3D=3D>  segment of=20 flow path protected by RSVP reservation

 

/=20 \   SIP signaling

 

 ^   =20 Network management interface between Application Level=20 Signaling

     =20 device and IPSec device

 

||    control=20 interface between Application Level Signaling device and ARSVP=20 Proxy

 

PT   =20 Plaintext Network

 

CT   =20 Cyphertext Network

 

------_=_NextPart_001_01C7B2A1.409E29A8-- From tsvwg-bounces@ietf.org Tue Jun 19 15:51:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0jjE-0003JH-HW; Tue, 19 Jun 2007 15:51:04 -0400 Received: from tsvwg by megatron.ietf.org with local (Exim 4.43) id 1I0jiG-0001GL-AY for tsvwg-confirm+ok@megatron.ietf.org; Tue, 19 Jun 2007 15:50:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0jiF-0001Ff-9Q; Tue, 19 Jun 2007 15:50:03 -0400 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0jiE-0006zb-Pm; Tue, 19 Jun 2007 15:50:03 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id ABDAB328F0; Tue, 19 Jun 2007 19:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1I0jiE-0004mL-JP; Tue, 19 Jun 2007 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Tue, 19 Jun 2007 15:50:02 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Cc: tsvwg@ietf.org Subject: [Tsvwg] I-D ACTION:draft-ietf-tsvwg-addip-sctp-22.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tsvwg-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Area Working Group Working Group of the IETF. Title : Stream Control Transmission Protocol (SCTP) Dynamic Address Reconfiguration Author(s) : R. Stewart, et al. Filename : draft-ietf-tsvwg-addip-sctp-22.txt Pages : 41 Date : 2007-6-19 A local host may have multiple points of attachment to the Internet, giving it a degree of fault tolerance from hardware failures. Stream Control Transmission Protocol (SCTP) [I-D.ietf-tsvwg-2960bis] was developed to take full advantage of such a multi-homed host to provide a fast failover and association survivability in the face of such hardware failures. This document describes an extension to SCTP that will allow an SCTP stack to dynamically add an IP Addresses to an SCTP association, dynamically delete an IP addresses from an SCTP association, and to request to set the primary address the peer will use when sending to an endpoint. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-addip-sctp-22.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-tsvwg-addip-sctp-22.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-tsvwg-addip-sctp-22.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-6-19140921.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-tsvwg-addip-sctp-22.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-tsvwg-addip-sctp-22.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-6-19140921.I-D@ietf.org> --OtherAccess-- --NextPart-- From tsvwg-bounces@ietf.org Tue Jun 19 15:51:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0jjx-00058o-3D; Tue, 19 Jun 2007 15:51:49 -0400 Received: from tsvwg by megatron.ietf.org with local (Exim 4.43) id 1I0jjM-0003XU-3t for tsvwg-confirm+ok@megatron.ietf.org; Tue, 19 Jun 2007 15:51:12 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0jjK-0003TT-C8; Tue, 19 Jun 2007 15:51:10 -0400 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I0jjC-0002Os-L4; Tue, 19 Jun 2007 15:51:10 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id F0D2C2ACC0; Tue, 19 Jun 2007 19:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1I0jiE-0004mF-I2; Tue, 19 Jun 2007 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Tue, 19 Jun 2007 15:50:02 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: tsvwg@ietf.org Subject: [Tsvwg] I-D ACTION:draft-ietf-tsvwg-ecn-mpls-01.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tsvwg-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Area Working Group Working Group of the IETF. Title : Explicit Congestion Marking in MPLS Author(s) : B. Davie, et al. Filename : draft-ietf-tsvwg-ecn-mpls-01.txt Pages : 22 Date : 2007-6-19 RFC 3270 defines how to support the Diffserv architecture in MPLS networks, including how to encode Diffserv Code Points (DSCPs) in an MPLS header. DSCPs may be encoded in the EXP field, while other uses of that field are not precluded. RFC3270 makes no statement about how Explicit Congestion Notification (ECN) marking might be encoded in the MPLS header. This draft defines how an operator might define some of the EXP codepoints for explicit congestion notification, without precluding other uses. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-ecn-mpls-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-tsvwg-ecn-mpls-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-tsvwg-ecn-mpls-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-6-19140740.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-tsvwg-ecn-mpls-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-tsvwg-ecn-mpls-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-6-19140740.I-D@ietf.org> --OtherAccess-- --NextPart-- From tsvwg-bounces@ietf.org Wed Jun 20 08:04:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0yvU-0002rO-BU; Wed, 20 Jun 2007 08:04:44 -0400 Received: from tsvwg by megatron.ietf.org with local (Exim 4.43) id 1I0gLC-0003k3-5A for tsvwg-confirm+ok@megatron.ietf.org; Tue, 19 Jun 2007 12:14:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0gLB-0003jv-Rk for tsvwg@ietf.org; Tue, 19 Jun 2007 12:14:01 -0400 Received: from mail5.primus.ca ([216.254.141.172] helo=mail-06.primus.ca) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0gLA-0003H4-Hp for tsvwg@ietf.org; Tue, 19 Jun 2007 12:14:01 -0400 Received: from [24.139.16.154] (helo=[10.0.1.3]) by mail-06.primus.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.63) (envelope-from ) id 1I0gLA-0002xQ-0A for tsvwg@ietf.org; Tue, 19 Jun 2007 12:14:00 -0400 Mime-Version: 1.0 (Apple Message framework v752.2) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: tsvwg@ietf.org From: Philip Matthews Date: Tue, 19 Jun 2007 12:13:57 -0400 X-Mailer: Apple Mail (2.752.2) X-Authenticated: philip_matthews - ([10.0.1.3]) [24.139.16.154] X-Spam-Score: 0.1 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb X-Mailman-Approved-At: Wed, 20 Jun 2007 08:04:43 -0400 Subject: [Tsvwg] Comment on draft-ietf-tsvwg-udp-guidelines-01 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tsvwg-bounces@ietf.org The document draft-ietf-tsvwg-udp-guidelines-01 contains the following text: Applications MAY in addition send periodic keep-alive messages to attempt to refresh middlebox state. Unfortunately, no common timeout has been specified for per-flow UDP state for arbitrary middleboxes. For NATs, [RFC4787] requires a state timeout of 2 minutes or longer, and it is likely that other types of middleboxes use timeouts of similar timescales. Consequently, if applications choose to send periodic keep-alives, they SHOULD NOT send them more frequently than once every two minutes. Three comments: 1) RFC 4787 recommends 2 minutes for NATs, but many NATs today implement shorter timeouts. Hopefully this will change in the future, but I would not recommend that an application designer today assume a 2-minute timeout. 2) Even if all NATs implemented a 2-minute timeout, I think an application should send keep-alives more frequently than every 2 minutes. The rule I have seen in IETF protocols that I am familiar with is to send at 3 times the timeout rate, to account for lost packets. Consider OSPF for example, where the time to declare your neighboring router dead is 45 seconds by default, and keep- alives are sent every 15 seconds by default. 3) The ICE protocol, which has gotten quite a bit of study by NAT experts, is recommending sending keep-alives every 15 seconds. I apologize if this has already been discussed. I searched the archives, but didn't find anything. Also, I am not subscribed to this mailing list, to please reply directly to me if you want me to see your message. - Philip From tsvwg-bounces@ietf.org Thu Jun 21 14:49:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1RiD-0005EC-GK; Thu, 21 Jun 2007 14:48:57 -0400 Received: from tsvwg by megatron.ietf.org with local (Exim 4.43) id 1I1RiB-0005E7-U6 for tsvwg-confirm+ok@megatron.ietf.org; Thu, 21 Jun 2007 14:48:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1RiB-0005Dw-KZ for tsvwg@ietf.org; Thu, 21 Jun 2007 14:48:55 -0400 Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1RiA-0007qy-74 for tsvwg@ietf.org; Thu, 21 Jun 2007 14:48:55 -0400 Received: from [75.215.210.27] (27.sub-75-215-210.myvzw.com [75.215.210.27]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id l5LImZFX002164; Thu, 21 Jun 2007 11:48:36 -0700 (PDT) Message-ID: <467AC802.6030400@isi.edu> Date: Thu, 21 Jun 2007 11:48:34 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: tsvwg IETF list Subject: Re: [Tsvwg] Does anyone have a defence in favour of flow rate fairness? References: <5.2.1.1.2.20070615191706.0405ec80@pop3.jungle.bt.co.uk> In-Reply-To: <5.2.1.1.2.20070615191706.0405ec80@pop3.jungle.bt.co.uk> X-Enigmail-Version: 0.95.1 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig14C023B8ECECC88E5A0C65FF" X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tsvwg-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig14C023B8ECECC88E5A0C65FF Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Bob Briscoe wrote: > TSVWG, >=20 > At the Prague IETF, I asked for the ideas discussed in the I-D below to= > be considered as a WG item (but written more diplomatically than I did)= =2E > "Flow Rate Fairness: Dismantling a Religion" > or via: > =2E.. > From the show of hands in Prague, more than half of a big room had read= > the I-D. Given the I-D provocatively challenges anyone who wants to > continue to use flow rate fairness to either defend it against the > arguments or stop promoting it, I'm assuming that a lack of defence > implies surrender. :) There's a third option not presented that might fit more closely: "TCP's behavior defines a kind of fairness; staying inside the bounds of that fairness is what we currently defend, largely because it's deployed and appears to currently be reasonably sufficient" That does NOT mean we all consider TCP's behavior "flow rate fair", but rather that TCPs sharing a bottleneck will get some proportion of resources and both make progress, and that new CC mechanisms should not upend that 'balance' - whatever it currently is. The next steps proposed below imply that our IETF WG would engage in IRTF-style investigation of what fairness even means. Whether we have consensus on going down that path, I don't agree that the IETF is the place where that work would occur. It seems like IRTF work at best. > More specifically, does the TSVWG want to take on as a WG item the > production of an informational RFC that would give a plan for the > evolution of fairness control from where we are now, to a future where > fairness policy can be controlled and enforced (or not) by more than > just endpoints? > - stating that we have a problem and what the problem is > - stating what a good solution might look like (who/what might take > control etc). > - stating which fairness metrics are valid and which aren't > - stating what implications the approach will have for evolution from > where we are > - etc Joe --------------enig14C023B8ECECC88E5A0C65FF 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 iD8DBQFGesgCE5f5cImnZrsRAiZxAKCNreqtK8hJiEr0gEfP2U1Ou9IDDQCfUV7f B7gjS5tnX/pvjthA+Ak5Vrc= =D4qW -----END PGP SIGNATURE----- --------------enig14C023B8ECECC88E5A0C65FF-- From tsvwg-bounces@ietf.org Thu Jun 21 15:50:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1Sfb-0004Fu-Kb; Thu, 21 Jun 2007 15:50:19 -0400 Received: from tsvwg by megatron.ietf.org with local (Exim 4.43) id 1I1SfL-0003cn-7F for tsvwg-confirm+ok@megatron.ietf.org; Thu, 21 Jun 2007 15:50:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1SfK-0003cP-Pc; Thu, 21 Jun 2007 15:50:02 -0400 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1SfK-0001a5-Eh; Thu, 21 Jun 2007 15:50:02 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id 66F1732925; Thu, 21 Jun 2007 19:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1I1SfK-0000so-8Q; Thu, 21 Jun 2007 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Thu, 21 Jun 2007 15:50:02 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Cc: tsvwg@ietf.org Subject: [Tsvwg] I-D ACTION:draft-ietf-tsvwg-udplite-mib-00.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tsvwg-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Area Working Group Working Group of the IETF. Title : MIB for the UDP-Lite protocol Author(s) : G. Renker, G. Fairhurst Filename : draft-ietf-tsvwg-udplite-mib-00.txt Pages : 32 Date : 2007-6-21 This document specifies a Management Information Base (MIB) for the Lightweight User Datagram Protocol (UDP-Lite, RFC 3828). It defines a set of new MIB entities to characterise the behaviour and performance of transport layer endpoints deploying UDP-Lite. UDP- Lite resembles UDP (RFC 768), but differs from the semantics of UDP by the addition of a single (socket) option. This adds the capability for variable-length data checksum coverage, which can benefit a class of applications that prefer delivery of (partially) corrupted datagram payload data in preference to discarding the datagram. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-udplite-mib-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-tsvwg-udplite-mib-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-tsvwg-udplite-mib-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-6-21115355.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-tsvwg-udplite-mib-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-tsvwg-udplite-mib-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-6-21115355.I-D@ietf.org> --OtherAccess-- --NextPart-- From tsvwg-bounces@ietf.org Thu Jun 21 18:28:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1V8N-0007S2-TK; Thu, 21 Jun 2007 18:28:11 -0400 Received: from tsvwg by megatron.ietf.org with local (Exim 4.43) id 1I1V8M-0007Rw-8b for tsvwg-confirm+ok@megatron.ietf.org; Thu, 21 Jun 2007 18:28:10 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1V8L-0007Ro-UO for tsvwg@ietf.org; Thu, 21 Jun 2007 18:28:09 -0400 Received: from smtpout.mac.com ([17.250.248.175]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I1V87-000737-Gq for tsvwg@ietf.org; Thu, 21 Jun 2007 18:28:09 -0400 Received: from mac.com (smtpin03-en2 [10.13.10.148]) by smtpout.mac.com (Xserve/smtpout05/MantshX 4.0) with ESMTP id l5LMRslA000959; Thu, 21 Jun 2007 15:27:54 -0700 (PDT) Received: from [192.150.186.170] (laptop170.icsi.berkeley.edu [192.150.186.170]) (authenticated bits=0) by mac.com (Xserve/smtpin03/MantshX 4.0) with ESMTP id l5LMRXHE006955; Thu, 21 Jun 2007 15:27:54 -0700 (PDT) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v624) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <27cf6ee8fdad1874be9fe96c034a43d0@mac.com> Content-Transfer-Encoding: 7bit From: Sally Floyd Subject: Re: [Tsvwg] Building the TSVWG agenda for Chicago IETF Date: Thu, 21 Jun 2007 15:27:34 -0700 To: "James M. Polk" X-Mailer: Apple Mail (2.624) X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: tsvwg X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tsvwg-bounces@ietf.org James - I would like to present a new draft (not yet submitted) on "Comments on the Usefulness of Simple Best-Effort Traffic". Presenter's name: Sally Floyd ID filename: draft-floyd-tsvwg-besteffort-00.txt Amount of time: 10 minutes. Intended status of draft: Informational This was written in part in response to draft-briscoe-tsvarea-fair-01.txt, which I think is being presented in tsvwg this time. I would be perfectly happy to present this in tsvwg, in tsvarea, or not to present it all, whichever seems appropriate. - Sally http://www.icir.org/floyd/ From tsvwg-bounces@ietf.org Mon Jun 25 09:14:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2oOM-0006de-Ex; Mon, 25 Jun 2007 09:14:06 -0400 Received: from tsvwg by megatron.ietf.org with local (Exim 4.43) id 1I2oOL-0006dY-EP for tsvwg-confirm+ok@megatron.ietf.org; Mon, 25 Jun 2007 09:14:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2oOL-0006dQ-4q for tsvwg@ietf.org; Mon, 25 Jun 2007 09:14:05 -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 1I2oOJ-0000el-H5 for tsvwg@ietf.org; Mon, 25 Jun 2007 09:14:05 -0400 Received: from [139.133.204.42] (ra-gorry.erg.abdn.ac.uk [139.133.204.42]) (authenticated bits=0) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id l5PDDEra011522 (version=TLSv1/SSLv3 cipher=DES-CBC3-SHA bits=168 verify=NOT); Mon, 25 Jun 2007 14:13:21 +0100 (BST) User-Agent: Microsoft-Entourage/11.3.3.061214 Date: Mon, 25 Jun 2007 14:13:12 +0100 Subject: Re: [Tsvwg] Does anyone have a defence in favour of flow rate fairness? From: Gorry Fairhurst To: tsvwg IETF list Message-ID: Thread-Topic: [Tsvwg] Does anyone have a defence in favour of flow rate fairness? Thread-Index: Ace3KpUF08PzHCMdEdyhdQAKlc/qXg== In-Reply-To: <467AC802.6030400@isi.edu> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" 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: 82c9bddb247d9ba4471160a9a865a5f3 Cc: Gorry Fairhurst X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tsvwg-bounces@ietf.org Bob Briscoe wrote: > TSVWG, > > At the Prague IETF, I asked for the ideas discussed in the I-D below to > be considered as a WG item (but written more diplomatically than I did). > "Flow Rate Fairness: Dismantling a Religion" > or via: > > Gorry Fairhurst voiced concern that the consensus was unlikely to have > shifted so quickly away from TCP fairness for this to be a feasible > WG item. But I'd like to hear someone argue against cost-fairness or > for flow rate fairness (or specifically for TCP-fairness), so we > can actually debate this issue. > > From the show of hands in Prague, more than half of a big room had read > the I-D. True. You have seem to have attention - new ideas are fine. I looking forward to seeing how this develops. > Given the I-D provocatively challenges anyone who wants to > continue to use flow rate fairness to either defend it against the > arguments or stop promoting it, I'm assuming that a lack of defence > implies surrender. :) That is not how I see this. > More specifically, does the TSVWG want to take on as a WG item the > production of an informational RFC that would give a plan for the > evolution of fairness control from where we are now, to a future where > fairness policy can be controlled and enforced (or not) by more than > just endpoints? > - stating that we have a problem and what the problem is > - stating what a good solution might look like (who/what might take > control etc). > - stating which fairness metrics are valid and which aren't > - stating what implications the approach will have for evolution from > where we are > - etc To me, the current revision -01, judges history, and although fine in a research environment, taking this topic as a WG item would need an interpretation that is endorsed by the WG, and relating this to the architecture. There are reasons why the current methods have evolved. I do not share the view this is just "myopia". Are you planning a new revision of the I-D prior to the next meeting? Gorry From tsvwg-bounces@ietf.org Mon Jun 25 13:15:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2s9c-0001VE-Fu; Mon, 25 Jun 2007 13:15:08 -0400 Received: from tsvwg by megatron.ietf.org with local (Exim 4.43) id 1I2s9a-0001V8-O1 for tsvwg-confirm+ok@megatron.ietf.org; Mon, 25 Jun 2007 13:15:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2s9a-0001V0-EM for tsvwg@ietf.org; Mon, 25 Jun 2007 13:15:06 -0400 Received: from smtp.nokia.com ([131.228.20.171] helo=mgw-ext12.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I2s9Z-0000rs-S3 for tsvwg@ietf.org; Mon, 25 Jun 2007 13:15:06 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext12.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l5PHEq8d022427; Mon, 25 Jun 2007 20:15:03 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 25 Jun 2007 20:14:45 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 25 Jun 2007 20:14:44 +0300 Received: from mgw-int01.ntc.nokia.com ([172.21.143.96]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Mon, 25 Jun 2007 20:14:43 +0300 Received: from [172.30.29.36] (essapo-nirac25379.europe.nokia.com [10.162.253.79]) by mgw-int01.ntc.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l5PHEfll029285; Mon, 25 Jun 2007 20:14:42 +0300 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-23-473532665; protocol="application/pkcs7-signature" Message-Id: From: Lars Eggert Subject: Re: [Tsvwg] Comment on draft-ietf-tsvwg-udp-guidelines-01 Date: Mon, 25 Jun 2007 20:14:38 +0300 To: ext Philip Matthews X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 25 Jun 2007 17:14:43.0512 (UTC) FILETIME=[52A26380:01C7B74C] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: b1c41982e167b872076d0018e4e1dc3c Cc: tsvwg@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tsvwg-bounces@ietf.org --Apple-Mail-23-473532665 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Hi, thanks for the feedback! That section is new in -01 and hasn't been discussed by the WG yet. (Similarly, the section on checksums was new in the -00 WG document, and needs some WG review.) On 2007-6-19, at 19:13, ext Philip Matthews wrote: > The document draft-ietf-tsvwg-udp-guidelines-01 contains the > following text: > > Applications MAY in addition send periodic keep-alive messages to > attempt to refresh middlebox state. Unfortunately, no common > timeout > has been specified for per-flow UDP state for arbitrary > middleboxes. > For NATs, [RFC4787] requires a state timeout of 2 minutes or > longer, > and it is likely that other types of middleboxes use timeouts of > similar timescales. Consequently, if applications choose to send > periodic keep-alives, they SHOULD NOT send them more frequently > than > once every two minutes. > > Three comments: > 1) RFC 4787 recommends 2 minutes for NATs, but many NATs today > implement shorter timeouts. > Hopefully this will change in the future, but I would not recommend > that an application designer today > assume a 2-minute timeout. I'm fine with adding a sentence that at the time of writing, NATs deployed in the wild have been known to not follow the IETF recommendation and use shorter timeouts. > 2) Even if all NATs implemented a 2-minute timeout, I think an > application should send keep-alives > more frequently than every 2 minutes. The rule I have seen in IETF > protocols that I am familiar with is to send at 3 times > the timeout rate, to account for lost packets. Consider OSPF for > example, where the time to declare > your neighboring router dead is 45 seconds by default, and keep- > alives are sent every 15 seconds by default. > 3) The ICE protocol, which has gotten quite a bit of study by NAT > experts, is recommending sending > keep-alives every 15 seconds. I understand the desire for short keepalive intervals, but on the other hand, I'm not comfortable recommending that all UDP applications should send 15-second keepalives. That seems awfully short. For ICE, which has arguable focused on supporting media transmission or at least started out that way, loss of NAT state is a bigger issue, because resynchronizing the connection causes interruptions in media delivery. Many other applications, however, can deal fine with the occasional resynchronization handshake, or have bursty communication patterns where keepalives end up eating much more resources (bandwidth but also power - think mobile devices) than the actual application traffic. I'd be interested in hearing suggestions from folks on what we should recommend here! > I apologize if this has already been discussed. I searched the > archives, but didn't find anything. > Also, I am not subscribed to this mailing list, to please reply > directly to me if you want me to see your message. What did you think of the rest of the document, by the way? Thanks, Lars --Apple-Mail-23-473532665 Content-Transfer-Encoding: base64 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGQDCCAvkw ggJioAMCAQICEGtxkLFHQu1g67hlmYfwPuIwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDEwNDE2MTE1NFoXDTA4MDEwNDE2MTE1 NFowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEA26hjntVPZMiwh4d8tyuk9KiucvG92BVUGArk5zO1jhmq7tLFgU1mqcIg VGumfQqjkAzIuh83kxIiqBrB05Wvxp85apwt4sUCvzMe8mQWzZZZYp0rBzwpOj+VC5pxsMRYtYW+ BaTFBEmvFr7D7C7roZUk0lDppS5SZFs4SQbEe9ykB9aeUf1iTiw2+ikyP2+JEYto14WYCoxFWbms FbQ1uaaK+yn1WH2YHhyMfi0IOxuT0jtbsngjHJMpWIqq334zBhj+rPSUug47YBHr41FCDMHbbbjv WbyTyDYneOW3WY8LY8bGWVlAknQGB7lgduShe6e0RI/7SL/VE6X27lM9LwIDAQABozIwMDAgBgNV HREEGTAXgRVsYXJzLmVnZ2VydEBub2tpYS5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUF AAOBgQCx3nxxTg/WowobVTRXBiXUEEZj4LBiunWbuAnR0UbJIgijvq3JbiJvZo2gUGiW9LPaHSBz 4oxT1VR/S/6O0a4e87oV5cOQm6ReB68o9rDfUzxHTwoCfv2wwMwBrXyzQMjyQK4Lt8siV41gmZpm rSXMhjTJdd9uYYNoZKQLq+VM+TCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJ BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgG A1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMg RGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3 DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3 MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9 fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+ uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMB Af8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3 dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgG A1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcP f6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH 2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8x ggMQMIIDDAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAo UHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ a3GQsUdC7WDruGWZh/A+4jAJBgUrDgMCGgUAoIIBbzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw0wNzA2MjUxNzE0MzlaMCMGCSqGSIb3DQEJBDEWBBTHOrNzT6q1EICJ As3zIkDLguXUijCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIwgYcGCyqGSIb3DQEJEAILMXigdjBiMQsw CQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIw DQYJKoZIhvcNAQEBBQAEggEAoJN6Jpei2ZMCjLbsAUbx+BSQuSJ/VxxyOIB5yq0Lwc2WnlNS3MRo QTKijsvTI5Hux8oz9/pgEkZGE8tcUbK/lmf2ZVKxxffOq8uwRu8QARvrkg40ZQmgwy2dsFz8T2oo 3mySySuH0l7Ncv5Vu0LuORD9/b+wNlbyIa//loMRnuMan83c3NAZGiToQ+0ob12tn57dUYrYC4kL T55Df20/MFIfxHrKsovoe1kjC4tWI0NXqp3tx+ezoTYJ2RraSluan8nGC/vW9RwhJAQ1yOUM4+eJ CvXh4ObEiurs5GRMN9UxXhI2r/wyyiuRj6Sa+nlR+1D2SjqcTMnR1/Uk0lhmbgAAAAAAAA== --Apple-Mail-23-473532665-- From tsvwg-bounces@ietf.org Mon Jun 25 13:44:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2sbi-0005F6-RX; Mon, 25 Jun 2007 13:44:10 -0400 Received: from tsvwg by megatron.ietf.org with local (Exim 4.43) id 1I2sbg-00058m-Lr for tsvwg-confirm+ok@megatron.ietf.org; Mon, 25 Jun 2007 13:44:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2sbg-00058e-C7 for tsvwg@ietf.org; Mon, 25 Jun 2007 13:44:08 -0400 Received: from mail5.primus.ca ([216.254.141.172] helo=smtp-04.primus.ca) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I2sbf-0005Id-2Q for tsvwg@ietf.org; Mon, 25 Jun 2007 13:44:08 -0400 Received: from [216.13.42.68] (helo=[10.10.80.124]) by smtp-04.primus.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.50) id 1I2sbn-00032B-DL; Mon, 25 Jun 2007 13:44:15 -0400 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <8BFCD65D-8DA4-4445-B23B-1136E4EFD9BC@magma.ca> Content-Transfer-Encoding: 7bit From: Philip Matthews Subject: Re: [Tsvwg] Comment on draft-ietf-tsvwg-udp-guidelines-01 Date: Mon, 25 Jun 2007 13:44:13 -0400 To: Lars Eggert X-Mailer: Apple Mail (2.752.2) X-Authenticated: philip_matthews - ([10.10.80.124]) [216.13.42.68] X-Spam-Score: 0.1 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Cc: tsvwg@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tsvwg-bounces@ietf.org On 25-Jun-07, at 13:14 , Lars Eggert wrote: > Hi, > > thanks for the feedback! You are welcome. >> Three comments: >> 1) RFC 4787 recommends 2 minutes for NATs, but many NATs today >> implement shorter timeouts. >> Hopefully this will change in the future, but I would not >> recommend that an application designer today >> assume a 2-minute timeout. > > I'm fine with adding a sentence that at the time of writing, NATs > deployed in the wild have been known to not follow the IETF > recommendation and use shorter timeouts. Sounds good to me. > >> 2) Even if all NATs implemented a 2-minute timeout, I think an >> application should send keep-alives >> more frequently than every 2 minutes. The rule I have seen in IETF >> protocols that I am familiar with is to send at 3 times >> the timeout rate, to account for lost packets. Consider OSPF for >> example, where the time to declare >> your neighboring router dead is 45 seconds by default, and keep- >> alives are sent every 15 seconds by default. >> 3) The ICE protocol, which has gotten quite a bit of study by NAT >> experts, is recommending sending >> keep-alives every 15 seconds. > > I understand the desire for short keepalive intervals, but on the > other hand, I'm not comfortable recommending that all UDP > applications should send 15-second keepalives. That seems awfully > short. For ICE, which has arguable focused on supporting media > transmission or at least started out that way, loss of NAT state is > a bigger issue, because resynchronizing the connection causes > interruptions in media delivery. Many other applications, however, > can deal fine with the occasional resynchronization handshake, or > have bursty communication patterns where keepalives end up eating > much more resources (bandwidth but also power - think mobile > devices) than the actual application traffic. > > I'd be interested in hearing suggestions from folks on what we > should recommend here! I see your point, but I don't know what to recommend. I would suggest asking the question on the P2P hackers mailing list, which is popular amongst implementors of P2P systems. http://lists.zooko.com/mailman/listinfo/p2p-hackers I think this may be a case where some research is required before a solid recommendation can be made, and it you want to advance your draft quickly, you might have to leave this as an open question. > >> I apologize if this has already been discussed. I searched the >> archives, but didn't find anything. >> Also, I am not subscribed to this mailing list, to please reply >> directly to me if you want me to see your message. > > What did you think of the rest of the document, by the way? Generally, I think it is a good draft. I think it reminds people of what they need to do. Perhaps you should discuss more WHY people want to use UDP. I suspect that, in many applications, people are inventing their own transport protocol because they need some semantics other than TCP semantics, and then they run it over UDP. Perhaps give a better discussion of when running directly over UDP is appropriate, and when running over DCCP or SCTP (perhaps encapsulated over UDP) is more appropriate. - Philip From tsvwg-bounces@ietf.org Mon Jun 25 14:36:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2tQG-0005JI-VW; Mon, 25 Jun 2007 14:36:24 -0400 Received: from tsvwg by megatron.ietf.org with local (Exim 4.43) id 1I2tQF-0005Aw-2q for tsvwg-confirm+ok@megatron.ietf.org; Mon, 25 Jun 2007 14:36:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2tQE-00059s-OV for tsvwg@ietf.org; Mon, 25 Jun 2007 14:36:22 -0400 Received: from smtp.nokia.com ([131.228.20.173] helo=mgw-ext14.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I2tQD-0007u4-4Z for tsvwg@ietf.org; Mon, 25 Jun 2007 14:36:22 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext14.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l5PIaIp5026348; Mon, 25 Jun 2007 21:36:19 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 25 Jun 2007 21:34:26 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 25 Jun 2007 21:34:26 +0300 Received: from mgw-int02.ntc.nokia.com ([172.21.143.97]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Mon, 25 Jun 2007 21:34:25 +0300 Received: from [172.30.29.126] (essapo-nirac252143.europe.nokia.com [10.162.252.143]) by mgw-int02.ntc.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l5PIYNvZ030018; Mon, 25 Jun 2007 21:34:24 +0300 In-Reply-To: <8BFCD65D-8DA4-4445-B23B-1136E4EFD9BC@magma.ca> References: <8BFCD65D-8DA4-4445-B23B-1136E4EFD9BC@magma.ca> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-27-478314168; protocol="application/pkcs7-signature" Message-Id: <1819A210-241D-4408-86F1-17CEE60914E4@nokia.com> From: Lars Eggert Subject: Re: [Tsvwg] Comment on draft-ietf-tsvwg-udp-guidelines-01 Date: Mon, 25 Jun 2007 21:34:20 +0300 To: ext Philip Matthews X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 25 Jun 2007 18:34:25.0515 (UTC) FILETIME=[74EE23B0:01C7B757] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Cc: tsvwg@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tsvwg-bounces@ietf.org --Apple-Mail-27-478314168 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed On 2007-6-25, at 20:44, ext Philip Matthews wrote: > I see your point, but I don't know what to recommend. > I would suggest asking the question on the P2P hackers mailing > list, which is popular amongst implementors of P2P systems. > http://lists.zooko.com/mailman/listinfo/p2p-hackers > I think this may be a case where some research is required before a > solid recommendation can be made, and it you want to advance your > draft quickly, you might have to leave this as an open question. Doing some background research on this is a good idea - thanks for the pointer to that list! FYI, I see no need to rush this document. I'd much rather get as many people as possible to look at it, esp. from outside the transport area. A BCP on this topic that doesn't have broader consensus it pretty useless. Ideally, we'd come to a rough consensus in the TSV community first, and then advertise it more widely. >>> Generally, I think it is a good draft. I think it reminds people >>> of what they need to do. > > Perhaps you should discuss more WHY people want to use UDP. > I suspect that, in many applications, people are inventing their > own transport protocol because they need some semantics other than > TCP semantics, and then they run it over UDP. Perhaps give a > better discussion of when running directly over UDP is appropriate, > and when running over DCCP or SCTP (perhaps encapsulated over UDP) > is more appropriate. Hm. That's an interesting question, but I wonder if this is the right document for it. In my mind, this document is about "if you use UDP, here's some things to keep in mind." What you describe might be a different document on the topic of "have application, need transport, what do I choose?" Lars --Apple-Mail-27-478314168 Content-Transfer-Encoding: base64 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGQDCCAvkw ggJioAMCAQICEGtxkLFHQu1g67hlmYfwPuIwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDEwNDE2MTE1NFoXDTA4MDEwNDE2MTE1 NFowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEA26hjntVPZMiwh4d8tyuk9KiucvG92BVUGArk5zO1jhmq7tLFgU1mqcIg VGumfQqjkAzIuh83kxIiqBrB05Wvxp85apwt4sUCvzMe8mQWzZZZYp0rBzwpOj+VC5pxsMRYtYW+ BaTFBEmvFr7D7C7roZUk0lDppS5SZFs4SQbEe9ykB9aeUf1iTiw2+ikyP2+JEYto14WYCoxFWbms FbQ1uaaK+yn1WH2YHhyMfi0IOxuT0jtbsngjHJMpWIqq334zBhj+rPSUug47YBHr41FCDMHbbbjv WbyTyDYneOW3WY8LY8bGWVlAknQGB7lgduShe6e0RI/7SL/VE6X27lM9LwIDAQABozIwMDAgBgNV HREEGTAXgRVsYXJzLmVnZ2VydEBub2tpYS5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUF AAOBgQCx3nxxTg/WowobVTRXBiXUEEZj4LBiunWbuAnR0UbJIgijvq3JbiJvZo2gUGiW9LPaHSBz 4oxT1VR/S/6O0a4e87oV5cOQm6ReB68o9rDfUzxHTwoCfv2wwMwBrXyzQMjyQK4Lt8siV41gmZpm rSXMhjTJdd9uYYNoZKQLq+VM+TCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJ BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgG A1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMg RGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3 DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3 MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9 fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+ uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMB Af8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3 dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgG A1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcP f6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH 2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8x ggMQMIIDDAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAo UHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ a3GQsUdC7WDruGWZh/A+4jAJBgUrDgMCGgUAoIIBbzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw0wNzA2MjUxODM0MjFaMCMGCSqGSIb3DQEJBDEWBBQhXqA0Zr7OG0xg GUvolt4zYzRGBjCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIwgYcGCyqGSIb3DQEJEAILMXigdjBiMQsw CQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIw DQYJKoZIhvcNAQEBBQAEggEAeNEofBrno8tHRxDyVIhcYOinBi2i/0PWhYl2/NwLnXke26P4/CbE reVNuBxQ4cAd4ZC66eMcDr3TrjgQErlagniJuU45M0rCwGJu2qVqSEkyRjTMyB0loV553qhVhsSP aGB65163tQejh/Jt/QIhEcv+riDgAiiS1KDa5qoCBhnYkKJtXyveB1yqylkrGrg8jZ1UI6Tb76ZQ 8IouxlG7rGWnGqmTIWxrw6JZ3ntEBmjoYSeW5cQAXpm/iab5yszYLxvAPCtWLFvkiOPnPZ5mctWB YXoBvTeZRz2YrDOmXy3P3me+uPdhWLIX8z3PUOWLLOdAqgUpSXb0JUxuXvsZigAAAAAAAA== --Apple-Mail-27-478314168-- From tsvwg-bounces@ietf.org Mon Jun 25 16:00:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2uj6-0002Pf-1U; Mon, 25 Jun 2007 15:59:56 -0400 Received: from tsvwg by megatron.ietf.org with local (Exim 4.43) id 1I2uj4-0002PQ-IG for tsvwg-confirm+ok@megatron.ietf.org; Mon, 25 Jun 2007 15:59:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2uj3-0002PG-NU for tsvwg@ietf.org; Mon, 25 Jun 2007 15:59:54 -0400 Received: from smtp2.smtp.bt.com ([217.32.164.150]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I2uj2-0008Gb-14 for tsvwg@ietf.org; Mon, 25 Jun 2007 15:59:53 -0400 Received: from i2kc06-ukbr.domain1.systemhost.net ([193.113.197.70]) by smtp2.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 25 Jun 2007 20:59:51 +0100 Received: from cbibipnt05.iuser.iroot.adidom.com ([147.149.196.177]) by i2kc06-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.1830); Mon, 25 Jun 2007 20:59:51 +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 1182801590339; Mon, 25 Jun 2007 20:59:50 +0100 Received: from mut.jungle.bt.co.uk ([10.215.130.87]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id l5PJxgbC020359; Mon, 25 Jun 2007 20:59:47 +0100 Message-Id: <5.2.1.1.2.20070625203745.0498d6c0@pop3.jungle.bt.co.uk> X-Sender: rbriscoe@pop3.jungle.bt.co.uk X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Mon, 25 Jun 2007 20:59:52 +0100 To: Joe Touch From: Bob Briscoe Subject: Re: [Tsvwg] Does anyone have a defence in favour of flow rate fairness? In-Reply-To: <467AC802.6030400@isi.edu> References: <5.2.1.1.2.20070615191706.0405ec80@pop3.jungle.bt.co.uk> <5.2.1.1.2.20070615191706.0405ec80@pop3.jungle.bt.co.uk> Mime-Version: 1.0 Content-Type: text/html; charset="us-ascii" X-Spam-Score: -2.868 () ALL_TRUSTED, AWL, BAYES_00, HTML_10_20, HTML_MESSAGE, MIME_HTML_ONLY X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 X-OriginalArrivalTime: 25 Jun 2007 19:59:51.0549 (UTC) FILETIME=[6448DAD0:01C7B763] X-Spam-Score: 1.5 (+) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Cc: tsvwg IETF list X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tsvwg-bounces@ietf.org Joe,

just returned from a week off...

At 19:48 21/06/2007, Joe Touch wrote:


Bob Briscoe wrote:
> TSVWG,
>
> At the Prague IETF, I asked for the ideas discussed in the I-D below to
> be considered as a WG item (but written more diplomatically than I did).
> "Flow Rate Fairness: Dismantling a Religion"
> <draft-briscoe-tsvarea-fair-01.pdf> or via:
> <http://www.cs.ucl.ac.uk/staff/B.Briscoe/pubs.html#rateFairDis>
...
> From the show of hands in Prague, more than half of a big room had read
> the I-D. Given the I-D provocatively challenges anyone who wants to
> continue to use flow rate fairness to either defend it against the
> arguments or stop promoting it, I'm assuming that a lack of defence
> implies surrender. :)

There's a third option not presented that might fit more closely:

"TCP's behavior defines a kind of fairness; staying inside the bounds of
that fairness is what we currently defend, largely because it's deployed
and appears to currently be reasonably sufficient"

That does NOT mean we all consider TCP's behavior "flow rate fair", but
rather that TCPs sharing a bottleneck will get some proportion of
resources and both make progress, and that new CC mechanisms should not
upend that 'balance' - whatever it currently is.

Hmmm. TCPs each 'make progress' is rather clutching at straws, isn't it?

If "upend" means "disturb", I'm afraid any change to allocations and not upending are incompatible. If a new allocation of a bottleneck resource is chosen in favour of an old one, the balance of the old one will be upended. You can't give to some without taking from others, when you're at the limit.

If "upend" means something more drastic than just disturb, then we have problems, because we need to define some degree of 'reasonable gradualness' for a change from an old regime to a new one. That's not only hard, but it would require some objective goal for what the gradualness is trying to achieve in order to know whether we were achieving it or not.

My proposed solution to this (in draft-briscoe-tsvwg-re-ecn-tcp-03.txt) was to allow operators to gradually tighten the controls they put in if they choose to. Then gradualness becomes their problem, and the 'best' gradualness becomes an outcome of market selection.

The next steps proposed below imply that our IETF WG would engage in
IRTF-style investigation of what fairness even means. Whether we have
consensus on going down that path, I don't agree that the IETF is the
place where that work would occur. It seems like IRTF work at best.

I agree entirely, but I much prefer the IRTF to be doing work that the IETF has bounced to it, rather than work the IETF says it doesn't need when it pops out of the IRTF some years hence. That's why I brought this to the IETF first (we did also have a long discussion about it at the last ICCRG).

I see Sally is planning a draft on this subject too, so we should decide on a venue for this discussion fairly sharpish if it's taking too much TSVWG time from day-to-day protocol business.


Bob

____________________________________________________________________________
Notice: This contribution is the personal view of the author and does not necessarily reflect the technical nor commercial direction of BT plc.
____________________________________________________________________________
Bob Briscoe,                           Networks Research Centre, BT Research
B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK.    +44 1473 645196 From tsvwg-bounces@ietf.org Tue Jun 26 00:59:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3395-0005Hp-BX; Tue, 26 Jun 2007 00:59:19 -0400 Received: from tsvwg by megatron.ietf.org with local (Exim 4.43) id 1I3393-0005Hf-FA for tsvwg-confirm+ok@megatron.ietf.org; Tue, 26 Jun 2007 00:59:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3392-0005HK-OX for tsvwg@ietf.org; Tue, 26 Jun 2007 00:59:16 -0400 Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I338y-0006cw-BQ for tsvwg@ietf.org; Tue, 26 Jun 2007 00:59:16 -0400 Received: from [192.168.1.42] (pool-71-105-86-112.lsanca.dsl-w.verizon.net [71.105.86.112]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id l5Q4x0O5007334; Mon, 25 Jun 2007 21:59:00 -0700 (PDT) Message-ID: <46809D0F.9090009@isi.edu> Date: Mon, 25 Jun 2007 21:58:55 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: Bob Briscoe Subject: Re: [Tsvwg] Does anyone have a defence in favour of flow rate fairness? References: <5.2.1.1.2.20070615191706.0405ec80@pop3.jungle.bt.co.uk> <5.2.1.1.2.20070615191706.0405ec80@pop3.jungle.bt.co.uk> <5.2.1.1.2.20070625203745.0498d6c0@pop3.jungle.bt.co.uk> In-Reply-To: <5.2.1.1.2.20070625203745.0498d6c0@pop3.jungle.bt.co.uk> X-Enigmail-Version: 0.95.1 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigD4A151285D3E0B83ECF01A30" X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Cc: tsvwg IETF list X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tsvwg-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigD4A151285D3E0B83ECF01A30 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Bob Briscoe wrote: > Joe, >=20 > just returned from a week off... =2E.. >> "TCP's behavior defines a kind of fairness; staying inside the bounds = of >> that fairness is what we currently defend, largely because it's deploy= ed >> and appears to currently be reasonably sufficient" >> >> That does NOT mean we all consider TCP's behavior "flow rate fair", bu= t >> rather that TCPs sharing a bottleneck will get some proportion of >> resources and both make progress, and that new CC mechanisms should no= t >> upend that 'balance' - whatever it currently is. >=20 > Hmmm. TCPs each 'make progress' is rather clutching at straws, isn't it= ? It's a straw that is already firmly in our grasp. You're current proposal asks us to take a few things on faith: 1) that information about the remaining path is more important than information about the investment thus far i.e., using "set TTL so it's 16 at the dest" means we know a lot about how many hops are left, but less about how many hops have been made from the origin 2) that information about how resources are used along a path is useful in a multiparty congestion control system vs., e.g., the fact that all component connections react the same way, and that congestion relief occurs more rapidly than congestion exploration 3) that your particular system is a good way to do either of the above Just asserting that "leave it alone" isn't good enough (which would likely have strong support), doesn't mean that this particular proposal is (or is not) a better way forward. Joe --------------enigD4A151285D3E0B83ECF01A30 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 iD8DBQFGgJ0SE5f5cImnZrsRAoAIAJ9Psyh0J7sX19us6qYJal2bBW8UhQCgjhuU eErBB7zH7WVBQUQ/GogsXA0= =8LTI -----END PGP SIGNATURE----- --------------enigD4A151285D3E0B83ECF01A30-- From tsvwg-bounces@ietf.org Tue Jun 26 12:21:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3DnC-00005l-VM; Tue, 26 Jun 2007 12:21:26 -0400 Received: from tsvwg by megatron.ietf.org with local (Exim 4.43) id 1I3DnB-00004u-Bl for tsvwg-confirm+ok@megatron.ietf.org; Tue, 26 Jun 2007 12:21:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3DnB-0008WS-29 for tsvwg@ietf.org; Tue, 26 Jun 2007 12:21:25 -0400 Received: from pork.icsi.berkeley.edu ([192.150.186.19]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I3DmM-0001Z5-KW for tsvwg@ietf.org; Tue, 26 Jun 2007 12:21:25 -0400 Received: from guns.icir.org (adsl-69-222-35-58.dsl.bcvloh.ameritech.net [69.222.35.58]) by pork.ICSI.Berkeley.EDU (8.12.11.20060308/8.12.11) with ESMTP id l5QGKOqZ010524; Tue, 26 Jun 2007 09:20:25 -0700 Received: from lawyers.icir.org (adsl-69-222-35-58.dsl.bcvloh.ameritech.net [69.222.35.58]) by guns.icir.org (Postfix) with ESMTP id 6E052C2A385; Tue, 26 Jun 2007 12:20:19 -0400 (EDT) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 43977244F3E; Tue, 26 Jun 2007 12:19:39 -0400 (EDT) To: Bob Briscoe From: Mark Allman Subject: Re: [Tsvwg] Does anyone have a defence in favour of flow rate fairness? In-Reply-To: <5.2.1.1.2.20070615191706.0405ec80@pop3.jungle.bt.co.uk> Organization: ICSI Center for Internet Research (ICIR) Song-of-the-Day: Touch of Grey MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=_bOundary"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Tue, 26 Jun 2007 12:19:39 -0400 Message-Id: <20070626161939.43977244F3E@lawyers.icir.org> X-Spam-Score: 0.1 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: Gorry Fairhurst , tsvwg IETF list X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: mallman@icir.org List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tsvwg-bounces@ietf.org --=_bOundary Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Bob- I agree with a few others who have chimed in on this thread. What do we need to defend the status quo against? If there was an actual choice here then perhaps one could talk in terms of mounting a defense or agreeing to go some different direction. However, we have what we have. I cannot simply switch to something else if I wanted to. I read this all as you want to (a) get rid of best-effort traffic in favor of a pay-as-you-congest model and (b) you want us to obsolete end-point congestion control as is currently specified by the IETF. I share Gorry's doubt that there is consensus (or even close) on either of these points. I would be perfectly happy to see new techniques to do different sorts of control pursued. I.e., I would be perfectly happy to see a framework developed to do cost-based congestion control. But, that does not mean I think it is useful to---in the absence of this something else---think that we should abandon what is currently working, however imperfectly. Sally and I put together a quick draft. In the intro it says: This document was motivated by [B07], an internet-draft on "Flow Rate Fairness: Dismantling a Religion" that asserts in the abstract that "Comparing flow rates should never again be used for claims of fairness in production networks." This document does not attempt to be a rebuttal to [B07], or to answer any or all of the issues raised in [B07], or to give the "intellectual heritage" for flow-based fairness in philosophy or social science, or to commit the authors of this document to an extended dialogue with the author of [B07]. This document is simply a separate viewpoint on some related topics. The draft is rough and we have not actually submitted it yet, but will before the deadline. It is available from the URLs below and we'd certainly be happy to hear comments on it. http://www.icir.org/floyd/papers/draft-floyd-tsvwg-besteffort-00b.txt http://www.icir.org/floyd/papers/draft-floyd-tsvwg-besteffort-00b.ps allman --=_bOundary Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) iD8DBQFGgTyaWyrrWs4yIs4RApC9AJ907Dr3GqU+5JbMSORsAjfo46kLwQCeMVTM iNiFrc5QLBFVYWRa4ejKRNM= =9cDT -----END PGP SIGNATURE----- --=_bOundary-- From tsvwg-bounces@ietf.org Tue Jun 26 14:02:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3FMd-0007j3-GY; Tue, 26 Jun 2007 14:02:07 -0400 Received: from tsvwg by megatron.ietf.org with local (Exim 4.43) id 1I3FMb-0007iy-RD for tsvwg-confirm+ok@megatron.ietf.org; Tue, 26 Jun 2007 14:02:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3FMb-0007hf-Gg for tsvwg@ietf.org; Tue, 26 Jun 2007 14:02:05 -0400 Received: from smtp3.smtp.bt.com ([217.32.164.138]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I3FM8-0001ed-1E for tsvwg@ietf.org; Tue, 26 Jun 2007 14:02:05 -0400 Received: from i2kc06-ukbr.domain1.systemhost.net ([193.113.197.70]) by smtp3.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 26 Jun 2007 18:19:48 +0100 Received: from cbibipnt05.iuser.iroot.adidom.com ([147.149.196.177]) by i2kc06-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 26 Jun 2007 18:19:19 +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 1182878357765; Tue, 26 Jun 2007 18:19:17 +0100 Received: from mut.jungle.bt.co.uk ([10.215.130.87]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id l5QHJDKI030508; Tue, 26 Jun 2007 18:19:15 +0100 Message-Id: <5.2.1.1.2.20070626085006.0498e188@pop3.jungle.bt.co.uk> X-Sender: rbriscoe@pop3.jungle.bt.co.uk X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Tue, 26 Jun 2007 18:19:24 +0100 To: Gorry Fairhurst From: Bob Briscoe Subject: Re: [Tsvwg] Does anyone have a defence in favour of flow rate fairness? In-Reply-To: References: <467AC802.6030400@isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: -3.757 () ALL_TRUSTED,AWL,BAYES_00 X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 X-OriginalArrivalTime: 26 Jun 2007 17:19:19.0114 (UTC) FILETIME=[2151AAA0:01C7B816] X-Spam-Score: 0.1 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: tsvwg IETF list X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tsvwg-bounces@ietf.org Gorry, At 14:13 25/06/2007, Gorry Fairhurst wrote: >Bob Briscoe wrote: > > TSVWG, > > > Gorry Fairhurst voiced concern that the consensus was unlikely to have > > shifted so quickly away from TCP fairness for this to be a feasible > > WG item. But I'd like to hear someone argue against cost-fairness or > > for flow rate fairness (or specifically for TCP-fairness), so we > > can actually debate this issue. > > > > > Given the I-D provocatively challenges anyone who wants to > > continue to use flow rate fairness to either defend it against the > > arguments or stop promoting it, I'm assuming that a lack of defence > > implies surrender. :) > >That is not how I see this. OK. I only said this because the IETF's hallmark is technical discussion of the issues in order to develop protocols based on technical merit. > > More specifically, does the TSVWG want to take on as a WG item the > > production of an informational RFC that would give a plan for the > > evolution of fairness control from where we are now, to a future where > > fairness policy can be controlled and enforced (or not) by more than > > just endpoints? > > - stating that we have a problem and what the problem is > > - stating what a good solution might look like (who/what might take > > control etc). > > - stating which fairness metrics are valid and which aren't > > - stating what implications the approach will have for evolution from > > where we are > > - etc > >To me, the current revision -01, judges history, I'm v happy to re-work the whole I-D (with co-author(s)) to be more forward looking. >and although fine in a >research environment, taking this topic as a WG item would need an >interpretation that is endorsed by the WG, and relating this to the >architecture. There are reasons why the current methods have evolved. I do >not share the view this is just "myopia". Certainly 20yrs ago TCP congestion ctrl solved a serious and immediate problem and it has served us well since. But the world has changed a lot since then and is now starting to extend its behaviour (ie many more flows, much longer flows) way outside the pragmatic assumptions behind TCP fairness. What was done 20 years ago was good, but the time has come to move on. Sticking with TCP-fairness from now on and into the future would indeed be myopic. >Are you planning a new revision of the I-D prior to the next meeting? Before the Chicago meeting I will simply add clearer answers to a few questions I keep getting. After Chicago, I would like to see a big re-work to make it more forward looking and less damning of the past - perhaps along the lines I suggest above. Louise Burness and Toby Moncaster here at BT are keen to help, but co-author(s) who have worked closely on TCP-fairness over the years would be more useful to add a different perspective. Are there any other volunteers? Bob ____________________________________________________________________________ Notice: This contribution is the personal view of the author and does not necessarily reflect the technical nor commercial direction of BT plc. ____________________________________________________________________________ Bob Briscoe, Networks Research Centre, BT Research B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK. +44 1473 645196 From tsvwg-bounces@ietf.org Tue Jun 26 14:50:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3G7h-00043W-Ko; Tue, 26 Jun 2007 14:50:45 -0400 Received: from tsvwg by megatron.ietf.org with local (Exim 4.43) id 1I3G7g-0003yV-3d for tsvwg-confirm+ok@megatron.ietf.org; Tue, 26 Jun 2007 14:50:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3G7f-0003wR-OR for tsvwg@ietf.org; Tue, 26 Jun 2007 14:50:43 -0400 Received: from smtp5.smtp.bt.com ([217.32.164.139]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I3G75-0001Mj-KN for tsvwg@ietf.org; Tue, 26 Jun 2007 14:50:43 -0400 Received: from i2kc06-ukbr.domain1.systemhost.net ([193.113.197.70]) by smtp5.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 26 Jun 2007 19:50:06 +0100 Received: from cbibipnt05.iuser.iroot.adidom.com ([147.149.196.177]) by i2kc06-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 26 Jun 2007 19:50: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 1182883804556; Tue, 26 Jun 2007 19:50:04 +0100 Received: from mut.jungle.bt.co.uk ([10.215.130.87]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id l5QInwRT000733; Tue, 26 Jun 2007 19:50:01 +0100 Message-Id: <5.2.1.1.2.20070626182056.04bd7c28@pop3.jungle.bt.co.uk> X-Sender: rbriscoe@pop3.jungle.bt.co.uk X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Tue, 26 Jun 2007 19:50:10 +0100 To: Joe Touch From: Bob Briscoe Subject: Re: [Tsvwg] Does anyone have a defence in favour of flow rate fairness? In-Reply-To: <46809D0F.9090009@isi.edu> References: <5.2.1.1.2.20070625203745.0498d6c0@pop3.jungle.bt.co.uk> <5.2.1.1.2.20070615191706.0405ec80@pop3.jungle.bt.co.uk> <5.2.1.1.2.20070615191706.0405ec80@pop3.jungle.bt.co.uk> <5.2.1.1.2.20070625203745.0498d6c0@pop3.jungle.bt.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: -3.759 () ALL_TRUSTED,AWL,BAYES_00 X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 X-OriginalArrivalTime: 26 Jun 2007 18:50:05.0565 (UTC) FILETIME=[CFA822D0:01C7B822] X-Spam-Score: 0.1 (/) X-Scan-Signature: 03169bfe4792634a390035a01a6c6d2f Cc: tsvwg IETF list X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tsvwg-bounces@ietf.org Joe, At 05:58 26/06/2007, Joe Touch wrote: >Bob Briscoe wrote: > > Joe, > > > > just returned from a week off... >... > >> "TCP's behavior defines a kind of fairness; staying inside the bounds of > >> that fairness is what we currently defend, largely because it's deployed > >> and appears to currently be reasonably sufficient" > >> > >> That does NOT mean we all consider TCP's behavior "flow rate fair", but > >> rather that TCPs sharing a bottleneck will get some proportion of > >> resources and both make progress, and that new CC mechanisms should not > >> upend that 'balance' - whatever it currently is. > > > > Hmmm. TCPs each 'make progress' is rather clutching at straws, isn't it? > >It's a straw that is already firmly in our grasp. You're current >proposal asks us to take a few things on faith: > >1) that information about the remaining path is more important than >information about the investment thus far I think there's a confusion here. The re-feedback protocol is designed to reveal (D) downstream and (E) e2e path info to network elements, as well as (U) upstream info already visible. They can then use whichever is appropriate for different purposes... <---------E--------------> <--U--><------D----------> If a network wanted to police each flow's rate response to congestion (which is possible but not necessary), it would use (E) e2e-path congestion If a network wanted to limit the bulk volume of congestion a user was dumping into it, it would use (D) downstream congestion, simply to avoid accounting for congestion that the user was causing in its own network. Neither need to be taken on faith: (E) is what senders use for congestion response today, so the network ingress seeing the same info a fraction of a RTT later allows it to mirror the algo of the sender. (D) is the same as (E) at the ingress to a public internetwork if we assume that congestion of the user's own local network is their concern. (D) allows a flat priced emulation of the congestion pricing that Kelly proved optimises global utility under reasonable assumptions using tried and tested methodology. Others have relaxed the assumptions and found congestion volume is still the useful metric in all cases. Kelly showed that, once sources are accountable for the congestion they cause they will want to prioritise (weight) their individual flows to fit within the overall bulk envelope they choose. So we won't need per-flow policing. (D) also enables inter-domain accountability to propagate recursively, by simple linear additivity. When we are talking about policing at the ingress to an internetwork, the jump from (E) to (D) isn't a leap of faith, it's just saying let's assume the user's machines all sit at her interface with her public provider. She can 'unfairly' share her own resources as much as she wants. From then on the jump from policing single flows to only policing bulk response to congestion is theory, but certainly not faith. And the theory and its assumptions have been extended and checked ad infinitum by other researchers over the past decade without particular cause for concern. And we/others have built prototypes, built simulations etc. Anyway, you also have (E) to police individual flows if you don't believe the theory-based jump to bulk policing. Spoilt for choice. > i.e., using "set TTL so it's 16 at the dest" means > we know a lot about how many hops are left, but less > about how many hops have been made from the origin Re-feedback of TTL is NOT something I would recommend. That's why it's in an appendix of draft-briscoe-tsvwg-re-ecn-tcp-03.txt. The TTL re-feedback idea was only necessary to show we could police the RTT dependence of TCP-fairness (you may have noticed I'm not a great fan of TCP-fairness any more). Policing bulk congestion volume is sufficient to ensure that sources on paths with longer RTTs are more careful to avoid causing congestion that they will not be able to correct for until an RTT later. This ensures there's an incentive for the dynamics to be more cautious for longer RTTs. But flows with different RTTs but the same weight could still eventually converge on the same rate - the longer RTT one would just want to take longer to get there. >2) that information about how resources are used along a path is useful >in a multiparty congestion control system > vs., e.g., the fact that all component connections react > the same way, and that congestion relief occurs more rapidly > than congestion exploration "Info about how resources are used along a path" is exactly what Internet senders use today to do multiparty congestion control. All the proposal adds is making this info visible to the entity (the network) that has the incentive to make sure the endpoints respond appropriately to it. I'm not proposing we change anything about the dynamics of the algorithms (relief/exploration). All that is necessary is to allow different transfers between apps to behave as if they are w flows, where w is a weight that may be <1 or >1. But, more freedom should be possible to allow experimentation (as with the slower dynamics of TFRC). However, if in the long distant future we find that everyone must "react the same way" or more likely with some bound on their dynamics to keep the network stable, ingress networks will have an incentive to enforce that, and the necessary info and the control. So revealing info to the network provides evolutionary pressure towards cost-fairness /and/ away from instability. >3) that your particular system is a good way to do either of the above > >Just asserting that "leave it alone" isn't good enough (which would >likely have strong support), doesn't mean that this particular proposal >is (or is not) a better way forward. I totally agree that I'm saying four things: 1) flow rate fairness is pants (solid argument) 2) cost-fairness is ultility-optimal in theory (solid argument) 3) we have a reasonable implementation for cost fairness that wouldn't require changes to ISP flat pricing (to be worked over by the community) 4) once you have a cost-fairness mechanism, sub-communities can arrange their own different fairness regimes between themselves (arm-wavy but self-evident) If I had just blown apart flow rate fairness, without an alternative I would (rightly) have been given a few cycles of people's attention then ignored. Methinks you do expect too much. Bob ____________________________________________________________________________ Notice: This contribution is the personal view of the author and does not necessarily reflect the technical nor commercial direction of BT plc. ____________________________________________________________________________ Bob Briscoe, Networks Research Centre, BT Research B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK. +44 1473 645196 From tsvwg-bounces@ietf.org Tue Jun 26 22:28:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3NGa-0001TA-Np; Tue, 26 Jun 2007 22:28:24 -0400 Received: from tsvwg by megatron.ietf.org with local (Exim 4.43) id 1I3NGZ-0001T0-M4 for tsvwg-confirm+ok@megatron.ietf.org; Tue, 26 Jun 2007 22:28:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3NGZ-0001Ss-CJ for tsvwg@ietf.org; Tue, 26 Jun 2007 22:28:23 -0400 Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I3NGM-0005Se-78 for tsvwg@ietf.org; Tue, 26 Jun 2007 22:28:23 -0400 Received: from [70.211.42.53] (53.sub-70-211-42.myvzw.com [70.211.42.53]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id l5R2Rvio022753; Tue, 26 Jun 2007 19:27:57 -0700 (PDT) Message-ID: <4681C537.6050101@isi.edu> Date: Tue, 26 Jun 2007 19:02:31 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: Bob Briscoe Subject: Re: [Tsvwg] Does anyone have a defence in favour of flow rate fairness? References: <5.2.1.1.2.20070625203745.0498d6c0@pop3.jungle.bt.co.uk> <5.2.1.1.2.20070615191706.0405ec80@pop3.jungle.bt.co.uk> <5.2.1.1.2.20070615191706.0405ec80@pop3.jungle.bt.co.uk> <5.2.1.1.2.20070625203745.0498d6c0@pop3.jungle.bt.co.uk> <5.2.1.1.2.20070626182056.04bd7c28@pop3.jungle.bt.co.uk> In-Reply-To: <5.2.1.1.2.20070626182056.04bd7c28@pop3.jungle.bt.co.uk> X-Enigmail-Version: 0.95.1 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigA1CF4802D8F8A1BD90553C12" X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: ed68cc91cc637fea89623888898579ba Cc: tsvwg IETF list X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tsvwg-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigA1CF4802D8F8A1BD90553C12 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Bob, These are all good arguments for IRTF study. See below. Bob Briscoe wrote: > Joe, >=20 > At 05:58 26/06/2007, Joe Touch wrote: >=20 >=20 >> Bob Briscoe wrote: >> > Joe, >> > >> > just returned from a week off... >> ... >> >> "TCP's behavior defines a kind of fairness; staying inside the >> bounds of >> >> that fairness is what we currently defend, largely because it's >> deployed >> >> and appears to currently be reasonably sufficient" >> >> >> >> That does NOT mean we all consider TCP's behavior "flow rate fair",= >> but >> >> rather that TCPs sharing a bottleneck will get some proportion of >> >> resources and both make progress, and that new CC mechanisms should= >> not >> >> upend that 'balance' - whatever it currently is. >> > >> > Hmmm. TCPs each 'make progress' is rather clutching at straws, isn't= >> it? >> >> It's a straw that is already firmly in our grasp. You're current >> proposal asks us to take a few things on faith: >> >> 1) that information about the remaining path is more important than >> information about the investment thus far >=20 > I think there's a confusion here. The re-feedback protocol is designed > to reveal (D) downstream and (E) e2e path info to network elements, as > well as (U) upstream info already visible. They can then use whichever > is appropriate for different purposes... How do you reveal all that information in a single existing field? You only get one of upstream or downstream; either you start with a known or you end with a known. You can't have both. >=20 > <---------E--------------> > <--U--><------D----------> >=20 > If a network wanted to police each flow's rate response to congestion > (which is possible but not necessary), it would use (E) e2e-path conges= tion >=20 > If a network wanted to limit the bulk volume of congestion a user was > dumping into it, it would use (D) downstream congestion, simply to avoi= d > accounting for congestion that the user was causing in its own network.= >=20 > Neither need to be taken on faith: > (E) is what senders use for congestion response today, so the network > ingress seeing the same info a fraction of a RTT later allows it to > mirror the algo of the sender. Agreed. > (D) is the same as (E) at the ingress to a public internetwork if we > assume that congestion of the user's own local network is their concern= =2E That would be a specific protocol for the ingress to public internetworks with that assumption. That would be one proposed protocol. > (D) allows a flat priced emulation of the congestion pricing that Kelly= > proved optimises global utility under reasonable assumptions using trie= d > and tested methodology. Others have relaxed the assumptions and found > congestion volume is still the useful metric in all cases. That would be a case to be made to the IETF as a whole, to get everyone on board with your assumption of a goal for this work. I don't think it can be assumed, regardless of what has been studied to date. > Kelly showed that, once sources are accountable for the congestion they= > cause they will want to prioritise (weight) their individual flows to > fit within the overall bulk envelope they choose. So we won't need > per-flow policing. The above statement appears to assume that per-source policing is in effect - i.e., that sources are accountable. That's still fairly fine-grained, isn't it? > (D) also enables inter-domain accountability to propagate recursively, > by simple linear additivity. >=20 > When we are talking about policing at the ingress to an internetwork, > the jump from (E) to (D) isn't a leap of faith, it's just saying let's > assume the user's machines all sit at her interface with her public > provider. She can 'unfairly' share her own resources as much as she wan= ts. Right, but under current nets she can basically emulate as many "she"s as she wants; that's how we get HTTP opening multiple connections. Won't this just encourage multiple IP addresses to get around per-source polici= ng? > From then on the jump from policing single flows to only policing bulk > response to congestion is theory, but certainly not faith. And the > theory and its assumptions have been extended and checked ad infinitum > by other researchers over the past decade without particular cause for > concern. And we/others have built prototypes, built simulations etc. >=20 > Anyway, you also have (E) to police individual flows if you don't > believe the theory-based jump to bulk policing. Spoilt for choice. (agreed that RTT is a red herring) =2E.. >> 2) that information about how resources are used along a path is usefu= l >> in a multiparty congestion control system >> vs., e.g., the fact that all component connections react >> the same way, and that congestion relief occurs more rapidly >> than congestion exploration >=20 > "Info about how resources are used along a path" is exactly what > Internet senders use today to do multiparty congestion control Endpoints know what resources are available between those endpoints; that could include multipath. Nothing about today's (ubiquitous) congestion control is dependent on a particular path per se. The exception would be RSVP and/or XCP which touch routers on a path, but they're not exactly widespread (and that's part of the problem we're grappling with). > All the > proposal adds is making this info visible to the entity (the network) > that has the incentive to make sure the endpoints respond appropriately= > to it. Why is it you think that endpoints aren't already responding appropriately to the information they get? How will this new system handle virtual paths and multipath? > I'm not proposing we change anything about the dynamics of the > algorithms (relief/exploration). All that is necessary is to allow > different transfers between apps to behave as if they are w flows, wher= e > w is a weight that may be <1 or >1. That seems nice in principle, but in practice what's to stop an app from faking being multiple apps to get more capacity? or multiple endpoints? Basically, what's to stop more 'gaming the system'? I agree that the current system can be gamed - we don't really have per-connection (it's more like per-connection with RTT weighting, but not exactly), and we can open multiple connections to game it. However, replacing one game-able system with another doesn't solve that problem. > But, more freedom should be possible to allow experimentation (as with > the slower dynamics of TFRC). That is a ringing endorsement for an IRTF effort. > However, if in the long distant future we find that everyone must "reac= t > the same way" or more likely with some bound on their dynamics to keep > the network stable, ingress networks will have an incentive to enforce > that, and the necessary info and the control. >=20 > So revealing info to the network provides evolutionary pressure towards= > cost-fairness /and/ away from instability. That, IMO, would be a conclusion from an experiment we have not yet conducted. I'd like to see the result before coming to that conclusion. >> 3) that your particular system is a good way to do either of the above= >> >> Just asserting that "leave it alone" isn't good enough (which would >> likely have strong support), doesn't mean that this particular proposa= l >> is (or is not) a better way forward. >=20 > I totally agree that I'm saying four things: > 1) flow rate fairness is pants (solid argument) > 2) cost-fairness is ultility-optimal in theory (solid argument) > 3) we have a reasonable implementation for cost fairness that wouldn't > require changes to ISP flat pricing (to be worked over by the community= ) > 4) once you have a cost-fairness mechanism, sub-communities can arrange= > their own different fairness regimes between themselves (arm-wavy but > self-evident) >=20 > If I had just blown apart flow rate fairness, without an alternative I > would (rightly) have been given a few cycles of people's attention then= > ignored. >=20 > Methinks you do expect too much. For the IETF, no. For the IRTF, yes. ;-) Joe --------------enigA1CF4802D8F8A1BD90553C12 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 iD8DBQFGgcU3E5f5cImnZrsRAnTCAKC2JIPcCI+f0z4Cbi6x5XoQ7XMaVwCeOegn MlCZeg+qCK4DUxxTINzjrj8= =icvB -----END PGP SIGNATURE----- --------------enigA1CF4802D8F8A1BD90553C12-- From tsvwg-bounces@ietf.org Wed Jun 27 06:21:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3UeP-0003Zg-Jb; Wed, 27 Jun 2007 06:21:29 -0400 Received: from tsvwg by megatron.ietf.org with local (Exim 4.43) id 1I3UeN-0003Yk-Ol for tsvwg-confirm+ok@megatron.ietf.org; Wed, 27 Jun 2007 06:21:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3Uck-0002qg-85 for tsvwg@ietf.org; Wed, 27 Jun 2007 06:19:46 -0400 Received: from wa-out-1112.google.com ([209.85.146.183]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I3UbU-0008Qj-Iq for tsvwg@ietf.org; Wed, 27 Jun 2007 06:18:42 -0400 Received: by wa-out-1112.google.com with SMTP id k17so185111waf for ; Wed, 27 Jun 2007 03:18:26 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=JXC1NlKl7fTtIMHv0vRd3i9n8BJD0E/JVUBvmgsbS22yCowxxPDMu9ROLzGVkKtbisGxMg89NLWg+SaMcy/ww+RpQO5RonyM94Pmu8OYYoUcCgIU7/IXO2i7ZwgZyINYHQdUtNNsl7Adty5U8cU91lVIPhlHHrOdk3H2Ew6nxjE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=H+a+hyOU3QgqrGPdm9xX8nkyeRRFL8/M2D0PtVMXURUUujeYBOw6eotHcv1WwR31PoC7971eiEMIqTj4F5OnnwPNsok6qPF9hwLbRTLcFiiE4P2h4bMJP3DimN+eI8f1w/DiSVq3PfWGDgmFaAGvBefULYJOSG9lHBbgVNCHzyo= Received: by 10.114.193.1 with SMTP id q1mr344239waf.1182939505949; Wed, 27 Jun 2007 03:18:25 -0700 (PDT) Received: by 10.115.60.15 with HTTP; Wed, 27 Jun 2007 03:18:25 -0700 (PDT) Message-ID: <84a612dd0706270318m2cf551a3m377648deb04073e9@mail.gmail.com> Date: Wed, 27 Jun 2007 11:18:25 +0100 From: "Mark Handley" To: "Joe Touch" Subject: Re: [Tsvwg] Does anyone have a defence in favour of flow rate fairness? In-Reply-To: <4681C537.6050101@isi.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <5.2.1.1.2.20070615191706.0405ec80@pop3.jungle.bt.co.uk> <5.2.1.1.2.20070625203745.0498d6c0@pop3.jungle.bt.co.uk> <5.2.1.1.2.20070626182056.04bd7c28@pop3.jungle.bt.co.uk> <4681C537.6050101@isi.edu> X-Google-Sender-Auth: e6adec2b709862f6 X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Cc: tsvwg IETF list X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tsvwg-bounces@ietf.org On 6/27/07, Joe Touch wrote: > > I totally agree that I'm saying four things: > > 1) flow rate fairness is pants (solid argument) > > 2) cost-fairness is ultility-optimal in theory (solid argument) > > 3) we have a reasonable implementation for cost fairness that wouldn't > > require changes to ISP flat pricing (to be worked over by the community) > > 4) once you have a cost-fairness mechanism, sub-communities can arrange > > their own different fairness regimes between themselves (arm-wavy but > > self-evident) > > > > If I had just blown apart flow rate fairness, without an alternative I > > would (rightly) have been given a few cycles of people's attention then > > ignored. > > > > Methinks you do expect too much. > > For the IETF, no. For the IRTF, yes. ;-) I don't quite share Bob's zeal on this precise issue, but I do think we need to have a proper debate on these issues in the IETF at this point, not the IRTF. - The basic theory here is something like ten years old now, and still looks good. - The basic re-feedback idea is simple and effective and has been through a ton of debate in the appropriate research venues including the IRTF. It has matured. - The incarnation of re-feedback in Re-ECN is (in my opinion) well thought through, and probably deployable. Even if it were used in ways Bob hasn't foreseen, it could form a very useful building block for all sorts of congestion monitoring/enforcement mechanisms that are hard to do today. What remains here is mostly engineering. - The real remaining question seems to be about the interaction between protocols and economics. This is the question Bob has rather unsubtly posed. So, it seems to me that bouncing something like Re-ECN to the IRTF would serve no useful purpose. The question is _not_ "would it work?" (in a mechanistic sense). I'm pretty confident it would work if it were widely deployed - at least confident enough for the IETF to take it on and beat it up with the club of reality. The question is _not_ would it work (in an ecomonic sense) - there's no way for the IRTF to test the theoretic basis. The real question is "do we want it?". This is a question that the IRTF _cannot_ answer. This _might_ be a question that the IETF can answer. I don't honestly know if the IETF can answer this question - certainly the IETF is very very poor at answering architectural and economic questions, and this is both. It really ought to be the job of the IAB to figure out how to answer such questions. If what people are saying is that the IETF cannot or should not answer this question, then please say so. If that is the case, then I suggest that Bob should publish his documents as Experimental, and take the debate to the people who need to implement them (router vendors, OS vendors, and the ISPs). However, many of these people are present at the IETF, and we also have a fair number of experienced people with good perspective on the issues. So it seems to me that the IETF should not punt on these questions, but should debate them properly. They are after all fundamentally very important questions. - Mark From tsvwg-bounces@ietf.org Wed Jun 27 09:37:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3XiQ-00024m-QZ; Wed, 27 Jun 2007 09:37:50 -0400 Received: from tsvwg by megatron.ietf.org with local (Exim 4.43) id 1I3XiP-00024b-F5 for tsvwg-confirm+ok@megatron.ietf.org; Wed, 27 Jun 2007 09:37:49 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3XiP-00024R-3Y for tsvwg@ietf.org; Wed, 27 Jun 2007 09:37:49 -0400 Received: from smtp5.smtp.bt.com ([217.32.164.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I3XiO-0008K6-Ih for tsvwg@ietf.org; Wed, 27 Jun 2007 09:37:49 -0400 Received: from i2kc08-ukbr.domain1.systemhost.net ([193.113.197.71]) by smtp5.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 27 Jun 2007 14:36:46 +0100 Received: from cbibipnt08.iuser.iroot.adidom.com ([147.149.100.81]) by i2kc08-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.1830); Wed, 27 Jun 2007 14:36:46 +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 1182951405367; Wed, 27 Jun 2007 14:36:45 +0100 Received: from mut.jungle.bt.co.uk ([10.215.130.87]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id l5RDaQZx011232; Wed, 27 Jun 2007 14:36:41 +0100 Message-Id: <5.2.1.1.2.20070626212717.04bede70@pop3.jungle.bt.co.uk> X-Sender: rbriscoe@pop3.jungle.bt.co.uk X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Wed, 27 Jun 2007 14:36:38 +0100 To: mallman@icir.org From: Bob Briscoe Subject: Re: [Tsvwg] Does anyone have a defence in favour of flow rate fairness? In-Reply-To: <20070626161939.43977244F3E@lawyers.icir.org> References: <5.2.1.1.2.20070615191706.0405ec80@pop3.jungle.bt.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: -3.761 () ALL_TRUSTED,AWL,BAYES_00 X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 X-OriginalArrivalTime: 27 Jun 2007 13:36:46.0291 (UTC) FILETIME=[34D45230:01C7B8C0] X-Spam-Score: 0.0 (/) X-Scan-Signature: 2e8fc473f5174be667965460bd5288ba Cc: Gorry Fairhurst , tsvwg IETF list X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tsvwg-bounces@ietf.org Mark, [I thought I sent this last night, but apparently not...] At 17:19 26/06/2007, Mark Allman wrote: >Bob- > >I agree with a few others who have chimed in on this thread. What do we >need to defend the status quo against? All currently standardised IETF congestion control protocols aim to equalise per-flow rates through a bottleneck. For future protocol work, this goal should be recognised as misguided as it is likely to lead to extreme unfairness in economic terms. >If there was an actual choice >here then perhaps one could talk in terms of mounting a defense or >agreeing to go some different direction. However, we have what we have. >I cannot simply switch to something else if I wanted to. I'm offering a choice at both the conceptual level (cost-fairness vs flow rate fairness) and at the protocol mechanism level (re-ECN which reveals path congestion info to network nodes so they can police either form of fairness and others). But in this thread, let's keep it to the choice between fairness goals. Once we have consensus on the goal, we can start discussing appropriate mechanism. >I read this all as you want to ... Both the intentions a) & b) below ascribed to me are the exact opposite of the stated intentions in the drafts. The issues are serious, so below I've tried to make it clear what we're not saying. >(a) you want to get rid of best-effort traffic in >favor of a pay-as-you-congest model and Most emphatically no, on both counts. a1) Best effort would stay as it is, except it should give operators reason to deploy ECN much more widely so we should see much less drop. [Also, BTW, re-ECN is applicable to all Diffserv PHBs, not just BE.] a2) The reason we brought this to the IETF was we had worked out a way for operators to ensure users behave fairly within typical flat rate ISP contracts WITHOUT pay-as-you-congest. Quoting S.5.2: " Note that we use the phrase "you get what you pay for" not just "you pay for what you get". In Kelly's original formulation, users had to pay for the congestion they caused, which was unlikely to be taken up commercially. But the reason we are revitalising Kelly's work is that recent advances (Section 5.3.2) should allow ISPs to keep their popular flat fee pricing packages by aiming to ensure that users cannot cause more congestion costs than their flat fee pays for. " a3) In the intro to draft-briscoe-tsvwg-re-ecn-tcp-0* and every time I have presented re-ECN and cost-fairness in tsvwg, I have started by explaining that the idea is to introduce a protocol field in IP. Full stop. All the rest is up to operators and app/OS developers to build policy controls around this field if they choose, but the incentives are there to make all this happen: - Enable network B to penalise network A for the congestion A's users cause in B and beyond. The IETF would only provide the field in IP to enable this. - It's up to each network pair whether they would choose this contractual model. - And it's up to network A whether it limits congestion from its users. The IETF would provide the field in IP to enable A to do this if it wanted. - Net A has the incentive to limit congestion from its users because, if it doesn't, it could find it pays net B more in penalties than it gets in flat fees from all its users. a4) You can't set BE against pay-as-you-congest anyway - they are in different sets: - Best effort is a service model. - Pay-as-you-congest is a payment model. >(b) you want us to obsolete >end-point congestion control as is currently specified by the IETF. b) Most emphatically no again. I do want to enable evolution of many new forms of endpoint congestion control within an overall envelope policed by networks - to ensure more responsible sharing of resources on short and long timescales. I do want to enable evolution of currently specified end-point controls so that they can be weighted under policy control. But those that don't evolve will still work just fine - they will just either eat up more congestion allowance (or less) than the user might have wished. They won't be obsolete, just unloved. >I >share Gorry's doubt that there is consensus (or even close) on either of >these points. If I had made these points, I agree consensus would be unlikely. But happily my motivations are the exact opposite in all cases. >I would be perfectly happy to see new techniques to do different sorts >of control pursued. I.e., I would be perfectly happy to see a framework >developed to do cost-based congestion control. Cool >But, that does not mean >I think it is useful to---in the absence of this something else---think >that we should abandon what is currently working, however imperfectly. Totally agree. You may want to take a look at the end of section 9 of the -01 rev of the fairness religion draft , which says what is likley to happen to currently spec'd congestion controls if cost-fairness were to become the norm. >Sally and I put together a quick draft. In the intro it says: > > This document was motivated by [B07], an internet-draft on "Flow > Rate Fairness: Dismantling a Religion" that asserts in the abstract > that "Comparing flow rates should never again be used for claims of > fairness in production networks." This document does not attempt to > be a rebuttal to [B07], or to answer any or all of the issues raised > in [B07], or to give the "intellectual heritage" for flow-based > fairness in philosophy or social science, or to commit the authors > of this document to an extended dialogue with the author of [B07]. > This document is simply a separate viewpoint on some related topics. Sounds like useful stuff. >The draft is rough and we have not actually submitted it yet, but will >before the deadline. It is available from the URLs below and we'd >certainly be happy to hear comments on it. > > http://www.icir.org/floyd/papers/draft-floyd-tsvwg-besteffort-00b.txt > http://www.icir.org/floyd/papers/draft-floyd-tsvwg-besteffort-00b.ps I'm trying to meet the initial draft deadline myself for a couple of drafts (fitting in 2-day car journeys to my son's graduation as well), so I may have to defer reading. But if I get a chance before the deadline, I will send comments. It's possible the clarifications in this email may have allayed some concerns. BTW, I assume the .ps is redundant? Cheers Bob ____________________________________________________________________________ Bob Briscoe, Networks Research Centre, BT Research B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK. +44 1473 645196 From tsvwg-bounces@ietf.org Wed Jun 27 10:38:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3Yet-00019l-Fc; Wed, 27 Jun 2007 10:38:15 -0400 Received: from tsvwg by megatron.ietf.org with local (Exim 4.43) id 1I3Yes-00019f-Mz for tsvwg-confirm+ok@megatron.ietf.org; Wed, 27 Jun 2007 10:38:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3Yes-00019W-DK for tsvwg@ietf.org; Wed, 27 Jun 2007 10:38:14 -0400 Received: from smtp1.smtp.bt.com ([217.32.164.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I3Yds-0004nT-J0 for tsvwg@ietf.org; Wed, 27 Jun 2007 10:38:14 -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, 27 Jun 2007 15:37:11 +0100 Received: from cbibipnt08.iuser.iroot.adidom.com ([147.149.100.81]) by i2kc08-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.1830); Wed, 27 Jun 2007 15:37:09 +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 1182955028134; Wed, 27 Jun 2007 15:37:08 +0100 Received: from mut.jungle.bt.co.uk ([10.215.130.87]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id l5REb161013686; Wed, 27 Jun 2007 15:37:04 +0100 Message-Id: <5.2.1.1.2.20070627103723.04c38d90@pop3.jungle.bt.co.uk> X-Sender: rbriscoe@pop3.jungle.bt.co.uk X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Wed, 27 Jun 2007 15:37:13 +0100 To: mallman@icir.org, "FLOYD, Sally" From: Bob Briscoe Subject: Re: [Tsvwg] Does anyone have a defence in favour of flow rate fairness? In-Reply-To: <20070626161939.43977244F3E@lawyers.icir.org> References: <5.2.1.1.2.20070615191706.0405ec80@pop3.jungle.bt.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: -3.758 () ALL_TRUSTED,AWL,BAYES_00 X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 X-OriginalArrivalTime: 27 Jun 2007 14:37:09.0329 (UTC) FILETIME=[A4540C10:01C7B8C8] X-Spam-Score: 0.1 (/) X-Scan-Signature: ff03b0075c3fc728d7d60a15b4ee1ad2 Cc: tsvwg IETF list X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tsvwg-bounces@ietf.org Mark, Sally, I haven't done more than scanned your useful doc, but just wanted to say you're pushing at an open door. I want to ensure that what you call 'simple BE traffic' can co-exist in a principled way on an internetwork with what one might call 'accountable BE traffic'. In such a way that the balance between the two is determined by natural selection. As I've outlined in every talk I've given on re-ECN at the IETF, I expect there to be networks that will NOT deploy any enforcement of fairness. Re-ECN was designed for permanent partial deployment (only some hosts and only some networks). But at inter-domain borders, those liberal networks that don't limit their users in any way would still be accountable for the congestion their users cause in other networks that do care. That needn't kill such liberal networks, which I expect will always exist. They will simply spread the cost of their excessive users over all their users - as they have to do today. But we might still find that liberal networks draw a line somewhere. E.g. a liberal network might still block sources of excessive congestion (e.g. DDoS) which would otherwise cause a liberal network to have to pay other networks excessive penalties (assuming the border contracts I predict come about). --- Perhaps you wrongly picked up on my phrase "Comparing flow rates should never again be used for claims of fairness in production networks.". This was carefully worded to mean only what it says: No-one should /claim/ this traffic is fair. It most emphatically does NOT mean I don't want this sort of traffic on the Internet. My personal preference is for simple, but I'm not setting myself up to judge what is good for the Internet or not, I'm offering a natural selection mechanism to decide between the two. --- I do slightly resent the general implication that what I'm proposing will make the Internet more complicated. My main motivation isn't optimality. It's simplicity. But not just to meet your goal of "One part of the Internet should remain simple". Rather, my goal is "What's the simplest way for all the different cultures and parts of the internetwork (traditional public ISP, cellular network, ad hoc wifi, NGN, corporate intranet, campus etc) to all interconnect but all keep their own resource control cultures along a spectrum from laissez faire to anally retentive". I said optimality isn't my goal. The odd 10% sub-optimality is fine, but straying too far from it causes pathological knock-on effects that lead to excess complexity, as I shall now explain. Flow rate fairness gives a user who has been running n flows for 24 hours, n times more bandwidth than another flow running for a few seconds. This has led to an Internet that is extremely non-optimal. Operators then have an incentive to intervene (e.g. throttling p2p filesharing), because it greatly improves their competitive position. They satisfy many more customers for the same cost. Effectively, a major cause of the rise of the middlebox has been the broken flow rate fairness goal. In the face of all the conflicting demands on the Internet, complex boxes are being deployed at borders and at user access interfaces to try to 'manage' selfish or malicious traffic. It's blocking evolution of new apps and increasingly causing bizarre feature interactions, with apps silently not working intermittently. That motivated me to propose truly simple mechanisms that manage the thing that most of these middleboxes are trying to deal with: control over sharing network resources. Hence my slight resentment at implications that I'm against the simple Internet. Bob At 17:19 26/06/2007, Mark Allman wrote: >Bob- > >I agree with a few others who have chimed in on this thread. What do we >need to defend the status quo against? If there was an actual choice >here then perhaps one could talk in terms of mounting a defense or >agreeing to go some different direction. However, we have what we have. >I cannot simply switch to something else if I wanted to. > >I read this all as you want to (a) get rid of best-effort traffic in >favor of a pay-as-you-congest model and (b) you want us to obsolete >end-point congestion control as is currently specified by the IETF. I >share Gorry's doubt that there is consensus (or even close) on either of >these points. > >I would be perfectly happy to see new techniques to do different sorts >of control pursued. I.e., I would be perfectly happy to see a framework >developed to do cost-based congestion control. But, that does not mean >I think it is useful to---in the absence of this something else---think >that we should abandon what is currently working, however imperfectly. > >Sally and I put together a quick draft. In the intro it says: > > This document was motivated by [B07], an internet-draft on "Flow > Rate Fairness: Dismantling a Religion" that asserts in the abstract > that "Comparing flow rates should never again be used for claims of > fairness in production networks." This document does not attempt to > be a rebuttal to [B07], or to answer any or all of the issues raised > in [B07], or to give the "intellectual heritage" for flow-based > fairness in philosophy or social science, or to commit the authors > of this document to an extended dialogue with the author of [B07]. > This document is simply a separate viewpoint on some related topics. > >The draft is rough and we have not actually submitted it yet, but will >before the deadline. It is available from the URLs below and we'd >certainly be happy to hear comments on it. > > http://www.icir.org/floyd/papers/draft-floyd-tsvwg-besteffort-00b.txt > http://www.icir.org/floyd/papers/draft-floyd-tsvwg-besteffort-00b.ps > >allman > > > ____________________________________________________________________________ Bob Briscoe, Networks Research Centre, BT Research B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK. +44 1473 645196 From tsvwg-bounces@ietf.org Wed Jun 27 12:28:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3aNS-0004xx-Jh; Wed, 27 Jun 2007 12:28:22 -0400 Received: from tsvwg by megatron.ietf.org with local (Exim 4.43) id 1I3aNR-0004xs-G0 for tsvwg-confirm+ok@megatron.ietf.org; Wed, 27 Jun 2007 12:28:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3aNR-0004xk-6X for tsvwg@ietf.org; Wed, 27 Jun 2007 12:28:21 -0400 Received: from pork.icsi.berkeley.edu ([192.150.186.19]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I3aMr-00044Y-9o for tsvwg@ietf.org; Wed, 27 Jun 2007 12:28:21 -0400 Received: from guns.icir.org (adsl-69-222-35-58.dsl.bcvloh.ameritech.net [69.222.35.58]) by pork.ICSI.Berkeley.EDU (8.12.11.20060308/8.12.11) with ESMTP id l5RGRZC5017407; Wed, 27 Jun 2007 09:27:36 -0700 Received: from lawyers.icir.org (adsl-69-222-35-58.dsl.bcvloh.ameritech.net [69.222.35.58]) by guns.icir.org (Postfix) with ESMTP id 8F09BC361B8; Wed, 27 Jun 2007 12:27:30 -0400 (EDT) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 7EF1B2472C7; Wed, 27 Jun 2007 12:26:47 -0400 (EDT) To: Bob Briscoe From: Mark Allman Subject: Re: [Tsvwg] Does anyone have a defence in favour of flow rate fairness? In-Reply-To: <5.2.1.1.2.20070626212717.04bede70@pop3.jungle.bt.co.uk> Organization: ICSI Center for Internet Research (ICIR) Song-of-the-Day: Lonesome Day MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=_bOundary"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Wed, 27 Jun 2007 12:26:47 -0400 Message-Id: <20070627162647.7EF1B2472C7@lawyers.icir.org> X-Spam-Score: 0.1 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Cc: Gorry Fairhurst , tsvwg IETF list X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: mallman@icir.org List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tsvwg-bounces@ietf.org --=_bOundary Content-Type: text/plain; charset=us-ascii Content-Disposition: inline > >If there was an actual choice here then perhaps one could talk in > >terms of mounting a defense or agreeing to go some different > >direction. However, we have what we have. I cannot simply switch to > >something else if I wanted to. > > I'm offering a choice at both the conceptual level (cost-fairness vs > flow rate fairness) and at the protocol mechanism level (re-ECN which > reveals path congestion info to network nodes so they can police > either form of fairness and others). My point is that conceptual mechanisms and schemes from research papers are great but they are not real choices. I can't twiddle the "something else" knob here and get something different on this machine than (roughly) IETF-standardized congestion control. So, I don't understand why someone needs to defend the status quo against a concept. (That does not mean we can't judge this new concept to be worthy of design/development/further exploration. See below.) > >(a) you want to get rid of best-effort traffic in > >favor of a pay-as-you-congest model and > > Most emphatically no, on both counts. I think we have a difference in terminology when we say "best effort" (this is actually why in our draft draft we define "simple best effort traffic" to avoid such terminology issues). That said, I read your note as essentially saying best effort is the same as it is today, except different. I.e., it seems that the end game is that there is no place for simple best effort traffic. > >(b) you want us to obsolete > >end-point congestion control as is currently specified by the IETF. > > b) Most emphatically no again. And, then later you note that "They won't be obsolete, just unloved." Obsolete / unloved / whatever. I understand you don't want to necessarily say "thou shell not use RFC 2581-style CC", but you're designing a world where that seems to be the intent. It seems to me that this is all backwards. I am perfectly happy to support IETF work on designing mechanisms to support cost-based congestion control. That seems fine to me. That does not mean that I have to agree that we should get rid of all simple best-effort traffic. That does not mean I have to sign on to a particular fairness criteria. It seems to me that this question need not gate work on cost-based schemes. IMHO. allman --=_bOundary Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) iD8DBQFGgo/HWyrrWs4yIs4RAg6kAJ92MfD1t2/C04u0+5I1F4u+jBduDACfcXzG 1U6GanBP9bOsRp3nnUvzHPU= =E/L1 -----END PGP SIGNATURE----- --=_bOundary-- From tsvwg-bounces@ietf.org Wed Jun 27 13:48:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3bci-000589-TC; Wed, 27 Jun 2007 13:48:12 -0400 Received: from tsvwg by megatron.ietf.org with local (Exim 4.43) id 1I3bch-00057q-MS for tsvwg-confirm+ok@megatron.ietf.org; Wed, 27 Jun 2007 13:48:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3bch-00057i-Cd for tsvwg@ietf.org; Wed, 27 Jun 2007 13:48:11 -0400 Received: from smtp5.smtp.bt.com ([217.32.164.139]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I3bc9-0006MQ-3Y for tsvwg@ietf.org; Wed, 27 Jun 2007 13:48:10 -0400 Received: from i2kc06-ukbr.domain1.systemhost.net ([193.113.197.70]) by smtp5.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 27 Jun 2007 18:47:35 +0100 Received: from cbibipnt05.iuser.iroot.adidom.com ([147.149.196.177]) by i2kc06-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.1830); Wed, 27 Jun 2007 18:47:36 +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 1182966455544; Wed, 27 Jun 2007 18:47:35 +0100 Received: from mut.jungle.bt.co.uk ([10.215.130.87]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id l5RHlTYR023160; Wed, 27 Jun 2007 18:47:33 +0100 Message-Id: <5.2.1.1.2.20070627182924.04cc2cb0@pop3.jungle.bt.co.uk> X-Sender: rbriscoe@pop3.jungle.bt.co.uk X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Wed, 27 Jun 2007 18:47:40 +0100 To: mallman@icir.org From: Bob Briscoe Subject: Re: [Tsvwg] Does anyone have a defence in favour of flow rate fairness? In-Reply-To: <20070627162647.7EF1B2472C7@lawyers.icir.org> References: <5.2.1.1.2.20070626212717.04bede70@pop3.jungle.bt.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: -3.769 () ALL_TRUSTED,AWL,BAYES_00 X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 X-OriginalArrivalTime: 27 Jun 2007 17:47:36.0243 (UTC) FILETIME=[3F4CC030:01C7B8E3] X-Spam-Score: 0.1 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 Cc: Gorry Fairhurst , tsvwg IETF list X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tsvwg-bounces@ietf.org Mark, At 17:26 27/06/2007, Mark Allman wrote: > > >If there was an actual choice here then perhaps one could talk in > > >terms of mounting a defense or agreeing to go some different > > >direction. However, we have what we have. I cannot simply switch to > > >something else if I wanted to. > > > > I'm offering a choice at both the conceptual level (cost-fairness vs > > flow rate fairness) and at the protocol mechanism level (re-ECN which > > reveals path congestion info to network nodes so they can police > > either form of fairness and others). > >My point is that conceptual mechanisms and schemes from research papers >are great but they are not real choices. I can't twiddle the "something >else" knob here and get something different on this machine than >(roughly) IETF-standardized congestion control. So, I don't understand >why someone needs to defend the status quo against a concept. That's perfectly fair. Except, it's a fully spec'd protocol in an I-D, not just a research paper. But I accept the criticism - it's not running code (yet). Writing that is what we're discussing right now on the re-ecn@ietf.org list. >(That does not mean we can't judge this new concept to be worthy of >design/development/further exploration. See below.) > > > >(a) you want to get rid of best-effort traffic in > > >favor of a pay-as-you-congest model and > > > > Most emphatically no, on both counts. > >I think we have a difference in terminology when we say "best effort" >(this is actually why in our draft draft we define "simple best effort >traffic" to avoid such terminology issues). I had issues with your terminology, but I'll deal with them when I've read it properly. >That said, I read your note as essentially saying best effort is the >same as it is today, except different. I.e., it seems that the end game >is that there is no place for simple best effort traffic. Not at all. On a network (or cluster of networks) that doesn't enforce any controls, any flows that start and end on that network would be 'simple BE traffic'. - If a flow from this liberal net crossed into an 'enforcing' net, they would still be sort-of 'simple BE', but the liberal net (not the user) would be accountable for the congestion they caused elsewhere. - If a flow entered this liberal net from an 'enforcing' net it would not be 'simple BE'. But let's be clear, if it wasn't 'simple BE', it would most likely still behave exactly like 'simple BE' unless the sender was indulging in causing excessive congestion across all traffic it was generating. > > >(b) you want us to obsolete > > >end-point congestion control as is currently specified by the IETF. > > > > b) Most emphatically no again. > >And, then later you note that "They won't be obsolete, just unloved." >Obsolete / unloved / whatever. I understand you don't want to >necessarily say "thou shell not use RFC 2581-style CC", but you're >designing a world where that seems to be the intent. > >It seems to me that this is all backwards. I am perfectly happy to >support IETF work on designing mechanisms to support cost-based >congestion control. That seems fine to me. That does not mean that I >have to agree that we should get rid of all simple best-effort traffic. >That does not mean I have to sign on to a particular fairness criteria. >It seems to me that this question need not gate work on cost-based >schemes. IMHO. [For the list, I've pasted below what I just replied to your off-list mail to answer this:] I thought about this long and hard. You can't have more than one top level fairness goal on an internetwork because any flow may traverse any resource. However, you can have different fairness regimes between subsets of users (see my section on fairness between fairnesses). Note by fairness "goal" I mean the criteria you use to judge fairness (not the relative allocations themselves): ie whether you measure rates or congestion volume, whether you compare flows or users. Bob ____________________________________________________________________________ Notice: This contribution is the personal view of the author and does not necessarily reflect the technical nor commercial direction of BT plc. ____________________________________________________________________________ Bob Briscoe, Networks Research Centre, BT Research B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK. +44 1473 645196 From tsvwg-bounces@ietf.org Wed Jun 27 14:30:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3cHn-0005h8-PK; Wed, 27 Jun 2007 14:30:39 -0400 Received: from tsvwg by megatron.ietf.org with local (Exim 4.43) id 1I3cHm-0005cq-3P for tsvwg-confirm+ok@megatron.ietf.org; Wed, 27 Jun 2007 14:30:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3cHl-0005ce-QC for tsvwg@ietf.org; Wed, 27 Jun 2007 14:30:37 -0400 Received: from relay3.san2.attens.net ([192.215.81.76]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I3cGu-0004uB-OS for tsvwg@ietf.org; Wed, 27 Jun 2007 14:30:37 -0400 Received: from [12.154.81.222] (1513ahost222.starwoodbroadband.com [12.154.81.222]) by relay3.san2.attens.net (8.13.6/8.13.6) with ESMTP id l5RITdHV022207; Wed, 27 Jun 2007 18:29:40 GMT Message-ID: <4682AC91.1020803@isi.edu> Date: Wed, 27 Jun 2007 11:29:37 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: Bob Briscoe Subject: Re: [Tsvwg] Does anyone have a defence in favour of flow rate fairness? References: <5.2.1.1.2.20070626212717.04bede70@pop3.jungle.bt.co.uk> <5.2.1.1.2.20070627182924.04cc2cb0@pop3.jungle.bt.co.uk> In-Reply-To: <5.2.1.1.2.20070627182924.04cc2cb0@pop3.jungle.bt.co.uk> X-Enigmail-Version: 0.95.1 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig8FCCB93857D3C9D652A549B1" X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: Gorry Fairhurst , tsvwg IETF list , mallman@icir.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tsvwg-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig8FCCB93857D3C9D652A549B1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Bob Briscoe wrote: > Mark, =2E.. >> My point is that conceptual mechanisms and schemes from research paper= s >> are great but they are not real choices. I can't twiddle the "somethi= ng >> else" knob here and get something different on this machine than >> (roughly) IETF-standardized congestion control. So, I don't understan= d >> why someone needs to defend the status quo against a concept. >=20 > That's perfectly fair. Except, it's a fully spec'd protocol in an I-D, > not just a research paper.=20 =2E.. Re-ECN is a specific proposal (albeit expired); the Dismantling ID is a research paper. Which one are we discussing here (I thought dismantling)?= Joe --=20 ---------------------------------------- Joe Touch Sr. Network Engineer, USAF TSAT Space Segment --------------enig8FCCB93857D3C9D652A549B1 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 iD8DBQFGgqyRE5f5cImnZrsRAhAfAJ92ebpaBXoY/ghgcFq7hQt1GF6IRQCg/EGp rftdPUkHkRb+6sbgAkrsGIs= =9h3W -----END PGP SIGNATURE----- --------------enig8FCCB93857D3C9D652A549B1-- From tsvwg-bounces@ietf.org Wed Jun 27 18:26:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3fxX-0007sv-LQ; Wed, 27 Jun 2007 18:25:59 -0400 Received: from tsvwg by megatron.ietf.org with local (Exim 4.43) id 1I3fxW-0007qq-C8 for tsvwg-confirm+ok@megatron.ietf.org; Wed, 27 Jun 2007 18:25:58 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3fxV-0007qh-HF for tsvwg@ietf.org; Wed, 27 Jun 2007 18:25:57 -0400 Received: from smtp4.smtp.bt.com ([217.32.164.151]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I3fxV-00084O-7o for tsvwg@ietf.org; Wed, 27 Jun 2007 18:25:57 -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, 27 Jun 2007 23:25:32 +0100 Received: from cbibipnt05.iuser.iroot.adidom.com ([147.149.196.177]) by i2kc06-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.1830); Wed, 27 Jun 2007 23:25:32 +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 1182983130919; Wed, 27 Jun 2007 23:25:30 +0100 Received: from mut.jungle.bt.co.uk ([10.86.0.10]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id l5RMPPxW004885; Wed, 27 Jun 2007 23:25:29 +0100 Message-Id: <5.2.1.1.2.20070627231832.03cffd40@pop3.jungle.bt.co.uk> X-Sender: rbriscoe@pop3.jungle.bt.co.uk X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Wed, 27 Jun 2007 23:25:37 +0100 To: Joe Touch From: Bob Briscoe Subject: Re: [Tsvwg] Does anyone have a defence in favour of flow rate fairness? In-Reply-To: <4682AC91.1020803@isi.edu> References: <5.2.1.1.2.20070627182924.04cc2cb0@pop3.jungle.bt.co.uk> <5.2.1.1.2.20070626212717.04bede70@pop3.jungle.bt.co.uk> <5.2.1.1.2.20070627182924.04cc2cb0@pop3.jungle.bt.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: -3.774 () ALL_TRUSTED,AWL,BAYES_00 X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 X-OriginalArrivalTime: 27 Jun 2007 22:25:32.0160 (UTC) FILETIME=[12EBC000:01C7B90A] X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: Gorry Fairhurst , tsvwg IETF list , mallman@icir.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tsvwg-bounces@ietf.org Joe, At 19:29 27/06/2007, Joe Touch wrote: >Bob Briscoe wrote: > > Mark, >... > >> My point is that conceptual mechanisms and schemes from research papers > >> are great but they are not real choices. I can't twiddle the "something > >> else" knob here and get something different on this machine than > >> (roughly) IETF-standardized congestion control. So, I don't understand > >> why someone needs to defend the status quo against a concept. > > > > That's perfectly fair. Except, it's a fully spec'd protocol in an I-D, > > not just a research paper. >... > >Re-ECN is a specific proposal (albeit expired); the Dismantling ID is a >research paper. Which one are we discussing here (I thought dismantling)? I'd like to keep the discussion to 'dismantling' initially (which I had said in an earlier response to Mark just after this bit of text). But given Mark was wanting code, I was just pointing out (as an aside) that the re-ECN protocol was /one/ possible mechanism that could provide cost-fairness and that it is a little more than just a research paper. Bob ____________________________________________________________________________ Bob Briscoe, Networks Research Centre, BT Research B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK. +44 1473 645196 From tsvwg-bounces@ietf.org Wed Jun 27 21:20:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3ifs-0008Jv-Vv; Wed, 27 Jun 2007 21:19:56 -0400 Received: from tsvwg by megatron.ietf.org with local (Exim 4.43) id 1I3ifr-0008Fh-EE for tsvwg-confirm+ok@megatron.ietf.org; Wed, 27 Jun 2007 21:19:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3ifr-0008DP-2c for tsvwg@ietf.org; Wed, 27 Jun 2007 21:19:55 -0400 Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I3ifn-0005iy-LU for tsvwg@ietf.org; Wed, 27 Jun 2007 21:19:55 -0400 Received: from [70.208.12.73] (73.sub-70-208-12.myvzw.com [70.208.12.73]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id l5S1JJ1L012763; Wed, 27 Jun 2007 18:19:20 -0700 (PDT) Message-ID: <46830C94.7060102@isi.edu> Date: Wed, 27 Jun 2007 18:19:16 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: Bob Briscoe Subject: Re: [Tsvwg] Does anyone have a defence in favour of flow rate fairness? References: <5.2.1.1.2.20070627182924.04cc2cb0@pop3.jungle.bt.co.uk> <5.2.1.1.2.20070626212717.04bede70@pop3.jungle.bt.co.uk> <5.2.1.1.2.20070627182924.04cc2cb0@pop3.jungle.bt.co.uk> <5.2.1.1.2.20070627231832.03cffd40@pop3.jungle.bt.co.uk> In-Reply-To: <5.2.1.1.2.20070627231832.03cffd40@pop3.jungle.bt.co.uk> X-Enigmail-Version: 0.95.1 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigF24C427FD84D5B1A93B78C7B" X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Cc: Gorry Fairhurst , tsvwg IETF list , mallman@icir.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tsvwg-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigF24C427FD84D5B1A93B78C7B Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Bob Briscoe wrote: > Joe, >=20 > At 19:29 27/06/2007, Joe Touch wrote: >=20 >=20 >> Bob Briscoe wrote: >> > Mark, >> ... >> >> My point is that conceptual mechanisms and schemes from research >> papers >> >> are great but they are not real choices. I can't twiddle the >> "something >> >> else" knob here and get something different on this machine than >> >> (roughly) IETF-standardized congestion control. So, I don't >> understand >> >> why someone needs to defend the status quo against a concept. >> > >> > That's perfectly fair. Except, it's a fully spec'd protocol in an I-= D, >> > not just a research paper. >> ... >> >> Re-ECN is a specific proposal (albeit expired); the Dismantling ID is = a >> research paper. Which one are we discussing here (I thought dismantlin= g)? >=20 > I'd like to keep the discussion to 'dismantling' initially (which I had= > said in an earlier response to Mark just after this bit of text). In that case, I'm with Mark in saying this isn't fully spec'd. Dismantling-ID isn't a spec at all - there's no 2119 language, no headers, etc. It's about what *can* be done, but not a specific enough proposal to evaluate. > But given Mark was wanting code, I was just pointing out (as an aside) > that the re-ECN protocol was /one/ possible mechanism that could provid= e > cost-fairness and that it is a little more than just a research paper. I don't understand how the IETF would evaluate the Dismantling-ID if what it does is argue that there could be possible mechanisms (which is what, IMO, it does). That's definitely IRTF - or even just research paper - territory. IETF ought to be specific enough to indicate a way forward. Joe --=20 ---------------------------------------- Joe Touch Sr. Network Engineer, USAF TSAT Space Segment --------------enigF24C427FD84D5B1A93B78C7B 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 iD8DBQFGgwyUE5f5cImnZrsRAjphAJ9o+P8aqDO9f0C8xbp18GKS/zEnNgCeORDw 4wUhYYQM0ErcyfTlbO9MiU8= =v2WM -----END PGP SIGNATURE----- --------------enigF24C427FD84D5B1A93B78C7B-- From tsvwg-bounces@ietf.org Thu Jun 28 00:36:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3ljv-0006K7-SH; Thu, 28 Jun 2007 00:36:19 -0400 Received: from tsvwg by megatron.ietf.org with local (Exim 4.43) id 1I3ljn-0005dl-4E for tsvwg-confirm+ok@megatron.ietf.org; Thu, 28 Jun 2007 00:36:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3ljm-0005bo-Hu; Thu, 28 Jun 2007 00:36:10 -0400 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I3lhc-00008z-Cv; Thu, 28 Jun 2007 00:33:56 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id 4ACB226EBE; Thu, 28 Jun 2007 04:04:01 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1I3lEf-0004Tx-6p; Thu, 28 Jun 2007 00:04:01 -0400 X-test-idtracker: no From: The IESG To: IETF-Announce Message-Id: Date: Thu, 28 Jun 2007 00:04:01 -0400 X-Spam-Score: -2.8 (--) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: tsvwg-chairs@tools.ietf.org, Internet Architecture Board , tsvwg@ietf.org, RFC Editor Subject: [Tsvwg] Protocol Action: 'Stream Control Transmission Protocol (SCTP) Dynamic Address Reconfiguration' to Proposed Standard X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tsvwg-bounces@ietf.org The IESG has approved the following document: - 'Stream Control Transmission Protocol (SCTP) Dynamic Address Reconfiguration ' as a Proposed Standard This document is the product of the Transport Area Working Group. The IESG contact persons are Lars Eggert and Magnus Westerlund. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-addip-sctp-22.txt Technical Summary A local host may have multiple points of attachment to the Internet, giving it a degree of fault tolerance from hardware failures. SCTP was developed to take full advantage of such a multi-homed host to provide a fast failover and association survivability in the face of such hardware failures. This document describes an extension to SCTP that will allow an SCTP stack to dynamically add an IP Addresses to an SCTP association, dynamically delete an IP addresses from an SCTP association, and to request to set the primary address the peer will use when sending to an endpoint. Working Group Summary There is WG consensus to publish this document. It has been reviewed by several people in the WG last call. Comments raised have been addressed. Document Quality Several SCTP implementations, including Solaris, BSD, Linux and HP, have implemented this extension. Personnel James Polk (jmpolk@cisco.com) is the document Shepherd. Lars Eggert (lars.eggert@nokia.com) is the responsible Area Director. From tsvwg-bounces@ietf.org Thu Jun 28 11:34:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3w0q-0006p6-ME; Thu, 28 Jun 2007 11:34:28 -0400 Received: from tsvwg by megatron.ietf.org with local (Exim 4.43) id 1I3w0p-0006j8-Ao for tsvwg-confirm+ok@megatron.ietf.org; Thu, 28 Jun 2007 11:34:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3w0p-0006iT-0G for tsvwg@ietf.org; Thu, 28 Jun 2007 11:34:27 -0400 Received: from mail141.messagelabs.com ([85.158.137.99]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1I3vzy-0004pV-28 for tsvwg@ietf.org; Thu, 28 Jun 2007 11:34:26 -0400 X-VirusChecked: Checked X-Env-Sender: iesg-secretary@ietf.org X-Msg-Ref: server-4.tower-141.messagelabs.com!1183043211!11773655!1 X-StarScan-Version: 5.5.12.11; banners=.,-,- X-Originating-IP: [217.154.25.30] Received: (qmail 14337 invoked from network); 28 Jun 2007 15:06:51 -0000 Received: from mail.apertio.com (HELO mail.apertio.com) (217.154.25.30) by server-4.tower-141.messagelabs.com with SMTP; 28 Jun 2007 15:06:51 -0000 Received: from [192.0.0.52] (helo=pat.apertio.com) by bonfire.apertio.com with smtp (Exim 4.43) id 1I3va6-0001As-SR; Thu, 28 Jun 2007 16:06:50 +0100 Received: from mail pickup service by pat.apertio.com with Microsoft SMTPSVC; Thu, 28 Jun 2007 16:04:07 +0100 Received: from mail.apertio.com ([192.0.0.56]) by pat.apertio.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 28 Jun 2007 05:41:43 +0100 Received-SPF: none (bonfire.apertio.com: 85.158.139.67 is neither permitted nor denied by domain of ietf.org) client-ip=85.158.139.67; envelope-from=ietf-announce-bounces@ietf.org; helo=mail181.messagelabs.com; Received: from mail181.messagelabs.com ([85.158.139.67]) by bonfire.apertio.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.43) id 1I3lp8-0001GM-S6 for norman.greenlee@apertio.co.uk; Thu, 28 Jun 2007 05:41:42 +0100 X-VirusChecked: Checked X-Env-Sender: ietf-announce-bounces@ietf.org X-Msg-Ref: server-12.tower-181.messagelabs.com!1183005700!3920557!1 X-StarScan-Version: 5.5.12.11; banners=-,-,- X-Originating-IP: [156.154.16.145] X-SpamReason: No, hits=0.0 required=7.0 tests= Received: (qmail 2851 invoked from network); 28 Jun 2007 04:41:41 -0000 Received: from stiedprmman1.ietf.org (HELO megatron.ietf.org) (156.154.16.145) by server-12.tower-181.messagelabs.com with AES256-SHA encrypted SMTP; 28 Jun 2007 04:41:41 -0000 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3ljv-0006JK-Bh; Thu, 28 Jun 2007 00:36:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3ljm-0005bo-Hu; Thu, 28 Jun 2007 00:36:10 -0400 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I3lhc-00008z-Cv; Thu, 28 Jun 2007 00:33:56 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id 4ACB226EBE; Thu, 28 Jun 2007 04:04:01 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1I3lEf-0004Tx-6p; Thu, 28 Jun 2007 00:04:01 -0400 X-test-idtracker: no From: The IESG To: IETF-Announce Message-Id: Date: Thu, 28 Jun 2007 00:04:01 -0400 X-Spam-Score: -2.8 (--) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 X-BeenThere: ietf-announce@ietf.org X-Mailman-Version: 2.1.5 Precedence: list X-OriginalArrivalTime: 28 Jun 2007 04:41:43.0778 (UTC) FILETIME=[A0A75420:01C7B93E] X-Spam-Score: 0.1 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: tsvwg-chairs@tools.ietf.org, Internet Architecture Board , tsvwg@ietf.org, RFC Editor Subject: [Tsvwg] Protocol Action: 'Stream Control Transmission Protocol (SCTP) Dynamic Address Reconfiguration' to Proposed Standard X-BeenThere: tsvwg@ietf.org List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tsvwg-bounces@ietf.org The IESG has approved the following document: - 'Stream Control Transmission Protocol (SCTP) Dynamic Address Reconfiguration ' as a Proposed Standard This document is the product of the Transport Area Working Group. The IESG contact persons are Lars Eggert and Magnus Westerlund. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-addip-sctp-22.txt Technical Summary A local host may have multiple points of attachment to the Internet, giving it a degree of fault tolerance from hardware failures. SCTP was developed to take full advantage of such a multi-homed host to provide a fast failover and association survivability in the face of such hardware failures. This document describes an extension to SCTP that will allow an SCTP stack to dynamically add an IP Addresses to an SCTP association, dynamically delete an IP addresses from an SCTP association, and to request to set the primary address the peer will use when sending to an endpoint. Working Group Summary There is WG consensus to publish this document. It has been reviewed by several people in the WG last call. Comments raised have been addressed. Document Quality Several SCTP implementations, including Solaris, BSD, Linux and HP, have implemented this extension. Personnel James Polk (jmpolk@cisco.com) is the document Shepherd. Lars Eggert (lars.eggert@nokia.com) is the responsible Area Director. _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ From tsvwg-bounces@ietf.org Thu Jun 28 12:51:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3xCp-0003B9-E7; Thu, 28 Jun 2007 12:50:55 -0400 Received: from tsvwg by megatron.ietf.org with local (Exim 4.43) id 1I3xCm-00039y-Ve for tsvwg-confirm+ok@megatron.ietf.org; Thu, 28 Jun 2007 12:50:53 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3xCm-00038n-Eg for tsvwg@ietf.org; Thu, 28 Jun 2007 12:50:52 -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 1I3xCl-0006sF-U4 for tsvwg@ietf.org; Thu, 28 Jun 2007 12:50:52 -0400 Received: from [139.133.207.156] (dhcp-207-156.erg.abdn.ac.uk [139.133.207.156]) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id l5SGnRTD000401; Thu, 28 Jun 2007 17:49:27 +0100 (BST) Message-ID: <4683E697.6090104@erg.abdn.ac.uk> Date: Thu, 28 Jun 2007 17:49:27 +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: Bob Briscoe , tsvwg@ietf.org, mallman@icir.org Subject: Re: [Tsvwg] Does anyone have a defence in favour of flow rate fairness? References: <467AC802.6030400@isi.edu> <5.2.1.1.2.20070626085006.0498e188@pop3.jungle.bt.co.uk> In-Reply-To: <5.2.1.1.2.20070626085006.0498e188@pop3.jungle.bt.co.uk> 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: 0.0 (/) X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0 Cc: X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: gorry@erg.abdn.ac.uk List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tsvwg-bounces@ietf.org Bob, There are many ways to disagree... I think writing an IETF document could be useful, now you're offering to focus this on the way forward. I suggest to keep active interest, we may like to establish the goals/benefits/drawbacks of TCP-fairness, cost-fairness, others; an architecture (how will this deal with dynamic networks, legacy networks, networks that wish to not do this, etc), and transition possibilities. If you made a document where we could agree the basis, I'd be one of those who would volunteer to read and comment on the detail (and if I have appropriate expertise I would offer to contribute). Best wishes, Gorry Bob Briscoe wrote: > Gorry, > > At 14:13 25/06/2007, Gorry Fairhurst wrote: > > >> Bob Briscoe wrote: >> > TSVWG, >> >> > Gorry Fairhurst voiced concern that the consensus was unlikely to have >> > shifted so quickly away from TCP fairness for this to be a feasible >> > WG item. But I'd like to hear someone argue against cost-fairness or >> > for flow rate fairness (or specifically for TCP-fairness), so we >> > can actually debate this issue. >> > >> >> > Given the I-D provocatively challenges anyone who wants to >> > continue to use flow rate fairness to either defend it against the >> > arguments or stop promoting it, I'm assuming that a lack of defence >> > implies surrender. :) >> >> That is not how I see this. > > > OK. > > I only said this because the IETF's hallmark is technical discussion of > the issues in order to develop protocols based on technical merit. > >> > More specifically, does the TSVWG want to take on as a WG item the >> > production of an informational RFC that would give a plan for the >> > evolution of fairness control from where we are now, to a future where >> > fairness policy can be controlled and enforced (or not) by more than >> > just endpoints? >> > - stating that we have a problem and what the problem is >> > - stating what a good solution might look like (who/what might take >> > control etc). >> > - stating which fairness metrics are valid and which aren't >> > - stating what implications the approach will have for evolution from >> > where we are >> > - etc >> >> To me, the current revision -01, judges history, > > > I'm v happy to re-work the whole I-D (with co-author(s)) to be more > forward looking. > >> and although fine in a >> research environment, taking this topic as a WG item would need an >> interpretation that is endorsed by the WG, and relating this to the >> architecture. There are reasons why the current methods have evolved. >> I do >> not share the view this is just "myopia". > > > Certainly 20yrs ago TCP congestion ctrl solved a serious and immediate > problem and it has served us well since. But the world has changed a lot > since then and is now starting to extend its behaviour (ie many more > flows, much longer flows) way outside the pragmatic assumptions behind > TCP fairness. What was done 20 years ago was good, but the time has come > to move on. Sticking with TCP-fairness from now on and into the future > would indeed be myopic. > >> Are you planning a new revision of the I-D prior to the next meeting? > > > Before the Chicago meeting I will simply add clearer answers to a few > questions I keep getting. > > After Chicago, I would like to see a big re-work to make it more forward > looking and less damning of the past - perhaps along the lines I suggest > above. Louise Burness and Toby Moncaster here at BT are keen to help, > but co-author(s) who have worked closely on TCP-fairness over the years > would be more useful to add a different perspective. > > Are there any other volunteers? > > > Bob > > > > ____________________________________________________________________________ > > Notice: This contribution is the personal view of the author and does > not necessarily reflect the technical nor commercial direction of BT plc. > ____________________________________________________________________________ > > Bob Briscoe, Networks Research Centre, BT > Research > B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK. +44 1473 > 645196 > > From tsvwg-bounces@ietf.org Thu Jun 28 13:53:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3yBO-00074E-O1; Thu, 28 Jun 2007 13:53:30 -0400 Received: from tsvwg by megatron.ietf.org with local (Exim 4.43) id 1I3yBM-00073l-Qx for tsvwg-confirm+ok@megatron.ietf.org; Thu, 28 Jun 2007 13:53:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3yBM-00073N-70; Thu, 28 Jun 2007 13:53:28 -0400 Received: from smtp.nokia.com ([131.228.20.171] helo=mgw-ext12.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I3yB9-0007GV-Hj; Thu, 28 Jun 2007 13:53:28 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext12.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l5SHqr6Z030265; Thu, 28 Jun 2007 20:53:13 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 28 Jun 2007 20:53:07 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 28 Jun 2007 20:53:06 +0300 Received: from mgw-int01.ntc.nokia.com ([172.21.143.96]) by esebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Thu, 28 Jun 2007 20:53:06 +0300 Received: from [172.21.35.147] (esdhcp035147.research.nokia.com [172.21.35.147]) by mgw-int01.ntc.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l5SHqknS020462; Thu, 28 Jun 2007 20:53:05 +0300 In-Reply-To: <46828A44.1050804@icann.org> References: <46828A44.1050804@icann.org> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-32-735035166; protocol="application/pkcs7-signature" Message-Id: From: Lars Eggert Date: Thu, 28 Jun 2007 20:53:01 +0300 To: tsvwg IETF list X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 28 Jun 2007 17:53:06.0696 (UTC) FILETIME=[2EADA080:01C7B9AD] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: c2e58d9873012c90703822e287241385 Cc: IESG IESG Subject: [Tsvwg] IANA issue with RFC2960/draft-ietf-tsvwg-2960bis X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tsvwg-bounces@ietf.org --Apple-Mail-32-735035166 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Hi, during a second IANA review of the IANA considerations section in draft-ietf-tsvwg-2960bis during the RFC Editor's "IANA" state, a discrepancy has been identified. Basically, the text that describes the port number assignment procedure - which had been taken verbatim from RFC2960 - wasn't describing the procedure that IANA has actually used since RFC2960 was published seven years ago. The IANA instructions in draft-ietf-tsvwg-2960bis and RFC2960 basically say "for each existing TCP/UDP port assignment, create a similar entry in the SCTP port number registry", i.e., a blanket assignment of SCTP port numbers for all existing TCP/UDP assignments. What appears to have happened is that the ADs at the time identified an issue with the text that was in the ID that became RFC2960 and instructed IANA to follow a different procedure, namely, to not perform a blanket assignment and instead create individual entries in the SCTP port number registry on request, similar to how IANA handles requests for TCP/UDP and DCCP port numbers. Unfortunately, the text in RFC2960 was never updated to reflect this change in procedure. When I reviewed 2960bis I didn't question this, because it was what I thought the policy was, and it wasn't for the -bis document to change the policy. Now that we've found out that the IANA procedures in RFC2960 were actually modified by the ADs at the time, the situation has changed. In my (and Magnus) opinion, we should change the IANA considerations text in 2960bis to describe the allocation policy that has actually been in effect for the last seven years, i.e., allocate individual SCTP ports by request, instead of the blanket registration that the text currently describes. I'll propose some text changes to 2960bis to that effect below, which I'd like TSVWG and the IESG to review, but let me first explain why I think this is the correct approach: (1) I find myself agreeing with the old ADs' argumentation. SCTP and TCP (and UDP) have different requirements, and it is not obvious that an application can substitute one transport protocol for another. (And yes, the current practice of allocating both TCP and UDP ports for an application if it requests either UDP or TCP only is for that reason also problematic, but let's get to that another time.) (2) For our other recent transport protocol (DCCP), we also didn't do a blanket port reservation for all existing TCP and UDP ports and instead require individual registrations, although one could similarly argue that UDP apps can simply migrate to DCCP. Doing something different for SCTP is inconsistent. (3) The scope of 2960bis was clarification and fixes. For that reason, the IANA registration that is used in practice should be described as part of 2960bis, i.e., 2960bis should "fix" that error in RFC2960. Several applications already use SCTP on port numbers that have been assigned to them for TCP or UDP, because the authors were not aware that they would need to request an allocation from IANA. I propose that the change to the IANA Considerations section in 2960bis register the SCTP ports of those applications, to "bless" those existing uses. All that said, below is the proposal to update 2960bis. The text mirrors the allocation procedure for DCCP ports (thanks, RFC4340 authors!) Please comment. IANA has agreed to put a hold on the document until this issue has been clarified. Lars OLD TEXT: 14. IANA Considerations This protocol will require port reservation like TCP for the use of "well known" servers within the Internet. All current TCP ports shall be automatically reserved in the SCTP port address space. New requests should follow IANA's current mechanisms for TCP. This protocol may also be extended through IANA in three ways: -- through definition of additional chunk types, -- through definition of additional parameter types, or -- through definition of additional cause codes within ERROR chunks In the case where a particular ULP using SCTP desires to have its own ports, the ULP should be responsible for registering with IANA for getting its ports assigned. NEW TEXT: 14. IANA Considerations SCTP defines three registries that IANA maintains: -- through definition of additional chunk types, -- through definition of additional parameter types, or -- through definition of additional cause codes within ERROR chunks SCTP requires that the IANA Port Numbers registry be opened for SCTP port registrations; Section 14.5 describes how. 14.5 Port Numbers Registry SCTP services may use contact port numbers to provide service to unknown callers, as in TCP and UDP. IANA is therefore requested to open the existing Port Numbers registry for SCTP using the following rules, which we intend to mesh well with existing Port Numbers registration procedures. Port numbers are divided into three ranges. The Well Known Ports are those from 0 through 1023, the Registered Ports are those from 1024 through 49151, and the Dynamic and/or Private Ports are those from 49152 through 65535. Well Known and Registered Ports are intended for use by server applications that desire a default contact point on a system. On most systems, Well Known Ports can only be used by system (or root) processes or by programs executed by privileged users, while Registered Ports can be used by ordinary user processes or programs executed by ordinary users. Dynamic and/or Private Ports are intended for temporary use, including client-side ports, out-of- band negotiated ports, and application testing prior to registration of a dedicated port; they MUST NOT be registered. The Port Numbers registry should accept registrations for SCTP ports in the Well Known Ports and Registered Ports ranges. Well Known and Registered Ports SHOULD NOT be used without registration. Although in some cases -- such as porting an application from TCP to SCTP -- it may seem natural to use a SCTP port before registration completes, we emphasize that IANA will not guarantee registration of particular Well Known and Registered Ports. Registrations should be requested as early as possible. Each port registration SHALL include the following information: o A short port name, consisting entirely of letters (A-Z and a-z), digits (0-9), and punctuation characters from "-_+./*" (not including the quotes). o The port number that is requested to be registered. o A short English phrase describing the port's purpose. o Name and contact information for the person or entity performing the registration, and possibly a reference to a document defining the port's use. Registrations coming from IETF working groups need only name the working group, but indicating a contact person is recommended. Registrants are encouraged to follow these guidelines when submitting a registration. o A port name SHOULD NOT be registered for more than one SCTP port number. o A port name registered for TCP MAY be registered for SCTP as well. Any such registration SHOULD use the same port number as the existing TCP registration. o Concrete intent to use a port SHOULD precede port registration. For example, existing TCP ports SHOULD NOT be registered in advance of any intent to use those ports for SCTP. This document registers the following ports. (These registrations should be considered models to follow for future allocation requests.) discard 9/sctp Discard # IETF TSVWG # Randall Stewart # [draft-ietf-tsvwg-2960bis-05] The discard service, which accepts SCTP connections on port 9, discards all incoming application data and sends no data in response. Thus, SCTP's discard port is analogous to TCP's discard port, and might be used to check the health of a SCTP stack. --Apple-Mail-32-735035166 Content-Transfer-Encoding: base64 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGQDCCAvkw ggJioAMCAQICEGtxkLFHQu1g67hlmYfwPuIwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDEwNDE2MTE1NFoXDTA4MDEwNDE2MTE1 NFowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEA26hjntVPZMiwh4d8tyuk9KiucvG92BVUGArk5zO1jhmq7tLFgU1mqcIg VGumfQqjkAzIuh83kxIiqBrB05Wvxp85apwt4sUCvzMe8mQWzZZZYp0rBzwpOj+VC5pxsMRYtYW+ BaTFBEmvFr7D7C7roZUk0lDppS5SZFs4SQbEe9ykB9aeUf1iTiw2+ikyP2+JEYto14WYCoxFWbms FbQ1uaaK+yn1WH2YHhyMfi0IOxuT0jtbsngjHJMpWIqq334zBhj+rPSUug47YBHr41FCDMHbbbjv WbyTyDYneOW3WY8LY8bGWVlAknQGB7lgduShe6e0RI/7SL/VE6X27lM9LwIDAQABozIwMDAgBgNV HREEGTAXgRVsYXJzLmVnZ2VydEBub2tpYS5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUF AAOBgQCx3nxxTg/WowobVTRXBiXUEEZj4LBiunWbuAnR0UbJIgijvq3JbiJvZo2gUGiW9LPaHSBz 4oxT1VR/S/6O0a4e87oV5cOQm6ReB68o9rDfUzxHTwoCfv2wwMwBrXyzQMjyQK4Lt8siV41gmZpm rSXMhjTJdd9uYYNoZKQLq+VM+TCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJ BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgG A1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMg RGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3 DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3 MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9 fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+ uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMB Af8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3 dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgG A1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcP f6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH 2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8x ggMQMIIDDAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAo UHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ a3GQsUdC7WDruGWZh/A+4jAJBgUrDgMCGgUAoIIBbzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw0wNzA2MjgxNzUzMDJaMCMGCSqGSIb3DQEJBDEWBBRjSidfBRA/Egdj PurDZ4FUvR7jGDCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIwgYcGCyqGSIb3DQEJEAILMXigdjBiMQsw CQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIw DQYJKoZIhvcNAQEBBQAEggEAfi+hRd/JEcMFJnrwHJwadITcHaMeL4Zggag7R8JAFSemybmwYuDU E3ThgoftycvMw1JuyC4ir+Qo7st2E/GnspfPQrUP2ksEf/EXV2Kqjdm6nMIGKtjepxmyB0AijFX0 WwSxkYZTOVaHhSkxuJEBD4B/0+1wr+aRo5e9Si3Rc5c8gIZpKjhtB4c0EmVKV+SyEXRUeMbD7cVr c+TdcNVEy+iQd7FIfDfGR/pmhm1cHLAlVczVzSnh3rm4gnjGjnXJ9+w5xbgYL57o6TVIeyzo1b1h 6+xDzSptN6PlCZiLlXF2PTORF6W5RujXd4+iugCrlVvS8q7TOa2982fZkEHXUwAAAAAAAA== --Apple-Mail-32-735035166-- From tsvwg-bounces@ietf.org Thu Jun 28 14:39:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3ytf-0004lr-DW; Thu, 28 Jun 2007 14:39:15 -0400 Received: from tsvwg by megatron.ietf.org with local (Exim 4.43) id 1I3ytc-0004lk-44 for tsvwg-confirm+ok@megatron.ietf.org; Thu, 28 Jun 2007 14:39:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3ytb-0004lc-Qi for tsvwg@ietf.org; Thu, 28 Jun 2007 14:39:11 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I3ysv-0002M4-3q for tsvwg@ietf.org; Thu, 28 Jun 2007 14:39:11 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-2.cisco.com with ESMTP; 28 Jun 2007 11:37:48 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAACOdg0arR7O6h2dsb2JhbACPKwIJDiw X-IronPort-AV: i="4.16,471,1175497200"; d="scan'208"; a="382461362:sNHT173485332" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l5SIbkDS022946 for ; Thu, 28 Jun 2007 11:37:46 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l5SIbeGq028299 for ; Thu, 28 Jun 2007 18:37:46 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 28 Jun 2007 14:37:38 -0400 Received: from jmpolk-wxp.cisco.com ([10.89.16.120]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 28 Jun 2007 14:37:37 -0400 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 28 Jun 2007 13:37:35 -0500 To: tsvwg From: "James M. Polk" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: X-OriginalArrivalTime: 28 Jun 2007 18:37:37.0796 (UTC) FILETIME=[66C72440:01C7B9B3] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=997; t=1183055866; x=1183919866; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=20=22James=20M.=20Polk=22=20 |Subject:=20Checking=20agenda=20requests=20for=20Chicago=20(authors!) |Sender:=20; bh=tHhlp2VapvHORrPpz2ojMCql9UtkqeG15u7ogZVT5Hs=; b=DNsiCHgyOHIDNy+IBLV7G7Mtpwrv3MbkkOmERh5VSXobVLHi7I7G9nhaGs9EFf1uFllZq/EU mFeWYAPisylNBPYVKVGy4CAb0uTeXpv+sDc3p2C8HAvPjTlnk2wzWBg9; Authentication-Results: sj-dkim-2; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Subject: [Tsvwg] Checking agenda requests for Chicago (authors!) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tsvwg-bounces@ietf.org TSVWG I'm putting together the agenda for Chicago, and want to verify all the timeslot requests sent to me; I fear I may have missed one or two. Here's what I have (in *no* particular order): draft-ietf-tsvwg-udp-guidelines-01 draft-ietf-tsvwg-rsvp-proxy-approaches-00 draft-ietf-tsvwg-rsvp-proxy-proto-00 draft-ietf-tsvwg-ecn-mpls-01 draft-ietf-tsvwg-udplite-mib-00 draft-behringer-tsvwg-rsvp-security-groupkeying-00 draft-davie-tsvwg-rsvp-l3vpn-00 draft-scharf-tsvwg-quick-start-flow-control-01 draft-floyd-tsvwg-besteffort-00 draft-polk-tsvwg-signaled-domain-id-00 draft-briscoe-tsvwg-byte-pkt-mark-00 draft-briscoe-tsvwg-ecn-tunnel-00 PLEASE let me know ASAP if you have sent me a timeslot request and don't see your ID above. TSVWG seems pretty set on meeting Thursday morning, July 26th, from 9am-1130am Cheers, James IETF TSVWG co-chair *********************************** "It should NEVER be inconvenient to do the right thing" From tsvwg-bounces@ietf.org Thu Jun 28 16:41:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I40nt-0006Yd-N4; Thu, 28 Jun 2007 16:41:25 -0400 Received: from tsvwg by megatron.ietf.org with local (Exim 4.43) id 1I40nr-0006UP-Q4 for tsvwg-confirm+ok@megatron.ietf.org; Thu, 28 Jun 2007 16:41:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I40nr-0006UH-GI; Thu, 28 Jun 2007 16:41:23 -0400 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I40n6-0001AX-Cd; Thu, 28 Jun 2007 16:41:23 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id 914CC26ED5; Thu, 28 Jun 2007 19:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1I400A-0005PX-DQ; Thu, 28 Jun 2007 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Thu, 28 Jun 2007 15:50:02 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Cc: tsvwg@ietf.org Subject: [Tsvwg] I-D ACTION:draft-ietf-tsvwg-rsvp-proxy-proto-01.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tsvwg-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Area Working Group Working Group of the IETF. Title : RSVP Extensions for Path-Triggered RSVP Receiver Proxy Author(s) : F. Le Faucheur, et al. Filename : draft-ietf-tsvwg-rsvp-proxy-proto-01.txt Pages : 25 Date : 2007-6-28 RSVP signaling can be used to make end-to-end resource reservations in an IP network in order to guarantee the QoS required by certain flows. With conventional RSVP, both the data sender and receiver of a given flow take part in RSVP signaling. Yet, there are many use cases where resource reservation is required, but the receiver, the sender, or both, is not RSVP-capable. Where the receiver is not RSVP-capable, an RSVP router may behave as an RSVP Receiver Proxy thereby performing RSVP signaling on behalf of the receiver. This allows resource reservations to be established on the segment of the end-to-end path from the sender to the RSVP Receiver Proxy. However, as discussed in the companion document presenting RSVP Proxy approaches, RSVP extensions are needed to facilitate operations with an RSVP Receiver Proxy whose signaling is triggered by receipt of RSVP Path messages from the sender. This document specifies these extensions. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-rsvp-proxy-proto-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-tsvwg-rsvp-proxy-proto-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-tsvwg-rsvp-proxy-proto-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-6-28132603.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-tsvwg-rsvp-proxy-proto-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-tsvwg-rsvp-proxy-proto-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-6-28132603.I-D@ietf.org> --OtherAccess-- --NextPart-- From tsvwg-bounces@ietf.org Sat Jun 30 05:35:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4ZLu-0004TT-2G; Sat, 30 Jun 2007 05:34:50 -0400 Received: from tsvwg by megatron.ietf.org with local (Exim 4.43) id 1I4ZLs-0004TM-Q5 for tsvwg-confirm+ok@megatron.ietf.org; Sat, 30 Jun 2007 05:34:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4ZLs-0004TE-GD for tsvwg@ietf.org; Sat, 30 Jun 2007 05:34:48 -0400 Received: from smtp4.smtp.bt.com ([217.32.164.151]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I4ZL8-0002M2-VK for tsvwg@ietf.org; Sat, 30 Jun 2007 05:34:48 -0400 Received: from i2kc06-ukbr.domain1.systemhost.net ([193.113.197.70]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 30 Jun 2007 10:34:02 +0100 Received: from cbibipnt05.iuser.iroot.adidom.com ([147.149.196.177]) by i2kc06-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.1830); Sat, 30 Jun 2007 10:34:02 +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 1183196040737; Sat, 30 Jun 2007 10:34:00 +0100 Received: from mut.jungle.bt.co.uk ([10.86.6.101]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id l5U9Xu9c012058; Sat, 30 Jun 2007 10:33:58 +0100 Message-Id: <5.2.1.1.2.20070630102758.03d3c908@pop3.jungle.bt.co.uk> X-Sender: rbriscoe@pop3.jungle.bt.co.uk X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Sat, 30 Jun 2007 10:34:09 +0100 To: Lars Eggert , "POLK, James" From: Bob Briscoe Subject: Fwd: RE: [Tsvwg] Re: IETF process concerning missed RFC dependencies? Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: -3.783 () ALL_TRUSTED,AWL,BAYES_00 X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 X-OriginalArrivalTime: 30 Jun 2007 09:34:02.0197 (UTC) FILETIME=[CB313050:01C7BAF9] X-Spam-Score: 0.1 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: "BLACK, David" , tsvwg IETF list X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tsvwg-bounces@ietf.org Lars, James, I've just posted the new initial I-D on ECN tunnelling to internet drafts. It turned out David Black didn't have time to contribute text (he will in the next cycle), but he's helped a lot with my understanding of the history on this. I won't ask for any dependency updates until after it's all been discussed in Chicago, even tho one at least seems straightforward (3168 updates 2003). Next mail will be a forward of the mail I sent to internet drafts giving URL etc. Cheers Bob >Date: Wed, 13 Jun 2007 09:07:00 +0100 >To: Lars Eggert >From: Bob Briscoe >Subject: RE: [Tsvwg] Re: IETF process concerning missed RFC dependencies? >Cc: braden@ISI.EDU, floyd@icir.org, tsvwg@ietf.org, >magnus.westerlund@ericsson.com > >>2/ As I said and you said, I don't believe the contradictions between >>3168 & 4301 can or should be solved by just updating the RFC index. >>That's why I've written a draft-I-D (to be posted as an I-D by end of >>this week when my co-authors have had a chance to refine it). David Black (co-author) needs more time. Prob another week, but definitely before -00 cut-off in fortnight. I've made a huge effort to make sure there are no changes to the security of the protocol, but David wants to make sure that message is put so unambiguously that the security community won't get unnecessarily concerned. Bob ____________________________________________________________________________ Notice: This contribution is the personal view of the author and does not necessarily reflect the technical nor commercial direction of BT plc. ____________________________________________________________________________ Bob Briscoe, Networks Research Centre, BT Research B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK. +44 1473 645196 From tsvwg-bounces@ietf.org Sat Jun 30 05:41:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4ZSg-0007Ey-ON; Sat, 30 Jun 2007 05:41:50 -0400 Received: from tsvwg by megatron.ietf.org with local (Exim 4.43) id 1I4ZSf-0007EZ-Fi for tsvwg-confirm+ok@megatron.ietf.org; Sat, 30 Jun 2007 05:41:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4ZSf-0007ER-5u for tsvwg@ietf.org; Sat, 30 Jun 2007 05:41:49 -0400 Received: from smtp5.smtp.bt.com ([217.32.164.139]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I4ZRx-0003dN-Ho for tsvwg@ietf.org; Sat, 30 Jun 2007 05:41:49 -0400 Received: from i2kc08-ukbr.domain1.systemhost.net ([193.113.197.71]) by smtp5.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 30 Jun 2007 10:41:04 +0100 Received: from cbibipnt08.iuser.iroot.adidom.com ([147.149.100.81]) by i2kc08-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.1830); Sat, 30 Jun 2007 10:41:04 +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 1183196463470; Sat, 30 Jun 2007 10:41:03 +0100 Received: from mut.jungle.bt.co.uk ([10.86.6.101]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id l5U9exT1012350; Sat, 30 Jun 2007 10:41:01 +0100 Message-Id: <5.2.1.1.2.20070630103425.048fa2d8@pop3.jungle.bt.co.uk> X-Sender: rbriscoe@pop3.jungle.bt.co.uk X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Sat, 30 Jun 2007 10:41:12 +0100 To: "POLK, James" , "tsvwg IETF list" From: Bob Briscoe Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: -3.784 () ALL_TRUSTED,AWL,BAYES_00 X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 X-OriginalArrivalTime: 30 Jun 2007 09:41:04.0762 (UTC) FILETIME=[C70F7DA0:01C7BAFA] X-Spam-Score: 0.1 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Cc: Subject: [Tsvwg] Initial I-D: draft-briscoe-tsvwg-ecn-tunnel-00 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tsvwg-bounces@ietf.org James & TSVWG folks, The draft proposing to bring RFC3168 ECN tunnelling behaviour into line with the new RFC4301 IPsec behaviour will appear shortly in internet-drafts (see below for header block/abstract etc) If you wish, until it pops out onto internet-drafts you can access my local copy in various formats via: Cheers Bob >Date: Sat, 30 Jun 2007 10:22:33 +0100 >To: internet-drafts@ietf.org >From: Bob Briscoe >Subject: Initial I-D: draft-briscoe-tsvwg-ecn-tunnel-00 >Cc: "BLACK, David" > >Internet-Drafts, > >Hi. Please upload the new Initial Internet Draft at the URL below to the >IETF Internet Drafts Directory. > > >Author, title, abstract etc below. > >It is part of discussions in the Transport Area (TSVWG), but it is not >(yet) a working group draft - just a personal contribution at this time. > > > > > > > >============================================================================= >Transport Area Working Group B. Briscoe >Internet-Draft BT >Intended status: Standards Track June 30, 2007 >Expires: January 1, 2008 > > Layered Encapsulation of Congestion Notification > draft-briscoe-tsvwg-ecn-tunnel-00 > >Abstract > > This document redefines how the explicit congestion notification > (ECN) field of the outer IP header of a tunnel should be constructed. > It brings all IP in IP tunnels (v4 or v6) into line with the way > IPsec tunnels now construct the ECN field, ensuring that the outer > header reveals any congestion experienced so far on the path. It > specifies the default ECN tunneling behaviour for any Diffserv per- > hop behaviour (PHB), but also gives general principles to guide the > design of alternate congestion marking behaviours for specific PHBs > and for lower layer congestion notification schemes. >============================================================================= > > ____________________________________________________________________________ Notice: This contribution is the personal view of the author and does not necessarily reflect the technical nor commercial direction of BT plc. ____________________________________________________________________________ Bob Briscoe, Networks Research Centre, BT Research B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK. +44 1473 645196