From tsvwg-bounces@ietf.org Thu Feb 01 17:08:59 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCk5u-00021V-AJ; Thu, 01 Feb 2007 17:07:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCk5t-00021N-Ls for tsvwg@ietf.org; Thu, 01 Feb 2007 17:07:49 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCk5s-0001hH-Ak for tsvwg@ietf.org; Thu, 01 Feb 2007 17:07:49 -0500 Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 01 Feb 2007 23:07:45 +0100 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 l11M7jNT027622 for ; Thu, 1 Feb 2007 23:07:45 +0100 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 l11M7iC8024044 for ; Thu, 1 Feb 2007 23:07:45 +0100 (MET) 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); Thu, 1 Feb 2007 23:07:44 +0100 Received: from jmpolk-wxp.cisco.com ([10.58.48.26]) by xfe-ams-332.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 1 Feb 2007 23:07:43 +0100 Message-Id: <4.3.2.7.2.20070201160244.034441c8@email.cisco.com> X-Sender: jmpolk@email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 01 Feb 2007 16:07:43 -0600 To: tsvwg From: "James M. Polk" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 01 Feb 2007 22:07:43.0931 (UTC) FILETIME=[65E570B0:01C7464D] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=421; t=1170367665; x=1171231665; c=relaxed/simple; s=amsdkim2001; 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:=20*Draft*=20Agenda=20for=20Prague=20(IETF68) |Sender:=20; bh=j4gwGQEp1KgXnQC4nz1QQ+Ej/VKF9DKSsU8QjbRequI=; b=cWmhlYRroOBtEJd+0NzYHvpzCr8u0JGr6gqE7UFMOBwBvjjUz03WTsKcH7+nkl2PPHi5f78z 466Uw5Yp39Bx4xhD/JoCvbhmGWPjMLoS8F+PBSYvK4MEhCahP6gpRNdS; Authentication-Results: ams-dkim-2; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Subject: [Tsvwg] *Draft* Agenda for Prague (IETF68) 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 WG Notice the *draft* agenda THAT MIGHT CHANGE AT ANY MOMENT (and will several times to come as conflicts are worked out) shows TSVWG currently meeting on Friday morning. https://datatracker.ietf.org/public/meeting_agenda_html.cgi?meeting_num=68 So, from this, if it does NOT change (and that's a big IF), please plan on flying home after the meeting - if you want to attend our WG session. the chairs From tsvwg-bounces@ietf.org Sun Feb 04 18:18:44 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HDqbd-000448-HN; Sun, 04 Feb 2007 18:17:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HDqbc-00043j-NV for tsvwg@ietf.org; Sun, 04 Feb 2007 18:17:08 -0500 Received: from smail.alcatel.fr ([62.23.212.165]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HDqbb-0001rG-4l for tsvwg@ietf.org; Sun, 04 Feb 2007 18:17:08 -0500 Received: from bemail05.netfr.alcatel.fr (bemail05.netfr.alcatel.fr [155.132.251.11]) by smail.alcatel.fr (8.13.4/8.13.4/ICT) with ESMTP id l14NHBL2016913; Mon, 5 Feb 2007 00:17:11 +0100 In-Reply-To: To: Bruce Davie Subject: Re: [Tsvwg] Making draft-davie-ecn-mpls a TSVWG item MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5 September 26, 2003 Message-ID: From: Dimitri.Papadimitriou@alcatel-lucent.be Date: Mon, 5 Feb 2007 00:17:03 +0100 X-MIMETrack: Serialize by Router on BEMAIL05/BE/ALCATEL(Release 5.0.13aHF163 | June 23, 2005) at 02/05/2007 00:17:04, Serialize complete at 02/05/2007 00:17:04 Content-Type: text/plain; charset="US-ASCII" X-Scanned-By: MIMEDefang 2.51 on 155.132.180.81 X-Spam-Score: 0.2 (/) X-Scan-Signature: 2a76bcd37b1c8a21336eb0a1ea6bbf48 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 Bruce Davie 26/01/2007 14:38 To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL cc: tsvwg@ietf.org Subject: Re: [Tsvwg] Making draft-davie-ecn-mpls a TSVWG item On Jan 25, 2007, at 7:07 PM, Dimitri.Papadimitriou@alcatel-lucent.be wrote: > lars - > > i am more generally questioning cost/perf. gain & value for 3 > major reasons (they would deserve imho further discussion - or > at least further proof of evidence) > > o) if it is to come up with a forwarding paradigm that becomes > equivalent to IP probably we should then start questioning the > need for MPLS itself (in part. in the present case focusing on > intra-domain operations where i always thought that data-traffic > and resource-oriented perf. objectives were taken into account > for edge-to-edge MPLS path provisioning) I think the need for MPLS is to support capabilities like VPNs and constraint-based routing. Giving MPLS the ability to support Diffserv (as was done in RFC3240) did not take away the need for VPNs or constraint-based routing. It simply enabled an operator to deploy MPLS to gain the extra capabilities of MPLS, without giving up the ability to do Diffserv. The same reasoning applies here: we want to allow an operator to deploy MPLS for the purposes of VPNs, TE, etc., without forcing him to give up the ability to do ECN. Of course, an operator who has no interest in ECN can leave this functionality disabled, just as RFC3270 functionality can be disabled for those operators who don't care for it. In short, adding more capabilities to MPLS does not negate the advantages that MPLS brings. [dp] that's not the point, you assume that CN is needed hence MPLS we should incorporate, my point is if the TE mechanisms and the related operations to MPLS-TE are not enough, then, one should question their real value and why not just stay w/ the pure-IP only techniques that are already delivering the goodies required, indeed, this comes very close to the argument that MPLS is simply becoming useless > o) MPLS paradigm assumed "intelligence@edges" we progressively > enter into a mode where intermediate LSRs will become (see end > of section 3) progressively require/result again more selective > processing of traffic > I'm not at all convinced that view is universally held. The task of assigning packets to FECs is indeed done at the edges, but I don't believe there is a grand principle that says MPLS core devices must do nothing other than forward packets based on the label. In fact, as one of the people who designed the MPLS shim header, I can say that the reason for reserving the 3 "EXP" bits was to allow for queueing treatment to be applied to packets independent of the label. That is exactly what both RFC3270 and this mpls-ecn draft do with those bits. [dp] i don't think i stated that label value independent queuing shall not be possible on intermediate nodes, the question is why is there a value to put more functionality on these nodes ? what i see is that we are lacking proven arguments in that direction > o) initial MPLS-ECN based its reasoning on expectations from > experience - quoting: > > "We believe the benefits from ECN of better overall performance > for a wide range of applications because of reduced packet loss > (especially those using non-TCP transports) and reduced queueing > delay is sufficiently significant. Furthermore, there seems to > be no reasons for LSRs to lack this capability as it becomes > available in other (non-label switched) IP routers." > > it would have been interesting to sustain the reasoning with > more tangible proofs - with the underlying question are we here > waiting for this doc. to make such experiment possible ? It is certainly true that ECN has yet to be proven to be universally useful. That is one reason why the draft goes to some lengths to specify this as optional behavior. But I can't see what bad thing will happen if TSVWG starts working on an MPLS ECN draft now. If proven utility is the standard that we have to reach before embarking on a working group draft, then a lot of work at the IETF should be stopped now. [dp] the point is to come at least with one good thing shared by the whole community - unique reason to put a functionality present at a higher level down the stack - Bruce > > much thanks, > - d. > > > > > > > > 18/01/2007 11:49 > > To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL > cc: tsvwg@ietf.org > Subject: RE: [Tsvwg] Making draft-davie-ecn-mpls a > TSVWG > item > > > < Attachment smime.p7s removed > > > > Dimitri, > >> discussion was led on the list mid november - no real >> conclusion or action where derived from the concerns >> expressed at that time > > thanks for pointing out that this draft was also discussed elsewhere! > > As for your specific points: > >>> 1. CN marking in the EXP bits of the MPLS header falls imho under > the >>> MPLS change process that states for an optional problem statement > and >>> a mandatory prior requirements statement I-D to commit for any >>> specific change or extension to MPLS >>> >>> see section 2.1.1 and 4.2 of >>> > change-06 > .txt> > > The process described in that document isn't official procedure > yet, and > has raised significant concern in parts of the IESG. IMO it is > unlikely > to proceed without major changes. Hence, it's questionable that we > should apply it here and now. > >> [dp] the same section 7 mentions >> >> "[RFC3168] does not give any reasons against conveying CE information >> from the inner header to the outer in the "full functionality" >> mode." >> >> nor the other way around - which leaves the point open for ECN itself >> -> the issue i am raising is that in absence of evidence current the >> processing should be left per RFC3168 and not inline with the >> expected >> PCN needs (even if it does not affect the former) > > I'm not quite sure I understand your point - are you saying that the > benefits of ECN for MPLS are unclear? > > Thanks, > Lars > -- > NEW EMAIL: lars.eggert@nokia.com > NEW MOBILE: +358 50 48 24461 > NEW JABBER: lars.eggert@googlemail.com > > > > From tsvwg-bounces@ietf.org Mon Feb 05 09:14:56 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HE4bu-0008Or-3a; Mon, 05 Feb 2007 09:14:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HE4bs-0008Mx-DU; Mon, 05 Feb 2007 09:14:20 -0500 Received: from nj300815-ier2.net.avaya.com ([198.152.12.103]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HE4bo-0002su-69; Mon, 05 Feb 2007 09:14:20 -0500 Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by nj300815-ier2.net.avaya.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id l15EEA5O012391; Mon, 5 Feb 2007 09:14:11 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 5 Feb 2007 16:14:10 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [802.1 - 1512] Draft PAR for PBBTE Thread-Index: AcdJI+LkwjsvIuqJQn6HEuES95aLqQAC8SuA From: "Romascanu, Dan \(Dan\)" To: "IAB" , , "tsvwg" , X-Scanner: InterScan AntiVirus for Sendmail X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: bwijnen@alcatel-lucent.com Subject: [Tsvwg] FW: [802.1 - 1512] Draft PAR for PBBTE 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 believe that this announcement of a new PAR (charter) for discussion in IEEE 802.1 may be of interest.=20 Dan =20 -----Original Message----- From: IEEE 802.1 list HELP only [mailto:hdk-731.q1d4kd0tvk@att.net] On Behalf Of Tony Jeffree Sent: Monday, February 05, 2007 2:32 PM To: STDS-802-1-L@listserv.ieee.org Subject: [802.1 - 1512] Draft PAR for PBBTE Colleauges - 802.1 expect to submit a PAR for Provider Backbone Bridge Traffic Engineering (PBBTE) at the cosing EC meeting in March; the draft PAR and 5C are therefore being circulated under the 30 day rule. The PAR text can be found here: http://www.ieee802.org/1/files/public/docs2007/new-pbbte-draft-par-0207. pdf and the 5C here: http://www.ieee802.org/1/files/public/docs2007/new-pbbte-draft-5c-0207.p df Regards, Tony ---- IEEE 802.1 Email List ---- DELETE THIS FOOTER from copies, forwards, & replies. List archives (access-controlled) by date: http://www.ieee802.org/1/private/email2/mail1.html by thread: http://www.ieee802.org/1/private/email2/thrd1.html From tsvwg-bounces@ietf.org Mon Feb 05 09:58:01 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HE5HH-0006IN-SD; Mon, 05 Feb 2007 09:57:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HE5HG-0006I9-71; Mon, 05 Feb 2007 09:57:06 -0500 Received: from lennon.multicasttech.com ([63.105.122.7] helo=multicasttech.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HE5HB-0003KC-Vd; Mon, 05 Feb 2007 09:57:06 -0500 Received: from [63.105.122.7] (account marshall_eubanks HELO [IPv6:::1]) by multicasttech.com (CommuniGate Pro SMTP 3.4.8) with ESMTP-TLS id 6160733; Mon, 05 Feb 2007 09:56:59 -0500 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: <26C4C318-51A7-4AE9-B5AB-A7E4B4CFE1AF@multicasttech.com> Content-Transfer-Encoding: 7bit From: Marshall Eubanks Subject: Re: [Tsvwg] FW: [802.1 - 1512] Draft PAR for PBBTE Date: Mon, 5 Feb 2007 09:56:57 -0500 To: "Romascanu, Dan ((Dan))" X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: new-work@ietf.org, IAB , tsvwg , bwijnen@alcatel-lucent.com, iesg@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 wrapped for me; this thus might be useful http://tinyurl.com/29pokx Marshall On Feb 5, 2007, at 9:14 AM, Romascanu, Dan ((Dan)) wrote: > I believe that this announcement of a new PAR (charter) for > discussion > in IEEE 802.1 may be of interest. > > Dan > > > > > > -----Original Message----- > From: IEEE 802.1 list HELP only [mailto:hdk-731.q1d4kd0tvk@att.net] On > Behalf Of Tony Jeffree > Sent: Monday, February 05, 2007 2:32 PM > To: STDS-802-1-L@listserv.ieee.org > Subject: [802.1 - 1512] Draft PAR for PBBTE > > Colleauges - > > 802.1 expect to submit a PAR for Provider Backbone Bridge Traffic > Engineering (PBBTE) at the cosing EC meeting in March; the draft > PAR and > 5C are therefore being circulated under the 30 day rule. The PAR text > can be found here: > > http://www.ieee802.org/1/files/public/docs2007/new-pbbte-draft- > par-0207. > pdf > > and the 5C here: > > http://www.ieee802.org/1/files/public/docs2007/new-pbbte- > draft-5c-0207.p > df > > Regards, > Tony > > > ---- IEEE 802.1 Email List ---- > DELETE THIS FOOTER from copies, forwards, & replies. > List archives (access-controlled) by date: > http://www.ieee802.org/1/private/email2/mail1.html > by thread: > http://www.ieee802.org/1/private/email2/thrd1.html > > From tsvwg-bounces@ietf.org Mon Feb 05 14:41:53 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HE9hq-0004Nq-4a; Mon, 05 Feb 2007 14:40:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HE9hp-0004Nl-3Y for tsvwg@ietf.org; Mon, 05 Feb 2007 14:40:49 -0500 Received: from smtp4.smtp.bt.com ([217.32.164.151]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HE9hj-00005I-FQ for tsvwg@ietf.org; Mon, 05 Feb 2007 14:40:49 -0500 Received: from i2kc08-ukbr.domain1.systemhost.net ([193.113.197.71]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 5 Feb 2007 19:37:04 +0000 Received: from cbibipnt08.iuser.iroot.adidom.com ([147.149.100.81]) by i2kc08-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.211); Mon, 5 Feb 2007 19:23:43 +0000 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 1170703422100; Mon, 5 Feb 2007 19:23:42 +0000 Received: from mut.jungle.bt.co.uk ([10.215.131.59]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id l15JNdFX021194; Mon, 5 Feb 2007 19:23:41 GMT Message-Id: <5.2.1.1.2.20070205181721.04adc878@pop3.jungle.bt.co.uk> X-Sender: rbriscoe@pop3.jungle.bt.co.uk X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Mon, 05 Feb 2007 19:23:37 +0000 To: Dimitri.Papadimitriou@alcatel-lucent.be From: Bob Briscoe Subject: Re: [Tsvwg] Making draft-davie-ecn-mpls a TSVWG item In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: -1.36 () ALL_TRUSTED X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 X-OriginalArrivalTime: 05 Feb 2007 19:23:43.0459 (UTC) FILETIME=[262B9330:01C7495B] X-Spam-Score: 0.1 (/) X-Scan-Signature: 6ffdee8af20de249c24731d8414917d3 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 Dimitri, I think I now understand your concerns from your latest posting, and hopefully can reassure you... You are concerned that we shouldn't have to put a function into a lower layer (MPLS) that is already in a higher layer (IP). In most cases I would agree with you. Usually a request to do something goes from upper layer to a lower layer. So if IP offers some function and the transport or app asks IP to do it, it should just do it. But ECN is the response, not the request. It's a message that travels upwards, not downwards. It enrichens the response from the lower layers to a request to forward a packet. Instead of the response being inferred from "delivered" or "lost", ECN adds the ability for the lower layers to say, "delivered but congestion approaching". Then we don't have to have drop in order to manage congestion. (Yes, TE also manages congestion without drop, but there are good reasons why ECN is far simpler for fine-grained per-microflow control.) This congestion information is about physical resource depletion. Therefore it effectively rises up through the layers from the very bottom (physical). Indeed, congestion information has to continue to rise up the layers above the transport in some cases (e.g. HTTP's "server busy" at the app layer). Many link technologies are simply point to point, so the IP layer can sufficiently model congestion of these simple links using the length of its queue into the link. But they are the exception, not the rule. Other link layer technologies can involve blocking - where there is a layer 2 network, not just a point-to-point link. For instance an ethernet or MPLS switched network. Or a shared wireless link. If an MPLS switch becomes congested, we want to allow it to say "delivered but congestion approaching" upwards to the layers above. If there's nowhere to say this in the MPLS shim, the MPLS switch has to say it in the IP header. I don't want MPLS switches to have to understand IP. The appropriate place to say this is in the MPLS shim. (Similarly, the IEEE have activities to add ECN to ethernet switches for the same reason.) --------- On the more general point concerning MPLS switches having to do more complicated stuff, the idea of adding ECN is so they have to do less. The idea is to use the ultra-simple AQM algorithms like RED to ship congestion information from LSRs to the edge of the network where more complicated fine-grained per-microflow rate control can be done. Either by the end-points (as in TCP-ECN), or perhaps by edge boxes (as in PCN admission control). OK, MPLS-ECN joins a line of functions that MPLS switches might "do in order that they can do less". E.g. Diffserv was added on the same promise. So this begins to sound like a suspicious excuse... But it may reassure you that, back in 2002, I wrote that only three protocol building blocks are necessary and sufficient to provide QoS: 1) a signalling protocol (e.g. RSVP) 2) per-packet class of service tags (DSCP) 3) per-packet congestion notification (ECN) The list still stands at 3 items in 2007 and I don't expect it to increase any further. Anyway, each vendor can choose whether it adds ECN. (I wouldn't buy from one that didn't though!) So I can assure you we've carefully thought about how this /should/ be done architecturally. We're not just adding kludges. Are you reassured enough to allow ECN-MPLS to become a WG item? Summaries of the above responding to each of your points inline... At 23:17 04/02/2007, Dimitri.Papadimitriou@alcatel-lucent.be wrote: >Bruce Davie >26/01/2007 14:38 > > To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL > cc: tsvwg@ietf.org > Subject: Re: [Tsvwg] Making draft-davie-ecn-mpls a TSVWG >item > >In short, adding more capabilities to MPLS does not negate the >advantages that MPLS brings. > >[dp] that's not the point, you assume that CN is needed hence MPLS >we should incorporate, my point is if the TE mechanisms and the >related operations to MPLS-TE are not enough, then, one should >question their real value and why not just stay w/ the pure-IP >only techniques that are already delivering the goodies required, >indeed, this comes very close to the argument that MPLS is simply >becoming useless ECN is for info to travel upwards through all layers from the very bottom of the stack. >[dp] i don't think i stated that label value independent queuing >shall not be possible on intermediate nodes, the question is why >is there a value to put more functionality on these nodes ? what >i see is that we are lacking proven arguments in that direction ECN is an ultra-simple addition to LSRs that ships congestion info out to where the complex rate control is done at the edges, reducing the need for complex fine-grained (per-flow) QoS functions on LSRs. >[dp] the point is to come at least with one good thing shared by >the whole community - unique reason to put a functionality present >at a higher level down the stack - One good reason: In order for endpoints to manage congestion per flow without /requiring/ drop, you need ultra-simple AQM algorithms at any lower layer forwarding function that could block without the higher layers being aware. Cheers 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 Feb 06 11:20:36 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HET2R-00067o-Qr; Tue, 06 Feb 2007 11:19:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HET2R-00067D-0K for tsvwg@ietf.org; Tue, 06 Feb 2007 11:19:23 -0500 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 1HET2P-0001si-9M for tsvwg@ietf.org; Tue, 06 Feb 2007 11:19:22 -0500 Received: from [139.133.207.152] (dhcp-207-152.erg.abdn.ac.uk [139.133.207.152]) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id l16GJ1Os021194; Tue, 6 Feb 2007 16:19:01 GMT Message-ID: <45C8AA82.9000507@erg.abdn.ac.uk> Date: Tue, 06 Feb 2007 16:19:14 +0000 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: Anders Persson Subject: Re: [Tsvwg] TCP and UDP MIB issues References: <45A68ABA.9070501@sun.com> <45B5E8BD.1080504@erg.abdn.ac.uk> <45BE50C2.2020306@sun.com> In-Reply-To: <45BE50C2.2020306@sun.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-ERG-MailScanner-To: anders.persson@sun.com, gerrit@erg.abdn.ac.uk, gorry@erg.abdn.ac.uk, tsvwg@ietf.org X-Spam-Status: No X-Spam-Score: -2.8 (--) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Cc: gorry Fairhurst , Gerrit Renker , tsvwg@ietf.org 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 I agree these new features could be applicable to UDP-Lite, as well as UDP. The situation is only different in that we are currently seeking to standardise the first MIB for UDP-Lite (preferably simple and therefore more likely to be implemented), whereas the UDP MIB has already been widely deployed. What I do not yet know is whether the best approach is to choose one of these methods (either 2 or 3) for inclusion as an optional part of the proposed UDP-Lite MIB, or whether to await a fix (MIB extension) that could apply equally to UDP-Lite and UDP (giving more consistency). Unless people really need these features urgently for UDP-Lite, I'd suggest a consistent approach is better. Have you thought about bringing the I-D to the TSV WG for discussion at the next IETF, it is often helpful to get feedback on the best way forward from the working groups that maintain the protocols that a MIB relates to. Gorry Anders Persson wrote: > Gorry, > > The same general issue does seem to appear within the UDP-Lite MIB, > which is how to deal with multiple processes using the same UDP-Lite > endpoint. For example, on a system using sockets, you can have one > socket being shared between multiple processes if the creator of the > socket uses fork() to create child processes. However, with the current > MIB it is only possible to associate one processes with an endpoint. > > There are at least four ways this could be addressed: > (1) Use udpliteEndpointInstance to create multiple entries. > Unfortunately, this approach > makes it look like multiple independent endpoints, which might > be a bit deceiving > (2) Make udpliteEndpointProcess part of the INDEX > (3) Create a new Identifier object (like tcpEStatsConnectIdEntry), > which could then be > referenced by other tables. For example, we could then have > udpliteProcessTable > (4) Create udpliteProcessTable that mirrors the INDEX of > udpliteEndpointTable, but adds > udpliteEndpointProcess to the INDEX as well :-( > > My personal choice would be (3), as it allows the MIB to be extended in > the future. > > Cheers, > Anders > > Gorry Fairhurst wrote: > >> >> Generally, the proposed UDP-Lite MIB follows that for UDP (supporting >> both multicast and unicast). It does differ in the udpliteEndpointTable: >> >> http://tools.ietf.org/wg/tsvwg/draft-renker-tsvwg-udplite-mib-01.txt >> >> If there are implications on the UDP-Lite MIB, we'd be pleased to try >> to understand what these are, and any ideas of what we should do. >> >> Best wishes, >> >> Gorry >> > > > From tsvwg-bounces@ietf.org Tue Feb 06 15:51:47 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEXH1-0002DZ-TX; Tue, 06 Feb 2007 15:50:43 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEXGt-0002Br-Hh; Tue, 06 Feb 2007 15:50:36 -0500 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HEXGr-0003OR-6I; Tue, 06 Feb 2007 15:50:35 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id 76BCE2AC83; Tue, 6 Feb 2007 20:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HEXGM-0005Tb-7y; Tue, 06 Feb 2007 15:50:02 -0500 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, 06 Feb 2007 15:50:02 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: tsvwg@ietf.org Subject: [Tsvwg] I-D ACTION:draft-ietf-tsvwg-vpn-signaled-preemption-02.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 : QoS Signaling in a Nested Virtual Private Network Author(s) : F. Baker, P. Bose Filename : draft-ietf-tsvwg-vpn-signaled-preemption-02.txt Pages : 38 Date : 2007-2-6 Some networks require communication between an interior and exterior portion of a VPN or through a concatenation of such networks resulting in a nested VPN, but have sensitivities about what information is communicated across the boundary, especially while providing quality of service to communications with different precedence. This note seeks to outline the issues and the nature of the proposed solutions based on the framework for Integrated Services operation over DiffServ networks as described in RFC 2998 . A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-vpn-signaled-preemption-02.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-vpn-signaled-preemption-02.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-vpn-signaled-preemption-02.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-2-6133741.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-tsvwg-vpn-signaled-preemption-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-tsvwg-vpn-signaled-preemption-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-2-6133741.I-D@ietf.org> --OtherAccess-- --NextPart-- From tsvwg-bounces@ietf.org Tue Feb 06 20:28:57 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEbaY-0003QV-4f; Tue, 06 Feb 2007 20:27:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEbaX-0003OX-7o for tsvwg@ietf.org; Tue, 06 Feb 2007 20:27:09 -0500 Received: from smtp4.smtp.bt.com ([217.32.164.151]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HEbaP-00057A-ET for tsvwg@ietf.org; Tue, 06 Feb 2007 20:27:09 -0500 Received: from i2kc08-ukbr.domain1.systemhost.net ([193.113.197.71]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 7 Feb 2007 01:26:33 +0000 Received: from cbibipnt08.iuser.iroot.adidom.com ([147.149.100.81]) by i2kc08-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.211); Wed, 7 Feb 2007 01:23:04 +0000 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 1170811383620; Wed, 7 Feb 2007 01:23:03 +0000 Received: from mut.jungle.bt.co.uk ([10.86.0.5]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id l171MvoA011893; Wed, 7 Feb 2007 01:23:02 GMT Message-Id: <5.2.1.1.2.20070206141557.028fb6e0@pop3.jungle.bt.co.uk> X-Sender: rbriscoe@pop3.jungle.bt.co.uk X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Wed, 07 Feb 2007 01:22:57 +0000 To: "FLOYD, Sally" , Lars Eggert From: Bob Briscoe Subject: Re: [Tsvwg] HEADS UP: consensus call on draft-floyd-tsvwg-cc-alt In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: -1.36 () ALL_TRUSTED X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 X-OriginalArrivalTime: 07 Feb 2007 01:23:04.0579 (UTC) FILETIME=[84032530:01C74A56] X-Spam-Score: 0.1 (/) X-Scan-Signature: 33cc095b503da4365ce57c727e553cf1 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 Sally, Lars, At 07:40 29/01/2007, Lars Eggert wrote: >the authors of draft-floyd-tsvwg-cc-alt have asked us to adopt the >document as a WG item with a publication target of BCP. > >Please review the document and send your comments to the list no >later than Friday, Feb 9. The doc seems reasonable. We have to be v careful writing these guidelines that aim to constrain future standards activity. I think this one has got the balance about right, except I'm very concerned in a couple of areas: - fairness - constraining 'congestion' control when there's spare capacity The draft could become a WG item so we deal with these issues formally as WG business. However, you might have noticed I'm not at all happy (typical British understatement!) about the prevailing fairness thinking at the IETF. So I'd rather see at least an attempt to try to work out how we might reach consensus on fairness /before/ this becomes a WG item. I believe the above tsvarea-fair I-D showed beyond doubt that comparing flow rates is irrelevant to real-world fairness, because fairness can only be between real-world entities like users, not inanimate objects like flows---users can create any number of flows, for any duration. This cc-alt I-D came out in parallel, so I'd like to hear if I've made any impression yet? Here's two questions as acid-tests of whether the bullets of section 3 will allow the evolution of congestion control that we need to allow: Q1. If I wrote an I-D defining MulTCP, would it satisfy this I-D's fairness criteria? Background: MulTCP effectively behaves like multiple TCPs (w of them) all within one flow ID. MulTCP is an excellent example of a good step towards true fairness between users (along with fairness enforcement). Light users who haven't caused much congestion recently would be able to allow their apps or OS to set the weight (w) of MulTCP high, while heavy users who have caused a lot of congestion recently would have to keep w low (perhaps less than 1). Effectively, each app would behave as if it were running w TCPs. The point I'm making here is that fairness between users (as opposed to between flows) /requires/ the mean rates of flows between different users to all be very different. This isn't a case of two forms of fairness. It's two mutually incompatible positions that cannot both be correct. The IETF cannot use both - it has to decide between them. Another point here is that it's only the dynamics (second order) that the IETF should pronounce on. The IETF should never make pronouncements on acceptable first order comparisons of flow rates. E.g. you would never expect the IETF to say something like * "A Diffserv AF TCP MUST NOT consume >5 x the b/w of a BE TCP flow". So why should this I-D be able to say * "A Diffserv BE TCP MUST NOT consume >1 x the b/w of a BE TCP flow"? How much flows or people are allowed isn't the concern of the IETF and never should be. But even if it was a legitimate IETF concern, constraining flow bandwidth is futile when apps can just open multiple flows. The dynamics /are/ a legitimate IETF concern. MulTCP responds very safely in the face of congestion. MulTCP is no less safe than the multiple TCPs from different apps we have on the Internet today. Why should the problem be any different if MulTCP emulates opening multiple TCPs but happens to label all the packets with the same flow ID? The rate behaviour is exactly the same as if they were w separate TCP flows? Browsers use w=4 already. 20 is just as safe. Or 20,000 for that matter. For instance, imagine two flows are competing through a single bottleneck; a MulTCP with say w=20 and a standard TCP with w=1. For the same congestion, during congestion avoidance the MulTCP (w=20) flow reduces its rate 20 times faster than the TCP (w=1) flow which reduces to 1/2 each congestion event. But the mean rate of the MulTCP will be 20 times higher than the standard TCP (it also increases 20 times faster when there's no congestion). --- Q2. Would PCN (pre-congestion notification) based admission control satisfy these fairness criteria ? Background: PCN flow doesn't usually respond at all to congestion once it's passed admission control. But the admission control decision is still based on the level of congestion at the time. Once admitted, if congestion gets very bad, some flows are kicked out (flow pre-emption), but others continue without changing their rate at all. And the flows can have very different bandwidths to each other and to competing TCP-friendly flows. So the draft needs to clarify that each flow doesn't have to respond to congestion as long as the system as a whole does. This also requires some clarification within bullet (5) on full back-off to avoid congestion collapse. The whole point of some congestion control schemes is to ensure some flows don't have to back-off, as long as others do. --- In summary on fairness, the wording of section 3 bullets (1)&(6) on fairness are problematic. The title of (1) talks of "Fairness to standard TCP, SCTP and DCCP". And the body of the bullet talks of N flows using 1/N of network capacity. Similarly, bullet (6) says a proposal should explore how bandwidth is shared among competing flows. The only interpretation of all this is that fairness is being judged in terms of flows being fair to other flows, measured by their rate. I think I've successfully argued that fairness can only be between users (or equivalent), not flows. Yes, TCP, SCTP etc are accepted standardised approaches, but that doesn't make them anything to do with any accepted definition of fairness in the real world. So it cannot make sense to constrain future authors to be fair to these things. I'm trying to make a path to evolve us out of this kooky corner we're in. Not collapsing further into it. I haven't seen any defence of why it's still appropriate for the IETF to judge fairness using flow rates, either on this list or TSV-AREA. So this cc-alt I-D either needs to acknowledge that a major U-turn on fairness is required, or someone should construct an argument for flow rate fairness before continuing to use it in this I-D. Before this draft expects to become a WG item, I'd prefer to see the two offending bullets (1) & (6) re-worded to solely talk about dynamics, removing any reference to first order comparisons of flow rates. --- Moving on from fairness, Bullet (2) presents a different problem. It seems to muddle a scenario where there is spare capacity with one where there was spare capacity but there isn't any more. As soon as there isn't spare capacity (even instantaneously), the system moves to a position where fairness becomes a concern (wihch should be covered by reworded bullets 1 or 6). While there is spare capacity, that implies no-one wants any more than they are using, so it shouldn't concern them that someone else takes more (unless we want to condone envy for the sake of it). It might conceivably concern a network operator, perhaps trying to make people pay more for free beer, I suppose. But that doesn't seem to be a practice that the IETF needs to concern itself with. I would certainly avoid writing any words constraining future congestion control schemes when there isn't congestion. That would go way beyond necessary constraints. I don't see any need for this bullet at all, that isn't already covered by (1) or (6). --- Lastly, how about an extra bullet?: * New cc proposals should explain how the protocol avoids loss of congestion event information (e.g. NACKs or congestion reports might get lost etc). --- Nits Abstract "...possible ramifications to both the network and to traffic using ... congestion control." I don't think you mean this. The network you are talking about /is/ other traffic - you don't need to say both. I assume you don't mean excess congestion might damage the equipment! Sec3.(1) DCCP isn't really in the same set as TCP & SCTP. Better to say "TCP, SCTP and any of the DCCP congestion control modules". Sec3.(1) I don't think "network capacity" is really what you mean. It should be resource capacity really. Otherwise, all the other sections are very good advice. Cheers 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 Feb 08 15:24:50 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFFo3-0003Bk-QX; Thu, 08 Feb 2007 15:23:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFFo3-0003Bf-51 for tsvwg@ietf.org; Thu, 08 Feb 2007 15:23:47 -0500 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 1HFFnt-00021T-Bb for tsvwg@ietf.org; Thu, 08 Feb 2007 15:23:47 -0500 Received: from [10.0.1.2] (maxp31.dialup.abdn.ac.uk [139.133.201.190]) (authenticated bits=0) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id l18KMq8p025807 (version=TLSv1/SSLv3 cipher=DES-CBC3-SHA bits=168 verify=NOT); Thu, 8 Feb 2007 20:23:02 GMT User-Agent: Microsoft-Entourage/11.2.5.060620 Date: Thu, 08 Feb 2007 20:23:00 +0000 From: Gorry Fairhurst To: "tsvwg@ietf.org" Message-ID: Thread-Topic: draft-floyd-tsvwg-cc-alt - Call for WG adoption Thread-Index: AcdLvu1FK6N9EreyEduDCQAKlc/qXg== 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-ERG-MailScanner-To: floyd@icir.org, mallman@icir.org, tsvwg@ietf.org X-Spam-Status: No X-Spam-Score: -2.4 (--) X-Scan-Signature: b22590c27682ace61775ee7b453b40d3 Cc: Sally Floyd , "mallman@icir.org" Subject: [Tsvwg] draft-floyd-tsvwg-cc-alt - Call for WG adoption 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 think this is useful, and support its adoption as a working group item intended for BCP publication. It could be worth writing about is the different aspects of this problem space. These are different, and raise issues with different communities. For instance we have views: * traditionally flows need to be controlled, but applications have spanned multiple flows to "modify" the intended behaviour, for good and bad reasons. * some think that end-host traffic need need to be controlled (rather than transport flows) - need to accommodate multi-homed hosts, multi-user systems ... * it's also possible to control traffic through edge routers, some are more concerned about mis-behaving "local" routers and end hosts to protect the service of other local users (e.g. ECN NONCE). It could also be useful to outline background: * End-hosts need to implement congestion-control to behave as responsible systems in the Internet, routers can assist in this role. * Some congestion-control algorithms introduce incentives for end hosts to cheat (not respond appropriately) to attempt to gain a larger share of the capacity along the Internet Path. * Not all paths are equal (in terms of loss, capacity, delay, delay variation, etc), and this can result in very different shares, even though intuitively this may seem unfair or be unexpected by a user. * The security implications of congestion control algorithms also need to be considered, and methods found to mitigate the effects of third-party attacks. * This problem space is orthogonal to RSVP, DS, etc. Best wishes, Gorry Specific comments follow: ---- Page 3: "The second class is algorithms that, while promising, are not deemed safe enough for deployment on the Internet, but are being specified to facilitate investigations via simulation and testbeds." - "Not deemed safe enough" - This sounds like it could be right, but I'd prefer a clearer distinction between the "deemed safe" case, where there is not currently sufficient understanding for IETF to gain consensus that this is safe. ---- Page 3: "describing environments where the protocol is not recommended for deployment even though it may not be unsafe for use" - The double negative makes this harder to read: "may not be unsafe" does this mean "not necessarily safe"? "not necessarily unsafe"? --- Page 3: Section 3: "As noted above, authors are expected to do a well-rounded evaluations" ^ - Omit "s"? ---- Page 3: Section 3: " should not be used as a check-list." - definitive checklist, i.e., it's fine to check these things, but you may need to do more. ---- Page 4: Point (3) "An assessment of proposed algorithms in difficult environments such as paths containing wireless links and paths with reverse-path congestion." - This is not a sentence, perhaps replace the start by: "The proposed algorithms should be assessed in..." - I'd prefer to be concrete on the sort of path characteristics to examine, there is nothing fundamentally dangerous about using "radio" links:-) - so I suspect readers should look at issues such as "corruption loss, higher delay, variable delay, varying capacity, and the implications of BoD" - in short, the sort of things mentioned in RFC3819. ---- Page 5: Point (7) - In point (7) I found it harder to understand what was envisaged to be assessed. I'd have preferred to have some clearer guidance on the sort of things to consider. * The effect of control packet loss /delay/ordering (in hosts, routers). * The effect of loss of state (e.g. due to a protocol restart at a router, or end host). * Returning control information that does not reflect the actual end host state, from an end host or router participating in the protocol. * The transmission of packets designed to trigger an incorrect response by an end host or router participating in the protocol. - IMHO, the effects could more usefully be split between on-path (above) and the other off-path attacks. * Transmission of packets by third parties (that do not have access to the network packets belonging to the flow) with the object of changing the protocol state. * Denial of service attacks against hosts/routers designed to consume resources and reduce resources available for this and/or other protocols. ---- Page 5: Point (9) "is to be carried out." - I'm not a fan of the words "carried out" could "deployed" or something else be used? ---- Section 5 - Not only should " Alternate congestion control schemes should be mindful of such pitfalls, as well." - they MUST of course examine potential security issues that may arise from their use:-) ---- References - I'm sure you've noted QS is now an RFC:-) - An informative reference to SCTP and DCCP may be useful. From tsvwg-bounces@ietf.org Sat Feb 10 17:41:24 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HG0sn-0006TI-Lm; Sat, 10 Feb 2007 17:39:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HG0sm-0006Rk-Lu for tsvwg@ietf.org; Sat, 10 Feb 2007 17:39:48 -0500 Received: from smtp1.xmundo.net ([201.216.232.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HG0sk-0006i3-WF for tsvwg@ietf.org; Sat, 10 Feb 2007 17:39:48 -0500 Received: from venus.xmundo.net (venus.xmundo.net [201.216.232.56]) by smtp1.xmundo.net (Postfix) with ESMTP id 858D2115BAB5 for ; Sat, 10 Feb 2007 19:39:35 -0300 (ART) Received: from fgont.gont.com.ar (157-184-231-201.fibertel.com.ar [201.231.184.157]) (authenticated bits=0) by venus.xmundo.net (8.12.11.20060308/8.12.11) with ESMTP id l1AMdRSd012723 for ; Sat, 10 Feb 2007 19:39:34 -0300 Message-Id: <7.0.1.0.0.20070210174947.0a7ccec0@gont.com.ar> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Sat, 10 Feb 2007 17:52:18 -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]); Sat, 10 Feb 2007 19:39:34 -0300 (ART) X-Spam-Score: 0.1 (/) X-Scan-Signature: e8c5db863102a3ada84e0cd52a81a79e Subject: [Tsvwg] Fwd: draft-larsen-tsvwg-port-randomization-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 Folks, We received this feedback for our draft=20 draft-larsen-tsvwg-port-randomization-00. We will be addressing these comments in the next=20 revision of the draft, together with other=20 feedback provided by Carlos Pignataro. Any further comments on the draft will be greatly appreciated. >From: Alfred =3D?hp-roman8?B?SM5uZXM=3D?=3D >Subject: draft-larsen-tsvwg-port-randomization-00 >To: michael.vittrup.larsen@ericsson.com, fernando@gont.com.ar >Date: Wed, 10 Jan 2007 17:48:35 +0100 (MEZ) > >Hello, >I've studied your I-D, draft-larsen-tsvwg-port-randomization-00, >and found a few issues worth noting. > > >(1) algorithm flaws > >The stated algorithms do not exactly deliver what the text pretends. > >Section 2.2, Figure 1: > > port =3D min_ephemeral + random() % (max_ephemeral - min_ephemeral) > >Taking 'min_ephemeral' and 'max_ephemeral' literally, >the number of ephemeral ports isn't > max_ephemeral - min_ephemeral , >it is: max_ephemeral - min_ephemeral + 1 !!! > >For use below, take num_ephemeral =3D max_ephemeral - min_ephemeral + 1 > >Hence, *that* should be used as the modulus. > >Similar issues exist in 'Algorithm 1' (Figure 2) and >'Algorithm 2' (Figure 3). > >Algorithm 1 adds "_port" to all "ephemeral" variables and constants; >drop that in favor of the notation in Figure 1 & 3 ! >I'll omit "_port" generally below, for brevity. > > >(2) other sources of pseudorandomness > >At the end of Section 2.2, the draft states: > > Note that on multiuser systems, the function F() could include user > specific information, thereby providing protection not only on a host > to host basis, but on a user to service basis. > >It would be easy to use the 'process ID' or a similar identifier >of the software context here because it has a greater temporal >variability, and hence a greater entropy. > >Also, a high resolution realtime clock could be used easily >(or just the least significant part thereof, e.g. the fractions >of seconds as available in Unix systems etc.); this is equivalent >to extremely rapid rekeying, and would perhaps allow to avoid the >use of the 'secret_key' at all. (Beware, that ought to be kept >secret -- a rather difficult job in practice! The goal is ease >of implementation; therefore this should be considered seriously.) > > >(3) Outdated Reference > >RFC 1750 has long been obsoleted by BCP 106, RFC 4086. >Please changce all occurrences of [RFC1750] appropriately! > > >(4) Further ideas for algorithm improvement > >Saving 'last_ephemeral' instead of 'next_ephemeral' seems to be >more natural, and it avoids to store somewhere a number of potential >value for a Trojan or other Spyware. >Additionally, IMHO, doing so would easily lead to a way to tackle the >subtle matter of loop prevention the draft is so tacitly about 'til now. > >First sketch of modified Algorithm 1 (1bis) : > > last_ephemeral =3D min_ephemeral ; // state variable > > port_t get_ephemeral ( ... ) { > > port_t port =3D last_ephemeral ; > > do { > if ( port =3D=3D max_ephemeral ) { > port =3D min_ephemeral ; > } else { > port++ ; > } > } until ( port =3D=3D last_ephemeral || (four-tuple is unique)) > > if ( port =3D=3D last_ephemeral ) { > return ERROR ; > } else { > last_ephemeral =3D port ; > return port ; > } > >First sketch of a variant (2bis) of Algorithm 2 , using internally >port numbers offset by -min_ephemeral, and assuming F() !=3D 0 : > > last_ephemeral =3D 0 ; // state variable -- truly: a port offset > > port_t get_ephemeral ( ... ) { > > port_t port ; > port_t portdif =3D last_ephemeral ; > port_t offset =3D F ( ... ) ; > > do while () { > portdif =3D ( portdif + offset ) % num_ephemeral ; > if ( portdif =3D=3D last_ephemeral ) { > return ERROR ; > } else { > port =3D min_ephemeral + portdif ; > if ( four-tuple with port is unique) break ; > } > } > last_ephemeral =3D portdif ; > return port ; > } > >Algorithm 1bis is exhaustive. Contrary to that, >Algorithm 2bis might miss an available four-tuple if > gcd ( offset, num_ephemeral ) !=3D 1 > >Another variant (2ter) of Algorithm 2 , using internally >port numbers offset by -min_ephemeral : > > last_ephemeral =3D 0 ; // state variable -- truly: a port offset > > port_t get_ephemeral ( ... ) { > > port_t port ; > port_t portdif =3D ( last_ephemeral + F(...) ) % num_ephemeral ; > port_t test_ephemeral =3D portdif ; > > do while () { > if ( portdif =3D=3D num_ephemeral ) { > portdif =3D 0 ; > } else { > portdif++ ; > } > if ( portdif =3D=3D test_ephemeral ) { > return ERROR ; > } else { > port =3D min_ephemeral + portdif ; > if ( four-tuple with port is unique) break ; > } > } > last_ephemeral =3D portdif ; > return port ; > >That's exhaustive again, but less elegant, and it doesn't spread >so well the port numbers returned. > > >Best 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 | >+------------------------+--------------------------------------------+ -- 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 Sun Feb 11 11:58:03 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HGI0b-00013D-Ka; Sun, 11 Feb 2007 11:57:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HGI0a-0000nS-03 for tsvwg@ietf.org; Sun, 11 Feb 2007 11:57:00 -0500 Received: from smtp1.xmundo.net ([201.216.232.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HGI08-00065D-MS for tsvwg@ietf.org; Sun, 11 Feb 2007 11:56:34 -0500 Received: from venus.xmundo.net (venus.xmundo.net [201.216.232.56]) by smtp1.xmundo.net (Postfix) with ESMTP id 6BD17F0C43A for ; Sun, 11 Feb 2007 13:56:05 -0300 (ART) Received: from fgont.gont.com.ar (157-184-231-201.fibertel.com.ar [201.231.184.157]) (authenticated bits=0) by venus.xmundo.net (8.12.11.20060308/8.12.11) with ESMTP id l1BGu4KG027256 for ; Sun, 11 Feb 2007 13:56:04 -0300 Message-Id: <200702111656.l1BGu4KG027256@venus.xmundo.net> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sun, 11 Feb 2007 13:55:36 -0300 To: tsvwg@ietf.org From: Fernando Gont 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]); Sun, 11 Feb 2007 13:56:05 -0300 (ART) X-Spam-Score: 0.1 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Subject: [Tsvwg] Revision of the port randomization draft 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, We have published a revision of our port randomization draft (draft-larsen-tsvwg-port-randomization). This version addresses feedback from Alfred Hoenes and Carlos Pignataro, and feedback from a fruitful talk with FreeBSD's Mike Silbersack. The draft is available at http://www.gont.com.ar/drafts/port-randomization/draft-larsen-tsvwg-port-randomization-01.txt , and will soon be available at the usual places. Any feedback will be more than welcome. Thanks! -- 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 Mon Feb 12 06:07:14 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HGZ0N-0003OZ-2z; Mon, 12 Feb 2007 06:05:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HGZ0K-0003Lb-UL for tsvwg@ietf.org; Mon, 12 Feb 2007 06:05:52 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HGZ0J-0000nz-Iu for tsvwg@ietf.org; Mon, 12 Feb 2007 06:05:52 -0500 Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 12 Feb 2007 12:05:51 +0100 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l1CB5omP014638; Mon, 12 Feb 2007 12:05:50 +0100 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l1CB5YCE023108; Mon, 12 Feb 2007 12:05:50 +0100 (MET) Received: from xfe-ams-331.emea.cisco.com ([144.254.231.72]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 12 Feb 2007 12:05:37 +0100 Received: from [10.0.0.3] ([10.61.65.131]) by xfe-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 12 Feb 2007 12:05:37 +0100 In-Reply-To: <45B87D4C.7050403@gmx.net> References: <45B87D4C.7050403@gmx.net> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <029F6AA3-A8C5-410B-8E93-4E1B9E9AED67@cisco.com> Content-Transfer-Encoding: 7bit From: Francois Le Faucheur IMAP Subject: Re: [Fwd: [Tsvwg] WG: Question regarding draft-ietf-tsvwg-rsvp-ipsec] Date: Mon, 12 Feb 2007 12:03:37 +0100 To: Hannes Tschofenig X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 12 Feb 2007 11:05:37.0551 (UTC) FILETIME=[B9AC29F0:01C74E95] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1117; t=1171278351; x=1172142351; c=relaxed/simple; s=amsdkim1002; 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[Fwd=3A=20[Tsvwg]=20WG=3A=20Question=20regarding=20dr aft-ietf-tsvwg-rsvp-ipsec] |Sender:=20; bh=jfsaoJTNsFv7bUy7WWxYYluz1zcCUWxENadBMdJHa70=; b=wLlQ0URXo+D8fy2HHuf/6BATV29KdQF/zktmQeFXxMaFQBvNm7ylELAk3gcQ47GiqxMZteLD avjbM54LJUfbidlhR74MhAXdCwRAD+/TJCekKvGYNZeDA4lXrqltMXrC; Authentication-Results: ams-dkim-1; header.From=flefauch@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: tsvwg 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 Hello Hannes, The key information from data packets signaled in the reservation is . As with RFC2207, the signaled VDestPort (and Extended VDestPort) is not visible inside data packets. As discussed in section 3.1 of rsvp- ipsec, this means that if multiple reservations are established for same and they cross a trust boundary requiring policing, those will be policed together. Cheers Francois PS: sorry for the belated response On 25 Jan 2007, at 10:50, Hannes Tschofenig wrote: > > > -------- Original Message -------- > Subject: [Tsvwg] WG: Question regarding draft-ietf-tsvwg-rsvp-ipsec > Date: Fri, 12 Jan 2007 09:14:24 +0100 > From: Tschofenig, Hannes > To: tsvwg tsvwg > > > Hi all, > My previous work in QoS told me that data packets need to relate > somehow to the information signaled in the QoS signaling messages. > How does the Virtual Destination Port and the Extended Virtual > Destination Port relate to the data traffic? > Ciao > Hannes From tsvwg-bounces@ietf.org Mon Feb 12 14:57:05 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HGhHj-0002mH-CY; Mon, 12 Feb 2007 14:56:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HGhHh-0002m9-WF for tsvwg@ietf.org; Mon, 12 Feb 2007 14:56:22 -0500 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 1HGhHe-0006Sb-Fp for tsvwg@ietf.org; Mon, 12 Feb 2007 14:56:21 -0500 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext11.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l1CJqeGT012622; Mon, 12 Feb 2007 21:52:50 +0200 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 12 Feb 2007 21:55:29 +0200 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 12 Feb 2007 21:55:40 +0200 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); Mon, 12 Feb 2007 21:55:23 +0200 Received: from [206.117.31.195] (daec-linuxvpn05867.americas.nokia.com [10.241.58.67]) by mgw-int01.ntc.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l1CJq73b023445; Mon, 12 Feb 2007 21:52:09 +0200 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-106--270615974; protocol="application/pkcs7-signature" Message-Id: <24F543C1-A813-489B-BA59-36B895371416@nokia.com> From: Lars Eggert Subject: Re: [Tsvwg] HEADS UP: consensus call on draft-floyd-tsvwg-cc-alt Date: Mon, 12 Feb 2007 11:55:12 -0800 To: tsvwg X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 12 Feb 2007 19:55:23.0669 (UTC) FILETIME=[BBACDC50:01C74EDF] X-eXpurgate-Category: 1/0 X-eXpurgate-ID: 149371::070212215250-30D44BB0-2B9D03AD/0-0/0-1 X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Cc: Sally Floyd , Mark Allman 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-106--270615974 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed On 2007-1-28, at 23:40, ext Lars Eggert wrote: > the authors of draft-floyd-tsvwg-cc-alt have asked us to adopt the > document as a WG item with a publication target of BCP. > > Please review the document and send your comments to the list no > later than Friday, Feb 9. My reading of the consensus was that there is significant support for adoption, and several people have also sent constructive feedback on the contents of the documents that the authors should incorporate. Authors, please submit the next version as draft-ietf-tsvwg-cc-alt. Lars --Apple-Mail-106--270615974 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 MBwGCSqGSIb3DQEJBTEPFw0wNzAyMTIxOTU1MTJaMCMGCSqGSIb3DQEJBDEWBBRHAn6aNbxUEhEt H4uHGES5G1FqoTCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIwgYcGCyqGSIb3DQEJEAILMXigdjBiMQsw CQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIw DQYJKoZIhvcNAQEBBQAEggEAYRX+yX+xAPb+G1Ho+N198FtA2yW0FJsKF+uDafRYYXO8FQMMhPdC j84Pmsdz8qzDg+4GzMe6VI6nhWGnGNB08ZKG9R3/ZjsUz2Ycxdwegz/lZZLljertK1sOS3yoLiY8 5Q3zzgsQpbhSXqcLyRN9LDw8LuJ658WB1iJN0mB126Isikh43u3bF1cu+vPidrBnV1GVXqaEN+Am BzrhG7UGURygAwBVAFnj0eoJ5adNVZBDLocWOxEcRFE0LwwULSLRNMCFvbXr3JkuXMwMp0qfjowy 8Q8j2O95cILGE7bkcjBUqhxcGNmZZTVh7XtfNp7ZD9/phkzz99wkZU2ReQBvugAAAAAAAA== --Apple-Mail-106--270615974-- From tsvwg-bounces@ietf.org Wed Feb 14 15:53:10 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHR7L-00004r-Gp; Wed, 14 Feb 2007 15:52:43 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHR5j-00076o-M6; Wed, 14 Feb 2007 15:51:04 -0500 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HHR5j-0008PK-AR; Wed, 14 Feb 2007 15:51:03 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id D34341761B; Wed, 14 Feb 2007 20:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HHR4k-0004Jz-5D; Wed, 14 Feb 2007 15:50:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 14 Feb 2007 15:50:02 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Cc: tsvwg@ietf.org Subject: [Tsvwg] I-D ACTION:draft-ietf-tsvwg-rsvp-ipsec-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 : Generic Aggregate Resource ReSerVation Protocol (RSVP) Reservations Author(s) : F. Le Faucheur, et al. Filename : draft-ietf-tsvwg-rsvp-ipsec-05.txt Pages : 30 Date : 2007-2-14 RFC3175 defines aggregate Resource ReSerVation Protocol (RSVP) reservations allowing resources to be reserved in a Diffserv network for a given Per Hop Behavior (PHB), or given set of PHBs, from a given source to a given destination. RFC3175 also defines how end-to- end RSVP reservations can be aggregated onto such aggregate reservations when transiting through a Diffserv cloud. There are situations where multiple such aggregate reservations are needed for the same source IP address, destination IP address and PHB (or set of PHBs). However, this is not supported by the aggregate reservations defined in RFC3175. In order to support this, the present document defines a more flexible type of aggregate RSVP reservations, referred to as generic aggregate reservation. Multiple such generic aggregate reservations can be established for a given PHB (or set of PHBs) from a given source IP address to a given destination IP address. The generic aggregate reservations may be used to aggregate end-to-end RSVP reservations. This document also defines the procedures for such aggregation. The generic aggregate reservations may also be used end- to-end directly by end-systems attached to a Diffserv network. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-rsvp-ipsec-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-rsvp-ipsec-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-rsvp-ipsec-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-2-14124442.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-tsvwg-rsvp-ipsec-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-tsvwg-rsvp-ipsec-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-2-14124442.I-D@ietf.org> --OtherAccess-- --NextPart-- From tsvwg-bounces@ietf.org Wed Feb 14 16:32:47 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHRjB-0000Gf-Vm; Wed, 14 Feb 2007 16:31:49 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHOoX-00028T-SS for tsvwg@ietf.org; Wed, 14 Feb 2007 13:25:09 -0500 Received: from laposte.rennes.enst-bretagne.fr ([192.44.77.17]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HHOoS-000648-61 for tsvwg@ietf.org; Wed, 14 Feb 2007 13:25:05 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by laposte.rennes.enst-bretagne.fr (8.13.7/8.13.7/2006.08.14) with ESMTP id l1EIOoaU028487; Wed, 14 Feb 2007 19:24:50 +0100 Received: from l2.rennes.enst-bretagne.fr (l2.rennes.enst-bretagne.fr [192.44.77.4]) by laposte.rennes.enst-bretagne.fr (8.13.7/8.13.7/2006.08.14) with ESMTP id l1EIE4Hx027636; Wed, 14 Feb 2007 19:14:04 +0100 Received: from [192.44.77.188] (dhcpe188.rennes.enst-bretagne.fr [192.44.77.188]) (authenticated bits=0) by l2.rennes.enst-bretagne.fr (8.13.1/8.13.1) with ESMTP id l1EIE4CC006591 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 14 Feb 2007 19:14:04 +0100 Mime-Version: 1.0 (Apple Message framework v752.3) References: <45D307BE.4060903@piuha.net> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <12DDA03F-7286-42D8-9987-21389087EE15@enst-bretagne.fr> Content-Transfer-Encoding: 7bit From: Nicolas Montavont Date: Wed, 14 Feb 2007 19:13:45 +0100 To: tsvwg@ietf.org X-Mailer: Apple Mail (2.752.3) X-Virus-Scanned: amavisd-new at enst-bretagne.fr X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da X-Mailman-Approved-At: Wed, 14 Feb 2007 16:31:49 -0500 Cc: magnus.westerlund@ericsson.com, jmpolk@cisco.com, Jari Arkko Subject: [Tsvwg] Fwd: Lifting up a filter discussion from Monami6 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 tsvwg, Within the Internet area, we just launched a discussion about flow distribution over multiple paths, for both Mobile nodes and Mobile routers. This initiative comes from the work being currently done in Monami6 working group. It seems that you have quite extensive knowledge on this topic. You are very welcome to add input to our discussion. Here is the thread initiated by Jari. Please do not hesitate to participate to the discussion by sending comments to int-area@ietf.org. I can also add tsv mailing list into the thread in order to give you the opportunity to follow all the discussion. Regards, Nicolas Begin forwarded message: > > I would like to lift up one issue from the Monami6 WG > to a more general discussion. Monami6 is developing an > extension to Mobile IPv6 / Nemo so that a mobile node could > register its presence in multiple locations simultaneously. > One of things that they expect to be able to do is to control > what traffic goes to what care-of address; this flow to this > address, and the other flow to that other address. Mobile nodes > can obviously decide by themselves what outgoing interface to use. > However, in order for a home agent to deal with return traffic > properly, the mobile node has to tell it what policy to > employ. > > The working group has debated between a number of different > approaches for doing this. In one approach, draft-soliman- > monami6-flow-binding the mobile node adds a filter to a Mobile > IPv6 Binding Update to tell what traffic should use this binding. > Another approach, draft-larsson-monami6-filter-rules, decouples > the policy exchange from the mobility protocol. The policies are > exchanged at a different time (typically earlier) and carried by a > different protocol (in this case over UDP). Yet another draft, > draft-mitsuya-monami6-flow-distribution-policy also separates > the mobility protocol and policy transfer, and carries > the policies in HTTP. > > Monami6 should of course decide how they want to design this. > But this may be an interesting debate from a more generic point > of view. Do we have input for them? For instance, are there needs > in HIP/Shim6/Mobike space for similar functionality? Should the > designs be tailored for each of these situations? Is there some > advantage or disadvantage in looking at a generic solution? > Would a generic solution be doable? > > Without going into too much detail about the specific proposals > it seems that there are actually a number of different topics here: > - carrier protocol choice > - policy container format > - timing of the policy exchange > - securing the transfer > - etc > > Thoughts? > > Jari From tsvwg-bounces@ietf.org Wed Feb 14 18:42:30 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHTkf-0006mF-20; Wed, 14 Feb 2007 18:41:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHTkd-0006lx-O1 for tsvwg@ietf.org; Wed, 14 Feb 2007 18:41:27 -0500 Received: from sca-ea-mail-3.sun.com ([192.18.43.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HHTkZ-00078y-9K for tsvwg@ietf.org; Wed, 14 Feb 2007 18:41:27 -0500 Received: from jurassic.eng.sun.com ([129.146.58.166]) by sca-ea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l1ENfEpm025655; Wed, 14 Feb 2007 15:41:14 -0800 (PST) Received: from [129.148.19.52] (punchin-client-129-148-19-52.East.Sun.COM [129.148.19.52]) by jurassic.eng.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l1ENf9J8242579; Wed, 14 Feb 2007 15:41:09 -0800 (PST) Message-ID: <45D39CEB.5040704@sun.com> Date: Wed, 14 Feb 2007 15:36:11 -0800 From: Anders Persson User-Agent: Thunderbird 1.5.0.8 (X11/20061204) MIME-Version: 1.0 To: gorry@erg.abdn.ac.uk Subject: Re: [Tsvwg] TCP and UDP MIB issues References: <45A68ABA.9070501@sun.com> <45B5E8BD.1080504@erg.abdn.ac.uk> <45BE50C2.2020306@sun.com> <45C8AA82.9000507@erg.abdn.ac.uk> In-Reply-To: <45C8AA82.9000507@erg.abdn.ac.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: Gerrit Renker , 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 Gorry Fairhurst wrote: > > I agree these new features could be applicable to UDP-Lite, as well as > UDP. The situation is only different in that we are currently seeking > to standardise the first MIB for UDP-Lite (preferably simple and > therefore more likely to be implemented), whereas the UDP MIB has > already been widely deployed. > > What I do not yet know is whether the best approach is to choose one > of these methods (either 2 or 3) for inclusion as an optional part of > the proposed UDP-Lite MIB, or whether to await a fix (MIB extension) > that could apply equally to UDP-Lite and UDP (giving more > consistency). Unless people really need these features urgently for > UDP-Lite, I'd suggest a consistent approach is better. If there was consensus that it is a real problem and an agreed upon solution existed, I would suggest including the fix. But right now we have neither, so taking the "consistent approach" might be the right thing to do. > > > Have you thought about bringing the I-D to the TSV WG for discussion > at the next IETF, it is often helpful to get feedback on the best way > forward from the working groups that maintain the protocols that a MIB > relates to. I will try to get a (short) slot for the next meeting. Regards, Anders > Gorry > > Anders Persson wrote: > >> Gorry, >> >> The same general issue does seem to appear within the UDP-Lite MIB, >> which is how to deal with multiple processes using the same UDP-Lite >> endpoint. For example, on a system using sockets, you can have one >> socket being shared between multiple processes if the creator of the >> socket uses fork() to create child processes. However, with the >> current MIB it is only possible to associate one processes with an >> endpoint. >> >> There are at least four ways this could be addressed: >> (1) Use udpliteEndpointInstance to create multiple entries. >> Unfortunately, this approach >> makes it look like multiple independent endpoints, which >> might be a bit deceiving >> (2) Make udpliteEndpointProcess part of the INDEX >> (3) Create a new Identifier object (like tcpEStatsConnectIdEntry), >> which could then be >> referenced by other tables. For example, we could then have >> udpliteProcessTable >> (4) Create udpliteProcessTable that mirrors the INDEX of >> udpliteEndpointTable, but adds >> udpliteEndpointProcess to the INDEX as well :-( >> >> My personal choice would be (3), as it allows the MIB to be extended >> in the future. >> >> Cheers, >> Anders >> >> Gorry Fairhurst wrote: >> >>> >>> Generally, the proposed UDP-Lite MIB follows that for UDP >>> (supporting both multicast and unicast). It does differ in the >>> udpliteEndpointTable: >>> >>> http://tools.ietf.org/wg/tsvwg/draft-renker-tsvwg-udplite-mib-01.txt >>> >>> If there are implications on the UDP-Lite MIB, we'd be pleased to >>> try to understand what these are, and any ideas of what we should do. >>> >>> Best wishes, >>> >>> Gorry >>> >> >> >> > From tsvwg-bounces@ietf.org Sat Feb 17 06:07:00 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HINN7-0003bs-Rw; Sat, 17 Feb 2007 06:04:53 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HINN5-0003bn-SY for tsvwg@ietf.org; Sat, 17 Feb 2007 06:04:51 -0500 Received: from adsl-070-155-160-098.sip.cae.bellsouth.net ([70.155.160.98] helo=lakerest.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HINN4-0000rs-GI for tsvwg@ietf.org; Sat, 17 Feb 2007 06:04:51 -0500 Received: from [127.0.0.1] (localhost [127.0.0.1]) by lakerest.net (8.13.6/8.13.6) with ESMTP id l1HB4gia097799; Sat, 17 Feb 2007 06:04:45 -0500 (EST) (envelope-from randall@lakerest.net) DKIM-Signature: a=rsa-sha1; c=simple/simple; d=lakerest.net; s=lakerest; t=1171710285; h=Message-ID:Date:From:User-Agent:MIME-Version:To:CC: Subject:References:In-Reply-To:Content-Type: Content-Transfer-Encoding; b=Zqrt2egqmG/st95ddEg5n4cVHpxdZI5H5cQmx4 7g5AfdLXjUm/rkMeI5mtxDWcnlWr24xNJEqA6tR3bPVbzt6g== Message-ID: <45D6E12D.1020402@lakerest.net> Date: Sat, 17 Feb 2007 06:04:13 -0500 From: Randall Stewart User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.8) Gecko/20061029 FreeBSD/i386 SeaMonkey/1.0.6 MIME-Version: 1.0 To: Michael Welzl Subject: Re: [Tsvwg] Separate header checksums and WiFi References: <1170256466.4805.614.camel@lap10-c703.uibk.ac.at> In-Reply-To: <1170256466.4805.614.camel@lap10-c703.uibk.ac.at> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d 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 Michael Welzl wrote: > > I'm sending this note to TCPM, TSVWG and DCCP because there > are similar mechanisms there (DCCP: the Data Checksum option; SCTP: > http://www.ietf.org/internet-drafts/draft-stewart-sctp-pktdrprep-06.txt > although I just noticed that this is apparently not a WG item... > still, it's SCTP related). > > Michael: One comment on the above... the pktdrp document deals not with checksums getting to or not getting to transport.. It is designed to interact with a cisco product that runs over satellite networks. Where the router learns that some packet was dropped and what it sends back to the SCTP sender is the whole intact packet that it could not get through the satellite link. aka SCTP --->- R1 ///// satelink //// R2 --->- SCTP It is R1 that has a copy of the packet, and realizes it had a corruption over the link between R1 <-> R2. and R1 then sends back the notification. If R2 sent back the notification then we would see a similar thing as in your testing... R -- Randall Stewart 803-345-0369 815-342-5222(cell) From tsvwg-bounces@ietf.org Sat Feb 17 18:28:59 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HIYxO-0006H2-Op; Sat, 17 Feb 2007 18:27:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HIYxN-0006Gx-FQ for tsvwg@ietf.org; Sat, 17 Feb 2007 18:27:05 -0500 Received: from smtpout.mac.com ([17.250.248.176]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HIYxK-00055w-VU for tsvwg@ietf.org; Sat, 17 Feb 2007 18:27:05 -0500 Received: from mac.com (smtpin04-en2 [10.13.10.149]) by smtpout.mac.com (Xserve/8.12.11/smtpout06/MantshX 4.0) with ESMTP id l1HNQu2W013279; Sat, 17 Feb 2007 15:26:56 -0800 (PST) Received: from [192.168.1.64] (adsl-70-231-251-107.dsl.snfc21.sbcglobal.net [70.231.251.107]) (authenticated bits=0) by mac.com (Xserve/smtpin04/MantshX 4.0) with ESMTP id l1HNQnOj006229; Sat, 17 Feb 2007 15:26:51 -0800 (PST) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v624) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <1fa75fc67f559d8541c1bb33421593ed@mac.com> Content-Transfer-Encoding: 7bit From: Sally Floyd Subject: Re: [Tsvwg] draft-floyd-tsvwg-cc-alt - Call for WG adoption Date: Sat, 17 Feb 2007 15:26:49 -0800 To: Gorry Fairhurst X-Mailer: Apple Mail (2.624) X-Brightmail-Tracker: AAAAAA== X-Brightmail-scanned: yes X-Spam-Score: 0.0 (/) X-Scan-Signature: 31b28e25e9d13a22020d8b7aedc9832c Cc: Transport WG , Mark Allman 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 - > I think this is useful, and support its adoption as a working group > item > intended for BCP publication. As always, many thanks for the feedback! > It could be worth writing about is the different aspects of this > problem > space. These are different, and raise issues with different > communities. For > instance we have views: > > * traditionally flows need to be controlled, but applications have > spanned > multiple flows to "modify" the intended behaviour, for good and bad > reasons. > * some think that end-host traffic need need to be controlled (rather > than > transport flows) - need to accommodate multi-homed hosts, multi-user > systems > ... > * it's also possible to control traffic through edge routers, some are > more > concerned about mis-behaving "local" routers and end hosts to protect > the > service of other local users (e.g. ECN NONCE). I didn't add this, because it seemed to me that it belonged to a different document. > It could also be useful to outline background: > > * End-hosts need to implement congestion-control to behave as > responsible > systems in the Internet, routers can assist in this role. > * Some congestion-control algorithms introduce incentives for end > hosts to > cheat (not respond appropriately) to attempt to gain a larger share of > the > capacity along the Internet Path. > * Not all paths are equal (in terms of loss, capacity, delay, delay > variation, etc), and this can result in very different shares, even > though > intuitively this may seem unfair or be unexpected by a user. > * The security implications of congestion control algorithms also need > to be > considered, and methods found to mitigate the effects of third-party > attacks. > * This problem space is orthogonal to RSVP, DS, etc. I added some of this in pointers to other documents, e.g., RFC 2914, and the TMRG documents. ... > Specific comments follow: > > ---- > Page 3: > "The second class is algorithms > that, while promising, are not deemed safe enough for deployment > on > the Internet, but are being specified to facilitate investigations > via simulation and testbeds." > > - "Not deemed safe enough" > - This sounds like it could be right, but I'd prefer a clearer > distinction > between the "deemed safe" case, where there is not currently sufficient > understanding for IETF to gain consensus that this is safe. Thanks. Done. > ---- > Page 3: > > "describing environments where the protocol > is not recommended for deployment even though it may not be unsafe > for use" > > - The double negative makes this harder to read: "may not be unsafe" > does > this mean "not necessarily safe"? "not necessarily unsafe"? Done. > --- > Page 3: Section 3: > "As noted above, authors are expected to do a well-rounded > evaluations" > ^ > - Omit "s"? Done. > ---- > Page 3: Section 3: > " should not be used as a > check-list." > > - definitive checklist, i.e., it's fine to check these things, but you > may > need to do more. Yep, done. > ---- > Page 4: Point (3) > "An assessment of proposed algorithms in difficult environments > such as paths containing wireless links and paths with > reverse-path congestion." > > - This is not a sentence, perhaps replace the start by: "The proposed > algorithms should be assessed in..." > - I'd prefer to be concrete on the sort of path characteristics to > examine, > there is nothing fundamentally dangerous about using "radio" links:-) > - so I suspect readers should look at issues such as "corruption loss, > higher delay, variable delay, varying capacity, and the implications > of BoD" > - in short, the sort of things mentioned in RFC3819. All done. > ---- > Page 5: Point (7) > - In point (7) I found it harder to understand what was envisaged to be > assessed. I'd have preferred to have some clearer guidance on the sort > of > things to consider. > > * The effect of control packet loss /delay/ordering (in hosts, > routers). > * The effect of loss of state (e.g. due to a protocol restart at a > router, > or end host). > * Returning control information that does not reflect the actual end > host > state, from an end host or router participating in the protocol. > * The transmission of packets designed to trigger an incorrect > response by > an end host or router participating in the protocol. > > - IMHO, the effects could more usefully be split between on-path > (above) and > the other off-path attacks. > > * Transmission of packets by third parties (that do not have access to > the > network packets belonging to the flow) with the object of changing the > protocol state. > * Denial of service attacks against hosts/routers designed to consume > resources and reduce resources available for this and/or other > protocols. I didn't add all this, but I did add a discussion of RFC 4782 (Quick-Start), as an example. > ---- > Page 5: Point (9) > "is to be carried out." > > - I'm not a fan of the words "carried out" could "deployed" or > something > else be used? I left it, but added another sentence for clarity. > ---- > Section 5 > > - Not only should " Alternate congestion control schemes should be > mindful > of such pitfalls, as well." - they MUST of course examine potential > security > issues that may arise from their use:-) Yep. Added. > ---- > References > - I'm sure you've noted QS is now an RFC:-) > - An informative reference to SCTP and DCCP may be useful. Yep, done. Again, many many thanks. - Sally http://www.icir.org/floyd/ From tsvwg-bounces@ietf.org Mon Feb 19 12:23:17 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJCDv-0003d2-Fn; Mon, 19 Feb 2007 12:22:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJCDt-0003aD-TI for tsvwg@ietf.org; Mon, 19 Feb 2007 12:22:45 -0500 Received: from smtp1.smtp.bt.com ([217.32.164.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HJCDm-000320-D6 for tsvwg@ietf.org; Mon, 19 Feb 2007 12:22:45 -0500 Received: from i2kc08-ukbr.domain1.systemhost.net ([193.113.197.71]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 19 Feb 2007 17:22:22 +0000 Received: from cbibipnt08.iuser.iroot.adidom.com ([147.149.100.81]) by i2kc08-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.211); Mon, 19 Feb 2007 17:20:51 +0000 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 1171905649287; Mon, 19 Feb 2007 17:20:49 +0000 Received: from mut.jungle.bt.co.uk ([10.86.0.193]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id l1JHKRwF006125; Mon, 19 Feb 2007 17:20:40 GMT Message-Id: <5.2.1.1.2.20070219165634.046f4c40@pop3.jungle.bt.co.uk> X-Sender: rbriscoe@pop3.jungle.bt.co.uk X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Mon, 19 Feb 2007 17:20:24 +0000 To: Lars EGGERT , Magnus WESTERLUND , James POLK From: Bob Briscoe Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: -1.36 () ALL_TRUSTED X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 X-OriginalArrivalTime: 19 Feb 2007 17:20:51.0502 (UTC) FILETIME=[4DECB4E0:01C7544A] X-Spam-Score: 0.1 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: tsvwg Subject: [Tsvwg] planned -00 I-Ds 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, Magnus, James, I notice the deadline for notifying you guys of planned w-g draft-00 I-Ds is today. This reminded me that I should let you know the personal -00 drafts I'm planning (with various co-authors) that are relevant to twvwg and/or transport area more generally, just to prevent surprises. * Transport layer test for receiver cheating (imminent posting - prob TSVWG, but may be TCPM - awaiting co-chair advice) * Bit and packet congestion notification (when and how to take packet size into account - affects DCCP-voip draft) * Re-ECN: architectural intent (I'm planning a Bar BoF to present this) Others I doubt I'll get time for, but they're on my schedule so you may see something appear: * Setting ECN field at the start of a tunnel (minor update to RFC3168 to align with how IPSec now does it) * General guidelines on passing up congestion notification from lower layers 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 Feb 19 12:31:40 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJCLu-0001og-2d; Mon, 19 Feb 2007 12:31:02 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJCLs-0001ob-A9 for tsvwg@ietf.org; Mon, 19 Feb 2007 12:31:00 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HJCLp-0004cm-VJ for tsvwg@ietf.org; Mon, 19 Feb 2007 12:31:00 -0500 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-5.cisco.com with ESMTP; 19 Feb 2007 09:30:58 -0800 X-IronPort-AV: i="4.14,191,1170662400"; d="scan'208"; a="390741207:sNHT76866414" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l1JHUuVc006370; Mon, 19 Feb 2007 09:30:56 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l1JHUkV0002798; Mon, 19 Feb 2007 09:30:47 -0800 (PST) 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, 19 Feb 2007 09:30:44 -0800 Received: from jmpolk-wxp.cisco.com ([10.21.122.35]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 19 Feb 2007 09:30:43 -0800 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 19 Feb 2007 11:30:42 -0600 To: Bob Briscoe , Lars EGGERT , Magnus WESTERLUND From: "James M. Polk" In-Reply-To: <5.2.1.1.2.20070219165634.046f4c40@pop3.jungle.bt.co.uk> References: <5.2.1.1.2.20070219165634.046f4c40@pop3.jungle.bt.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: X-OriginalArrivalTime: 19 Feb 2007 17:30:44.0013 (UTC) FILETIME=[AF16B5D0:01C7544B] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1316; t=1171906256; x=1172770256; 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:=20Re=3A=20planned=20-00=20I-Ds |Sender:=20; bh=YF5A+KV0Y/LiIdv/544OHejp3Eb0JvByPAsftVtC2bA=; b=UPtmFuROiEYmq5QUTJxxOlEMD1KJXhINFXIvhrfw/1vIm8nwp8wqUANL3reQNUnoDxYzcirD k3b0xVNtCMlMQhou75MzkWNz+i1pqfoNd1DYDUfdsu3jRjHhJl5HR/Vc; 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: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: tsvwg Subject: [Tsvwg] Re: planned -00 I-Ds 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 We appreciate the early notice Thanks James At 11:20 AM 2/19/2007, Bob Briscoe wrote: >Lars, Magnus, James, > >I notice the deadline for notifying you guys of planned w-g draft-00 >I-Ds is today. > >This reminded me that I should let you know the personal -00 drafts >I'm planning (with various co-authors) that are relevant to twvwg >and/or transport area more generally, just to prevent surprises. > >* Transport layer test for receiver cheating > (imminent posting - prob TSVWG, but may be TCPM - awaiting co-chair advice) >* Bit and packet congestion notification > (when and how to take packet size into account - affects DCCP-voip draft) >* Re-ECN: architectural intent > (I'm planning a Bar BoF to present this) > >Others I doubt I'll get time for, but they're on my schedule so you >may see something appear: > >* Setting ECN field at the start of a tunnel > (minor update to RFC3168 to align with how IPSec now does it) >* General guidelines on passing up congestion notification from lower layers > > >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 Feb 20 15:39:21 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJbkW-0005fJ-PF; Tue, 20 Feb 2007 15:38:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJbkV-0005e9-9Z for tsvwg@ietf.org; Tue, 20 Feb 2007 15:38:07 -0500 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 1HJbkU-00071o-0G for tsvwg@ietf.org; Tue, 20 Feb 2007 15:38:07 -0500 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-3.cisco.com with ESMTP; 20 Feb 2007 12:38:04 -0800 X-IronPort-AV: i="4.14,197,1170662400"; d="scan'208"; a="465813251:sNHT59636548" 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 l1KKc3AO003020 for ; Tue, 20 Feb 2007 12:38:03 -0800 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 l1KKc3Dk011793 for ; Tue, 20 Feb 2007 12:38:03 -0800 (PST) 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); Tue, 20 Feb 2007 12:38:03 -0800 Received: from jmpolk-wxp.cisco.com ([10.21.97.200]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Feb 2007 12:38:02 -0800 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 20 Feb 2007 14:38:01 -0600 To: tsvwg From: "James M. Polk" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: X-OriginalArrivalTime: 20 Feb 2007 20:38:02.0838 (UTC) FILETIME=[045D0F60:01C7552F] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=866; t=1172003883; x=1172867883; 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:=20TSVWG=20call=20for=20presentation=20timeslots=20in=20Prague |Sender:=20; bh=Q8dAfC22FAImy9othxqjBRpiGGt+1mPdkGOCmvoEojE=; b=GJNX9a5Vrlp/+qJtPFCAr/9jqQRc+Kuq8dDOPCucBMAr1CvjyHfrwqdILnPyUDiQMllwCLQ/ MNDcwFWWHuyuB4pyKC4gp9cJjeQP8BjI9+d7MLHBXT9dCkx/PCh2RwUG; 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: 2409bba43e9c8d580670fda8b695204a Subject: [Tsvwg] TSVWG call for presentation timeslots in Prague 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 This is a request for anyone wanting to discuss a TSVWG related ID during the meeting we have coming up in Prague next month. Please indicate to me the following: - what ID you want to discuss (by filename) - the link to the file - who is the point of contact for the ID - please indicate how long you would prefer to talk ( this will be adjusted based on how many presentations there are) - who is the identified presenter during the meeting I'd like to have this list completed for scheduling by March 5th (the date -0X versions are due). NOTE: for new ideas (meaning -00 individual submissions), the ADs have the right to move a presentation to the TSV-Area meeting, if it is better suited for that audience cheers, James Lars Magnus IETF TSVWG co-chairs From tsvwg-bounces@ietf.org Wed Feb 21 10:51:31 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJtkU-00005h-2g; Wed, 21 Feb 2007 10:51:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJtjV-0006Z1-9A; Wed, 21 Feb 2007 10:50:17 -0500 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HJtjU-0004kN-5U; Wed, 21 Feb 2007 10:50:17 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id 9D94626ED1; Wed, 21 Feb 2007 15:50:15 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HJtjT-0008UF-HU; Wed, 21 Feb 2007 10:50:15 -0500 X-test-idtracker: no From: The IESG To: IETF-Announce Message-Id: Date: Wed, 21 Feb 2007 10:50:15 -0500 X-Spam-Score: -2.8 (--) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: tsvwg chair , Internet Architecture Board , tsvwg mailing list , RFC Editor Subject: [Tsvwg] Protocol Action: 'Generic Aggregate Resource ReSerVation Protocol (RSVP) Reservations' 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: - 'Generic Aggregate Resource ReSerVation Protocol (RSVP) Reservations ' as a Proposed Standard This document is the product of the Transport Area Working Group Working Group. The IESG contact persons are Magnus Westerlund and Lars Eggert. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-rsvp-ipsec-05.txt Technical Summary RFC 3175 defines aggregate RSVP reservations allowing resources to be reserved in a Diffserv network for a given DSCP from a given source to a given destination. RFC 3175 also defines how end-to-end RSVP reservations can be aggregated onto such aggregate reservations when transiting through a Diffserv cloud. There are situations where multiple such aggregate reservations are needed for the same source IP address, destination IP address and DSCP. However, this is not supported by the aggregate reservations defined in RFC 3175. In order to support this capability, the present document defines a more flexible type of aggregate RSVP reservations, referred to as generic aggregate reservation. Multiple such generic aggregate reservations can be established for a given DSCP from a given source IP address to a given destination IP address. The generic aggregate reservations may be used to aggregate end-to-end RSVP reservations. This document also defines the procedures for such aggregation. The generic aggregate reservations may also be used end-to-end directly by end-systems attached to a Diffserv network. Working Group Summary There is consensus in the WG to publish this document. It has been reviewed by several people prior to the WG last call. Comments raised have been addressed. Protocol Quality This document has been well reviewed in the WG and comments raised has been addressed. Responsible AD was Magnus Westerlund. WG PROTO shepherd was James Polk. Last call comments in the IETF last call has been addressed. From tsvwg-bounces@ietf.org Wed Feb 21 21:21:10 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HK3ZP-0006zo-Jt; Wed, 21 Feb 2007 21:20:31 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HK3ZM-0006yq-Iu; Wed, 21 Feb 2007 21:20:28 -0500 Received: from nit.isi.edu ([128.9.160.116]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HK3ZG-0005wh-4C; Wed, 21 Feb 2007 21:20:23 -0500 Received: from nit.isi.edu (loopback [127.0.0.1]) by nit.isi.edu (8.12.11.20060308/8.12.11) with ESMTP id l1M2KHJV023936; Wed, 21 Feb 2007 18:20:17 -0800 Received: (from apache@localhost) by nit.isi.edu (8.12.11.20060308/8.12.11/Submit) id l1M2KHEK023935; Wed, 21 Feb 2007 18:20:17 -0800 Date: Wed, 21 Feb 2007 18:20:17 -0800 Message-Id: <200702220220.l1M2KHEK023935@nit.isi.edu> To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org X-Spam-Score: -14.8 (--------------) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Cc: tsvwg@ietf.org, rfc-editor@rfc-editor.org Subject: [Tsvwg] RFC 4804 on Aggregation of Resource ReSerVation Protocol (RSVP) Reservations over MPLS TE/DS-TE Tunnels 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 A new Request for Comments is now available in online RFC libraries. RFC 4804 Title: Aggregation of Resource ReSerVation Protocol (RSVP) Reservations over MPLS TE/DS-TE Tunnels Author: F. Le Faucheur, Ed. Status: Standards Track Date: February 2007 Mailbox: flefauch@cisco.com Pages: 31 Characters: 69473 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-tsvwg-rsvp-dste-05.txt URL: http://www.rfc-editor.org/rfc/rfc4804.txt RFC 3175 specifies aggregation of Resource ReSerVation Protocol (RSVP) end-to-end reservations over aggregate RSVP reservations. This document specifies aggregation of RSVP end-to-end reservations over MPLS Traffic Engineering (TE) tunnels or MPLS Diffserv-aware MPLS Traffic Engineering (DS-TE) tunnels. This approach is based on RFC 3175 and simply modifies the corresponding procedures for operations over MPLS TE tunnels instead of aggregate RSVP reservations. This approach can be used to achieve admission control of a very large number of flows in a scalable manner since the devices in the core of the network are unaware of the end-to-end RSVP reservations and are only aware of the MPLS TE tunnels. [STANDARDS TRACK] This document is a product of the Transport Area Working Group Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements.Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. The RFC Editor Team USC/Information Sciences Institute ... From tsvwg-bounces@ietf.org Thu Feb 22 12:35:40 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HKHpt-00056q-SS; Thu, 22 Feb 2007 12:34:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HKHps-00056h-LI; Thu, 22 Feb 2007 12:34:28 -0500 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 1HKHpr-0004xq-6w; Thu, 22 Feb 2007 12:34:28 -0500 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext11.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l1MHUNxE022102; Thu, 22 Feb 2007 19:30:30 +0200 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 22 Feb 2007 19:34:07 +0200 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 22 Feb 2007 19:34:08 +0200 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, 22 Feb 2007 19:34:08 +0200 Received: from [172.21.34.242] (esdhcp034242.research.nokia.com [172.21.34.242]) by mgw-int02.ntc.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l1MHVVgW016084; Thu, 22 Feb 2007 19:31:31 +0200 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-4-584914650; protocol="application/pkcs7-signature" Message-Id: From: Lars Eggert Date: Thu, 22 Feb 2007 19:34:02 +0200 To: TSV Area X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 22 Feb 2007 17:34:08.0533 (UTC) FILETIME=[A83B3C50:01C756A7] X-eXpurgate-Category: 1/0 X-eXpurgate-ID: 149371::070222193030-4D957BB0-5FE5BBCE/0-0/0-1 X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: tmrg-interest@ICSI.Berkeley.EDU, iccrg@cs.ucl.ac.uk, tsvwg WG , tsv-chairs@ietf.org Subject: [Tsvwg] TSVAREA presentation slots for Prague X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: tsv-ads@tools.ietf.org List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tsvwg-bounces@ietf.org --Apple-Mail-4-584914650 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Hi, please send agenda requests for TSVAREA in Prague to tsv- ads@tools.ietf.org, including: title/topic presenter requested time The purpose of the TSVAREA meeting is to inform about and discuss important issues, developments and work within the transport area or outside work that impacts the transport area. In contrast to TSVWG, TSVAREA does not produce any documents. TSVAREA can include tutorial- style talks on tranport topics, maybe based on related IRTF or other research work. Again, we encourage relevant presentations from both within the transport area and from outside parties, such as other IETF WGs or the IRTF. Thanks, Lars --Apple-Mail-4-584914650 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 MBwGCSqGSIb3DQEJBTEPFw0wNzAyMjIxNzM0MDNaMCMGCSqGSIb3DQEJBDEWBBQ/+sTLBrePqFTH qVXLXhumIQmpJDCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIwgYcGCyqGSIb3DQEJEAILMXigdjBiMQsw CQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIw DQYJKoZIhvcNAQEBBQAEggEAIl6FPThZwY4EUCU3mzLEWWGCAQwj9sLz3UJh3iWlyaod7t8SWQbP G04vwrimlpItfH+2YB1dBxerA67ikRbC/msclm3xBamRvsaCZ7IK/JeChvqIpAjg550o3O7139Iv vTITDzJbPvayUZjb+tRzSM75yqBl4Sp1J7xkesuYLdg7lq0PED6SM43f7zwNTu/sb5b2yGgRannv M6BbfxHG6gJx3NvIrM3EoqDGF5fUHV4JWf2YXC+Ad8UQrmbyo58ZeN3S0OdXx820TdLE+2Z6g8d6 YRSwgoRkrDCb0qFcU2HS8oH4iG4jiJ5fGsTdvIEV9uQUjN+KeSXHdCAcHeIjQwAAAAAAAA== --Apple-Mail-4-584914650-- From tsvwg-bounces@ietf.org Thu Feb 22 18:13:38 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HKN6v-0006Kk-Qx; Thu, 22 Feb 2007 18:12:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HKN6u-0006Kf-Nn for tsvwg@ietf.org; Thu, 22 Feb 2007 18:12:24 -0500 Received: from smtpout.mac.com ([17.250.248.185]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HKN6s-0004sf-5R for tsvwg@ietf.org; Thu, 22 Feb 2007 18:12:24 -0500 Received: from mac.com (smtpin07-en2 [10.13.10.152]) by smtpout.mac.com (Xserve/8.12.11/smtpout15/MantshX 4.0) with ESMTP id l1MNCEgn028413; Thu, 22 Feb 2007 15:12:16 -0800 (PST) Received: from [192.168.1.64] (adsl-70-231-231-10.dsl.snfc21.sbcglobal.net [70.231.231.10]) (authenticated bits=0) by mac.com (Xserve/smtpin07/MantshX 4.0) with ESMTP id l1MNC5qH004078; Thu, 22 Feb 2007 15:12:09 -0800 (PST) In-Reply-To: <5.2.1.1.2.20070206141557.028fb6e0@pop3.jungle.bt.co.uk> References: <5.2.1.1.2.20070206141557.028fb6e0@pop3.jungle.bt.co.uk> Mime-Version: 1.0 (Apple Message framework v624) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Sally Floyd Subject: Re: [Tsvwg] HEADS UP: consensus call on draft-floyd-tsvwg-cc-alt Date: Thu, 22 Feb 2007 15:12:02 -0800 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: 848ed35f2a4fc0638fa89629cb640f48 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 Bob - My apologies for not getting to your email earlier. > The doc seems reasonable. We have to be v careful writing these > guidelines that aim to constrain future standards activity. I think > this one has got the balance about right, except I'm very concerned in > a couple of areas: > - fairness > - constraining 'congestion' control when there's spare capacity > > The draft could become a WG item so we deal with these issues formally > as WG business. However, you might have noticed > I'm not at all happy (typical British > understatement!) about the prevailing fairness thinking at the IETF. > So I'd rather see at least an attempt to try to work out how we might > reach consensus on fairness /before/ this becomes a WG item. > > I believe the above tsvarea-fair I-D showed beyond doubt that > comparing flow rates is irrelevant to real-world fairness, because > fairness can only be between real-world entities like users, not > inanimate objects like flows---users can create any number of flows, > for any duration. This cc-alt I-D came out in parallel, so I'd like to > hear if I've made any impression yet? Well, the I-D is aimed not at the next generation Internet, but at the current, real-world Internet, where there are many congested links that aren't covered by ingress and egress access routers legislating for fairness. And in this world, for traffic that could traverse these congested links, I believe that it is necessary for transport protocols to provide some form of per-flow fairness. As we state in draft-floyd-tsvwg-cc-alt. Yes, I know about "The Amorphous Problem of Fairness", which I discussed in Section 3.3 of RFC 3714 back in March 2004, and I know about the well-known problems about the granularity of a flow that I discussed in Section 3.2 on "Fairness" in RFC 2914 in September 2000. I have never claimed that per-flow fairness was perfect. Just that it was necessary, for best-effort traffic. My bottom line about per-flow fairness is that it is a little like democracy: "It has been said that democracy is the worst form of government except all the others that have been tried." - Sir Winston Churchill. > Here's two questions as acid-tests of whether the bullets of section 3 > will allow the evolution of congestion control that we need to allow: > > Q1. If I wrote an I-D defining MulTCP, would it satisfy this I-D's > fairness criteria? Like much else, draft-floyd-tsvwg-cc-alt leaves such decisions as judgement calls, that would have to be made by the IETF at the time. I personally wouldn't consider the fairness of MulTCP as sufficient fairness for best effort traffic to receive a sentence in the abstract saying that "this is considered ok for widespread deployment as best-effort traffic in the current Interent". Other people might call it differently, who knows? ... > The point I'm making here is that fairness between users (as opposed > to between flows) /requires/ the mean rates of flows between different > users to all be very different. This isn't a case of two forms of > fairness. It's two mutually incompatible positions that cannot both be > correct. The IETF cannot use both - it has to decide between them. What, you are planning on having a flag day, when all links not covered for fairness between users, as opposed to fairness between flows, are required to be turned off? And all transport protocols that deliver some form of fairness between flows, instead of fairness between users, are not allowed to transmit packets on the Internet? Really? I don't think that Internet evolution works that way. Another alternative would be that the IETF could have one set of standards for best-effort traffic, and other standards for traffic other than best effort. That is, the IETF could require per-flow fairness for transport protocols used for connections when it is possible that some congested link on the end-to-end path is not protected by some other mechanism (i.e., diffserv, intserv, some other QoS, fairness enforced by ingress and egress routers, or whatever.) That is what would make sense to me. I will add a sentence to draft-floyd-tsvwg-cc-alt clarifying that some of its concerns only apply to best-effort traffic. > The dynamics /are/ a legitimate IETF concern. MulTCP responds very > safely in the face of congestion. MulTCP is no less safe than the > multiple TCPs from different apps we have on the Internet today. Why > should the problem be any different if MulTCP emulates opening > multiple TCPs but happens to label all the packets with the same flow > ID? The rate behaviour is exactly the same as if they were w separate > TCP flows? Browsers use w=4 already. 20 is just as safe. Or 20,000 for > that matter. I happen to disagree. I think that an end-node opening 20,000 concurrent flows, as best-effort traffic with no other guarantees or protection about available bandwidth, could be causing very bad packet loss rates for the competing traffic in the Internet. The good news is that a concerned router in the Internet could detect this and take some protective action. And a vendor that designed its web browser this way, opening 20,000 concurrent flows as a default behavior for best-effort traffic, would have to answer to the considered views of the rest of the Internet community. ... > Q2. Would PCN (pre-congestion notification) based admission control > satisfy these fairness criteria > ? I think of PCN as a form of QoS protection (at least for some of the links on the end-to-end path - I forget if it covers all of them). So I would say that some parts of draft-floyd-tsvwg-cc-alt don't necessarily apply to traffic covered by PCN, since some parts of draft-tsvwg-cc-alt only apply for best-effort traffic. ... > I haven't seen any defence of why it's still appropriate for the IETF > to judge fairness using flow rates, either on this list or TSV-AREA. > So this cc-alt I-D either needs to acknowledge that a major U-turn on > fairness is required, or someone should construct an argument for flow > rate fairness before continuing to use it in this I-D. I obviously don't believe that the IETF should throw out flow rate fairness for best effort traffic, so I will say so more explicitly in draft-floyd-tsvwg-cc-alt. .. > While there is spare capacity, that implies no-one wants any more than > they are using, so it shouldn't concern them that someone else takes > more (unless we want to condone envy for the sake of it). It might > conceivably concern a network operator, perhaps trying to make people > pay more for free beer, I suppose. But that doesn't seem to be a > practice that the IETF needs to concern itself with. I would leave bullet (2) about "Using Spare Capacity" in. It was motivated by Quick-Start, whose entire purpose is to use spare capacity. It was also motivated by High-Speed TCP, which had as a motivation using spare capacity. I think it is worthwhile that say that successfully using space capacity is a good thing, but it doesn't eliminate the requirement for fairness. ... > Lastly, how about an extra bullet?: > > * New cc proposals should explain how the protocol avoids loss of > congestion event information (e.g. NACKs or congestion reports might > get lost etc). I think that is covered already in bullets (1), (2), and (5). If the protocol can't avoid the loss of congestion event information, then it can't provide either fairness or protection against congestion collapse. > Nits Thanks, I will take care of them. (I should say that I haven't passed this answer by my co-author, Mark Allman, so he could have different opinions about things...) - Sally http://www.icir.org/floyd/ From tsvwg-bounces@ietf.org Fri Feb 23 16:37:26 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HKi6H-0007Ap-LS; Fri, 23 Feb 2007 16:37:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HKi6G-00078h-73 for tsvwg@ietf.org; Fri, 23 Feb 2007 16:37:08 -0500 Received: from smtp1.smtp.bt.com ([217.32.164.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HKi65-0000KA-N8 for tsvwg@ietf.org; Fri, 23 Feb 2007 16:37:08 -0500 Received: from i2kc08-ukbr.domain1.systemhost.net ([193.113.197.71]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 23 Feb 2007 21:36:56 +0000 Received: from cbibipnt08.iuser.iroot.adidom.com ([147.149.100.81]) by i2kc08-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.1830); Fri, 23 Feb 2007 21:36:56 +0000 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 1172266615241; Fri, 23 Feb 2007 21:36:55 +0000 Received: from mut.jungle.bt.co.uk ([10.215.131.59]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id l1NLapBK015979; Fri, 23 Feb 2007 21:36:54 GMT Message-Id: <5.2.1.1.2.20070223011554.0357f330@pop3.jungle.bt.co.uk> X-Sender: rbriscoe@pop3.jungle.bt.co.uk X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Fri, 23 Feb 2007 21:36:53 +0000 To: Sally Floyd From: Bob Briscoe Subject: Re: [Tsvwg] HEADS UP: consensus call on draft-floyd-tsvwg-cc-alt In-Reply-To: References: <5.2.1.1.2.20070206141557.028fb6e0@pop3.jungle.bt.co.uk> <5.2.1.1.2.20070206141557.028fb6e0@pop3.jungle.bt.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: -1.36 () ALL_TRUSTED X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 X-OriginalArrivalTime: 23 Feb 2007 21:36:56.0814 (UTC) FILETIME=[BE0440E0:01C75792] X-Spam-Score: 0.1 (/) X-Scan-Signature: 031b5f42d6d2cd097710e6b68613cb36 Cc: tsvwg , Mark ALLMAN 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 Sally, I've added Mark to the distr. more inline... At 23:12 22/02/2007, Sally Floyd wrote: >Bob - > >My apologies for not getting to your email earlier. > >>The doc seems reasonable. We have to be v careful writing these >>guidelines that aim to constrain future standards activity. I think this >>one has got the balance about right, except I'm very concerned in a >>couple of areas: >>- fairness >>- constraining 'congestion' control when there's spare capacity >> >>The draft could become a WG item so we deal with these issues formally as >>WG business. However, you might have noticed >> I'm not at all happy (typical British >>understatement!) about the prevailing fairness thinking at the IETF. So >>I'd rather see at least an attempt to try to work out how we might reach >>consensus on fairness /before/ this becomes a WG item. >> >>I believe the above tsvarea-fair I-D showed beyond doubt that comparing >>flow rates is irrelevant to real-world fairness, because fairness can >>only be between real-world entities like users, not inanimate objects >>like flows---users can create any number of flows, for any duration. This >>cc-alt I-D came out in parallel, so I'd like to hear if I've made any >>impression yet? > >Well, the I-D is aimed not at the next generation Internet, but at the >current, real-world Internet, where there >are many congested links that aren't covered by ingress and egress access >routers legislating for fairness. And in this world, >for traffic that could traverse these congested links, I believe that it >is necessary for transport protocols to provide some form >of per-flow fairness. As we state in draft-floyd-tsvwg-cc-alt. When people are proved incorrect, they are meant to stop saying the incorrect thing. That's how we reach consensus. Rather than just asserting there is merit in carrying on regardless (just like this whole sorry story has carried on for 9yrs since Kelly proved it wrong), please can we see an argument against the points in my I-D, before we discuss putting anything more about fairness in any RFCs. Let's please just accept that the form of fairness you and many many others have defended throughout your careers isn't actually any form of fairness at all.{*} Then we can have a proper debate about where we should go from here. This isn't personal - it may seem recently I'm been jibing at you personally but that's because I usually say nothing when I agree (which is most of the time). My issue is with an idea that has been held much more widely than just you personally of course, but at last more and more people are abandoning it. In fact, I greatly admire everything you have done for the Internet, but on this one point on fairness, I'm not saying anything you did was wrong at the time, but it's actually been a mirage. The reason this needs facing now is that this whole flow rate fairness charade is stopping progress. It used to provide some degree of restraint among those that didnt' understand. But the world is way beyond that now. I don't believe pretending TCP is fair is achieving anything useful any more. What we do have is a definition of fairness where allocations maximise global utility. And it is likely that any other reasonable fairness definitions will result in allocations close to this. When two flows happen to run at the same rate through the same bottleneck, in 99.9999% of cases this situation will be extremely unfair by this definition, when taken in the context of what has gone before, and what the same user is doing on other unrelated routers not even on this path. This is mostly because flows that go on thousands of times longer than other flows are effectively allocated thousands of times more resources. On the basis that TCP's allocations might then be thousands of times different from those that would maximise utility, two things can be concluded: - because the fairness outcome is completely arbitrary, depending on parameters TCP doesn't control, TCP can't claim to produce a fairness outcome - the outcome that happens to result isn't even close to 'reasonable' anyway. But, as long as apps are using some form of TCP-like congestion control /dynamics/, the Internet is at least safe even though it's not fair. >Yes, I know about "The Amorphous Problem of Fairness", which I discussed >in Section 3.3 of RFC 3714 back in March 2004, >and I know about the well-known problems about the granularity of a flow >that I discussed in Section 3.2 on "Fairness" in RFC 2914 >in September 2000. Yup, I appreciated these RFCs said these things. I should ref them in the next rev of the fairness draft. >I have never claimed that per-flow fairness was perfect. Just that it was >necessary, for best-effort traffic. How can per-flow fairness, which is actually unfairness by all 'reasonable' definitions, be necessary? I'm afraid, this isn't just a minor point. It really does need a re-think of everything ever said about TCP fairness. It cannot go on any longer without a proper case being made for why we should pretend it's fair when it isn't. >My bottom line about per-flow fairness is that it is a little like democracy: >"It has been said that democracy is the worst form of government except >all the others that have been tried." - Sir Winston Churchill. It's not a form of government at all. It doesn't govern anything. It's complete anarchy, but TCP (and MulTCP) is at least *safe*. >>Here's two questions as acid-tests of whether the bullets of section 3 >>will allow the evolution of congestion control that we need to allow: >> >>Q1. If I wrote an I-D defining MulTCP, would it satisfy this I-D's >>fairness criteria? > >Like much else, draft-floyd-tsvwg-cc-alt leaves such decisions as >judgement calls, that would have to be made >by the IETF at the time. I personally wouldn't consider the fairness of >MulTCP as sufficient fairness for best effort >traffic to receive a sentence in the abstract saying that "this is >considered ok for widespread deployment as best-effort >traffic in the current Interent". Other people might call it differently, >who knows? > >... >>The point I'm making here is that fairness between users (as opposed to >>between flows) /requires/ the mean rates of flows between different users >>to all be very different. This isn't a case of two forms of fairness. >>It's two mutually incompatible positions that cannot both be correct. The >>IETF cannot use both - it has to decide between them. > >What, you are planning on having a flag day, when all links not covered >for fairness between users, as opposed to fairness >between flows, are required to be turned off? And all transport protocols >that deliver some form of fairness between flows, >instead of fairness between users, are not allowed to transmit packets on >the Internet? Really? I don't think that Internet >evolution works that way. Perhaps you think I have been irresponsible knocking down the only touchstone we had, before we had anything else to bolster fairness. But I thought about it very hard before going public with that fairness draft. I realised that there is no need for a flag day. Because we aren't transitioning from any form of fairness at all.{*} So any moves towards starting to protect links to ensure fairness between users as opposed to so-called 'fairness' between flows will be an improvement over nothing. Even if we find there's a big security flaw in re-ECN, we won't have lost anything, because we didn't have anything{*} wrt fairness in the first place. The transports that deliver so-called fairness between flows would work just fine, while this new policed environment materialises, because 1-TCP works just as well as w-TCPs in this new environment. Unless the user causes too much congestion over a sustained period, or is running a bot-agent into a DoS attack. Then, if the network operator chooses to, it can bring in some throttling, just like the vast majority of ISPs are doing already to heavy users (at least over here in Europe they are). But with congestion information, they will be able to throttle much more fairly than they can now. And they will only need to throttle packets running into congested paths (e.g. DoS attacks). The user will still be able to run flows into low congestion paths perfectly fast. A lot of ISPs are using volume as a metric, but volume's a v poor proxy for congestion and therefore fairness. Volume does no harm when there's no congestion and volume at some times or on some paths does a lot more harm than volume at other times or on other paths, depending on how much congestion there is. Worse, plenty of ISPs are throttling traffic based on inferring which apps most often cause congestion, using deep packet inspection. This is why we need to stop pretending TCP fairness is the solution and really face up to the problem properly. We can't blame these people for screwing up the Internet with middleboxes, if we've not done our job properly. >Another alternative would be that the IETF could have one set of standards >for best-effort traffic, and other standards >for traffic other than best effort. That is, the IETF could require >per-flow fairness for transport protocols used for connections >when it is possible that some congested link on the end-to-end path is not >protected by some other mechanism >(i.e., diffserv, intserv, some other QoS, fairness enforced by ingress and >egress routers, or whatever.) That is what would >make sense to me. Actually, I believe it's this alternative model of the world that is /not/ how Internet evolution works. No-one expects the IETF to legislate on the policies you've outlined above, which are about how networks should be operated or used. No-one expects the IETF to legislate on how operators write acceptable use policies, or for that matter how they use Diffserv codepoints, or what they put in SLAs. The IETF is respected for standardising what vendors implement. But no-one expects the IETF to legislate on operational polices. Or how we all use the Internet. That's why, even though the IETF has legislated instantaneous TCP fairness in RFC2581, ISPs still deploy DPI boxes and throttle flows down if the user runs too many TCPs for too long. Do these ISPs make sure these flows comply with RFC2581? No. They deliberately break RFC2581. Because in these cases RFC2581 flows are pushing the system well away from maximum user utility (= max customer value). Why should ISPs comply with an RFC that would push the Internet to a point that massively reduces customer value? That's the message of tussle in cyberspace that you re-inforced yourself in (the excellent) RFC3426. If we're forcing people and businesses into places the market or society doesn't want to go to, we can't be surprised if our rules are broken and ignored. >I will add a sentence to draft-floyd-tsvwg-cc-alt clarifying that some of >its concerns only apply to best-effort traffic. I'm afraid that's not the issue. At the moment TCP is being used within BE to create much better QoS for long lived flows than would be fair. I know this sounds bizarre, but it has to be seen from what fairness /would/ be like if it was 'reasonably' fair. >>The dynamics /are/ a legitimate IETF concern. MulTCP responds very safely >>in the face of congestion. MulTCP is no less safe than the multiple TCPs >>from different apps we have on the Internet today. Why should the problem >>be any different if MulTCP emulates opening multiple TCPs but happens to >>label all the packets with the same flow ID? The rate behaviour is >>exactly the same as if they were w separate TCP flows? Browsers use w=4 >>already. 20 is just as safe. Or 20,000 for that matter. > >I happen to disagree. I think that an end-node opening 20,000 concurrent >flows, as best-effort traffic with no other guarantees >or protection about available bandwidth, could be causing very bad packet >loss rates for the competing traffic in the Internet. The >good news is that a concerned router in the Internet could detect this and >take some protective action. And a vendor that designed >its web browser this way, opening 20,000 concurrent flows as a default >behavior for best-effort traffic, would have to >answer to the considered views of the rest of the Internet community. Of course. My point was that this is already possible on the current Internet. Certainly I agree that a MulTCP API would be misunderstood by many application developers without general deployment of network protections against excess congestion, as above. And, true (as I just said in the version of my fairness presentation I just gave at ICCRG), we shouldn't encourage an API to MulTCP until we have all the standards in place and wide deployment of congestion protections. But that's /not/ because of the potential for an excessively large converged rate. It's because the slow start and back-off behaviour of each of the TCP's in MulTCP would need to be scaled back to not be the same as the back-off behaviour of w TCPs. I certainly agree on that point. But that's the neat thing about putting all the separate flows together. MulTCP only needs one set of back-off probes, not w. This is why I've put an asterisk after a few of the times I've said we have no fairness at all.{*} Because we do have some form of fairness during exponential back-off, and that's important. Related to this, if you search for hints on how to improve BitTorrent performance, you'll get advice to install a patch for WinXP that allows many more half connections to open at one time, then it tells you how to config BitTorrent so it opens many more connections much faster. It also tells you to ignore the warnings from your virus protection software about opening up the number of half-connections allowed. It admits this is the OS's protection against fast-spreading worms but "it doesn't matter" because "you need it for BitTorrent". Also, have you seen Mustang TCP? It's a start-up company aiming to sell a version of TCP that is deliberately unfair to regular TCP flows, for hi-speed video download, etc. This is the reality that ordinary Internet users are used to already. It's not that these folks wouldn't want to be fair if they understood. In fact, I recently picked up a paper about BitTorrent fairness, but it wasn't about fairness to other Internet users, it was about fairness between uploads and downloads within the community of users. Most users are meticulous about fairness within the community, but they really just don't realise how many other users outside their community they are swamping. And why should they? That's our job - they assume the transport must be handling that - why would any lay person imagine it doesn't? Plenty of folks at the IETF but outside the transport area don't understand this themselves, at all. >... >>Q2. Would PCN (pre-congestion notification) based admission control >>satisfy these fairness criteria ? > >I think of PCN as a form of QoS protection (at least for some of the links >on the end-to-end path - I forget if it covers >all of them). So I would say that some parts of draft-floyd-tsvwg-cc-alt >don't necessarily apply to traffic covered by PCN, >since some parts of draft-tsvwg-cc-alt only apply for best-effort traffic. A form of words that distinguishes protected (or perhaps third-party mediated) congestion control from voluntary would be useful, to be able to say what is out of scope. But for what remains in scope---on paths where congestion control is voluntary---I really don't think it is right that the IETF should legislate what is fair. Even if the IETF did legislate, it certainly shouldn't say equal flow rates are fair. The IETF might just as well legislate that causing equal congestion per flow is fair (over the duration of the flow). Instead of just carrying on regardless, it would be progress to debate whose concern fairness should be. I have proposed the IETF should provide the machinery for others to decide on fairness. We need to stop writing RFCs that legislate policies that should be in the hands of others. >... >>I haven't seen any defence of why it's still appropriate for the IETF to >>judge fairness using flow rates, either on this list or TSV-AREA. So this >>cc-alt I-D either needs to acknowledge that a major U-turn on fairness is >>required, or someone should construct an argument for flow rate fairness >>before continuing to use it in this I-D. > >I obviously don't believe that the IETF should throw out flow rate >fairness for best effort traffic, so I will say so >more explicitly in draft-floyd-tsvwg-cc-alt. I obviously differ strongly, because it is actually saying we must have allocations that are very very likely to be extremely unfair (by a scientific definition of the word). >.. >>While there is spare capacity, that implies no-one wants any more than >>they are using, so it shouldn't concern them that someone else takes more >>(unless we want to condone envy for the sake of it). It might conceivably >>concern a network operator, perhaps trying to make people pay more for >>free beer, I suppose. But that doesn't seem to be a practice that the >>IETF needs to concern itself with. > >I would leave bullet (2) about "Using Spare Capacity" in. It was >motivated by Quick-Start, whose entire purpose is to >use spare capacity. It was also motivated by High-Speed TCP, which had as >a motivation using spare capacity. >I think it is worthwhile that say that successfully using space capacity >is a good thing, but it doesn't eliminate the >requirement for fairness. Let's try to untangle what might be the disagreement here. Perhaps, you are thinking of fairness as a rate thing so you have to think of fairness over a duration. I think that's why you aren't able to separate the period when there's spare capacity from when the system spills over into congestion. If instead you think of fairness in terms of volume of congestion caused, there is a very distinct immediate boundary between the two situations. Then fairness becomes irrelevant at every instant when the system is uncongested. But the shares of capacity users have in flight at the instant a resource becomes congested determine how much of the sudden incidence of congestion is attributed to each of them. The relation between the uncongested and congested periods is one of risk of how much congestion traffic in flight will cause before the source gets feedback. Then fairness is very strictly only an issue from the instant congestion starts to the instant it stops - the congested episode. >... >>Lastly, how about an extra bullet?: >> >>* New cc proposals should explain how the protocol avoids loss of >>congestion event information (e.g. NACKs or congestion reports might get >>lost etc). > >I think that is covered already in bullets (1), (2), and (5). If the >protocol can't avoid the loss of congestion event information, >then it can't provide either fairness or protection against congestion >collapse. I strongly believe it would be worth saying this very explicitly, not assume people understand. It is this more than anything that determines whether algorithm behaviour runs to collapse or pulls back from collapse if load suddenly surges. >>Nits > >Thanks, I will take care of them. > >(I should say that I haven't passed this answer by my co-author, Mark >Allman, so he could have different opinions about things...) Cheers 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 Feb 24 01:57:52 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HKqpK-0007jv-QZ; Sat, 24 Feb 2007 01:56:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HKqpI-0007f9-VN for tsvwg@ietf.org; Sat, 24 Feb 2007 01:56:12 -0500 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 1HKqpC-0007S1-Td for tsvwg@ietf.org; Sat, 24 Feb 2007 01:56:12 -0500 Received: from Arjuna (ra-arjuna.erg.abdn.ac.uk [139.133.204.50]) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id l1O6tkrI026247; Sat, 24 Feb 2007 06:55:48 GMT Message-Id: <200702240655.l1O6tkrI026247@erg.abdn.ac.uk> From: "Arjuna Sathiaseelan" To: Date: Sat, 24 Feb 2007 06:55:41 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcdXkthaNX3ARaB3SOuGMTOW66xpHgASi/Ag X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 In-Reply-To: X-ERG-MailScanner: Found to be clean X-ERG-MailScanner-From: arjuna@erg.abdn.ac.uk X-Spam-Status: No X-Spam-Score: -2.8 (--) X-Scan-Signature: d6c15d82a53e26283536b4a751453103 Cc: gorry@erg.abdn.ac.uk Subject: [Tsvwg] RE: HEADS UP: consensus call on draft-floyd-tsvwg-cc-alt 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 Regarding fairness, One question that may sound silly is when we say we should be fair to TCP, should we be fair to which version of TCP? TCP Tahoe, Reno, New Reno, SACK or other versions? I was told that TCP Reno should be the target, but I hear people saying that New Reno, is the most used version of TCP in the Internet! And I strongly believe this is also SUBJECT to change. IMHO, benchmarking fairness with "some" protocol that does not perform well to "certain" conditions is questionable. Another thing we need to note is, that the limitations in the routers (in packets per second or bytes per second etc). So if a protocol "X" sends 4 packets with 1500 byte segments, and a protocol "Y" sends 8 packets with 160 byte packets, and if "a single" router in the path drops packets of "Y" due to the pps limitation causing Y to behave badly, do we say, that protocol "X" is unfair to "Y"? One silly question that still lurks in my mind is, say a protocol "X", does not do slowstart, and sends at a desired rate, but on seeing congestion, reduces the rate accordingly. Is this a "fair" protocol? I think this is definitely better than UDP and when we still have UDP, why not have protocol "X". I know that I will be beaten if I go with this protocol to the IETF :) This is just a novice's point of view, please pardon me if I sounded ignorant, and please do correct me if I am wrong :) -Arjuna -----Original Message----- From: tsvwg-request@ietf.org [mailto:tsvwg-request@ietf.org] Sent: 23 February 2007 21:37 To: tsvwg@ietf.org Subject: tsvwg Digest, Vol 34, Issue 25 Send tsvwg mailing list submissions to tsvwg@ietf.org To subscribe or unsubscribe via the World Wide Web, visit https://www1.ietf.org/mailman/listinfo/tsvwg or, via email, send a message with subject or body 'help' to tsvwg-request@ietf.org You can reach the person managing the list at tsvwg-owner@ietf.org When replying, please edit your Subject line so it is more specific than "Re: Contents of tsvwg digest..." Today's Topics: 1. Re: HEADS UP: consensus call on draft-floyd-tsvwg-cc-alt (Bob Briscoe) ---------------------------------------------------------------------- Message: 1 Date: Fri, 23 Feb 2007 21:36:53 +0000 From: Bob Briscoe Subject: Re: [Tsvwg] HEADS UP: consensus call on draft-floyd-tsvwg-cc-alt To: Sally Floyd Cc: tsvwg , Mark ALLMAN Message-ID: <5.2.1.1.2.20070223011554.0357f330@pop3.jungle.bt.co.uk> Content-Type: text/plain; charset="us-ascii"; format=flowed Sally, I've added Mark to the distr. more inline... At 23:12 22/02/2007, Sally Floyd wrote: >Bob - > >My apologies for not getting to your email earlier. > >>The doc seems reasonable. We have to be v careful writing these >>guidelines that aim to constrain future standards activity. I think this >>one has got the balance about right, except I'm very concerned in a >>couple of areas: >>- fairness >>- constraining 'congestion' control when there's spare capacity >> >>The draft could become a WG item so we deal with these issues formally as >>WG business. However, you might have noticed >> I'm not at all happy (typical British >>understatement!) about the prevailing fairness thinking at the IETF. So >>I'd rather see at least an attempt to try to work out how we might reach >>consensus on fairness /before/ this becomes a WG item. >> >>I believe the above tsvarea-fair I-D showed beyond doubt that comparing >>flow rates is irrelevant to real-world fairness, because fairness can >>only be between real-world entities like users, not inanimate objects >>like flows---users can create any number of flows, for any duration. This >>cc-alt I-D came out in parallel, so I'd like to hear if I've made any >>impression yet? > >Well, the I-D is aimed not at the next generation Internet, but at the >current, real-world Internet, where there >are many congested links that aren't covered by ingress and egress access >routers legislating for fairness. And in this world, >for traffic that could traverse these congested links, I believe that it >is necessary for transport protocols to provide some form >of per-flow fairness. As we state in draft-floyd-tsvwg-cc-alt. When people are proved incorrect, they are meant to stop saying the incorrect thing. That's how we reach consensus. Rather than just asserting there is merit in carrying on regardless (just like this whole sorry story has carried on for 9yrs since Kelly proved it wrong), please can we see an argument against the points in my I-D, before we discuss putting anything more about fairness in any RFCs. Let's please just accept that the form of fairness you and many many others have defended throughout your careers isn't actually any form of fairness at all.{*} Then we can have a proper debate about where we should go from here. This isn't personal - it may seem recently I'm been jibing at you personally but that's because I usually say nothing when I agree (which is most of the time). My issue is with an idea that has been held much more widely than just you personally of course, but at last more and more people are abandoning it. In fact, I greatly admire everything you have done for the Internet, but on this one point on fairness, I'm not saying anything you did was wrong at the time, but it's actually been a mirage. The reason this needs facing now is that this whole flow rate fairness charade is stopping progress. It used to provide some degree of restraint among those that didnt' understand. But the world is way beyond that now. I don't believe pretending TCP is fair is achieving anything useful any more. What we do have is a definition of fairness where allocations maximise global utility. And it is likely that any other reasonable fairness definitions will result in allocations close to this. When two flows happen to run at the same rate through the same bottleneck, in 99.9999% of cases this situation will be extremely unfair by this definition, when taken in the context of what has gone before, and what the same user is doing on other unrelated routers not even on this path. This is mostly because flows that go on thousands of times longer than other flows are effectively allocated thousands of times more resources. On the basis that TCP's allocations might then be thousands of times different from those that would maximise utility, two things can be concluded: - because the fairness outcome is completely arbitrary, depending on parameters TCP doesn't control, TCP can't claim to produce a fairness outcome - the outcome that happens to result isn't even close to 'reasonable' anyway. But, as long as apps are using some form of TCP-like congestion control /dynamics/, the Internet is at least safe even though it's not fair. >Yes, I know about "The Amorphous Problem of Fairness", which I discussed >in Section 3.3 of RFC 3714 back in March 2004, >and I know about the well-known problems about the granularity of a flow >that I discussed in Section 3.2 on "Fairness" in RFC 2914 >in September 2000. Yup, I appreciated these RFCs said these things. I should ref them in the next rev of the fairness draft. >I have never claimed that per-flow fairness was perfect. Just that it was >necessary, for best-effort traffic. How can per-flow fairness, which is actually unfairness by all 'reasonable' definitions, be necessary? I'm afraid, this isn't just a minor point. It really does need a re-think of everything ever said about TCP fairness. It cannot go on any longer without a proper case being made for why we should pretend it's fair when it isn't. >My bottom line about per-flow fairness is that it is a little like democracy: >"It has been said that democracy is the worst form of government except >all the others that have been tried." - Sir Winston Churchill. It's not a form of government at all. It doesn't govern anything. It's complete anarchy, but TCP (and MulTCP) is at least *safe*. >>Here's two questions as acid-tests of whether the bullets of section 3 >>will allow the evolution of congestion control that we need to allow: >> >>Q1. If I wrote an I-D defining MulTCP, would it satisfy this I-D's >>fairness criteria? > >Like much else, draft-floyd-tsvwg-cc-alt leaves such decisions as >judgement calls, that would have to be made >by the IETF at the time. I personally wouldn't consider the fairness of >MulTCP as sufficient fairness for best effort >traffic to receive a sentence in the abstract saying that "this is >considered ok for widespread deployment as best-effort >traffic in the current Interent". Other people might call it differently, >who knows? > >... >>The point I'm making here is that fairness between users (as opposed to >>between flows) /requires/ the mean rates of flows between different users >>to all be very different. This isn't a case of two forms of fairness. >>It's two mutually incompatible positions that cannot both be correct. The >>IETF cannot use both - it has to decide between them. > >What, you are planning on having a flag day, when all links not covered >for fairness between users, as opposed to fairness >between flows, are required to be turned off? And all transport protocols >that deliver some form of fairness between flows, >instead of fairness between users, are not allowed to transmit packets on >the Internet? Really? I don't think that Internet >evolution works that way. Perhaps you think I have been irresponsible knocking down the only touchstone we had, before we had anything else to bolster fairness. But I thought about it very hard before going public with that fairness draft. I realised that there is no need for a flag day. Because we aren't transitioning from any form of fairness at all.{*} So any moves towards starting to protect links to ensure fairness between users as opposed to so-called 'fairness' between flows will be an improvement over nothing. Even if we find there's a big security flaw in re-ECN, we won't have lost anything, because we didn't have anything{*} wrt fairness in the first place. The transports that deliver so-called fairness between flows would work just fine, while this new policed environment materialises, because 1-TCP works just as well as w-TCPs in this new environment. Unless the user causes too much congestion over a sustained period, or is running a bot-agent into a DoS attack. Then, if the network operator chooses to, it can bring in some throttling, just like the vast majority of ISPs are doing already to heavy users (at least over here in Europe they are). But with congestion information, they will be able to throttle much more fairly than they can now. And they will only need to throttle packets running into congested paths (e.g. DoS attacks). The user will still be able to run flows into low congestion paths perfectly fast. A lot of ISPs are using volume as a metric, but volume's a v poor proxy for congestion and therefore fairness. Volume does no harm when there's no congestion and volume at some times or on some paths does a lot more harm than volume at other times or on other paths, depending on how much congestion there is. Worse, plenty of ISPs are throttling traffic based on inferring which apps most often cause congestion, using deep packet inspection. This is why we need to stop pretending TCP fairness is the solution and really face up to the problem properly. We can't blame these people for screwing up the Internet with middleboxes, if we've not done our job properly. >Another alternative would be that the IETF could have one set of standards >for best-effort traffic, and other standards >for traffic other than best effort. That is, the IETF could require >per-flow fairness for transport protocols used for connections >when it is possible that some congested link on the end-to-end path is not >protected by some other mechanism >(i.e., diffserv, intserv, some other QoS, fairness enforced by ingress and >egress routers, or whatever.) That is what would >make sense to me. Actually, I believe it's this alternative model of the world that is /not/ how Internet evolution works. No-one expects the IETF to legislate on the policies you've outlined above, which are about how networks should be operated or used. No-one expects the IETF to legislate on how operators write acceptable use policies, or for that matter how they use Diffserv codepoints, or what they put in SLAs. The IETF is respected for standardising what vendors implement. But no-one expects the IETF to legislate on operational polices. Or how we all use the Internet. That's why, even though the IETF has legislated instantaneous TCP fairness in RFC2581, ISPs still deploy DPI boxes and throttle flows down if the user runs too many TCPs for too long. Do these ISPs make sure these flows comply with RFC2581? No. They deliberately break RFC2581. Because in these cases RFC2581 flows are pushing the system well away from maximum user utility (= max customer value). Why should ISPs comply with an RFC that would push the Internet to a point that massively reduces customer value? That's the message of tussle in cyberspace that you re-inforced yourself in (the excellent) RFC3426. If we're forcing people and businesses into places the market or society doesn't want to go to, we can't be surprised if our rules are broken and ignored. >I will add a sentence to draft-floyd-tsvwg-cc-alt clarifying that some of >its concerns only apply to best-effort traffic. I'm afraid that's not the issue. At the moment TCP is being used within BE to create much better QoS for long lived flows than would be fair. I know this sounds bizarre, but it has to be seen from what fairness /would/ be like if it was 'reasonably' fair. >>The dynamics /are/ a legitimate IETF concern. MulTCP responds very safely >>in the face of congestion. MulTCP is no less safe than the multiple TCPs >>from different apps we have on the Internet today. Why should the problem >>be any different if MulTCP emulates opening multiple TCPs but happens to >>label all the packets with the same flow ID? The rate behaviour is >>exactly the same as if they were w separate TCP flows? Browsers use w=4 >>already. 20 is just as safe. Or 20,000 for that matter. > >I happen to disagree. I think that an end-node opening 20,000 concurrent >flows, as best-effort traffic with no other guarantees >or protection about available bandwidth, could be causing very bad packet >loss rates for the competing traffic in the Internet. The >good news is that a concerned router in the Internet could detect this and >take some protective action. And a vendor that designed >its web browser this way, opening 20,000 concurrent flows as a default >behavior for best-effort traffic, would have to >answer to the considered views of the rest of the Internet community. Of course. My point was that this is already possible on the current Internet. Certainly I agree that a MulTCP API would be misunderstood by many application developers without general deployment of network protections against excess congestion, as above. And, true (as I just said in the version of my fairness presentation I just gave at ICCRG), we shouldn't encourage an API to MulTCP until we have all the standards in place and wide deployment of congestion protections. But that's /not/ because of the potential for an excessively large converged rate. It's because the slow start and back-off behaviour of each of the TCP's in MulTCP would need to be scaled back to not be the same as the back-off behaviour of w TCPs. I certainly agree on that point. But that's the neat thing about putting all the separate flows together. MulTCP only needs one set of back-off probes, not w. This is why I've put an asterisk after a few of the times I've said we have no fairness at all.{*} Because we do have some form of fairness during exponential back-off, and that's important. Related to this, if you search for hints on how to improve BitTorrent performance, you'll get advice to install a patch for WinXP that allows many more half connections to open at one time, then it tells you how to config BitTorrent so it opens many more connections much faster. It also tells you to ignore the warnings from your virus protection software about opening up the number of half-connections allowed. It admits this is the OS's protection against fast-spreading worms but "it doesn't matter" because "you need it for BitTorrent". Also, have you seen Mustang TCP? It's a start-up company aiming to sell a version of TCP that is deliberately unfair to regular TCP flows, for hi-speed video download, etc. This is the reality that ordinary Internet users are used to already. It's not that these folks wouldn't want to be fair if they understood. In fact, I recently picked up a paper about BitTorrent fairness, but it wasn't about fairness to other Internet users, it was about fairness between uploads and downloads within the community of users. Most users are meticulous about fairness within the community, but they really just don't realise how many other users outside their community they are swamping. And why should they? That's our job - they assume the transport must be handling that - why would any lay person imagine it doesn't? Plenty of folks at the IETF but outside the transport area don't understand this themselves, at all. >... >>Q2. Would PCN (pre-congestion notification) based admission control >>satisfy these fairness criteria ? > >I think of PCN as a form of QoS protection (at least for some of the links >on the end-to-end path - I forget if it covers >all of them). So I would say that some parts of draft-floyd-tsvwg-cc-alt >don't necessarily apply to traffic covered by PCN, >since some parts of draft-tsvwg-cc-alt only apply for best-effort traffic. A form of words that distinguishes protected (or perhaps third-party mediated) congestion control from voluntary would be useful, to be able to say what is out of scope. But for what remains in scope---on paths where congestion control is voluntary---I really don't think it is right that the IETF should legislate what is fair. Even if the IETF did legislate, it certainly shouldn't say equal flow rates are fair. The IETF might just as well legislate that causing equal congestion per flow is fair (over the duration of the flow). Instead of just carrying on regardless, it would be progress to debate whose concern fairness should be. I have proposed the IETF should provide the machinery for others to decide on fairness. We need to stop writing RFCs that legislate policies that should be in the hands of others. >... >>I haven't seen any defence of why it's still appropriate for the IETF to >>judge fairness using flow rates, either on this list or TSV-AREA. So this >>cc-alt I-D either needs to acknowledge that a major U-turn on fairness is >>required, or someone should construct an argument for flow rate fairness >>before continuing to use it in this I-D. > >I obviously don't believe that the IETF should throw out flow rate >fairness for best effort traffic, so I will say so >more explicitly in draft-floyd-tsvwg-cc-alt. I obviously differ strongly, because it is actually saying we must have allocations that are very very likely to be extremely unfair (by a scientific definition of the word). >.. >>While there is spare capacity, that implies no-one wants any more than >>they are using, so it shouldn't concern them that someone else takes more >>(unless we want to condone envy for the sake of it). It might conceivably >>concern a network operator, perhaps trying to make people pay more for >>free beer, I suppose. But that doesn't seem to be a practice that the >>IETF needs to concern itself with. > >I would leave bullet (2) about "Using Spare Capacity" in. It was >motivated by Quick-Start, whose entire purpose is to >use spare capacity. It was also motivated by High-Speed TCP, which had as >a motivation using spare capacity. >I think it is worthwhile that say that successfully using space capacity >is a good thing, but it doesn't eliminate the >requirement for fairness. Let's try to untangle what might be the disagreement here. Perhaps, you are thinking of fairness as a rate thing so you have to think of fairness over a duration. I think that's why you aren't able to separate the period when there's spare capacity from when the system spills over into congestion. If instead you think of fairness in terms of volume of congestion caused, there is a very distinct immediate boundary between the two situations. Then fairness becomes irrelevant at every instant when the system is uncongested. But the shares of capacity users have in flight at the instant a resource becomes congested determine how much of the sudden incidence of congestion is attributed to each of them. The relation between the uncongested and congested periods is one of risk of how much congestion traffic in flight will cause before the source gets feedback. Then fairness is very strictly only an issue from the instant congestion starts to the instant it stops - the congested episode. >... >>Lastly, how about an extra bullet?: >> >>* New cc proposals should explain how the protocol avoids loss of >>congestion event information (e.g. NACKs or congestion reports might get >>lost etc). > >I think that is covered already in bullets (1), (2), and (5). If the >protocol can't avoid the loss of congestion event information, >then it can't provide either fairness or protection against congestion >collapse. I strongly believe it would be worth saying this very explicitly, not assume people understand. It is this more than anything that determines whether algorithm behaviour runs to collapse or pulls back from collapse if load suddenly surges. >>Nits > >Thanks, I will take care of them. > >(I should say that I haven't passed this answer by my co-author, Mark >Allman, so he could have different opinions about things...) Cheers 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 End of tsvwg Digest, Vol 34, Issue 25 ************************************* From tsvwg-bounces@ietf.org Wed Feb 28 05:41:33 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMME1-0007ZZ-0t; Wed, 28 Feb 2007 05:39:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMMDz-0007VN-FP for tsvwg@ietf.org; Wed, 28 Feb 2007 05:39:55 -0500 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 1HMMDw-0007cr-Q9 for tsvwg@ietf.org; Wed, 28 Feb 2007 05:39:55 -0500 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 l1SAZPXQ024416 for ; Wed, 28 Feb 2007 12:35:57 +0200 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 28 Feb 2007 12:39:25 +0200 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 28 Feb 2007 12:39:24 +0200 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); Wed, 28 Feb 2007 12:39:24 +0200 Received: from [172.21.34.191] (esdhcp034191.research.nokia.com [172.21.34.191]) by mgw-int01.ntc.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l1SAZTp4007580 for ; Wed, 28 Feb 2007 12:35:29 +0200 Mime-Version: 1.0 (Apple Message framework v752.3) To: tsvwg WG Message-Id: <21B62EB2-7A61-44EA-A346-3C86BCAADD76@nokia.com> Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-38--1069050903; protocol="application/pkcs7-signature" References: From: Lars Eggert Date: Wed, 28 Feb 2007 12:39:20 +0200 X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 28 Feb 2007 10:39:24.0995 (UTC) FILETIME=[B6F72930:01C75B24] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Subject: [Tsvwg] comments wanted: draft-eggert-tsvwg-udp-guidelines 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-38--1069050903 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Hi, Magnus and have recently had a number of discussions with application and application-layer-procotol designers on the use of UDP as a transport protocol. I've tried to write up a pretty short document that intends to give some guidelines to that community on the use of UDP as a transport protocol. I'd be very interested in feedback from the transport community on whether this document is (1) useful and (2) has the correct guidelines. Begin forwarded message: > Title : UDP Usage Guidelines for Application Designers > Author(s) : L. Eggert > Filename : draft-eggert-tsvwg-udp-guidelines-00.txt > Pages : 10 > Date : 2007-2-27 > > 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 a 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. > > http://www.ietf.org/internet-drafts/draft-eggert-tsvwg-udp- > guidelines-00.txt Lars --Apple-Mail-38--1069050903 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 MBwGCSqGSIb3DQEJBTEPFw0wNzAyMjgxMDM5MjFaMCMGCSqGSIb3DQEJBDEWBBT8YE3yAjva8Sx9 tcXrOFKxfPq3QzCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIwgYcGCyqGSIb3DQEJEAILMXigdjBiMQsw CQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIw DQYJKoZIhvcNAQEBBQAEggEAD3YZZ6algRWF9fNyZs/wBNKPL6SvaZK8JzZCh3qYOZgXuF350qLh LeCf8lfMSSnV4Stl5DFAIUn2pqdAZkw8kihJzwhwDf4vE+RsxVOKAkw6EBf8BEW+rN4sjmmH84zC tQ6Xa29Pg4tJVuORRd5rQaa4yfLU+vnsffSi245Hq7EDud7yzQVKymHiYvXLivNtuxaBW1Dqhim2 ywE1TQJGzqg19GTmFaR7dKyuPvQxdplD/OurPDbLwHKijSeP/XmeVwtPinsaEv7BfLQcQL9nSy7D JzF05o2BgaNLalW0cRr0CYrVlRC8J/rPT0Fa8ofdmTkyxdr/uXrawUzXOEv98AAAAAAAAA== --Apple-Mail-38--1069050903-- From tsvwg-bounces@ietf.org Wed Feb 28 06:55:36 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMNNT-0002yz-MK; Wed, 28 Feb 2007 06:53:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMNNS-0002yu-IA for tsvwg@ietf.org; Wed, 28 Feb 2007 06:53:46 -0500 Received: from smtp1.smtp.bt.com ([217.32.164.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HMNNL-0007wi-5X for tsvwg@ietf.org; Wed, 28 Feb 2007 06:53:46 -0500 Received: from i2kc08-ukbr.domain1.systemhost.net ([193.113.197.71]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 28 Feb 2007 11:53:38 +0000 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, 28 Feb 2007 11:53:37 +0000 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 1172663616105; Wed, 28 Feb 2007 11:53:36 +0000 Received: from mut.jungle.bt.co.uk ([10.215.131.59]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id l1SBrUDd011752; Wed, 28 Feb 2007 11:53:34 GMT Message-Id: <5.2.1.1.2.20070228104215.04018008@pop3.jungle.bt.co.uk> X-Sender: rbriscoe@pop3.jungle.bt.co.uk X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Wed, 28 Feb 2007 11:53:27 +0000 To: "Arjuna Sathiaseelan" From: Bob Briscoe Subject: Re: [Tsvwg] RE: HEADS UP: consensus call on draft-floyd-tsvwg-cc-alt In-Reply-To: <200702240655.l1O6tkrI026247@erg.abdn.ac.uk> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: -1.36 () ALL_TRUSTED X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 X-OriginalArrivalTime: 28 Feb 2007 11:53:37.0706 (UTC) FILETIME=[14FCF0A0:01C75B2F] X-Spam-Score: 0.1 (/) X-Scan-Signature: 5d188b91ff79eaa1be2a0e9635461d9a Cc: gorry@erg.abdn.ac.uk, 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 Arjuna, I'm writing a draft about how to deal with different packet sizes right now (almost complete). Yes, you're right it is a problem. This hasn't been too much of a problem because of the long running consensus over 1500B. But many people are saying larger MTUs would be better. Then we'd need to think about TCP fairness a lot harder. Consider this quite reasonable topology: _ _ _ ->-----------|_|-------------------|_|-------------------|_|-----> E1 (H) | C1 E2 (1500) | | | _ E3 (H) +--------------------|_|-----> where E are edge routers and C is (potentially lots of) core routers. If E1 is congested, but it has an interface card with a higher MTU (H), and E3 has as well, then E2 determines the PMTU through E1 for its path, so you get different TCP bit rates through the same bottleneck at E1. In the DCCP w-g, TFRC-SP (for Small Packets - in the RFC-editor queue for experimental RFC) deals with this issue, by taking 1500B the norm. Modulo a load of other wrinkles, that's easier to do with an equation-based control. In the draft I've nearly written I provide pointers to research that implemented solutions to this in window-based rather than equation based congestion controllers. They use the same weighting concept that I've said will be nec to fix the other problems with fairness - over time etc. For example, a weighted TCP like MulTCP, or Siris's window-based weighted-fair algorithm. Even if you believed flow bit-rates should be equal on the same path (rather than packet-rates like TCP does), you could use these algorithms solely to allow for packet size differences. Bob At 06:55 24/02/2007, Arjuna Sathiaseelan wrote: >Regarding fairness, > >Another thing we need to note is, that the limitations in the routers (in >packets per second or bytes per second etc). So if a protocol "X" sends 4 >packets with 1500 byte segments, and a protocol "Y" sends 8 packets with 160 >byte packets, and if "a single" router in the path drops packets of "Y" due >to the pps limitation causing Y to behave badly, do we say, that protocol >"X" is unfair to "Y"? > >One silly question that still lurks in my mind is, say a protocol "X", does >not do slowstart, and sends at a desired rate, but on seeing congestion, >reduces the rate accordingly. Is this a "fair" protocol? I think this is >definitely better than UDP and when we still have UDP, why not have protocol >"X". I know that I will be beaten if I go with this protocol to the IETF :) > >This is just a novice's point of view, please pardon me if I sounded >ignorant, and please do correct me if I am wrong :) > > > >-Arjuna > >-----Original Message----- >From: tsvwg-request@ietf.org [mailto:tsvwg-request@ietf.org] >Sent: 23 February 2007 21:37 >To: tsvwg@ietf.org >Subject: tsvwg Digest, Vol 34, Issue 25 > >Send tsvwg mailing list submissions to > tsvwg@ietf.org > >To subscribe or unsubscribe via the World Wide Web, visit > https://www1.ietf.org/mailman/listinfo/tsvwg >or, via email, send a message with subject or body 'help' to > tsvwg-request@ietf.org > >You can reach the person managing the list at > tsvwg-owner@ietf.org > >When replying, please edit your Subject line so it is more specific >than "Re: Contents of tsvwg digest..." > > >Today's Topics: > > 1. Re: HEADS UP: consensus call on draft-floyd-tsvwg-cc-alt > (Bob Briscoe) > > >---------------------------------------------------------------------- > >Message: 1 >Date: Fri, 23 Feb 2007 21:36:53 +0000 >From: Bob Briscoe >Subject: Re: [Tsvwg] HEADS UP: consensus call on > draft-floyd-tsvwg-cc-alt >To: Sally Floyd >Cc: tsvwg , Mark ALLMAN >Message-ID: <5.2.1.1.2.20070223011554.0357f330@pop3.jungle.bt.co.uk> >Content-Type: text/plain; charset="us-ascii"; format=flowed > >Sally, > >I've added Mark to the distr. more inline... > >At 23:12 22/02/2007, Sally Floyd wrote: > >Bob - > > > >My apologies for not getting to your email earlier. > > > >>The doc seems reasonable. We have to be v careful writing these > >>guidelines that aim to constrain future standards activity. I think this > >>one has got the balance about right, except I'm very concerned in a > >>couple of areas: > >>- fairness > >>- constraining 'congestion' control when there's spare capacity > >> > >>The draft could become a WG item so we deal with these issues formally as > >>WG business. However, you might have noticed > >> I'm not at all happy (typical British > >>understatement!) about the prevailing fairness thinking at the IETF. So > >>I'd rather see at least an attempt to try to work out how we might reach > >>consensus on fairness /before/ this becomes a WG item. > >> > >>I believe the above tsvarea-fair I-D showed beyond doubt that comparing > >>flow rates is irrelevant to real-world fairness, because fairness can > >>only be between real-world entities like users, not inanimate objects > >>like flows---users can create any number of flows, for any duration. This > >>cc-alt I-D came out in parallel, so I'd like to hear if I've made any > >>impression yet? > > > >Well, the I-D is aimed not at the next generation Internet, but at the > >current, real-world Internet, where there > >are many congested links that aren't covered by ingress and egress access > >routers legislating for fairness. And in this world, > >for traffic that could traverse these congested links, I believe that it > >is necessary for transport protocols to provide some form > >of per-flow fairness. As we state in draft-floyd-tsvwg-cc-alt. > >When people are proved incorrect, they are meant to stop saying the >incorrect thing. That's how we reach consensus. Rather than just asserting >there is merit in carrying on regardless (just like this whole sorry story >has carried on for 9yrs since Kelly proved it wrong), please can we see an >argument against the points in my I-D, before we discuss putting anything >more about fairness in any RFCs. > >Let's please just accept that the form of fairness you and many many others >have defended throughout your careers isn't actually any form of fairness >at all.{*} Then we can have a proper debate about where we should go from >here. > >This isn't personal - it may seem recently I'm been jibing at you >personally but that's because I usually say nothing when I agree (which is >most of the time). My issue is with an idea that has been held much more >widely than just you personally of course, but at last more and more people >are abandoning it. In fact, I greatly admire everything you have done for >the Internet, but on this one point on fairness, I'm not saying anything >you did was wrong at the time, but it's actually been a mirage. > >The reason this needs facing now is that this whole flow rate fairness >charade is stopping progress. It used to provide some degree of restraint >among those that didnt' understand. But the world is way beyond that now. I >don't believe pretending TCP is fair is achieving anything useful any more. > >What we do have is a definition of fairness where allocations maximise >global utility. And it is likely that any other reasonable fairness >definitions will result in allocations close to this. > >When two flows happen to run at the same rate through the same bottleneck, >in 99.9999% of cases this situation will be extremely unfair by this >definition, when taken in the context of what has gone before, and what the >same user is doing on other unrelated routers not even on this path. This >is mostly because flows that go on thousands of times longer than other >flows are effectively allocated thousands of times more resources. > >On the basis that TCP's allocations might then be thousands of times >different from those that would maximise utility, two things can be >concluded: >- because the fairness outcome is completely arbitrary, depending on >parameters TCP doesn't control, TCP can't claim to produce a fairness >outcome >- the outcome that happens to result isn't even close to 'reasonable' >anyway. > >But, as long as apps are using some form of TCP-like congestion control >/dynamics/, the Internet is at least safe even though it's not fair. > > >Yes, I know about "The Amorphous Problem of Fairness", which I discussed > >in Section 3.3 of RFC 3714 back in March 2004, > >and I know about the well-known problems about the granularity of a flow > >that I discussed in Section 3.2 on "Fairness" in RFC 2914 > >in September 2000. > >Yup, I appreciated these RFCs said these things. I should ref them in the >next rev of the fairness draft. > > >I have never claimed that per-flow fairness was perfect. Just that it was > >necessary, for best-effort traffic. > >How can per-flow fairness, which is actually unfairness by all 'reasonable' >definitions, be necessary? > >I'm afraid, this isn't just a minor point. It really does need a re-think >of everything ever said about TCP fairness. It cannot go on any longer >without a proper case being made for why we should pretend it's fair when >it isn't. > > >My bottom line about per-flow fairness is that it is a little like >democracy: > >"It has been said that democracy is the worst form of government except > >all the others that have been tried." - Sir Winston Churchill. > >It's not a form of government at all. It doesn't govern anything. It's >complete anarchy, but TCP (and MulTCP) is at least *safe*. > > >>Here's two questions as acid-tests of whether the bullets of section 3 > >>will allow the evolution of congestion control that we need to allow: > >> > >>Q1. If I wrote an I-D defining MulTCP, would it satisfy this I-D's > >>fairness criteria? > > > >Like much else, draft-floyd-tsvwg-cc-alt leaves such decisions as > >judgement calls, that would have to be made > >by the IETF at the time. I personally wouldn't consider the fairness of > >MulTCP as sufficient fairness for best effort > >traffic to receive a sentence in the abstract saying that "this is > >considered ok for widespread deployment as best-effort > >traffic in the current Interent". Other people might call it differently, > >who knows? > > > >... > >>The point I'm making here is that fairness between users (as opposed to > >>between flows) /requires/ the mean rates of flows between different users > >>to all be very different. This isn't a case of two forms of fairness. > >>It's two mutually incompatible positions that cannot both be correct. The > >>IETF cannot use both - it has to decide between them. > > > >What, you are planning on having a flag day, when all links not covered > >for fairness between users, as opposed to fairness > >between flows, are required to be turned off? And all transport protocols > >that deliver some form of fairness between flows, > >instead of fairness between users, are not allowed to transmit packets on > >the Internet? Really? I don't think that Internet > >evolution works that way. > >Perhaps you think I have been irresponsible knocking down the only >touchstone we had, before we had anything else to bolster fairness. But I >thought about it very hard before going public with that fairness draft. > >I realised that there is no need for a flag day. Because we aren't >transitioning from any form of fairness at all.{*} So any moves towards >starting to protect links to ensure fairness between users as opposed to >so-called 'fairness' between flows will be an improvement over nothing. >Even if we find there's a big security flaw in re-ECN, we won't have lost >anything, because we didn't have anything{*} wrt fairness in the first >place. > >The transports that deliver so-called fairness between flows would work >just fine, while this new policed environment materialises, because 1-TCP >works just as well as w-TCPs in this new environment. Unless the user >causes too much congestion over a sustained period, or is running a >bot-agent into a DoS attack. > >Then, if the network operator chooses to, it can bring in some throttling, >just like the vast majority of ISPs are doing already to heavy users (at >least over here in Europe they are). But with congestion information, they >will be able to throttle much more fairly than they can now. And they will >only need to throttle packets running into congested paths (e.g. DoS >attacks). The user will still be able to run flows into low congestion >paths perfectly fast. > >A lot of ISPs are using volume as a metric, but volume's a v poor proxy for >congestion and therefore fairness. Volume does no harm when there's no >congestion and volume at some times or on some paths does a lot more harm >than volume at other times or on other paths, depending on how much >congestion there is. Worse, plenty of ISPs are throttling traffic based on >inferring which apps most often cause congestion, using deep packet >inspection. > >This is why we need to stop pretending TCP fairness is the solution and >really face up to the problem properly. We can't blame these people for >screwing up the Internet with middleboxes, if we've not done our job >properly. > > > >Another alternative would be that the IETF could have one set of standards > >for best-effort traffic, and other standards > >for traffic other than best effort. That is, the IETF could require > >per-flow fairness for transport protocols used for connections > >when it is possible that some congested link on the end-to-end path is not > >protected by some other mechanism > >(i.e., diffserv, intserv, some other QoS, fairness enforced by ingress and > >egress routers, or whatever.) That is what would > >make sense to me. > >Actually, I believe it's this alternative model of the world that is /not/ >how Internet evolution works. No-one expects the IETF to legislate on the >policies you've outlined above, which are about how networks should be >operated or used. > >No-one expects the IETF to legislate on how operators write acceptable use >policies, or for that matter how they use Diffserv codepoints, or what they >put in SLAs. The IETF is respected for standardising what vendors >implement. But no-one expects the IETF to legislate on operational polices. >Or how we all use the Internet. > >That's why, even though the IETF has legislated instantaneous TCP fairness >in RFC2581, ISPs still deploy DPI boxes and throttle flows down if the user >runs too many TCPs for too long. Do these ISPs make sure these flows comply >with RFC2581? No. They deliberately break RFC2581. Because in these cases >RFC2581 flows are pushing the system well away from maximum user utility (= >max customer value). Why should ISPs comply with an RFC that would push the >Internet to a point that massively reduces customer value? > >That's the message of tussle in cyberspace that you re-inforced yourself in >(the excellent) RFC3426. If we're forcing people and businesses into places >the market or society doesn't want to go to, we can't be surprised if our >rules are broken and ignored. > > >I will add a sentence to draft-floyd-tsvwg-cc-alt clarifying that some of > >its concerns only apply to best-effort traffic. > >I'm afraid that's not the issue. At the moment TCP is being used within BE >to create much better QoS for long lived flows than would be fair. I know >this sounds bizarre, but it has to be seen from what fairness /would/ be >like if it was 'reasonably' fair. > > > >>The dynamics /are/ a legitimate IETF concern. MulTCP responds very safely > >>in the face of congestion. MulTCP is no less safe than the multiple TCPs > >>from different apps we have on the Internet today. Why should the problem > >>be any different if MulTCP emulates opening multiple TCPs but happens to > >>label all the packets with the same flow ID? The rate behaviour is > >>exactly the same as if they were w separate TCP flows? Browsers use w=4 > >>already. 20 is just as safe. Or 20,000 for that matter. > > > >I happen to disagree. I think that an end-node opening 20,000 concurrent > >flows, as best-effort traffic with no other guarantees > >or protection about available bandwidth, could be causing very bad packet > >loss rates for the competing traffic in the Internet. The > >good news is that a concerned router in the Internet could detect this and > >take some protective action. And a vendor that designed > >its web browser this way, opening 20,000 concurrent flows as a default > >behavior for best-effort traffic, would have to > >answer to the considered views of the rest of the Internet community. > >Of course. > >My point was that this is already possible on the current Internet. >Certainly I agree that a MulTCP API would be misunderstood by many >application developers without general deployment of network protections >against excess congestion, as above. And, true (as I just said in the >version of my fairness presentation I just gave at ICCRG), we shouldn't >encourage an API to MulTCP until we have all the standards in place and >wide deployment of congestion protections. > >But that's /not/ because of the potential for an excessively large >converged rate. It's because the slow start and back-off behaviour of each >of the TCP's in MulTCP would need to be scaled back to not be the same as >the back-off behaviour of w TCPs. I certainly agree on that point. But >that's the neat thing about putting all the separate flows together. MulTCP >only needs one set of back-off probes, not w. > >This is why I've put an asterisk after a few of the times I've said we have >no fairness at all.{*} Because we do have some form of fairness during >exponential back-off, and that's important. > >Related to this, if you search for hints on how to improve BitTorrent >performance, you'll get advice to install a patch for WinXP that allows >many more half connections to open at one time, then it tells you how to >config BitTorrent so it opens many more connections much faster. It also >tells you to ignore the warnings from your virus protection software about >opening up the number of half-connections allowed. It admits this is the >OS's protection against fast-spreading worms but "it doesn't matter" >because "you need it for BitTorrent". > >Also, have you seen Mustang TCP? It's a start-up company aiming to sell a >version of TCP that is deliberately unfair to regular TCP flows, for >hi-speed video download, etc. > >This is the reality that ordinary Internet users are used to already. It's >not that these folks wouldn't want to be fair if they understood. In fact, >I recently picked up a paper about BitTorrent fairness, but it wasn't about >fairness to other Internet users, it was about fairness between uploads and >downloads within the community of users. Most users are meticulous about >fairness within the community, but they really just don't realise how many >other users outside their community they are swamping. > >And why should they? That's our job - they assume the transport must be >handling that - why would any lay person imagine it doesn't? Plenty of >folks at the IETF but outside the transport area don't understand this >themselves, at all. > > > >... > >>Q2. Would PCN (pre-congestion notification) based admission control > >>satisfy these fairness criteria >? > > > >I think of PCN as a form of QoS protection (at least for some of the links > >on the end-to-end path - I forget if it covers > >all of them). So I would say that some parts of draft-floyd-tsvwg-cc-alt > >don't necessarily apply to traffic covered by PCN, > >since some parts of draft-tsvwg-cc-alt only apply for best-effort traffic. > >A form of words that distinguishes protected (or perhaps third-party >mediated) congestion control from voluntary would be useful, to be able to >say what is out of scope. > >But for what remains in scope---on paths where congestion control is >voluntary---I really don't think it is right that the IETF should legislate >what is fair. Even if the IETF did legislate, it certainly shouldn't say >equal flow rates are fair. The IETF might just as well legislate that >causing equal congestion per flow is fair (over the duration of the flow). > >Instead of just carrying on regardless, it would be progress to debate >whose concern fairness should be. I have proposed the IETF should provide >the machinery for others to decide on fairness. We need to stop writing >RFCs that legislate policies that should be in the hands of others. > > > >... > >>I haven't seen any defence of why it's still appropriate for the IETF to > >>judge fairness using flow rates, either on this list or TSV-AREA. So this > >>cc-alt I-D either needs to acknowledge that a major U-turn on fairness is > >>required, or someone should construct an argument for flow rate fairness > >>before continuing to use it in this I-D. > > > >I obviously don't believe that the IETF should throw out flow rate > >fairness for best effort traffic, so I will say so > >more explicitly in draft-floyd-tsvwg-cc-alt. > >I obviously differ strongly, because it is actually saying we must have >allocations that are very very likely to be extremely unfair (by a >scientific definition of the word). > > > >.. > >>While there is spare capacity, that implies no-one wants any more than > >>they are using, so it shouldn't concern them that someone else takes more > >>(unless we want to condone envy for the sake of it). It might conceivably > >>concern a network operator, perhaps trying to make people pay more for > >>free beer, I suppose. But that doesn't seem to be a practice that the > >>IETF needs to concern itself with. > > > >I would leave bullet (2) about "Using Spare Capacity" in. It was > >motivated by Quick-Start, whose entire purpose is to > >use spare capacity. It was also motivated by High-Speed TCP, which had as > >a motivation using spare capacity. > >I think it is worthwhile that say that successfully using space capacity > >is a good thing, but it doesn't eliminate the > >requirement for fairness. > >Let's try to untangle what might be the disagreement here. Perhaps, you are >thinking of fairness as a rate thing so you have to think of fairness over >a duration. I think that's why you aren't able to separate the period when >there's spare capacity from when the system spills over into congestion. > >If instead you think of fairness in terms of volume of congestion caused, >there is a very distinct immediate boundary between the two situations. >Then fairness becomes irrelevant at every instant when the system is >uncongested. But the shares of capacity users have in flight at the instant >a resource becomes congested determine how much of the sudden incidence of >congestion is attributed to each of them. The relation between the >uncongested and congested periods is one of risk of how much congestion >traffic in flight will cause before the source gets feedback. > >Then fairness is very strictly only an issue from the instant congestion >starts to the instant it stops - the congested episode. > > >... > >>Lastly, how about an extra bullet?: > >> > >>* New cc proposals should explain how the protocol avoids loss of > >>congestion event information (e.g. NACKs or congestion reports might get > >>lost etc). > > > >I think that is covered already in bullets (1), (2), and (5). If the > >protocol can't avoid the loss of congestion event information, > >then it can't provide either fairness or protection against congestion > >collapse. > >I strongly believe it would be worth saying this very explicitly, not >assume people understand. It is this more than anything that determines >whether algorithm behaviour runs to collapse or pulls back from collapse if >load suddenly surges. > > > >>Nits > > > >Thanks, I will take care of them. > > > >(I should say that I haven't passed this answer by my co-author, Mark > >Allman, so he could have different opinions about things...) > >Cheers > > >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 > > > > > > >End of tsvwg Digest, Vol 34, Issue 25 >************************************* ____________________________________________________________________________ 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 Feb 28 10:12:37 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMQSv-0006bS-UO; Wed, 28 Feb 2007 10:11:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMQSu-0006bK-Lh for tsvwg@ietf.org; Wed, 28 Feb 2007 10:11:36 -0500 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 1HMQSt-0001Fr-5J for tsvwg@ietf.org; Wed, 28 Feb 2007 10:11:36 -0500 Received: from [10.10.10.2] (fgrpf.plus.com [212.159.18.54]) (authenticated bits=0) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id l1SFBMws019065 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 28 Feb 2007 15:11:23 GMT Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=WINDOWS-1252; delsp=yes; format=flowed Message-Id: <699816EE-2153-4D51-A7C6-241701198893@erg.abdn.ac.uk> Content-Transfer-Encoding: quoted-printable From: Gorry Fairhurst Date: Wed, 28 Feb 2007 15:11:28 +0000 To: tsvwg@ietf.org X-Mailer: Apple Mail (2.752.2) 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: 4b800b1eab964a31702fa68f1ff0e955 Cc: Gorry Fairhurst Subject: [Tsvwg] comments wanted: draft-eggert-tsvwg-udp-guidelines 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 > Title : UDP Usage Guidelines for Application =20 Designers > Author(s) : L. Eggert > Filename : draft-eggert-tsvwg-udp-guidelines-00.txt Thanks Lars, This seems like this is heading the correct direction. =46rom a first =20= read I have the following observations: --------- 1) If I understand, that what the ID says applies to unicast use of UDP =20 (and UDP-Lite for that matter), but there are also different concerns =20= when we use datagram transport fro multicast. --------- 2) Section 3: Says: =93Similarly, well-designed applications can shift maintenance of the TIME-WAIT state after a connection ends to the client=94 - Not clear what this means. --------- 3) Section 3.1 Says:=93If an application or upper-layer protocol chooses not to use a congestion-controlled transport protocol, it SHOULD control the rate at which it sends UDP messages to a destination, using one of the approaches discussed in this section.=94 _ I think so too. - It would be nice to note the impact here of path reservations =20 (RSVP, INTSERV) et al - what CC do you need to use if you reserv per-=20 flow capacity? and how does the app know this really is reserved? --------- 4) Section 3.2 Says: =93application SHOULD implement path MTU discovery=94 - or should support and use the path MTU information provided by the =20 IP network layer, including the use of probing.... but note that =20 applications do NOT need to probe above the largest size that they =20 intend to use. The discussion of =93natural=94 packet sizes (as in latest pmtud work) = is =20 also pertinent here to UDP apps. --------- 5) I think we need to offer some comment on the old issue of multiple =20 UDP ports between the same applications;-) --------- 6) You may wish to point out a note to the dangers in embedding IP =20 addresses in UDP payloads, etc --- Guidance already published elsewhere. --------- 7) It could also mention link-local addressing in IPv6. the lalter =20 raises some issues, in that you don=92t expect there to be any networlk =20= routers in a path that is link-local.... Do you need CC here? One NiT: I guess =93octets=94 is OK, but I=92d have found bytes more = obvious. Best wishes, Gorry= From tsvwg-bounces@ietf.org Wed Feb 28 14:40:36 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMUdW-0007WL-NW; Wed, 28 Feb 2007 14:38:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMUdV-0007R3-Mv for tsvwg@ietf.org; Wed, 28 Feb 2007 14:38:49 -0500 Received: from smtpout.mac.com ([17.250.248.185]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HMUdT-0006U9-Bm for tsvwg@ietf.org; Wed, 28 Feb 2007 14:38:49 -0500 Received: from mac.com (smtpin08-en2 [10.13.10.153]) by smtpout.mac.com (Xserve/8.12.11/smtpout15/MantshX 4.0) with ESMTP id l1SJcg9n001461; Wed, 28 Feb 2007 11:38:42 -0800 (PST) Received: from [192.168.1.64] (adsl-70-231-254-220.dsl.snfc21.sbcglobal.net [70.231.254.220]) (authenticated bits=0) by mac.com (Xserve/smtpin08/MantshX 4.0) with ESMTP id l1SJcZds005809; Wed, 28 Feb 2007 11:38:37 -0800 (PST) In-Reply-To: <200702240655.l1O6tkrI026247@erg.abdn.ac.uk> References: <200702240655.l1O6tkrI026247@erg.abdn.ac.uk> Mime-Version: 1.0 (Apple Message framework v624) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <10f6e4b46860e83f30ae4aed8bfe3552@mac.com> Content-Transfer-Encoding: 7bit From: Sally Floyd Subject: Re: [Tsvwg] RE: HEADS UP: consensus call on draft-floyd-tsvwg-cc-alt Date: Wed, 28 Feb 2007 11:38:34 -0800 To: "Arjuna Sathiaseelan" X-Mailer: Apple Mail (2.624) X-Brightmail-Tracker: AAAAAA== X-Brightmail-scanned: yes X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: gorry@erg.abdn.ac.uk, 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 Arjuna - > One question that may sound silly is when we say we should be fair to > TCP, > should we be fair to which version of TCP? ... > Another thing we need to note is, that the limitations in the routers > (in > packets per second or bytes per second etc). draft-floyd-tsvwg-cc-alt doesn't attempt to give detailed *requirements* for fairness, it just discusses fairness (flow-rate fairness) as one of the issues to be considered in evaluating new congestion control mechanisms. Detailed metrics on fairness, issues about fairness and packet size, etc., are discussed in draft-irtf-tmrg-metrics-07, Metrics for the Evaluation of Congestion Control Mechanisms. That draft, and an updated version in progress that has not yet been submitted, are available from "http://www.icir.org/floyd/papers.html". - Sally http://www.icir.org/floyd/ From tsvwg-bounces@ietf.org Wed Feb 28 16:57:26 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMWmS-0008Gn-QH; Wed, 28 Feb 2007 16:56:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMWmR-0008Gd-8K for tsvwg@ietf.org; Wed, 28 Feb 2007 16:56:11 -0500 Received: from elasmtp-mealy.atl.sa.earthlink.net ([209.86.89.69]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HMWmP-00053k-SP for tsvwg@ietf.org; Wed, 28 Feb 2007 16:56:11 -0500 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=Aot/YjmIomsoRal2Zp3gHa2TGDRqnsejDYCLFAXvBptZvIWC6X4vKr/eb7fQjh+U; h=Received:Message-ID:Date:From:X-Sender:X-Mailer:X-Accept-Language:MIME-Version:To:CC:Subject:References:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [68.164.91.80] (helo=earthlink.net) by elasmtp-mealy.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1HMWmN-0003c4-7P; Wed, 28 Feb 2007 16:56:07 -0500 Message-ID: <45E5F9C4.8FFE4F5@earthlink.net> Date: Wed, 28 Feb 2007 13:53:08 -0800 From: Erblichs X-Sender: "Erblichs" (Unverified) X-Mailer: Mozilla 4.72 [en]C-gatewaynet (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: Sally Floyd Subject: Re: [Tsvwg] RE: HEADS UP: consensus call on draft-floyd-tsvwg-cc-alt References: <200702240655.l1O6tkrI026247@erg.abdn.ac.uk> <10f6e4b46860e83f30ae4aed8bfe3552@mac.com> Content-Type: text/plain; charset=iso-8859-2 Content-Transfer-Encoding: 7bit X-ELNK-Trace: 074f60c55517ea841aa676d7e74259b7b3291a7d08dfec7955b8317dfe49abe9b84aac12c38fbc90350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 68.164.91.80 X-Spam-Score: 0.1 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Cc: gorry@erg.abdn.ac.uk, Arjuna Sathiaseelan , 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 Sally Floyd, et al, My two cents.. One cent --------- Is TCP fair? With two flows that start at the same time, with at least 1 hop in common, doesn't a lower RTT flow, absorb a greater amount of bandwidth? Of course it does.. Shouldn't TCP allow both, in this example, to achieve a stasis window where both flows are using approximately 50% of the available bandwidth on this common hop? There are more examples of where TCP isn't fair. However, should TCP have a priority goal of fairness? If one flow sees congestion before another and does a MD, where the other flow keeps doing AI, then this does not violate the TCP protocol. Maybe I missed it, but should the doc discuss the effects of tail-drop versus RED on multiple flows? Thus, is it fair to measure different TCP implementations in a heterogenous environment based on some set of criteria of fairness?? Shouldn't we EXPECT some level of UNFAIRNESS in heterogeneous environments (multiple different systems using diifferent TCP implementations)? Two cent -------- Maybe I missed it, but should the doc discuss the effects of tail-drop versus RED on TCP flows? Which one is "more fair"? Does RED reduce congestion as it reduces the effective size of the input buffers, which allows for bursty traffic. Isn't the TCP protocol bursty in nature due to the fact that no interpacket gap is MANDATORY or even suggested between segments on transmission? Mitchell Erblich --------------- Sally Floyd wrote: > > Arjuna - > > > One question that may sound silly is when we say we should be fair to > > TCP, > > should we be fair to which version of TCP? > ... > > > Another thing we need to note is, that the limitations in the routers > > (in > > packets per second or bytes per second etc). > > draft-floyd-tsvwg-cc-alt doesn't attempt to give detailed *requirements* > for fairness, it just discusses fairness (flow-rate fairness) as one of > the > issues to be considered in evaluating new congestion control mechanisms. > > Detailed metrics on fairness, issues about fairness and packet size, > etc., > are discussed in draft-irtf-tmrg-metrics-07, Metrics for the Evaluation > of > Congestion Control Mechanisms. That draft, and an updated version > in progress that has not yet been submitted, are available from > "http://www.icir.org/floyd/papers.html". > > - Sally > http://www.icir.org/floyd/ From tsvwg-bounces@ietf.org Wed Feb 28 18:51:44 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMYZx-0002Sk-39; Wed, 28 Feb 2007 18:51:25 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMYZ9-0001Hp-I5; Wed, 28 Feb 2007 18:50:35 -0500 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HMYZ6-00088n-R6; Wed, 28 Feb 2007 18:50:35 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id BDFA12AD34; Wed, 28 Feb 2007 23:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HMYYc-00043s-Ga; Wed, 28 Feb 2007 18:50:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 28 Feb 2007 18:50:02 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Cc: tsvwg@ietf.org Subject: [Tsvwg] I-D ACTION:draft-ietf-tsvwg-addip-sctp-18.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-18.txt Pages : 37 Date : 2007-2-28 This document describes extensions to the Stream Control Transmission Protocol (SCTP) [RFC2960] that provides a method to reconfigure IP address information on an existing association. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-addip-sctp-18.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-18.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-18.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-2-28152702.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-tsvwg-addip-sctp-18.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-tsvwg-addip-sctp-18.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-2-28152702.I-D@ietf.org> --OtherAccess-- --NextPart-- From tsvwg-bounces@ietf.org Wed Feb 28 18:51:44 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMYZ7-0001FN-9r; Wed, 28 Feb 2007 18:50:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMYYe-00015a-N2; Wed, 28 Feb 2007 18:50:04 -0500 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HMYYe-0002iw-As; Wed, 28 Feb 2007 18:50:04 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id 990F926EEA; Wed, 28 Feb 2007 23:50:03 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HMYYc-00044V-Re; Wed, 28 Feb 2007 18:50:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 28 Feb 2007 18:50:02 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Cc: tsvwg@ietf.org Subject: [Tsvwg] I-D ACTION:draft-ietf-tsvwg-rsvp-proxy-approaches-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 : RSVP Proxy Approaches Author(s) : F. Le Faucheur, et al. Filename : draft-ietf-tsvwg-rsvp-proxy-approaches-00.txt Pages : 37 Date : 2007-2-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. This document presents RSVP Proxy behaviors allowing RSVP routers to perform RSVP signaling on behalf of a receiver or a sender that is not RSVP-capable. This allows resource reservations to be established on parts of the end- to-end path. This document reviews conceptual approaches for deploying RSVP Proxies and discusses how those can synchronize RSVP reservations with application requirements. This document also points out where extensions to RSVP (or to other protocols) may be needed for deployment of a given RSVP Proxy approach. However, such extensions are outside the scope of this document. Finally, practical use cases for RSVP Proxy are described. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-rsvp-proxy-approaches-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-rsvp-proxy-approaches-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-rsvp-proxy-approaches-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-2-28161103.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-tsvwg-rsvp-proxy-approaches-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-tsvwg-rsvp-proxy-approaches-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-2-28161103.I-D@ietf.org> --OtherAccess-- --NextPart-- From tsvwg-bounces@ietf.org Wed Feb 28 18:51:50 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMYa0-0002Yf-NS; Wed, 28 Feb 2007 18:51:28 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMYZA-0001IY-Ck; Wed, 28 Feb 2007 18:50:36 -0500 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HMYZ7-00088t-C7; Wed, 28 Feb 2007 18:50:36 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id 2F96917644; Wed, 28 Feb 2007 23:50:03 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HMYYc-00044e-U1; Wed, 28 Feb 2007 18:50:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 28 Feb 2007 18:50:02 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Cc: tsvwg@ietf.org Subject: [Tsvwg] I-D ACTION:draft-ietf-tsvwg-rsvp-proxy-proto-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 : RSVP Extensions for Path-Triggered RSVP Receiver Proxy Author(s) : F. Le Faucheur, et al. Filename : draft-ietf-tsvwg-rsvp-proxy-proto-00.txt Pages : 19 Date : 2007-2-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-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-rsvp-proxy-proto-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-rsvp-proxy-proto-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-2-28161527.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-tsvwg-rsvp-proxy-proto-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-tsvwg-rsvp-proxy-proto-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-2-28161527.I-D@ietf.org> --OtherAccess-- --NextPart-- From tsvwg-bounces@ietf.org Wed Feb 28 18:52:01 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMYaX-0003iY-Dy; Wed, 28 Feb 2007 18:52:01 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMYZh-0002DS-OU; Wed, 28 Feb 2007 18:51:09 -0500 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HMYZc-0008Ke-Tg; Wed, 28 Feb 2007 18:51:09 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id 4D90417652; Wed, 28 Feb 2007 23:50:03 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HMYYd-00044q-0g; Wed, 28 Feb 2007 18:50:03 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 28 Feb 2007 18:50:03 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: tsvwg@ietf.org Subject: [Tsvwg] I-D ACTION:draft-ietf-tsvwg-sctp-auth-08.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 : Authenticated Chunks for Stream Control Transmission Protocol (SCTP) Author(s) : M. Tuexen, et al. Filename : draft-ietf-tsvwg-sctp-auth-08.txt Pages : 20 Date : 2007-2-28 This document describes a new chunk type, several parameters and procedures for SCTP. This new chunk type can be used to authenticate SCTP chunks by using shared keys between the sender and receiver. The new parameters are used to establish the shared keys. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-sctp-auth-08.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-sctp-auth-08.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-sctp-auth-08.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-2-28162307.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-tsvwg-sctp-auth-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-tsvwg-sctp-auth-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-2-28162307.I-D@ietf.org> --OtherAccess-- --NextPart--