From Ruediger.Geib@telekom.de Wed Aug 1 01:10:54 2012 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A17F021F85D6 for ; Wed, 1 Aug 2012 01:10:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.949 X-Spam-Level: X-Spam-Status: No, score=-2.949 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id arsq1s8hypXA for ; Wed, 1 Aug 2012 01:10:53 -0700 (PDT) Received: from tcmail83.telekom.de (tcmail83.telekom.de [62.225.183.131]) by ietfa.amsl.com (Postfix) with ESMTP id 470C721F8629 for ; Wed, 1 Aug 2012 01:10:51 -0700 (PDT) Received: from he111628.emea1.cds.t-internal.com ([10.134.93.20]) by tcmail81.telekom.de with ESMTP/TLS/AES128-SHA; 01 Aug 2012 10:10:50 +0200 Received: from HE111648.emea1.cds.t-internal.com ([10.134.93.17]) by HE111628.emea1.cds.t-internal.com ([::1]) with mapi; Wed, 1 Aug 2012 10:10:49 +0200 From: To: Date: Wed, 1 Aug 2012 10:10:48 +0200 Thread-Topic: [tsvwg] draft-polk-diffserv-stds-problem-statement-01 - Comments Thread-Index: Ac1ubvqMg3SWHLTsTLe/LUI7KsQ/7wBSeySw Message-ID: <580BEA5E3B99744AB1F5BFF5E9A3C67D14DD3C7D31@HE111648.emea1.cds.t-internal.com> References: <201207171928.q6HJSqTZ019139@mtv-core-3.cisco.com> <50066248.3030502@gmail.com> <201207190047.q6J0lwHb020765@mtv-core-1.cisco.com> <580BEA5E3B99744AB1F5BFF5E9A3C67D14DD244CAC@HE111648.emea1.cds.t-internal.com> <201207301618.q6UGIYKr005197@mtv-core-3.cisco.com> In-Reply-To: <201207301618.q6UGIYKr005197@mtv-core-3.cisco.com> Accept-Language: en-US, de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: tsvwg@ietf.org Subject: Re: [tsvwg] draft-polk-diffserv-stds-problem-statement-01 - Comments X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2012 08:10:55 -0000 James, replies summed up here to keep that readable: Standard RFCs an EF/AF/CS and others: The intent to better explain DiffServ deployment is also part of the ITU-work. Also other standards bodies define QoS classes (PHB groups). Also your IETF work tries to better explain the standards, if I understand that right. With the exception of IETF, noone goes for 20+x DSCPs or PHBs, no matter which layer is in focus. Neither standards bodies nor carriers, nor the customers I'm aware off or regulation and noone of our product managers. My approach is: let's look what those interested in DiffServ deployment have in common and focus on that for new standards. Review existing standards on QoS. As you point out, IETF depricated IP Precedence, for example. Why not review the AF and other IETF QoS specifications now? As an example, I'm not aware of any AF implementation with 3 drop priorities (there are standards in the wireless community however on a single class with 3 drop priorities, but no implementation, I think). Why maintain 3 drop priorities in four classes? If your aim is to inform the community how to design DiffServ networks, why do you ignore IP Precedence utilisation? To me it's time to accept that DiffServ is utilsed in IP over Ethernet or IP over MPLS and so on, usually with layer interworking, maybe with an interconnection in between. Standards should reflect that. If IETF was to go for an AF review, guidance on a migration to a new standard should be given of course. Regards, R=FCdiger -----Original Message----- From: James Polk [mailto:jmpolk@cisco.com] Sent: Monday, July 30, 2012 6:19 PM To: Geib, R=FCdiger; jmpolk@cisco.com Cc: tsvwg@ietf.org Subject: Re: [tsvwg] draft-polk-diffserv-stds-problem-statement-01 - Commen= ts At 04:33 AM 7/27/2012, Ruediger.Geib@telekom.de wrote: >Hi James, > >some comments on draft-polk-diffserv-stds-problem-statement-01 > >The introduction states > > DSCP > values are used to differentiate packet treatment within an > intermediate node, not across a network, as the conditions affecting > that marking are different within each node. This is called Per Hop > Behavior (PHB). A packet could have the same DSCP value from source > to destination, but the intended mode of operation is for the DSCP > value to be rewritten when the packet crosses the boundary of a > DiffServ administrative domain. Indeed, the packet may be fully > reclassified at a domain boundary. The DSCP value should stay the > same only if adjacent domains have agreed to use the same set of > DSCP values and the same, or equivalent, PHBs. Inconsistency will > arise if a domain does not rewrite the DSCP value when receiving a > packet from another domain that uses a different set of DSCPs and > PHBs. > >My take is, if DiffServ design plans rewriting DSCPs at network >boundaries, then DSCPs shouldn't be on standards track (or if at all, >a low number only to leave room for DSCP remarking shemes). EF is a standards track DSCP defined in RFC 3246. AF4X, 3X, 2X, and 1X are a series of standards track DSCPs defined in RFC 2= 597. CS0, CS1, CS2, CS3, CS4, CS5, CS6, CS7 are standards track DSCPs defined in RFC 2474. VOICE-ADMIT is a standards track DSCP defined in RFC 5865. If you want a low number of DSCPs to be on standards track, is the above - too many? - and if too many, which should be deprecated? - not enough? - just the right number? I'm just trying to figure out where you want this going? >Now the next section of your drfat states: > > At issue is a combination of the number of networks or endpoints > that are choosing to use DiffServ markings, and the number of > administrative domains (called "networks" in this document) a packet > traverses with different policies for how packet flows of a similar > type (e.g., a voice flow, or an email flow, etc.) are to be marked. > >I'm sorry, I'm lost here. Could you describe that more precise and >may be add a figure? That figure doesn't need to be .txt, but I'd >appreciate it within your presentation of the draft during IETF 84. > >You further continue: > > The community presently has RFC 4594 [RFC4594], which is an > informational guideline on how networks can or should mark certain > packet flows with differing traffic characteristics using DiffServ. > >Please define "community" in a terminology section (or replace it >with another word). the "community" is the Internet community, and everyone here knows that. >The community I'm aware of produced a couple >of other informational standards on DiffServ PHBs and DSCPs. Al >Morton's presentation on the ITU liaision may contain more >information. > >Apart from that, by now many carriers implemented DiffServ. > >Your text continues: > > o confusion between RFC 4594 and RFC 5127 [RFC5127], the latter of > which is for aggregating many 6-bit DSCP values into the 3-bit (8 > value) field available in MPLS. This confusion arises because > RFC 5127 is written in general terms, and indeed aggregation > could be used on non-MPLS paths, but the specific restriction > to 3 bits is due entirely to MPLS and only applies to the > MPLS portion of a packet's path. A similar 3-bit field exists > within IEEE's 802 specifications, which causes the same > confusion. > >The statement "only applies to the MPLS portion of a packet's path" >is wrong and does not reflect all actual deployments. > >Deriving MPLS TC and Ethernet P-Bits from the three most significant >DSCP bits (so called IP Precedence) is a commodity. Carriers also >differentiate services based on IP Precedence rather than DSCPs >on IP level, and forward traffic based on IP Precedence only. IP Precedence was obsoleted by RFC 2474 in the year 1999. >To me, this is a fundamental issue for any revision of RFC4594 or 5127. > >You go on: > > o some believe RFC 5127 is for SPs only, and want RFC 4594 to > reduce the number of DSCPs within its guidelines to recommend > using only 3 or 4 DSCPs. This seems to stem from a manageability > and operational perspective. > >Please provide an example. I've never heard of that. I need go back no later than the Paris SVWG meeting in which someone within the WG suggested only a few DSCPs were necessary, and that any update to RFC 4594 should reflect that view. >I can't support the problem statement as is. ok James >Regards, > >Ruediger From Ruediger.Geib@telekom.de Wed Aug 1 01:54:09 2012 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FA1921F86DF for ; Wed, 1 Aug 2012 01:54:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Si7OLAxy3aoc for ; Wed, 1 Aug 2012 01:54:08 -0700 (PDT) Received: from tcmail13.telekom.de (tcmail13.telekom.de [80.149.113.165]) by ietfa.amsl.com (Postfix) with ESMTP id B2B6921F86DA for ; Wed, 1 Aug 2012 01:54:02 -0700 (PDT) Received: from he113657.emea1.cds.t-internal.com ([10.134.99.17]) by tcmail11.telekom.de with ESMTP/TLS/AES128-SHA; 01 Aug 2012 10:54:00 +0200 Received: from HE111648.emea1.cds.t-internal.com ([10.134.93.17]) by HE113657.emea1.cds.t-internal.com ([::1]) with mapi; Wed, 1 Aug 2012 10:54:00 +0200 From: To: Date: Wed, 1 Aug 2012 10:53:59 +0200 Thread-Topic: [tsvwg] draft-polk-diffserv-stds-problem-statement-01 - Comments Thread-Index: Ac1udEim3814az39Re+j1kcXFbiQdQBSPMWA Message-ID: <580BEA5E3B99744AB1F5BFF5E9A3C67D14DD4B4CCE@HE111648.emea1.cds.t-internal.com> References: <201207171928.q6HJSqTZ019139@mtv-core-3.cisco.com> <50066248.3030502@gmail.com> <201207190047.q6J0lwHb020765@mtv-core-1.cisco.com> <580BEA5E3B99744AB1F5BFF5E9A3C67D14DD244CAC@HE111648.emea1.cds.t-internal.com> <5012892F.9040308@gmail.com> <580BEA5E3B99744AB1F5BFF5E9A3C67D14DD245424@HE111648.emea1.cds.t-internal.com> <50164C66.4020106@gmail.com> <580BEA5E3B99744AB1F5BFF5E9A3C67D14DD24581D@HE111648.emea1.cds.t-internal.com> <201207301654.q6UGsmhQ012615@mtv-core-4.cisco.com> In-Reply-To: <201207301654.q6UGsmhQ012615@mtv-core-4.cisco.com> Accept-Language: en-US, de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: tsvwg@ietf.org Subject: Re: [tsvwg] draft-polk-diffserv-stds-problem-statement-01 - Comments X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2012 08:54:09 -0000 [snip] and replies marked by [RG] >BC: >Sure. That's exactly the sort of thing I'd expect to see in >an inter-operator or operator-customer SLA. > >RG: That's what it is designed for. >I'd like to RECOMMEND just that on standards track. >But not more than that. Once we learned, this doesn't suffice, >let's RECOMMEND more DSCPs, PHBs, classes and the like on >standards track. I don't say: depricate the remaining stuff. >(but a review may be useful). [James] how exactly does one "RECOMMEND more DSCPs, PHBs, Classes and the like" without first creating each in a standards track RFC? [James] http://www.ietf.org/internet-drafts/draft-polk-tsvwg-new-dscp-assignments-= 00.txt does this creation. [James] Now we have a chicken and the egg situation. Do you define the traffic characteristics for each new DSCP before you define the guidelines but after you make the DSCP standards track, or do you do it all at the same time, while ensuring the golden rule of "anything new shall do no harm to the Internet". [RG] My aim is to first have a look, why existing PHBs (and DSCPs) can't be used. One of the problems I have is that noone I know can deal with more than around 6 deployed/requested PHBs and many people comming to standards with an application perspective continue to tell me that the PHBs only available in standards documents aren't good enough. Why then isn't any of these "not good enough" PHBs, which never saw or will see deployment, depricated? This [James] If your company does not implement the understanding for what to do with each new DSCP, what harm is caused? I submit none, because you'll either remark the packets to some other DSCP or zero the field out. [RG] As pointed out several times we end up in per customer class and codepoint mapping discussions. That's neither speeding up negotiations nor are these customers really happy with that. That's why I've initiated work on an interconnection PHB/class scheme. [James] At the same time, where each new DSCP can be used, it can be implemented with certain expectations for packet treatment of such marked packets, geared towards application expectations. Or, applications are the ones that are requiring these new traffic characteristics by claiming the existing treatments are insufficient or differentiated from other traffic that's expected on the same networks. [snip] [RG] Two things and I talk from practice: During my discussions with network engineers, not naming classes by application names was an issue. With 4 PHBs only, the philosophy is you never know which PHB is picked by your customer for an application. By adding more PHBs, this isn't simplified. [RG] I don't get the point why new applications require new PHBs. This sounds as if operational experience with deployed PHBs is so bad, that there's no other choice. Honestly, who's got operational experience with deployed PHBs in the community and does support that point? Operational experience (with those 3-6 PHBs you'll find most often) is limited. They produce QoS, if correctly engineered. If they don't, the fault usually isn't caused by the DiffServ architecture or features. My point here is: let these new applications try the deployed PHBs. Once this proves unresolvable issues, go for something new on standards track. Regards, R=FCdiger [James] None of this is mandating every operator has to become aware of each differentiated treatment characteristic, rather they are willing to merge several treatments together, thus creating treatment aggregates - as defined by RFC 5127 alrea= dy. >Please keep in mind: I'm out for end to end QoS, across >many domains. There should be codepoint and PHB definition >reserves left for future deployments (like PCN or PHB >groups / Ordered Aggregate under 3 bit space conditions). >Otherwise those happy to add and create own solutions >in their domain - they can continue as today. What about between domains that fall into an existing treatment aggregate? That is a fundamental point/question here that is being missed. James >Ruediger > > > -----Original Message----- > > From: Brian E Carpenter [mailto:brian.e.carpenter@gmail.com] > > Sent: Friday, July 27, 2012 2:27 PM > > To: Geib, R=FCdiger > > Cc: jmpolk@cisco.com; tsvwg@ietf.org > > Subject: Re: [tsvwg] > draft-polk-diffserv-stds-problem-statement-01 - Comments > > > > On 27/07/2012 10:33, Ruediger.Geib@telekom.de wrote: > >> Hi James, > >> > >> some comments on draft-polk-diffserv-stds-problem-statement-01 > >> > >> The introduction states > >> > >> DSCP > >> values are used to differentiate packet treatment within an > >> intermediate node, not across a network, as the conditions affectin= g > >> that marking are different within each node. This is called Per Hop > >> Behavior (PHB). A packet could have the same DSCP value from source > >> to destination, but the intended mode of operation is for the DSCP > >> value to be rewritten when the packet crosses the boundary of a > >> DiffServ administrative domain. Indeed, the packet may be fully > >> reclassified at a domain boundary. The DSCP value should stay the > >> same only if adjacent domains have agreed to use the same set of > >> DSCP values and the same, or equivalent, PHBs. Inconsistency will > >> arise if a domain does not rewrite the DSCP value when receiving a > >> packet from another domain that uses a different set of DSCPs and > >> PHBs. > >> > >> My take is, if DiffServ design plans rewriting DSCPs at network > >> boundaries, then DSCPs shouldn't be on standards track (or if at all, > >> a low number only to leave room for DSCP remarking shemes). > > > > That's exactly why the standards-track DSCP values are all "RECOMMENDED= " > > as the default for a particular behaviour, and it's also why there are > > not many of them, with most of the space available for local or > > experimental use. > > > > > >> Now the next section of your drfat states: > >> > >> At issue is a combination of the number of networks or endpoints > >> that are choosing to use DiffServ markings, and the number of > >> administrative domains (called "networks" in this document) a packe= t > >> traverses with different policies for how packet flows of a similar > >> type (e.g., a voice flow, or an email flow, etc.) are to be marked. > >> > >> I'm sorry, I'm lost here. Could you describe that more precise and > >> may be add a figure? That figure doesn't need to be .txt, but I'd > >> appreciate it within your presentation of the draft during IETF 84. > > > > That sentence seems to me to be a completely accurate summary. At the > > insistence of the ISPs involved when diffserv was defined, each domain > > is allowed to do what it likes, and that can lead to combinatorial > > complexity when a traffic aggregate crosses several domains. If the > > discussions in RFC 2475 and RFC 3086 aren't enough to describe this, > > there is more (with non-ASCII art) in Carpenter & Nichols, Differentiat= ed > > Services in the Internet, Proc. IEEE, 90 (9) (2002) 1479-1494. > > > >> You further continue: > >> > >> The community presently has RFC 4594 [RFC4594], which is an > >> informational guideline on how networks can or should mark certain > >> packet flows with differing traffic characteristics using DiffServ. > >> > >> Please define "community" in a terminology section (or replace it > >> with another word). The community I'm aware of produced a couple > >> of other informational standards on DiffServ PHBs and DSCPs. Al > >> Morton's presentation on the ITU liaision may contain more > >> information. > >> > >> Apart from that, by now many carriers implemented DiffServ. > >> > >> Your text continues: > >> > >> o confusion between RFC 4594 and RFC 5127 [RFC5127], the latter of > >> which is for aggregating many 6-bit DSCP values into the 3-bit (= 8 > >> value) field available in MPLS. This confusion arises because > >> RFC 5127 is written in general terms, and indeed aggregation > >> could be used on non-MPLS paths, but the specific restriction > >> to 3 bits is due entirely to MPLS and only applies to the > >> MPLS portion of a packet's path. A similar 3-bit field exists > >> within IEEE's 802 specifications, which causes the same > >> confusion. > >> > >> The statement "only applies to the MPLS portion of a packet's path" > >> is wrong and does not reflect all actual deployments. > > > > What do you mean? If an operators *chooses* to only use a maximum of > > 8 traffic classes, that is fine, but it is not a restriction except > > in MPLS and 802. > > > > > >> Deriving MPLS TC and Ethernet P-Bits from the three most significant > >> DSCP bits (so called IP Precedence) is a commodity. > > > > I don't know exactly what you mean by the word "commodity" here, but > > the three most significant DSCP bits *are not* the same as IP Precedenc= e. > > If people are doing blind mapping of that kind, they have quite simply > > implemented diffserv incorrectly. > > > >> Carriers also > >> differentiate services based on IP Precedence rather than DSCPs > >> on IP level, and forward traffic based on IP Precedence only. > > > > Again, carriers can choose to do that, which is why we included > > the Class Selector PHBs in RFC 2474. But then it is only a partial > > implementation of diffserv and cannot capture behaviours such as > > EF or AF. > >> To me, this is a fundamental issue for any revision of RFC4594 or 5127= . > > > > The fact that carriers don't implement RFC 2474 correctly is an issue, = yes. > > > >> You go on: > >> > >> o some believe RFC 5127 is for SPs only, and want RFC 4594 to > >> reduce the number of DSCPs within its guidelines to recommend > >> using only 3 or 4 DSCPs. This seems to stem from a manageability > >> and operational perspective. > >> > >> Please provide an example. I've never heard of that. > > > > Some people have always complained that 3 or 4 service classes is > > sufficient (including me, as it happens). Fine grain QoS is overrated > > IMHO. What I object to in the model you describe is that it relies on > > naive precedence rather than on queuing disciplines adapted to various > > types of traffic. > > > > Brian > >> I can't support the problem statement as is. > >> > >> > >> Regards, > >> > >> Ruediger > >> > >> > >> > >> > >> > > From acmorton@att.com Wed Aug 1 11:28:20 2012 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F7AF11E83AF; Wed, 1 Aug 2012 11:28:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.665 X-Spam-Level: X-Spam-Status: No, score=-105.665 tagged_above=-999 required=5 tests=[AWL=0.131, BAYES_00=-2.599, MSGID_FROM_MTA_HEADER=0.803, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EVIwr7tuPfGG; Wed, 1 Aug 2012 11:28:18 -0700 (PDT) Received: from nbfkord-smmo05.seg.att.com (nbfkord-smmo05.seg.att.com [209.65.160.92]) by ietfa.amsl.com (Postfix) with ESMTP id 0D7B511E81CE; Wed, 1 Aug 2012 11:28:17 -0700 (PDT) Received: from unknown [144.160.20.145] (EHLO mlpd192.enaf.sfdc.sbc.com) by nbfkord-smmo05.seg.att.com(mxl_mta-6.11.0-10) over TLS secured channel with ESMTP id 14579105.0.936502.00-329.2573193.nbfkord-smmo05.seg.att.com (envelope-from ); Wed, 01 Aug 2012 18:28:18 +0000 (UTC) X-MXL-Hash: 5019754209200271-51fcd31c5f9e07a910883ef4a3aa34571a7080e7 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q71ISGSU017699; Wed, 1 Aug 2012 14:28:17 -0400 Received: from sflint02.pst.cso.att.com (sflint02.pst.cso.att.com [144.154.234.229]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q71ISDlZ017696 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 1 Aug 2012 14:28:14 -0400 Received: from alpd052.aldc.att.com (alpd052.aldc.att.com [130.8.42.31]) by sflint02.pst.cso.att.com (RSA Interceptor); Wed, 1 Aug 2012 14:27:58 -0400 Received: from aldc.att.com (localhost.localdomain [127.0.0.1]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id q71IRvQx024903; Wed, 1 Aug 2012 14:27:57 -0400 Received: from mailgw1.maillennium.att.com (dns.maillennium.att.com [135.25.114.99]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id q71IRpOV024697; Wed, 1 Aug 2012 14:27:52 -0400 Message-Id: <201208011827.q71IRpOV024697@alpd052.aldc.att.com> Received: from acmt.att.com (vpn-135-70-240-95.vpn.east.att.com[135.70.240.95](misconfigured sender)) by maillennium.att.com (mailgw1) with SMTP id <20120801182319gw10025cufe>; Wed, 1 Aug 2012 18:23:20 +0000 X-Originating-IP: [135.70.240.95] X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 01 Aug 2012 14:27:23 -0400 To: tsvwg@ietf.org From: Al Morton Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.20.145] X-AnalysisOut: [v=1.0 c=1 a=zSOqplUit0gA:10 a=dRNClBhXWMcA:10 a=ofMgfj31e3] X-AnalysisOut: [cA:10 a=BLceEmwcHowA:10 a=kj9zAlcOel0A:10 a=ZRNLZ4dFUbCvG8] X-AnalysisOut: [UMqPvVAA==:17 a=0FD05c-RAAAA:8 a=48vgC7mUAAAA:8 a=hZG83p_y] X-AnalysisOut: [AAAA:8 a=2UFH3SNg1t3ncIyfiP8A:9 a=CjuIK1q_8ugA:10 a=3qFsgw] X-AnalysisOut: [-wyTgA:10 a=jM_x9b4JT8QA:10 a=f7GxY0FH8QIA:10 a=lZB815dzVv] X-AnalysisOut: [QA:10 a=qgRezc3XQjWTNDXG:21 a=kNLUO4gSpudhLnv1:21] Cc: pmol@ietf.org Subject: [tsvwg] Fwd: Re: [PMOL] Fwd: I-D Action: draft-sun-tsvwg-flowbased-pm-00.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2012 18:28:20 -0000 tsvwg, When I saw this draft >Zhu Lei - Flow-based Performance Measurement (10 min) >draft-sun-tsvwg-flowbased-pm on the I-D announcement list, I asked for and received a review from the Performance Metrics Directorate. I've inserted a few of my own comments below. We try to do early review when requested by WG chairs, and since this draft is now on the tsvwg agenda we are sharing our comments with the tsvwg list. Overall, I would like to suggest that the authors examine the IPPM measurement protocols more fully and implement them to see if their need for flow-based measurement can be met without developing new protocols. Al PMDir admin >From: Andreas Johnsson A >To: "pmol@ietf.org" >Date: Mon, 2 Jul 2012 11:31:22 +0200 > > >Hi, >I have tried to put together a short review. Please see my comments >below (and please provide further comments). [ACM] = Al's additional comments. >Best regards, >Andreas Johnsson > >----- > >Comments on draft-sun-tsvwg-flowbased-pm-00.txt. > >1) The draft describes a new active measurement protocol with the >aim of measuring delay, jitter and loss over an IP path. The >protocol is similar to TWAMP (RFC5357), however the measurement >setup is performed in a TCP-like manner instead of using a specific >control plane. Despite its similarities to TWAMP there are no >references nor does the draft contain a comparison. > >2) The draft includes a description on how to calculate statistics >based on time stamps obtained by the protocol. The metrics are >delay, jitter and loss. An advice is to use RFC 6390 section 5.4.5 >guidelines for describing the metrics. > >3) The draft does not prior art in IPPM (or elsewhere) >related to delay, jitter or loss. Suggested documents are > >IPPM Delay (http://tools.ietf.org/html/rfc2679) >IPPM Loss (http://tools.ietf.org/html/rfc2680) >IPPM Delay variation (http://www.ietf.org/rfc/rfc3393.txt) [ACM] IPPM Packet Reordering RFC 4737 >ITU-T Y.1540 (http://www.itu.int/rec/T-REC-Y.1540-200711-S) > >4) I would like the authors to elaborate on their delay calculation >method. The draft assumes that the forward delay is always equal to >the reverse delay. How often is this the case? > >5) The jitter calculations are based upon the delay calculations. >Since the delay is calculated as the RTT (minus the time a packet >spends at the PM responder) divided by 2, the jitter will be the >same in both directions. Does this really reflect what is happening >on the path? Please elaborate on this. [ACM] In general, the statistics suggested here are not widely used, especially the jitter as delay variance. Suggest that the authors look at http://tools.ietf.org/html/rfc5481 and decide what measurement task and PDV method suits their needs. >-----Original Message----- >From: pmol-bounces@ietf.org [mailto:pmol-bounces@ietf.org] On Behalf >Of Al Morton >Sent: den 29 juni 2012 13:58 >To: pmol@ietf.org >Subject: [PMOL] Fwd: I-D Action: draft-sun-tsvwg-flowbased-pm-00.txt > >After reading the abstract, ... > >Would anyone volunteer to review this in a timely way? > >Al >PMDir admin > > > >From: internet-drafts@ietf.org > >To: i-d-announce@ietf.org > >Subject: I-D Action: draft-sun-tsvwg-flowbased-pm-00.txt > >X-Test-IDTracker: no > >X-IETF-IDTracker: 4.21p1 > >Date: Fri, 29 Jun 2012 01:40:50 -0700 > >X-BeenThere: i-d-announce@ietf.org > >X-Mailman-Version: 2.1.12 > >Reply-To: internet-drafts@ietf.org > > > > > >A New Internet-Draft is available from the on-line Internet-Drafts > >directories. > > > > > > Title : Flow-based Performance Measurement > > Author(s) : Lishun Sun > > Wendong Wang > > Fang Yu > > Filename : draft-sun-tsvwg-flowbased-pm-00.txt > > Pages : 15 > > Date : 2012-06-29 > > > >Abstract: > > The performance measurements of service flow are becoming significant > > important for administrators monitoring the fitness of the network. > > This memo defines an end-to-end application-based performance > > measurement method, which is achieved by generating synthetic > > measurement packets, injecting them to the network and analyzing the > > statistics carried in the measurement packets. > > > > > >The IETF datatracker status page for this draft is: > >https://datatracker.ietf.org/doc/draft-sun-tsvwg-flowbased-pm > > > >There's also a htmlized version available at: > >http://tools.ietf.org/html/draft-sun-tsvwg-flowbased-pm-00 > > > > > >Internet-Drafts are also available by anonymous FTP at: > >ftp://ftp.ietf.org/internet-drafts/ > > > >_______________________________________________ > >I-D-Announce mailing list > >I-D-Announce@ietf.org > >https://www.ietf.org/mailman/listinfo/i-d-announce > >Internet-Draft directories: http://www.ietf.org/shadow.html or > >ftp://ftp.ietf.org/ietf/1shadow-sites.txt > >_______________________________________________ >PMOL mailing list >PMOL@ietf.org >https://www.ietf.org/mailman/listinfo/pmol >_______________________________________________ >PMOL mailing list >PMOL@ietf.org >https://www.ietf.org/mailman/listinfo/pmol From david.black@emc.com Thu Aug 2 09:07:57 2012 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3177021E8041 for ; Thu, 2 Aug 2012 09:07:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.464 X-Spam-Level: X-Spam-Status: No, score=-102.464 tagged_above=-999 required=5 tests=[AWL=0.135, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2fse4jpk2ZmO for ; Thu, 2 Aug 2012 09:07:56 -0700 (PDT) Received: from mexforward.lss.emc.com (hop-nat-141.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id 241DC11E808D for ; Thu, 2 Aug 2012 09:07:55 -0700 (PDT) Received: from hop04-l1d11-si01.isus.emc.com (HOP04-L1D11-SI01.isus.emc.com [10.254.111.54]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q72G7pfp017451 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 2 Aug 2012 12:07:54 -0400 Received: from mailhub.lss.emc.com (mailhub.lss.emc.com [10.254.221.145]) by hop04-l1d11-si01.isus.emc.com (RSA Interceptor) for ; Thu, 2 Aug 2012 12:07:38 -0400 Received: from mxhub30.corp.emc.com (mxhub30.corp.emc.com [128.222.70.170]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q72G7cNq007826 for ; Thu, 2 Aug 2012 12:07:38 -0400 Received: from mx15a.corp.emc.com ([169.254.1.189]) by mxhub30.corp.emc.com ([128.222.70.170]) with mapi; Thu, 2 Aug 2012 12:07:38 -0400 From: To: Date: Thu, 2 Aug 2012 12:07:36 -0400 Thread-Topic: Diffserv discussion yesterday Thread-Index: Ac1wyO7e1y8aGgr4TN6rd7XjMKiqeg== Message-ID: <8D3D17ACE214DC429325B2B98F3AE71208E7FFB1@MX15A.corp.emc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EMM-MHVC: 1 Subject: [tsvwg] Diffserv discussion yesterday X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 16:07:57 -0000 There was a lengthy discussion in yesterday's tsvwg meeting around James's diffserv problem statement draft and the liaison from ITU-T SG12/Q17 on QoS classes and markings for interconnection. Here's the summary of the interesting points that I captured from the4 disc= ussion: - We may be looking at a tunnel structure where the RFC 4594 classes and ma= rkings are used in the inner IP header (can be viewed as enterprise-orient= ed), but a much smaller number of classes/markings (e.g., see RFC 5127 a= nd ITU-T liaison) are used in the outer MPLS header's TC bits (can be viewed as carrier- and inter-carrier-oriented). That smaller numbe= r of aggregates could also apply to the Ethernet priority field. - The ITU-T liaison can be read as also asking if the treatment aggregates = in RFC 5127 are the right ones. This may be much more important than whether the right RFC 4594 classes are in each RFC 5127 traffic agg= regate. - In addition, RFC 5127 needs some more detailed work, e.g., as VOICE-ADMIT isn't included, but figuring out whether RFC 5127 has the right tre= atment aggregates is more important. - The response to the ITU-T liaison is not due until next March so there is= time to consider the issues. Thanks, --David ---------------------------------------------------- David L. Black, Distinguished Engineer EMC Corporation, 176 South St., Hopkinton, MA=A0 01748 +1 (508) 293-7953=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 FAX: +1 (508) 293-778= 6 david.black@emc.com=A0=A0=A0=A0=A0=A0=A0 Mobile: +1 (978) 394-7754 ---------------------------------------------------- From jmpolk@cisco.com Thu Aug 2 11:58:21 2012 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A90211E824F for ; Thu, 2 Aug 2012 11:58:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.508 X-Spam-Level: X-Spam-Status: No, score=-110.508 tagged_above=-999 required=5 tests=[AWL=0.091, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v8zVikFpxgPu for ; Thu, 2 Aug 2012 11:58:20 -0700 (PDT) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 33CE611E8248 for ; Thu, 2 Aug 2012 11:58:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jmpolk@cisco.com; l=3321; q=dns/txt; s=iport; t=1343933900; x=1345143500; h=message-id:date:to:from:subject:in-reply-to:references: mime-version; bh=Zpqb6HZ3LxcBKtRHH1ZGX+zXu/7qQzpXzheb1ajhfoI=; b=aNGqdablXyUlcpn84/NRO1iahYK4SoEfBd94iZWMm3ZpBNnaOBgAwxz3 DIRcsln0dSV/klUJ1rwcppd1Qk7Qpvc87WTNig0BiNyXzy2ei5IJB8yoI Fb2ENsZY/28qDmLEJldkKiKvnxs/yvkWlpEY6YZ++I5ZHVJ/zSCoMNscA Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAKrNGlCrRDoI/2dsb2JhbABCA7kagQeCIAEBAQQSASUCLSIHBBgeEBk+BgESGgiHapx0oE+LSoNjgyEDiE2bIYFmgn0 X-IronPort-AV: E=Sophos;i="4.77,702,1336348800"; d="scan'208";a="53818948" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-4.cisco.com with ESMTP; 02 Aug 2012 18:57:59 +0000 Received: from jmpolk-WS.cisco.com ([10.21.168.247]) (authenticated bits=0) by mtv-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id q72IvwAs029956 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 2 Aug 2012 18:57:58 GMT Message-Id: <201208021857.q72IvwAs029956@mtv-core-3.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 02 Aug 2012 13:57:58 -0500 To: , From: James Polk In-Reply-To: <8D3D17ACE214DC429325B2B98F3AE71208E7FFB1@MX15A.corp.emc.co m> References: <8D3D17ACE214DC429325B2B98F3AE71208E7FFB1@MX15A.corp.emc.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Authenticated-User: jmpolk Subject: Re: [tsvwg] Diffserv discussion yesterday X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 18:58:21 -0000 David (as an individual/author) I agree with your first two bullets as stated. I also agree with bullet #3 that RFC 5127 needs to be updated, and agree SG12's liaison statement presentation (at least) gave the impression that these outer markings are inconsistent with between the 2 efforts (RFC 5127 and SG12's "question" on the topic). I think it was slide 5 of the SG12 Liaison preso that particularly caught my eye as to just how inconsistent the two are, and yet helped greatly determine that "the inner packet markings aren't to be overwritten or changed through SG12's effort". This was news to me, and I'm glad to have heard that finally. Maybe I was slow. It appears SG12 has a lot of different voice and video markings, yet RFC 5127 has only 1 treatment aggregate for "realtime". If there are to be synergies between the two documents, work on an agreement isn't really close - but might not be hard to achieve. I'm not sure, because discussion up until yesterday's presentations appears to have been talking past each other - perhaps - with neither side fully realizing just how far away we were talking. I feel partly responsible for that, and want to work towards fixing it immediately. Your bullet 4 is also good to know (from what Eliot said in the room), but we shouldn't wait until February to start this (as we authors often do with ID deadlines -- i.e., don't start the work until the weekend before the deadline)). This part I'm saying as much with my WG chair hat on as an individual. James At 11:07 AM 8/2/2012, david.black@emc.com wrote: >There was a lengthy discussion in yesterday's tsvwg meeting around James's >diffserv problem statement draft and the liaison from ITU-T SG12/Q17 on >QoS classes and markings for interconnection. > >Here's the summary of the interesting points that I captured from >the4 discussion: > >- We may be looking at a tunnel structure where the RFC 4594 classes >and markings > are used in the inner IP header (can be viewed as > enterprise-oriented), > but a much smaller number of classes/markings (e.g., see RFC 5127 and > ITU-T liaison) are used in the outer MPLS header's TC bits (can be > viewed as carrier- and inter-carrier-oriented). That > smaller number of > aggregates could also apply to the Ethernet priority field. >- The ITU-T liaison can be read as also asking if the treatment aggregates in > RFC 5127 are the right ones. This may be much more important than > whether the right RFC 4594 classes are in each RFC 5127 > traffic aggregate. >- In addition, RFC 5127 needs some more detailed work, e.g., as VOICE-ADMIT > isn't included, but figuring out whether RFC 5127 has the > right treatment > aggregates is more important. >- The response to the ITU-T liaison is not due until next March so >there is time > to consider the issues. > >Thanks, >--David >---------------------------------------------------- >David L. Black, Distinguished Engineer >EMC Corporation, 176 South St., Hopkinton, MA 01748 >+1 (508) 293-7953 FAX: +1 (508) 293-7786 >david.black@emc.com Mobile: +1 (978) 394-7754 >---------------------------------------------------- From david.black@emc.com Thu Aug 2 13:56:21 2012 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FB5B11E80FD for ; Thu, 2 Aug 2012 13:56:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.474 X-Spam-Level: X-Spam-Status: No, score=-102.474 tagged_above=-999 required=5 tests=[AWL=0.125, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OJRrQ70v5Zku for ; Thu, 2 Aug 2012 13:56:20 -0700 (PDT) Received: from mexforward.lss.emc.com (hop-nat-141.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id EFDB521F8A3F for ; Thu, 2 Aug 2012 13:56:19 -0700 (PDT) Received: from hop04-l1d11-si02.isus.emc.com (HOP04-L1D11-SI02.isus.emc.com [10.254.111.55]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q72KuIFR024558 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 2 Aug 2012 16:56:18 -0400 Received: from mailhub.lss.emc.com (mailhub.lss.emc.com [10.254.222.130]) by hop04-l1d11-si02.isus.emc.com (RSA Interceptor); Thu, 2 Aug 2012 16:56:02 -0400 Received: from mxhub02.corp.emc.com (mxhub02.corp.emc.com [10.254.141.104]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q72Ku00u018167; Thu, 2 Aug 2012 16:56:01 -0400 Received: from mx15a.corp.emc.com ([169.254.1.189]) by mxhub02.corp.emc.com ([10.254.141.104]) with mapi; Thu, 2 Aug 2012 16:56:00 -0400 From: To: , Date: Thu, 2 Aug 2012 16:55:55 -0400 Thread-Topic: [tsvwg] Diffserv discussion yesterday Thread-Index: Ac1w4NXNaNQx/HXPTN6T0s14vC8vLgAD4q5g Message-ID: <8D3D17ACE214DC429325B2B98F3AE71208E80071@MX15A.corp.emc.com> References: <8D3D17ACE214DC429325B2B98F3AE71208E7FFB1@MX15A.corp.emc.com> <201208021857.q72IvwAs029956@mtv-core-3.cisco.com> In-Reply-To: <201208021857.q72IvwAs029956@mtv-core-3.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EMM-MHVC: 1 Subject: Re: [tsvwg] Diffserv discussion yesterday X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 20:56:21 -0000 James, I think we're in agreement, and I would *definitely* like to see comments and opinions from others ... please do comment, as the implications of what we do here may be significant. I'm replying primarily to agree with your comment on the 4th bullet: > Your bullet 4 is also good to know (from what Eliot said in the > room), but we shouldn't wait until February to start this (as we > authors often do with ID deadlines -- i.e., don't start the work > until the weekend before the deadline)). This part I'm saying as much > with my WG chair hat on as an individual. Specifically, I think we need a clear understanding of what (if anything) we (the IETF transport area) intend to do to/with RFC 5127 before we can craft an effective liaison response. Thanks, --David > -----Original Message----- > From: James Polk [mailto:jmpolk@cisco.com] > Sent: Thursday, August 02, 2012 2:58 PM > To: Black, David; tsvwg@ietf.org > Subject: Re: [tsvwg] Diffserv discussion yesterday >=20 > David >=20 > (as an individual/author) >=20 > I agree with your first two bullets as stated. >=20 > I also agree with bullet #3 that RFC 5127 needs to be updated, and > agree SG12's liaison statement presentation (at least) gave the > impression that these outer markings are inconsistent with between > the 2 efforts (RFC 5127 and SG12's "question" on the topic). >=20 > I think it was slide 5 of the SG12 Liaison preso that particularly > caught my eye as to just how inconsistent the two are, and yet helped > greatly determine that "the inner packet markings aren't to be > overwritten or changed through SG12's effort". This was news to me, > and I'm glad to have heard that finally. Maybe I was slow. It appears > SG12 has a lot of different voice and video markings, yet RFC 5127 > has only 1 treatment aggregate for "realtime". If there are to be > synergies between the two documents, work on an agreement isn't > really close - but might not be hard to achieve. I'm not sure, > because discussion up until yesterday's presentations appears to have > been talking past each other - perhaps - with neither side fully > realizing just how far away we were talking. I feel partly > responsible for that, and want to work towards fixing it immediately. >=20 > Your bullet 4 is also good to know (from what Eliot said in the > room), but we shouldn't wait until February to start this (as we > authors often do with ID deadlines -- i.e., don't start the work > until the weekend before the deadline)). This part I'm saying as much > with my WG chair hat on as an individual. >=20 > James >=20 > At 11:07 AM 8/2/2012, david.black@emc.com wrote: > >There was a lengthy discussion in yesterday's tsvwg meeting around James= 's > >diffserv problem statement draft and the liaison from ITU-T SG12/Q17 on > >QoS classes and markings for interconnection. > > > >Here's the summary of the interesting points that I captured from > >the4 discussion: > > > >- We may be looking at a tunnel structure where the RFC 4594 classes and= markings > > are used in the inner IP header (can be viewed as enterprise- = oriented), > > but a much smaller number of classes/markings (e.g., see RFC 51= 27 and > > ITU-T liaison) are used in the outer MPLS header's TC bits (can= be > > viewed as carrier- and inter-carrier-oriented). That smaller n= umber of > > aggregates could also apply to the Ethernet priority field. > >- The ITU-T liaison can be read as also asking if the treatment aggregat= es in > > RFC 5127 are the right ones. This may be much more important t= han > > whether the right RFC 4594 classes are in each RFC 5127 traffic= aggregate. > >- In addition, RFC 5127 needs some more detailed work, e.g., as VOICE-AD= MIT > > isn't included, but figuring out whether RFC 5127 has the right= treatment > > aggregates is more important. > >- The response to the ITU-T liaison is not due until next March so there= is time > > to consider the issues. > > > >Thanks, > >--David > >---------------------------------------------------- > >David L. Black, Distinguished Engineer > >EMC Corporation, 176 South St., Hopkinton, MA 01748 > >+1 (508) 293-7953 FAX: +1 (508) 293-7786 > >david.black@emc.com Mobile: +1 (978) 394-7754 > >---------------------------------------------------- From jmpolk@cisco.com Thu Aug 2 14:38:15 2012 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B60821E80A0 for ; Thu, 2 Aug 2012 14:38:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.51 X-Spam-Level: X-Spam-Status: No, score=-110.51 tagged_above=-999 required=5 tests=[AWL=0.089, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8DYBZfB0yeNU for ; Thu, 2 Aug 2012 14:38:14 -0700 (PDT) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 3B5BD21E8095 for ; Thu, 2 Aug 2012 14:38:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jmpolk@cisco.com; l=6046; q=dns/txt; s=iport; t=1343943494; x=1345153094; h=message-id:date:to:from:subject:cc:in-reply-to: references:mime-version; bh=FeOgvmKB4vEHjuomWN0hrj0r59bL6QoUo8EQJ4+SREg=; b=USNChPtwTmOQMdAxte8et1DQCFCw8xdpKHO8ZthiZpQ8pbAJWM+HNQio b40ukO72ob5t18beSfaQ3jvzDDteykanch8dHiGTol6y+3aSiclhaW0ys bMGcEoqSGFvDygxEH3weSwLcTUKz1UsM2i9WZ669qVRwy539z/nSdBY/J I=; X-IronPort-AV: E=Sophos;i="4.77,703,1336348800"; d="scan'208";a="50807814" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-1.cisco.com with ESMTP; 02 Aug 2012 21:38:14 +0000 Received: from jmpolk-WS.cisco.com ([10.21.166.41]) (authenticated bits=0) by mtv-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id q72LcDtN024334 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 2 Aug 2012 21:38:13 GMT Message-Id: <201208022138.q72LcDtN024334@mtv-core-1.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 02 Aug 2012 16:38:13 -0500 To: , , From: James Polk In-Reply-To: <8D3D17ACE214DC429325B2B98F3AE71208E80071@MX15A.corp.emc.co m> References: <8D3D17ACE214DC429325B2B98F3AE71208E7FFB1@MX15A.corp.emc.com> <201208021857.q72IvwAs029956@mtv-core-3.cisco.com> <8D3D17ACE214DC429325B2B98F3AE71208E80071@MX15A.corp.emc.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Authenticated-User: jmpolk Subject: Re: [tsvwg] Diffserv discussion yesterday X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 21:38:15 -0000 At 03:55 PM 8/2/2012, david.black@emc.com wrote: >James, > >I think we're in agreement, and I would *definitely* like to see comments >and opinions from others ... please do comment, as the implications of >what we do here may be significant. > >I'm replying primarily to agree with your comment on the 4th bullet: > > > Your bullet 4 is also good to know (from what Eliot said in the > > room), but we shouldn't wait until February to start this (as we > > authors often do with ID deadlines -- i.e., don't start the work > > until the weekend before the deadline)). This part I'm saying as much > > with my WG chair hat on as an individual. > >Specifically, I think we need a clear understanding of what (if anything) >we (the IETF transport area) intend to do to/with RFC 5127 before we can >craft an effective liaison response. David Indeed, and we have a problem with timing on that one - which I'm sure you've figured out already. I know I don't own anything here, but I as I've said before I was planning write an update to RFC 5127, focusing on aligning it to whatever was agreed to for the update to RFC 4594 wrt any new service classes, and the agreed to names of each. The current update to RFC 4594 has several new service classes, and several existing ones renamed. This was going to me my focus of the RFC 5127 update, as I don't personally believe that it would receive the scale of rewrite that I've given to the update to RFC 4594. That said, with respect to the existing 4 treatment aggregates within RFC 5127, I was going to open up a fairly serious debate on whether there ought to be a 5th aggregate specifically for capacity-admitted service classes (which are already in the RFC 4594 update proposal). I don't know if this 5th aggregate is needed, but I think it might be. Getting all that hashed out before we craft the response to SG12's liaison statement will be challenging (at best), in my view, especially with the seen differences between SG12's liaison presentation table on slide 5 compared to the existing treatment aggregates in RFC 5127 (which I put into the DiffServ problem statement draft and presentation). James >Thanks, >--David > > > -----Original Message----- > > From: James Polk [mailto:jmpolk@cisco.com] > > Sent: Thursday, August 02, 2012 2:58 PM > > To: Black, David; tsvwg@ietf.org > > Subject: Re: [tsvwg] Diffserv discussion yesterday > > > > David > > > > (as an individual/author) > > > > I agree with your first two bullets as stated. > > > > I also agree with bullet #3 that RFC 5127 needs to be updated, and > > agree SG12's liaison statement presentation (at least) gave the > > impression that these outer markings are inconsistent with between > > the 2 efforts (RFC 5127 and SG12's "question" on the topic). > > > > I think it was slide 5 of the SG12 Liaison preso that particularly > > caught my eye as to just how inconsistent the two are, and yet helped > > greatly determine that "the inner packet markings aren't to be > > overwritten or changed through SG12's effort". This was news to me, > > and I'm glad to have heard that finally. Maybe I was slow. It appears > > SG12 has a lot of different voice and video markings, yet RFC 5127 > > has only 1 treatment aggregate for "realtime". If there are to be > > synergies between the two documents, work on an agreement isn't > > really close - but might not be hard to achieve. I'm not sure, > > because discussion up until yesterday's presentations appears to have > > been talking past each other - perhaps - with neither side fully > > realizing just how far away we were talking. I feel partly > > responsible for that, and want to work towards fixing it immediately. > > > > Your bullet 4 is also good to know (from what Eliot said in the > > room), but we shouldn't wait until February to start this (as we > > authors often do with ID deadlines -- i.e., don't start the work > > until the weekend before the deadline)). This part I'm saying as much > > with my WG chair hat on as an individual. > > > > James > > > > At 11:07 AM 8/2/2012, david.black@emc.com wrote: > > >There was a lengthy discussion in yesterday's tsvwg meeting around James's > > >diffserv problem statement draft and the liaison from ITU-T SG12/Q17 on > > >QoS classes and markings for interconnection. > > > > > >Here's the summary of the interesting points that I captured from > > >the4 discussion: > > > > > >- We may be looking at a tunnel structure where the RFC 4594 > classes and markings > > > are used in the inner IP header (can be viewed > as enterprise- oriented), > > > but a much smaller number of classes/markings (e.g., > see RFC 5127 and > > > ITU-T liaison) are used in the outer MPLS header's TC > bits (can be > > > viewed as carrier- and inter-carrier-oriented). That > smaller number of > > > aggregates could also apply to the Ethernet priority field. > > >- The ITU-T liaison can be read as also asking if the treatment > aggregates in > > > RFC 5127 are the right ones. This may be much more > important than > > > whether the right RFC 4594 classes are in each RFC 5127 > traffic aggregate. > > >- In addition, RFC 5127 needs some more detailed work, e.g., as > VOICE-ADMIT > > > isn't included, but figuring out whether RFC 5127 has > the right treatment > > > aggregates is more important. > > >- The response to the ITU-T liaison is not due until next March > so there is time > > > to consider the issues. > > > > > >Thanks, > > >--David > > >---------------------------------------------------- > > >David L. Black, Distinguished Engineer > > >EMC Corporation, 176 South St., Hopkinton, MA 01748 > > >+1 (508) 293-7953 FAX: +1 (508) 293-7786 > > >david.black@emc.com Mobile: +1 (978) 394-7754 > > >---------------------------------------------------- From lear@cisco.com Thu Aug 2 16:20:03 2012 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08F6821F8564 for ; Thu, 2 Aug 2012 16:20:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ot0-121midpF for ; Thu, 2 Aug 2012 16:20:02 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 18BDA11E814E for ; Thu, 2 Aug 2012 16:20:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=lear@cisco.com; l=677; q=dns/txt; s=iport; t=1343949602; x=1345159202; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=obxD8H/c8f8JLXqSYJbZbp/pU5msCe/zFCncoGySiUE=; b=RNEgAfBz7MFYU/TuPTkJ2JTGAgIiuiq1vzMg+j1355F6ECz3Yd8awz1c tLYGvD/oyRO+I+N6vEiflNMOqS/1wp0nSH4nV1ZcShYHuO2tMtDCpht0L Z3A0XiSjAGOvz4Yefdk3jhApWZxm+inbRd8m9vphaT/BxaC/zAExLierj s=; X-IronPort-AV: E=Sophos;i="4.77,704,1336348800"; d="scan'208";a="51357566" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-3.cisco.com with ESMTP; 02 Aug 2012 23:20:02 +0000 Received: from sjc-vpn4-563.cisco.com (sjc-vpn4-563.cisco.com [10.21.82.51]) by mtv-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q72NK1pH026240 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 2 Aug 2012 23:20:01 GMT Message-ID: <501B0B22.2050007@cisco.com> Date: Thu, 02 Aug 2012 16:20:02 -0700 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: James Polk References: <8D3D17ACE214DC429325B2B98F3AE71208E7FFB1@MX15A.corp.emc.com> <201208021857.q72IvwAs029956@mtv-core-3.cisco.com> <8D3D17ACE214DC429325B2B98F3AE71208E80071@MX15A.corp.emc.com> <201208022138.q72LcDtN024334@mtv-core-1.cisco.com> In-Reply-To: <201208022138.q72LcDtN024334@mtv-core-1.cisco.com> X-Enigmail-Version: 1.4.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: tsvwg@ietf.org Subject: Re: [tsvwg] Diffserv discussion yesterday X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 23:20:03 -0000 James, On 8/2/12 2:38 PM, James Polk wrote: > > Getting all that hashed out before we craft the response to SG12's > liaison statement will be challenging (at best), in my view, > especially with the seen differences between SG12's liaison > presentation table on slide 5 compared to the existing treatment > aggregates in RFC 5127 (which I put into the DiffServ problem > statement draft and presentation). I would suggest that you answer with what the working group has concluded around the time of the deadline, if you need to take that long. No need to rush, and you can always indicate problems and open questions that are raised by the work. Eliot From david.black@emc.com Thu Aug 2 16:47:47 2012 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5994E11E8118 for ; Thu, 2 Aug 2012 16:47:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.466 X-Spam-Level: X-Spam-Status: No, score=-102.466 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ERb55P2ujJSA for ; Thu, 2 Aug 2012 16:47:46 -0700 (PDT) Received: from mexforward.lss.emc.com (hop-nat-141.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id 4952311E8072 for ; Thu, 2 Aug 2012 16:47:45 -0700 (PDT) Received: from hop04-l1d11-si01.isus.emc.com (HOP04-L1D11-SI01.isus.emc.com [10.254.111.54]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q72Nliea003930 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 2 Aug 2012 19:47:44 -0400 Received: from mailhub.lss.emc.com (mailhubhoprd01.lss.emc.com [10.254.221.251]) by hop04-l1d11-si01.isus.emc.com (RSA Interceptor); Thu, 2 Aug 2012 19:47:29 -0400 Received: from mxhub05.corp.emc.com (mxhub05.corp.emc.com [128.222.70.202]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q72NlSWw005191; Thu, 2 Aug 2012 19:47:28 -0400 Received: from mx15a.corp.emc.com ([169.254.1.189]) by mxhub05.corp.emc.com ([128.222.70.202]) with mapi; Thu, 2 Aug 2012 19:47:27 -0400 From: To: , Date: Thu, 2 Aug 2012 19:47:26 -0400 Thread-Topic: [tsvwg] Diffserv discussion yesterday Thread-Index: Ac1w9zXjKKeDdlXLSlqw1ABTjcLKOwADSiQQ Message-ID: <8D3D17ACE214DC429325B2B98F3AE71208E8008C@MX15A.corp.emc.com> References: <8D3D17ACE214DC429325B2B98F3AE71208E7FFB1@MX15A.corp.emc.com> <201208021857.q72IvwAs029956@mtv-core-3.cisco.com> <8D3D17ACE214DC429325B2B98F3AE71208E80071@MX15A.corp.emc.com> <201208022138.q72LcDtN024334@mtv-core-1.cisco.com> In-Reply-To: <201208022138.q72LcDtN024334@mtv-core-1.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EMM-MHVC: 1 Subject: Re: [tsvwg] Diffserv discussion yesterday X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 23:47:47 -0000 James, I suggest engagement on the RFC 5127 aggregate discussion without waiting for a determination of which classes will and/or will not be added to RFC 4594. IMHO, it's not necessary to publish a 5127bis RFC based solely on the conclusion of the aggregate discussion. OTOH, once that discussion is concluded, I would hope that assignment of new classes in 4594bis to the applicable aggregates would be reasonably straightforward. Thanks, --David > -----Original Message----- > From: James Polk [mailto:jmpolk@cisco.com] > Sent: Thursday, August 02, 2012 5:38 PM > To: Black, David; jmpolk@cisco.com; tsvwg@ietf.org > Cc: Eliot Lear > Subject: RE: [tsvwg] Diffserv discussion yesterday >=20 > At 03:55 PM 8/2/2012, david.black@emc.com wrote: > >James, > > > >I think we're in agreement, and I would *definitely* like to see comment= s > >and opinions from others ... please do comment, as the implications of > >what we do here may be significant. > > > >I'm replying primarily to agree with your comment on the 4th bullet: > > > > > Your bullet 4 is also good to know (from what Eliot said in the > > > room), but we shouldn't wait until February to start this (as we > > > authors often do with ID deadlines -- i.e., don't start the work > > > until the weekend before the deadline)). This part I'm saying as much > > > with my WG chair hat on as an individual. > > > >Specifically, I think we need a clear understanding of what (if anything= ) > >we (the IETF transport area) intend to do to/with RFC 5127 before we can > >craft an effective liaison response. >=20 > David >=20 > Indeed, and we have a problem with timing on that one - which I'm > sure you've figured out already. I know I don't own anything here, > but I as I've said before I was planning write an update to RFC 5127, > focusing on aligning it to whatever was agreed to for the update to > RFC 4594 wrt any new service classes, and the agreed to names of > each. The current update to RFC 4594 has several new service classes, > and several existing ones renamed. This was going to me my focus of > the RFC 5127 update, as I don't personally believe that it would > receive the scale of rewrite that I've given to the update to RFC > 4594. That said, with respect to the existing 4 treatment aggregates > within RFC 5127, I was going to open up a fairly serious debate on > whether there ought to be a 5th aggregate specifically for > capacity-admitted service classes (which are already in the RFC 4594 > update proposal). I don't know if this 5th aggregate is needed, but I > think it might be. >=20 > Getting all that hashed out before we craft the response to SG12's > liaison statement will be challenging (at best), in my view, > especially with the seen differences between SG12's liaison > presentation table on slide 5 compared to the existing treatment > aggregates in RFC 5127 (which I put into the DiffServ problem > statement draft and presentation). >=20 > James >=20 >=20 > >Thanks, > >--David > > > > > -----Original Message----- > > > From: James Polk [mailto:jmpolk@cisco.com] > > > Sent: Thursday, August 02, 2012 2:58 PM > > > To: Black, David; tsvwg@ietf.org > > > Subject: Re: [tsvwg] Diffserv discussion yesterday > > > > > > David > > > > > > (as an individual/author) > > > > > > I agree with your first two bullets as stated. > > > > > > I also agree with bullet #3 that RFC 5127 needs to be updated, and > > > agree SG12's liaison statement presentation (at least) gave the > > > impression that these outer markings are inconsistent with between > > > the 2 efforts (RFC 5127 and SG12's "question" on the topic). > > > > > > I think it was slide 5 of the SG12 Liaison preso that particularly > > > caught my eye as to just how inconsistent the two are, and yet helped > > > greatly determine that "the inner packet markings aren't to be > > > overwritten or changed through SG12's effort". This was news to me, > > > and I'm glad to have heard that finally. Maybe I was slow. It appears > > > SG12 has a lot of different voice and video markings, yet RFC 5127 > > > has only 1 treatment aggregate for "realtime". If there are to be > > > synergies between the two documents, work on an agreement isn't > > > really close - but might not be hard to achieve. I'm not sure, > > > because discussion up until yesterday's presentations appears to have > > > been talking past each other - perhaps - with neither side fully > > > realizing just how far away we were talking. I feel partly > > > responsible for that, and want to work towards fixing it immediately. > > > > > > Your bullet 4 is also good to know (from what Eliot said in the > > > room), but we shouldn't wait until February to start this (as we > > > authors often do with ID deadlines -- i.e., don't start the work > > > until the weekend before the deadline)). This part I'm saying as much > > > with my WG chair hat on as an individual. > > > > > > James > > > > > > At 11:07 AM 8/2/2012, david.black@emc.com wrote: > > > >There was a lengthy discussion in yesterday's tsvwg meeting around > James's > > > >diffserv problem statement draft and the liaison from ITU-T SG12/Q17= on > > > >QoS classes and markings for interconnection. > > > > > > > >Here's the summary of the interesting points that I captured from > > > >the4 discussion: > > > > > > > >- We may be looking at a tunnel structure where the RFC 4594 > > classes and markings > > > > are used in the inner IP header (can be viewed > > as enterprise- oriented), > > > > but a much smaller number of classes/markings (e.g., > > see RFC 5127 and > > > > ITU-T liaison) are used in the outer MPLS header's TC > > bits (can be > > > > viewed as carrier- and inter-carrier-oriented). That > > smaller number of > > > > aggregates could also apply to the Ethernet priority field. > > > >- The ITU-T liaison can be read as also asking if the treatment > > aggregates in > > > > RFC 5127 are the right ones. This may be much more > > important than > > > > whether the right RFC 4594 classes are in each RFC 5127 > > traffic aggregate. > > > >- In addition, RFC 5127 needs some more detailed work, e.g., as > > VOICE-ADMIT > > > > isn't included, but figuring out whether RFC 5127 has > > the right treatment > > > > aggregates is more important. > > > >- The response to the ITU-T liaison is not due until next March > > so there is time > > > > to consider the issues. > > > > > > > >Thanks, > > > >--David > > > >---------------------------------------------------- > > > >David L. Black, Distinguished Engineer > > > >EMC Corporation, 176 South St., Hopkinton, MA 01748 > > > >+1 (508) 293-7953 FAX: +1 (508) 293-7786 > > > >david.black@emc.com Mobile: +1 (978) 394-7754 > > > >---------------------------------------------------- >=20 From rs@netapp.com Thu Aug 2 16:58:32 2012 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A77B211E8159 for ; Thu, 2 Aug 2012 16:58:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.134 X-Spam-Level: X-Spam-Status: No, score=-10.134 tagged_above=-999 required=5 tests=[AWL=0.465, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A5O4qvOH9Qyg for ; Thu, 2 Aug 2012 16:58:32 -0700 (PDT) Received: from mx2.netapp.com (mx2.netapp.com [216.240.18.37]) by ietfa.amsl.com (Postfix) with ESMTP id 0FA2811E8150 for ; Thu, 2 Aug 2012 16:58:32 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.77,704,1336374000"; d="scan'208";a="672433901" Received: from smtp2.corp.netapp.com ([10.57.159.114]) by mx2-out.netapp.com with ESMTP; 02 Aug 2012 16:58:29 -0700 Received: from vmwexceht03-prd.hq.netapp.com (vmwexceht03-prd.hq.netapp.com [10.106.76.241]) by smtp2.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id q72NwQkF023879; Thu, 2 Aug 2012 16:58:27 -0700 (PDT) Received: from SACEXCMBX02-PRD.hq.netapp.com ([169.254.1.34]) by vmwexceht03-prd.hq.netapp.com ([10.106.76.241]) with mapi id 14.02.0298.004; Thu, 2 Aug 2012 16:58:26 -0700 From: "Scheffenegger, Richard" To: "randall@lakerest.net" , "tuexen@fh-muenster.de" , "stevedong@huawei.com" Thread-Topic: draft-stewart-tsvwg-sctpecn Thread-Index: Ac1xCpQnt7Qi4CRkRDaO8iAwZyWYDA== Date: Thu, 2 Aug 2012 23:58:26 +0000 Message-ID: <012C3117EDDB3C4781FD802A8C27DD4F0D4E24FC@SACEXCMBX02-PRD.hq.netapp.com> Accept-Language: de-AT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.104.60.116] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "gorry@erg.abdn.ac.uk" , "Matthew Mathis \(mattmathis@google.com\)" , "tsvwg@ietf.org" Subject: [tsvwg] draft-stewart-tsvwg-sctpecn X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 23:58:32 -0000 Hi, While looking as to how other protocol do ECN feedback signaling, I found t= hat this draft is missing (at least not mentioning) an interesting detail. The existence of a CWR Chunk indicates, that the feedback signal is suppose= d to be reliable. However, the ECN Echo chunk defines the Number of CE marked Packets as 32-b= it unsigned int, and does not specify how a receiver should behave it never= received a CWR chunk... The sheer size of the ECN Echo chunk would lend itself to be a simple feedb= ack signal, without any explicit signal from the sender. Historically, in RFC4960, it appears that this chunk effectively contained = only a single bit (no counter; only the presence of the chunk). In order to= establish a reliable feedback for at most one ECN signal per RTT, a handsh= ake mechanism (CWR chunk) is required. That mechanism was very much alike w= hat TCP does with ECE / CWR. IMHO, this draft should be more clear around the mechanism: If a handshake is required, the 32-bit counter MUST NOT roll over at 2^32-1= , but remain at that value until CWR is received. The sheer size of the counter however makes it highly unlikely that the sen= der will not receive a signal (before the session collapses for lack of fee= dback from the receiver). So a handshake-less (CWR chunk optional on the se= nder?) is also feasible, but then the ECN counter MUST roll over... As it stands now, the counter rolls over, and is reset via CWR... Are there any specific reasons for this chimera mechanism?=20 Does it allow for special use cases, which cannot be addressed by either ha= ndshake or simple counter alone? I'm very interested in the answers to the last two questions, as I am one o= f the authors of an Accurate ECN feedback draft for TCP, and TCPM has a mil= estone to define an appropriate (accurate) feedback mechanism that allows m= ore than 1 bit per RTT...=20 Best regards, Richard Scheffenegger > draft-stewart-tsvwg-sctpecn-02 > Partially replaces (draft-stewart-tsvwg-sctp-nonce) > IETF-78 suggested there was interest in this topic. > Discussed at IETF-83, Paris. > DUE: ECN is within the TSVWG Charter, > will call for adoption on the list. > Please comment on list. From jmpolk@cisco.com Thu Aug 2 18:39:44 2012 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCDA311E80A6 for ; Thu, 2 Aug 2012 18:39:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.513 X-Spam-Level: X-Spam-Status: No, score=-110.513 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AZPLqwHH2L3Y for ; Thu, 2 Aug 2012 18:39:43 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id D1C6211E80A4 for ; Thu, 2 Aug 2012 18:39:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jmpolk@cisco.com; l=763; q=dns/txt; s=iport; t=1343957983; x=1345167583; h=message-id:date:to:from:subject:cc:in-reply-to: references:mime-version; bh=5VMDSX2fHrxDdE+AuzCGnz0OOIZAtGS6XUbURahrdS4=; b=Bfipxz2+A9zeGNtY/bqxVkPe2Txx77zU0w6qH838sjK4kR306iEG46mR J94m+brOa6NGAVNhfsjG18QUdxFS5+OXYoA2F+TDaSbwb0L2YoY7iyNR0 XAh/Qj+bByBoC9BqvyRina5tvjIqx6r/1tNnPxnNZPuqOY8d5cvMe10HQ 4=; X-IronPort-AV: E=Sophos;i="4.77,704,1336348800"; d="scan'208";a="51365510" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-3.cisco.com with ESMTP; 03 Aug 2012 01:39:43 +0000 Received: from jmpolk-WS.cisco.com ([10.21.166.204]) (authenticated bits=0) by mtv-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id q731dhF7014543 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 3 Aug 2012 01:39:43 GMT Message-Id: <201208030139.q731dhF7014543@mtv-core-1.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 02 Aug 2012 20:39:42 -0500 To: Eliot Lear , James Polk From: James Polk In-Reply-To: <501B0B22.2050007@cisco.com> References: <8D3D17ACE214DC429325B2B98F3AE71208E7FFB1@MX15A.corp.emc.com> <201208021857.q72IvwAs029956@mtv-core-3.cisco.com> <8D3D17ACE214DC429325B2B98F3AE71208E80071@MX15A.corp.emc.com> <201208022138.q72LcDtN024334@mtv-core-1.cisco.com> <501B0B22.2050007@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Authenticated-User: jmpolk Cc: tsvwg@ietf.org Subject: Re: [tsvwg] Diffserv discussion yesterday X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Aug 2012 01:39:44 -0000 At 06:20 PM 8/2/2012, Eliot Lear wrote: >James, > > >On 8/2/12 2:38 PM, James Polk wrote: > > > > Getting all that hashed out before we craft the response to SG12's > > liaison statement will be challenging (at best), in my view, > > especially with the seen differences between SG12's liaison > > presentation table on slide 5 compared to the existing treatment > > aggregates in RFC 5127 (which I put into the DiffServ problem > > statement draft and presentation). > >I would suggest that you answer with what the working group has >concluded around the time of the deadline, if you need to take that >long. No need to rush, and you can always indicate problems and open >questions that are raised by the work. agreed James >Eliot From jmpolk@cisco.com Thu Aug 2 18:47:53 2012 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AAD421F8C5C for ; Thu, 2 Aug 2012 18:47:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.514 X-Spam-Level: X-Spam-Status: No, score=-110.514 tagged_above=-999 required=5 tests=[AWL=0.085, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WcUAQO03GABg for ; Thu, 2 Aug 2012 18:47:52 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 4B1C721F8C58 for ; Thu, 2 Aug 2012 18:47:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jmpolk@cisco.com; l=7993; q=dns/txt; s=iport; t=1343958472; x=1345168072; h=message-id:date:to:from:subject:cc:in-reply-to: references:mime-version; bh=9gJWMittKg8B0StFArf20NSWWP+ywMPSDJJmnvt3ra0=; b=fWsPpTFRLdEfqL3Sp+hOKttkOL0VsKiws9oGxSBoia8qoN1EMP8IsHy6 PIJPlyM6XVXBpc3LB1+Nw5dFyb+vIyuPEON0o9+LX+Jz9pEQ+QUP93zkK wv0J5Ya4o2jZGmJHyFxBMPJgXAHnxbREp36b52ZUTTjRb6IMHAj8RKxKD w=; X-IronPort-AV: E=Sophos;i="4.77,704,1336348800"; d="scan'208";a="51365882" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-3.cisco.com with ESMTP; 03 Aug 2012 01:47:52 +0000 Received: from jmpolk-WS.cisco.com ([10.21.166.204]) (authenticated bits=0) by mtv-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q731lpZd029644 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 3 Aug 2012 01:47:51 GMT Message-Id: <201208030147.q731lpZd029644@mtv-core-2.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 02 Aug 2012 20:47:51 -0500 To: , , From: James Polk In-Reply-To: <8D3D17ACE214DC429325B2B98F3AE71208E8008C@MX15A.corp.emc.co m> References: <8D3D17ACE214DC429325B2B98F3AE71208E7FFB1@MX15A.corp.emc.com> <201208021857.q72IvwAs029956@mtv-core-3.cisco.com> <8D3D17ACE214DC429325B2B98F3AE71208E80071@MX15A.corp.emc.com> <201208022138.q72LcDtN024334@mtv-core-1.cisco.com> <8D3D17ACE214DC429325B2B98F3AE71208E8008C@MX15A.corp.emc.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Authenticated-User: jmpolk Subject: Re: [tsvwg] Diffserv discussion yesterday X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Aug 2012 01:47:53 -0000 David Yes, I agree this liaison request is accelerating the work on 5127bis due to the disparity in treatment aggregates vs. what SG12 wants in their recommendation. I fully expect both the 4594bis (as you call it) and 5127bis documents to align as soon as is possible on both the service classes including names) and number and names of treatment aggregates. I'll open a dialog with Al and Ruediger about exactly what they are expecting or wanting the treatment aggregates to change to, as well as what goes in each. I want to understand that a lot better. In that understanding, perhaps we can reach common ground. James At 06:47 PM 8/2/2012, david.black@emc.com wrote: >James, > >I suggest engagement on the RFC 5127 aggregate discussion without >waiting for a determination of which classes will and/or will not >be added to RFC 4594. > >IMHO, it's not necessary to publish a 5127bis RFC based solely on >the conclusion of the aggregate discussion. OTOH, once that >discussion is concluded, I would hope that assignment of new classes >in 4594bis to the applicable aggregates would be reasonably >straightforward. > >Thanks, >--David > > > -----Original Message----- > > From: James Polk [mailto:jmpolk@cisco.com] > > Sent: Thursday, August 02, 2012 5:38 PM > > To: Black, David; jmpolk@cisco.com; tsvwg@ietf.org > > Cc: Eliot Lear > > Subject: RE: [tsvwg] Diffserv discussion yesterday > > > > At 03:55 PM 8/2/2012, david.black@emc.com wrote: > > >James, > > > > > >I think we're in agreement, and I would *definitely* like to see comments > > >and opinions from others ... please do comment, as the implications of > > >what we do here may be significant. > > > > > >I'm replying primarily to agree with your comment on the 4th bullet: > > > > > > > Your bullet 4 is also good to know (from what Eliot said in the > > > > room), but we shouldn't wait until February to start this (as we > > > > authors often do with ID deadlines -- i.e., don't start the work > > > > until the weekend before the deadline)). This part I'm saying as much > > > > with my WG chair hat on as an individual. > > > > > >Specifically, I think we need a clear understanding of what (if anything) > > >we (the IETF transport area) intend to do to/with RFC 5127 before we can > > >craft an effective liaison response. > > > > David > > > > Indeed, and we have a problem with timing on that one - which I'm > > sure you've figured out already. I know I don't own anything here, > > but I as I've said before I was planning write an update to RFC 5127, > > focusing on aligning it to whatever was agreed to for the update to > > RFC 4594 wrt any new service classes, and the agreed to names of > > each. The current update to RFC 4594 has several new service classes, > > and several existing ones renamed. This was going to me my focus of > > the RFC 5127 update, as I don't personally believe that it would > > receive the scale of rewrite that I've given to the update to RFC > > 4594. That said, with respect to the existing 4 treatment aggregates > > within RFC 5127, I was going to open up a fairly serious debate on > > whether there ought to be a 5th aggregate specifically for > > capacity-admitted service classes (which are already in the RFC 4594 > > update proposal). I don't know if this 5th aggregate is needed, but I > > think it might be. > > > > Getting all that hashed out before we craft the response to SG12's > > liaison statement will be challenging (at best), in my view, > > especially with the seen differences between SG12's liaison > > presentation table on slide 5 compared to the existing treatment > > aggregates in RFC 5127 (which I put into the DiffServ problem > > statement draft and presentation). > > > > James > > > > > > >Thanks, > > >--David > > > > > > > -----Original Message----- > > > > From: James Polk [mailto:jmpolk@cisco.com] > > > > Sent: Thursday, August 02, 2012 2:58 PM > > > > To: Black, David; tsvwg@ietf.org > > > > Subject: Re: [tsvwg] Diffserv discussion yesterday > > > > > > > > David > > > > > > > > (as an individual/author) > > > > > > > > I agree with your first two bullets as stated. > > > > > > > > I also agree with bullet #3 that RFC 5127 needs to be updated, and > > > > agree SG12's liaison statement presentation (at least) gave the > > > > impression that these outer markings are inconsistent with between > > > > the 2 efforts (RFC 5127 and SG12's "question" on the topic). > > > > > > > > I think it was slide 5 of the SG12 Liaison preso that particularly > > > > caught my eye as to just how inconsistent the two are, and yet helped > > > > greatly determine that "the inner packet markings aren't to be > > > > overwritten or changed through SG12's effort". This was news to me, > > > > and I'm glad to have heard that finally. Maybe I was slow. It appears > > > > SG12 has a lot of different voice and video markings, yet RFC 5127 > > > > has only 1 treatment aggregate for "realtime". If there are to be > > > > synergies between the two documents, work on an agreement isn't > > > > really close - but might not be hard to achieve. I'm not sure, > > > > because discussion up until yesterday's presentations appears to have > > > > been talking past each other - perhaps - with neither side fully > > > > realizing just how far away we were talking. I feel partly > > > > responsible for that, and want to work towards fixing it immediately. > > > > > > > > Your bullet 4 is also good to know (from what Eliot said in the > > > > room), but we shouldn't wait until February to start this (as we > > > > authors often do with ID deadlines -- i.e., don't start the work > > > > until the weekend before the deadline)). This part I'm saying as much > > > > with my WG chair hat on as an individual. > > > > > > > > James > > > > > > > > At 11:07 AM 8/2/2012, david.black@emc.com wrote: > > > > >There was a lengthy discussion in yesterday's tsvwg meeting around > > James's > > > > >diffserv problem statement draft and the liaison from ITU-T > SG12/Q17 on > > > > >QoS classes and markings for interconnection. > > > > > > > > > >Here's the summary of the interesting points that I captured from > > > > >the4 discussion: > > > > > > > > > >- We may be looking at a tunnel structure where the RFC 4594 > > > classes and markings > > > > > are used in the inner IP header (can be viewed > > > as enterprise- oriented), > > > > > but a much smaller number of classes/markings (e.g., > > > see RFC 5127 and > > > > > ITU-T liaison) are used in the outer MPLS header's TC > > > bits (can be > > > > > viewed as carrier- and inter-carrier-oriented). That > > > smaller number of > > > > > aggregates could also apply to the Ethernet priority field. > > > > >- The ITU-T liaison can be read as also asking if the treatment > > > aggregates in > > > > > RFC 5127 are the right ones. This may be much more > > > important than > > > > > whether the right RFC 4594 classes are in each RFC 5127 > > > traffic aggregate. > > > > >- In addition, RFC 5127 needs some more detailed work, e.g., as > > > VOICE-ADMIT > > > > > isn't included, but figuring out whether RFC 5127 has > > > the right treatment > > > > > aggregates is more important. > > > > >- The response to the ITU-T liaison is not due until next March > > > so there is time > > > > > to consider the issues. > > > > > > > > > >Thanks, > > > > >--David > > > > >---------------------------------------------------- > > > > >David L. Black, Distinguished Engineer > > > > >EMC Corporation, 176 South St., Hopkinton, MA 01748 > > > > >+1 (508) 293-7953 FAX: +1 (508) 293-7786 > > > > >david.black@emc.com Mobile: +1 (978) 394-7754 > > > > >---------------------------------------------------- > > From randall@lakerest.net Fri Aug 3 08:40:15 2012 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E64821F8D33 for ; Fri, 3 Aug 2012 08:40:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 54UGaDTxw5bL for ; Fri, 3 Aug 2012 08:40:13 -0700 (PDT) Received: from lakerest.net (lakerest.net [70.155.160.98]) by ietfa.amsl.com (Postfix) with ESMTP id 1F14F21F8D36 for ; Fri, 3 Aug 2012 08:40:13 -0700 (PDT) Received: from [10.1.1.141] (bsd3.lakerest.net [70.155.160.101]) (authenticated bits=0) by lakerest.net (8.14.4/8.14.3) with ESMTP id q73FZMSZ001111 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 3 Aug 2012 11:35:23 -0400 (EDT) (envelope-from randall@lakerest.net) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=windows-1252 From: Randy Stewart In-Reply-To: <012C3117EDDB3C4781FD802A8C27DD4F0D4E24FC@SACEXCMBX02-PRD.hq.netapp.com> Date: Fri, 3 Aug 2012 11:35:22 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <04876CA5-E6F8-4FFF-83B0-D0CBAF101E08@lakerest.net> References: <012C3117EDDB3C4781FD802A8C27DD4F0D4E24FC@SACEXCMBX02-PRD.hq.netapp.com> To: "Scheffenegger, Richard" X-Mailer: Apple Mail (2.1278) Cc: "gorry@erg.abdn.ac.uk" , "tsvwg@ietf.org" , "tuexen@fh-muenster.de" , "Matthew Mathis \(mattmathis@google.com\)" , "stevedong@huawei.com" Subject: Re: [tsvwg] draft-stewart-tsvwg-sctpecn X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Aug 2012 15:40:15 -0000 Richard: Well maybe am mis-understanding your comments. Are you concerned that the counter really should not roll over? This would require 2Billion attempts at sending an update CWR. This is a = bit far-fetched so I never thought about it ever happening. Now the counter does not have a defined use, sort of like the duplicate = receipts of TSN's in the SACK. I was playing with it actually in a different CC algorithm = and thought it=20 was a good idea to have for future work since its easily obtainable. As far as what to do when you don't get a CWR=85 hmm let me re-read the = document. You are supposed to (like TCP) continue to retransmit ECN Echo chunks until a = CWR is received Maybe I missed that statement in the document. R On Aug 2, 2012, at 7:58 PM, Scheffenegger, Richard wrote: > Hi, >=20 >=20 > While looking as to how other protocol do ECN feedback signaling, I = found that this draft is missing (at least not mentioning) an = interesting detail. >=20 > The existence of a CWR Chunk indicates, that the feedback signal is = supposed to be reliable. >=20 > However, the ECN Echo chunk defines the Number of CE marked Packets as = 32-bit unsigned int, and does not specify how a receiver should behave = it never received a CWR chunk... >=20 > The sheer size of the ECN Echo chunk would lend itself to be a simple = feedback signal, without any explicit signal from the sender. >=20 > Historically, in RFC4960, it appears that this chunk effectively = contained only a single bit (no counter; only the presence of the = chunk). In order to establish a reliable feedback for at most one ECN = signal per RTT, a handshake mechanism (CWR chunk) is required. That = mechanism was very much alike what TCP does with ECE / CWR. >=20 >=20 >=20 > IMHO, this draft should be more clear around the mechanism: >=20 > If a handshake is required, the 32-bit counter MUST NOT roll over at = 2^32-1, but remain at that value until CWR is received. >=20 > The sheer size of the counter however makes it highly unlikely that = the sender will not receive a signal (before the session collapses for = lack of feedback from the receiver). So a handshake-less (CWR chunk = optional on the sender?) is also feasible, but then the ECN counter MUST = roll over... >=20 >=20 > As it stands now, the counter rolls over, and is reset via CWR... >=20 > Are there any specific reasons for this chimera mechanism?=20 >=20 > Does it allow for special use cases, which cannot be addressed by = either handshake or simple counter alone? >=20 > I'm very interested in the answers to the last two questions, as I am = one of the authors of an Accurate ECN feedback draft for TCP, and TCPM = has a milestone to define an appropriate (accurate) feedback mechanism = that allows more than 1 bit per RTT...=20 >=20 > Best regards, >=20 > Richard Scheffenegger >=20 >> draft-stewart-tsvwg-sctpecn-02 >> Partially replaces (draft-stewart-tsvwg-sctp-nonce) >> IETF-78 suggested there was interest in this topic. >> Discussed at IETF-83, Paris. >> DUE: ECN is within the TSVWG Charter, >> will call for adoption on the list. >> Please comment on list. >=20 >=20 ----- Randall Stewart randall@lakerest.net From randall@lakerest.net Fri Aug 3 08:56:36 2012 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AE5921F8E19 for ; Fri, 3 Aug 2012 08:56:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id okcW6VHfgrth for ; Fri, 3 Aug 2012 08:56:35 -0700 (PDT) Received: from lakerest.net (lakerest.net [70.155.160.98]) by ietfa.amsl.com (Postfix) with ESMTP id F2C7321F8E20 for ; Fri, 3 Aug 2012 08:56:34 -0700 (PDT) Received: from [10.1.1.141] (bsd3.lakerest.net [70.155.160.101]) (authenticated bits=0) by lakerest.net (8.14.4/8.14.3) with ESMTP id q73FqcY0001393 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 3 Aug 2012 11:52:39 -0400 (EDT) (envelope-from randall@lakerest.net) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Randy Stewart In-Reply-To: <012C3117EDDB3C4781FD802A8C27DD4F0D4E24FC@SACEXCMBX02-PRD.hq.netapp.com> Date: Fri, 3 Aug 2012 11:52:38 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <955ED31B-9201-43FA-8C8C-13B622DB2D80@lakerest.net> References: <012C3117EDDB3C4781FD802A8C27DD4F0D4E24FC@SACEXCMBX02-PRD.hq.netapp.com> To: "Scheffenegger, Richard" X-Mailer: Apple Mail (2.1278) Cc: "gorry@erg.abdn.ac.uk" , "tsvwg@ietf.org" , "tuexen@fh-muenster.de" , "Matthew Mathis \(mattmathis@google.com\)" , "stevedong@huawei.com" Subject: Re: [tsvwg] draft-stewart-tsvwg-sctpecn X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Aug 2012 15:56:36 -0000 Richard: Hmm Re-reading the document a bit, I don't see that it does not tell you to retransmit the chunk in the receiver side (5.3) we state: " After transmission of the ECN Echo chunk, usually bundled with the SACK, the receiver does NOT discard the ECN Echo chunk. Instead it keeps the chunk in its queue and continues to send this chunk bundled with at least a SACK chunk on each outgoing packet, updating it as described above if other CE codepoint data packets arrive. The ECN Echo chunk should only be discarded when a CWR Chunk arrives holding a TSN value that is greater than or equal to the value inside the ECN Echo Chunk. " If this is not clear enough please let me know a wording that would make = it clearer. Note that the ECN echo continues to be received until a CWR shows up with a TSN number at least as big as the TSN sent in the ECN Echo. R On Aug 2, 2012, at 7:58 PM, Scheffenegger, Richard wrote: > Hi, >=20 >=20 > While looking as to how other protocol do ECN feedback signaling, I = found that this draft is missing (at least not mentioning) an = interesting detail. >=20 > The existence of a CWR Chunk indicates, that the feedback signal is = supposed to be reliable. >=20 > However, the ECN Echo chunk defines the Number of CE marked Packets as = 32-bit unsigned int, and does not specify how a receiver should behave = it never received a CWR chunk... >=20 > The sheer size of the ECN Echo chunk would lend itself to be a simple = feedback signal, without any explicit signal from the sender. >=20 > Historically, in RFC4960, it appears that this chunk effectively = contained only a single bit (no counter; only the presence of the = chunk). In order to establish a reliable feedback for at most one ECN = signal per RTT, a handshake mechanism (CWR chunk) is required. That = mechanism was very much alike what TCP does with ECE / CWR. >=20 >=20 >=20 > IMHO, this draft should be more clear around the mechanism: >=20 > If a handshake is required, the 32-bit counter MUST NOT roll over at = 2^32-1, but remain at that value until CWR is received. >=20 > The sheer size of the counter however makes it highly unlikely that = the sender will not receive a signal (before the session collapses for = lack of feedback from the receiver). So a handshake-less (CWR chunk = optional on the sender?) is also feasible, but then the ECN counter MUST = roll over... >=20 >=20 > As it stands now, the counter rolls over, and is reset via CWR... >=20 > Are there any specific reasons for this chimera mechanism?=20 >=20 > Does it allow for special use cases, which cannot be addressed by = either handshake or simple counter alone? >=20 > I'm very interested in the answers to the last two questions, as I am = one of the authors of an Accurate ECN feedback draft for TCP, and TCPM = has a milestone to define an appropriate (accurate) feedback mechanism = that allows more than 1 bit per RTT...=20 >=20 > Best regards, >=20 > Richard Scheffenegger >=20 >> draft-stewart-tsvwg-sctpecn-02 >> Partially replaces (draft-stewart-tsvwg-sctp-nonce) >> IETF-78 suggested there was interest in this topic. >> Discussed at IETF-83, Paris. >> DUE: ECN is within the TSVWG Charter, >> will call for adoption on the list. >> Please comment on list. >=20 >=20 ----- Randall Stewart randall@lakerest.net From rs@netapp.com Fri Aug 3 09:17:10 2012 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC96B21F8E49 for ; Fri, 3 Aug 2012 09:17:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.176 X-Spam-Level: X-Spam-Status: No, score=-10.176 tagged_above=-999 required=5 tests=[AWL=0.423, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gs11bHwyVBvO for ; Fri, 3 Aug 2012 09:17:09 -0700 (PDT) Received: from mx2.netapp.com (mx2.netapp.com [216.240.18.37]) by ietfa.amsl.com (Postfix) with ESMTP id D78DD21F8E50 for ; Fri, 3 Aug 2012 09:17:09 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.77,707,1336374000"; d="scan'208";a="672883927" Received: from smtp1.corp.netapp.com ([10.57.156.124]) by mx2-out.netapp.com with ESMTP; 03 Aug 2012 09:17:09 -0700 Received: from vmwexceht01-prd.hq.netapp.com (vmwexceht01-prd.hq.netapp.com [10.106.76.239]) by smtp1.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id q73GH9a5019863; Fri, 3 Aug 2012 09:17:09 -0700 (PDT) Received: from SACEXCMBX02-PRD.hq.netapp.com ([169.254.1.34]) by vmwexceht01-prd.hq.netapp.com ([10.106.76.239]) with mapi id 14.02.0298.004; Fri, 3 Aug 2012 09:17:09 -0700 From: "Scheffenegger, Richard" To: Randy Stewart Thread-Topic: [tsvwg] draft-stewart-tsvwg-sctpecn Thread-Index: Ac1xCpQnt7Qi4CRkRDaO8iAwZyWYDAAwBnUAAA5sUDA= Date: Fri, 3 Aug 2012 16:17:08 +0000 Message-ID: <012C3117EDDB3C4781FD802A8C27DD4F0D4E3811@SACEXCMBX02-PRD.hq.netapp.com> References: <012C3117EDDB3C4781FD802A8C27DD4F0D4E24FC@SACEXCMBX02-PRD.hq.netapp.com> <955ED31B-9201-43FA-8C8C-13B622DB2D80@lakerest.net> In-Reply-To: <955ED31B-9201-43FA-8C8C-13B622DB2D80@lakerest.net> Accept-Language: de-AT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.104.60.115] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "gorry@erg.abdn.ac.uk" , "tsvwg@ietf.org" , "tuexen@fh-muenster.de" , "Matthew Mathis \(mattmathis@google.com\)" , "stevedong@huawei.com" Subject: Re: [tsvwg] draft-stewart-tsvwg-sctpecn X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Aug 2012 16:17:10 -0000 Hi Randy, My point being, that it is not clear, architecturally, if the mechanism imp= lements a reliable feedback, or not. The way TCP (3168) signals ECN is, that you have a counter that counts up t= o a specific maximum value, and remains at that value until reset. In TCP, = that counter is only 1 bit (ECE), and CWR is the reset signal. Now, when the counter is large enough (5+ bits), the resiliency no longer r= equires a reset signal (statistically), as the counter is increasingly unli= kely to wrap over unnoticed. So with a 32 bit counter, you can do away with= the CWR signal entirely. Or is there any use to the receiver to know when = the sender has reacted to congestion (by an unknown extent)? (Historically,= SCTP implemented the same one-bit counter/reset scheme that TCP did, IIRC;= so CWR is really only relevant for legacy compatibility, correct?). Since the receiver resets the ECN counter only if it receives a CWR with th= e appropriate TSN, that means that you implicitly require at least one RTT = without a CE mark, for that to happen... Assume a pretty congested network, where you'll get one CE mark per RTT (an= d the source doesn't react traditionally with halving the sending rate), th= en the counter can increase continuously. Understanding the concept (counte= r with reset, pure counter) would answer what the receiver is to do when th= e counter hits 2^32-1... I am bringing this up because for TCP, a single bit counter is insufficient= for the requirements of Conex; and I want to understand if the signaling s= cheme was given thorough thought that I could leverage for a redesign in th= e TCP space... I do agree, that when one excludes misbehaving implementations, this questi= on is more of academic interest rather than a true issue of a deployment fo= llowing the draft, owed to the large counter. Richard Scheffenegger > -----Original Message----- > From: Randy Stewart [mailto:randall@lakerest.net] > Sent: Freitag, 03. August 2012 08:53 > To: Scheffenegger, Richard > Cc: tuexen@fh-muenster.de; stevedong@huawei.com; gorry@erg.abdn.ac.uk; > Matthew Mathis (mattmathis@google.com); tsvwg@ietf.org > Subject: Re: [tsvwg] draft-stewart-tsvwg-sctpecn >=20 > Richard: >=20 > Hmm >=20 > Re-reading the document a bit, I don't see that it does not tell you to > retransmit the chunk in the receiver side (5.3) we state: >=20 > " > After transmission of the ECN Echo chunk, usually bundled with the > SACK, the receiver does NOT discard the ECN Echo chunk. Instead it > keeps the chunk in its queue and continues to send this chunk bundled > with at least a SACK chunk on each outgoing packet, updating it as > described above if other CE codepoint data packets arrive. The ECN > Echo chunk should only be discarded when a CWR Chunk arrives holding > a TSN value that is greater than or equal to the value inside the ECN > Echo Chunk. > " >=20 > If this is not clear enough please let me know a wording that would make > it clearer. >=20 > Note that the ECN echo continues to be received until a CWR shows up with > a TSN number at least as big as the TSN sent in the ECN Echo. >=20 > R >=20 > On Aug 2, 2012, at 7:58 PM, Scheffenegger, Richard wrote: >=20 > > Hi, > > > > > > While looking as to how other protocol do ECN feedback signaling, I > found that this draft is missing (at least not mentioning) an interesting > detail. > > > > The existence of a CWR Chunk indicates, that the feedback signal is > supposed to be reliable. > > > > However, the ECN Echo chunk defines the Number of CE marked Packets as > 32-bit unsigned int, and does not specify how a receiver should behave it > never received a CWR chunk... > > > > The sheer size of the ECN Echo chunk would lend itself to be a simple > feedback signal, without any explicit signal from the sender. > > > > Historically, in RFC4960, it appears that this chunk effectively > contained only a single bit (no counter; only the presence of the chunk). > In order to establish a reliable feedback for at most one ECN signal per > RTT, a handshake mechanism (CWR chunk) is required. That mechanism was > very much alike what TCP does with ECE / CWR. > > > > > > > > IMHO, this draft should be more clear around the mechanism: > > > > If a handshake is required, the 32-bit counter MUST NOT roll over at > 2^32-1, but remain at that value until CWR is received. > > > > The sheer size of the counter however makes it highly unlikely that the > sender will not receive a signal (before the session collapses for lack o= f > feedback from the receiver). So a handshake-less (CWR chunk optional on > the sender?) is also feasible, but then the ECN counter MUST roll over... > > > > > > As it stands now, the counter rolls over, and is reset via CWR... > > > > Are there any specific reasons for this chimera mechanism? > > > > Does it allow for special use cases, which cannot be addressed by eithe= r > handshake or simple counter alone? > > > > I'm very interested in the answers to the last two questions, as I am > one of the authors of an Accurate ECN feedback draft for TCP, and TCPM ha= s > a milestone to define an appropriate (accurate) feedback mechanism that > allows more than 1 bit per RTT... > > > > Best regards, > > > > Richard Scheffenegger > > > >> draft-stewart-tsvwg-sctpecn-02 > >> Partially replaces (draft-stewart-tsvwg-sctp-nonce) > >> IETF-78 suggested there was interest in this topic. > >> Discussed at IETF-83, Paris. > >> DUE: ECN is within the TSVWG Charter, will call for adoption on the > >> list. > >> Please comment on list. > > > > >=20 > ----- > Randall Stewart > randall@lakerest.net >=20 >=20 >=20 From randall@lakerest.net Fri Aug 3 10:31:38 2012 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6BC521F8D60 for ; Fri, 3 Aug 2012 10:31:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id domv6E1PzWyD for ; Fri, 3 Aug 2012 10:31:36 -0700 (PDT) Received: from lakerest.net (lakerest.net [70.155.160.98]) by ietfa.amsl.com (Postfix) with ESMTP id 7ACC821F8D7D for ; Fri, 3 Aug 2012 10:31:28 -0700 (PDT) Received: from [10.1.1.141] (bsd3.lakerest.net [70.155.160.101]) (authenticated bits=0) by lakerest.net (8.14.4/8.14.3) with ESMTP id q73HRVJg002553 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 3 Aug 2012 13:27:32 -0400 (EDT) (envelope-from randall@lakerest.net) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=windows-1252 From: Randy Stewart In-Reply-To: <012C3117EDDB3C4781FD802A8C27DD4F0D4E3811@SACEXCMBX02-PRD.hq.netapp.com> Date: Fri, 3 Aug 2012 13:27:31 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <012C3117EDDB3C4781FD802A8C27DD4F0D4E24FC@SACEXCMBX02-PRD.hq.netapp.com> <955ED31B-9201-43FA-8C8C-13B622DB2D80@lakerest.net> <012C3117EDDB3C4781FD802A8C27DD4F0D4E3811@SACEXCMBX02-PRD.hq.netapp.com> To: "Scheffenegger, Richard" X-Mailer: Apple Mail (2.1278) Cc: "gorry@erg.abdn.ac.uk" , "stevedong@huawei.com" , "tuexen@fh-muenster.de" , "tsvwg@ietf.org" , "Matthew Mathis \(mattmathis@google.com\)" Subject: Re: [tsvwg] draft-stewart-tsvwg-sctpecn X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Aug 2012 17:31:39 -0000 Richard: Ok so this is not a case where you are not seeing the ECN/CWR are = reliable. Thats good ;-) On Aug 3, 2012, at 12:17 PM, Scheffenegger, Richard wrote: > Hi Randy, >=20 > My point being, that it is not clear, architecturally, if the = mechanism implements a reliable feedback, or not. >=20 > The way TCP (3168) signals ECN is, that you have a counter that counts = up to a specific maximum value, and remains at that value until reset. = In TCP, that counter is only 1 bit (ECE), and CWR is the reset signal. >=20 > Now, when the counter is large enough (5+ bits), the resiliency no = longer requires a reset signal (statistically), as the counter is = increasingly unlikely to wrap over unnoticed. So with a 32 bit counter, = you can do away with the CWR signal entirely. Or is there any use to the = receiver to know when the sender has reacted to congestion (by an = unknown extent)? (Historically, SCTP implemented the same one-bit = counter/reset scheme that TCP did, IIRC; so CWR is really only relevant = for legacy compatibility, correct?). >=20 > Since the receiver resets the ECN counter only if it receives a CWR = with the appropriate TSN, that means that you implicitly require at = least one RTT without a CE mark, for that to happen=85 Correct. >=20 > Assume a pretty congested network, where you'll get one CE mark per = RTT (and the source doesn't react traditionally with halving the sending = rate), = = ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ and here is the heart of the problem. If you follow the RFC and 1/2 your = rate, eventually you *would* reach a state where you could get (possibly = just 1) packet though without a mark. So first and for most I see the question phrased = as "If I do things wrong and violate the spec, what happens when this = counter over here wraps?". > then the counter can increase continuously. Understanding the concept = (counter with reset, pure counter) would answer what the receiver is to = do when the counter hits 2^32-1=85 The CE counter in the ECN-Echo was never reset, this is because when the = TSN actually does cover the value then the ECN-E it is discarded so the next set of events = will start at 1 all over again with a higher TSN. This means that the ECN-E = receiver, if the sender wants to track the actual number of packets CE marked, then = when sending a CWR it needs to note down (in the TCB) the last counter/TSN. If it = receives another ECN-E with a larger TSN and a larger counter in the next window of data, = then this is a continuing episode. If it receives a smaller counter value (nominally 1) then it can be assured = the past CWR was processed and we have entered a new congestion event. Note that = the=20 last counter/TSN needs to be held for one new window of data, after = which it can be discarded as well (unless of course another ECN-E arrives.. = then it has to be updated and held another window of data aka RTT). Of course if you are not reducing your cwnd, you could stay in this for = 2billion packets, but if so then I guess you probably don't care about how many CE marks are = there anyway since you are not doing anything to slow down =85 ;-) R >=20 > I am bringing this up because for TCP, a single bit counter is = insufficient for the requirements of Conex; and I want to understand if = the signaling scheme was given thorough thought that I could leverage = for a redesign in the TCP space... >=20 >=20 > I do agree, that when one excludes misbehaving implementations, this = question is more of academic interest rather than a true issue of a = deployment following the draft, owed to the large counter. >=20 > Richard Scheffenegger >=20 >> -----Original Message----- >> From: Randy Stewart [mailto:randall@lakerest.net] >> Sent: Freitag, 03. August 2012 08:53 >> To: Scheffenegger, Richard >> Cc: tuexen@fh-muenster.de; stevedong@huawei.com; = gorry@erg.abdn.ac.uk; >> Matthew Mathis (mattmathis@google.com); tsvwg@ietf.org >> Subject: Re: [tsvwg] draft-stewart-tsvwg-sctpecn >>=20 >> Richard: >>=20 >> Hmm >>=20 >> Re-reading the document a bit, I don't see that it does not tell you = to >> retransmit the chunk in the receiver side (5.3) we state: >>=20 >> " >> After transmission of the ECN Echo chunk, usually bundled with the >> SACK, the receiver does NOT discard the ECN Echo chunk. Instead it >> keeps the chunk in its queue and continues to send this chunk = bundled >> with at least a SACK chunk on each outgoing packet, updating it as >> described above if other CE codepoint data packets arrive. The ECN >> Echo chunk should only be discarded when a CWR Chunk arrives = holding >> a TSN value that is greater than or equal to the value inside the = ECN >> Echo Chunk. >> " >>=20 >> If this is not clear enough please let me know a wording that would = make >> it clearer. >>=20 >> Note that the ECN echo continues to be received until a CWR shows up = with >> a TSN number at least as big as the TSN sent in the ECN Echo. >>=20 >> R >>=20 >> On Aug 2, 2012, at 7:58 PM, Scheffenegger, Richard wrote: >>=20 >>> Hi, >>>=20 >>>=20 >>> While looking as to how other protocol do ECN feedback signaling, I >> found that this draft is missing (at least not mentioning) an = interesting >> detail. >>>=20 >>> The existence of a CWR Chunk indicates, that the feedback signal is >> supposed to be reliable. >>>=20 >>> However, the ECN Echo chunk defines the Number of CE marked Packets = as >> 32-bit unsigned int, and does not specify how a receiver should = behave it >> never received a CWR chunk... >>>=20 >>> The sheer size of the ECN Echo chunk would lend itself to be a = simple >> feedback signal, without any explicit signal from the sender. >>>=20 >>> Historically, in RFC4960, it appears that this chunk effectively >> contained only a single bit (no counter; only the presence of the = chunk). >> In order to establish a reliable feedback for at most one ECN signal = per >> RTT, a handshake mechanism (CWR chunk) is required. That mechanism = was >> very much alike what TCP does with ECE / CWR. >>>=20 >>>=20 >>>=20 >>> IMHO, this draft should be more clear around the mechanism: >>>=20 >>> If a handshake is required, the 32-bit counter MUST NOT roll over at >> 2^32-1, but remain at that value until CWR is received. >>>=20 >>> The sheer size of the counter however makes it highly unlikely that = the >> sender will not receive a signal (before the session collapses for = lack of >> feedback from the receiver). So a handshake-less (CWR chunk optional = on >> the sender?) is also feasible, but then the ECN counter MUST roll = over... >>>=20 >>>=20 >>> As it stands now, the counter rolls over, and is reset via CWR... >>>=20 >>> Are there any specific reasons for this chimera mechanism? >>>=20 >>> Does it allow for special use cases, which cannot be addressed by = either >> handshake or simple counter alone? >>>=20 >>> I'm very interested in the answers to the last two questions, as I = am >> one of the authors of an Accurate ECN feedback draft for TCP, and = TCPM has >> a milestone to define an appropriate (accurate) feedback mechanism = that >> allows more than 1 bit per RTT... >>>=20 >>> Best regards, >>>=20 >>> Richard Scheffenegger >>>=20 >>>> draft-stewart-tsvwg-sctpecn-02 >>>> Partially replaces (draft-stewart-tsvwg-sctp-nonce) >>>> IETF-78 suggested there was interest in this topic. >>>> Discussed at IETF-83, Paris. >>>> DUE: ECN is within the TSVWG Charter, will call for adoption on the >>>> list. >>>> Please comment on list. >>>=20 >>>=20 >>=20 >> ----- >> Randall Stewart >> randall@lakerest.net >>=20 >>=20 >>=20 >=20 >=20 ----- Randall Stewart randall@lakerest.net From rs@netapp.com Fri Aug 3 10:44:35 2012 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4135721F8DE8 for ; Fri, 3 Aug 2012 10:44:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.211 X-Spam-Level: X-Spam-Status: No, score=-10.211 tagged_above=-999 required=5 tests=[AWL=0.388, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NrXea8ppR9NN for ; Fri, 3 Aug 2012 10:44:34 -0700 (PDT) Received: from mx2.netapp.com (mx2.netapp.com [216.240.18.37]) by ietfa.amsl.com (Postfix) with ESMTP id 2FD3821F8DE5 for ; Fri, 3 Aug 2012 10:44:34 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.77,707,1336374000"; d="scan'208";a="672925340" Received: from smtp1.corp.netapp.com ([10.57.156.124]) by mx2-out.netapp.com with ESMTP; 03 Aug 2012 10:44:33 -0700 Received: from vmwexceht04-prd.hq.netapp.com (vmwexceht04-prd.hq.netapp.com [10.106.77.34]) by smtp1.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id q73HiXU3013865; Fri, 3 Aug 2012 10:44:33 -0700 (PDT) Received: from SACEXCMBX02-PRD.hq.netapp.com ([169.254.1.34]) by vmwexceht04-prd.hq.netapp.com ([10.106.77.34]) with mapi id 14.02.0298.004; Fri, 3 Aug 2012 10:44:33 -0700 From: "Scheffenegger, Richard" To: Randy Stewart Thread-Topic: [tsvwg] draft-stewart-tsvwg-sctpecn Thread-Index: Ac1xCpQnt7Qi4CRkRDaO8iAwZyWYDAAwBnUAAA5sUDD//6cggIAAcueQ Date: Fri, 3 Aug 2012 17:44:32 +0000 Message-ID: <012C3117EDDB3C4781FD802A8C27DD4F0D4E3C80@SACEXCMBX02-PRD.hq.netapp.com> References: <012C3117EDDB3C4781FD802A8C27DD4F0D4E24FC@SACEXCMBX02-PRD.hq.netapp.com> <955ED31B-9201-43FA-8C8C-13B622DB2D80@lakerest.net> <012C3117EDDB3C4781FD802A8C27DD4F0D4E3811@SACEXCMBX02-PRD.hq.netapp.com> In-Reply-To: Accept-Language: de-AT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.104.60.115] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "gorry@erg.abdn.ac.uk" , "stevedong@huawei.com" , "tuexen@fh-muenster.de" , "tsvwg@ietf.org" , "Matthew Mathis \(mattmathis@google.com\)" Subject: Re: [tsvwg] draft-stewart-tsvwg-sctpecn X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Aug 2012 17:44:35 -0000 Hi Randy, you have elegantly avoided to answer my question around the conceptual beha= vior :) So let me rephrase my question a little bit differently: Suppose you are restricted on bits available to signal the congestion back = to the sender, would you implement a continuously increasing counter (that = eventually wraps), or a gauge that only increases up to a certain point bef= ore requiring an explicit reset. Independently from this, do you see value in letting the receiver (and impl= icitly, the network) explicitly know that the sender (supposedly) did perfo= rm a congestion control reaction? Think of this scenario as when the send window (# packets) is larger than t= he largest value that the counter could hold; With TCP, that happens with w= indows > 1 packet; with this draft, when the window grows beyond 2^32 packe= ts (purely hypothetical). Thanks for your help! Richard Scheffenegger > -----Original Message----- > From: Randy Stewart [mailto:randall@lakerest.net] > Sent: Freitag, 03. August 2012 10:28 > To: Scheffenegger, Richard > Cc: gorry@erg.abdn.ac.uk; tsvwg@ietf.org; tuexen@fh-muenster.de; Matthew > Mathis (mattmathis@google.com); stevedong@huawei.com > Subject: Re: [tsvwg] draft-stewart-tsvwg-sctpecn >=20 > Richard: >=20 > Ok so this is not a case where you are not seeing the ECN/CWR are > reliable. Thats good ;-) >=20 > On Aug 3, 2012, at 12:17 PM, Scheffenegger, Richard wrote: >=20 > > Hi Randy, > > > > My point being, that it is not clear, architecturally, if the mechanism > implements a reliable feedback, or not. > > > > The way TCP (3168) signals ECN is, that you have a counter that counts > up to a specific maximum value, and remains at that value until reset. In > TCP, that counter is only 1 bit (ECE), and CWR is the reset signal. > > > > Now, when the counter is large enough (5+ bits), the resiliency no > longer requires a reset signal (statistically), as the counter is > increasingly unlikely to wrap over unnoticed. So with a 32 bit counter, > you can do away with the CWR signal entirely. Or is there any use to the > receiver to know when the sender has reacted to congestion (by an unknown > extent)? (Historically, SCTP implemented the same one-bit counter/reset > scheme that TCP did, IIRC; so CWR is really only relevant for legacy > compatibility, correct?). > > > > Since the receiver resets the ECN counter only if it receives a CWR > > with the appropriate TSN, that means that you implicitly require at > > least one RTT without a CE mark, for that to happen... >=20 > Correct. >=20 > > > > Assume a pretty congested network, where you'll get one CE mark per > > RTT (and the source doesn't react traditionally with halving the > > sending rate), >=20 > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >=20 > and here is the heart of the problem. If you follow the RFC and 1/2 your > rate, eventually you *would* reach a state where you could get (possibly > just 1) packet though without a mark. So first and for most I see the > question phrased as "If I do things wrong and violate the spec, what > happens when this counter over here wraps?". >=20 >=20 > > then the counter can increase continuously. Understanding the concept > > (counter with reset, pure counter) would answer what the receiver is > > to do when the counter hits 2^32-1... >=20 > The CE counter in the ECN-Echo was never reset, this is because when the > TSN actually does cover the value then the ECN-E it is discarded so the > next set of events will start at 1 all over again with a higher TSN. This > means that the ECN-E receiver, if the sender wants to track the actual > number of packets CE marked, then when sending a CWR it needs to note > down (in the TCB) the last counter/TSN. If it receives another ECN-E with > a larger TSN and a larger counter in the next window of data, then this i= s > a continuing episode. If it receives a smaller counter value (nominally 1= ) > then it can be assured the past CWR was processed and we have entered a > new congestion event. Note that the last counter/TSN needs to be held for > one new window of data, after which it can be discarded as well (unless o= f > course another ECN-E arrives.. then it has to be updated and held another > window of data aka RTT). >=20 > Of course if you are not reducing your cwnd, you could stay in this for > 2billion packets, but if so then I guess you probably don't care about ho= w > many CE marks are there anyway since you are not doing anything to slow > down ... ;-) >=20 > R >=20 > > > > I am bringing this up because for TCP, a single bit counter is > insufficient for the requirements of Conex; and I want to understand if > the signaling scheme was given thorough thought that I could leverage for > a redesign in the TCP space... > > > > > > I do agree, that when one excludes misbehaving implementations, this > question is more of academic interest rather than a true issue of a > deployment following the draft, owed to the large counter. > > > > Richard Scheffenegger > > > >> -----Original Message----- > >> From: Randy Stewart [mailto:randall@lakerest.net] > >> Sent: Freitag, 03. August 2012 08:53 > >> To: Scheffenegger, Richard > >> Cc: tuexen@fh-muenster.de; stevedong@huawei.com; > >> gorry@erg.abdn.ac.uk; Matthew Mathis (mattmathis@google.com); > >> tsvwg@ietf.org > >> Subject: Re: [tsvwg] draft-stewart-tsvwg-sctpecn > >> > >> Richard: > >> > >> Hmm > >> > >> Re-reading the document a bit, I don't see that it does not tell you > >> to retransmit the chunk in the receiver side (5.3) we state: > >> > >> " > >> After transmission of the ECN Echo chunk, usually bundled with the > >> SACK, the receiver does NOT discard the ECN Echo chunk. Instead it > >> keeps the chunk in its queue and continues to send this chunk bundle= d > >> with at least a SACK chunk on each outgoing packet, updating it as > >> described above if other CE codepoint data packets arrive. The ECN > >> Echo chunk should only be discarded when a CWR Chunk arrives holding > >> a TSN value that is greater than or equal to the value inside the EC= N > >> Echo Chunk. > >> " > >> > >> If this is not clear enough please let me know a wording that would > >> make it clearer. > >> > >> Note that the ECN echo continues to be received until a CWR shows up > >> with a TSN number at least as big as the TSN sent in the ECN Echo. > >> > >> R > >> > >> On Aug 2, 2012, at 7:58 PM, Scheffenegger, Richard wrote: > >> > >>> Hi, > >>> > >>> > >>> While looking as to how other protocol do ECN feedback signaling, I > >> found that this draft is missing (at least not mentioning) an > >> interesting detail. > >>> > >>> The existence of a CWR Chunk indicates, that the feedback signal is > >> supposed to be reliable. > >>> > >>> However, the ECN Echo chunk defines the Number of CE marked Packets > >>> as > >> 32-bit unsigned int, and does not specify how a receiver should > >> behave it never received a CWR chunk... > >>> > >>> The sheer size of the ECN Echo chunk would lend itself to be a > >>> simple > >> feedback signal, without any explicit signal from the sender. > >>> > >>> Historically, in RFC4960, it appears that this chunk effectively > >> contained only a single bit (no counter; only the presence of the > chunk). > >> In order to establish a reliable feedback for at most one ECN signal > >> per RTT, a handshake mechanism (CWR chunk) is required. That > >> mechanism was very much alike what TCP does with ECE / CWR. > >>> > >>> > >>> > >>> IMHO, this draft should be more clear around the mechanism: > >>> > >>> If a handshake is required, the 32-bit counter MUST NOT roll over at > >> 2^32-1, but remain at that value until CWR is received. > >>> > >>> The sheer size of the counter however makes it highly unlikely that > >>> the > >> sender will not receive a signal (before the session collapses for > >> lack of feedback from the receiver). So a handshake-less (CWR chunk > >> optional on the sender?) is also feasible, but then the ECN counter > MUST roll over... > >>> > >>> > >>> As it stands now, the counter rolls over, and is reset via CWR... > >>> > >>> Are there any specific reasons for this chimera mechanism? > >>> > >>> Does it allow for special use cases, which cannot be addressed by > >>> either > >> handshake or simple counter alone? > >>> > >>> I'm very interested in the answers to the last two questions, as I > >>> am > >> one of the authors of an Accurate ECN feedback draft for TCP, and > >> TCPM has a milestone to define an appropriate (accurate) feedback > >> mechanism that allows more than 1 bit per RTT... > >>> > >>> Best regards, > >>> > >>> Richard Scheffenegger > >>> > >>>> draft-stewart-tsvwg-sctpecn-02 > >>>> Partially replaces (draft-stewart-tsvwg-sctp-nonce) > >>>> IETF-78 suggested there was interest in this topic. > >>>> Discussed at IETF-83, Paris. > >>>> DUE: ECN is within the TSVWG Charter, will call for adoption on the > >>>> list. > >>>> Please comment on list. > >>> > >>> > >> > >> ----- > >> Randall Stewart > >> randall@lakerest.net > >> > >> > >> > > > > >=20 > ----- > Randall Stewart > randall@lakerest.net >=20 >=20 >=20 From john@jlc.net Fri Aug 3 18:03:04 2012 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7018721F8D4D for ; Fri, 3 Aug 2012 18:03:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.672 X-Spam-Level: X-Spam-Status: No, score=-105.672 tagged_above=-999 required=5 tests=[AWL=0.927, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UXwWp9rc+1qD for ; Fri, 3 Aug 2012 18:03:04 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id E100621F8D56 for ; Fri, 3 Aug 2012 18:03:03 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id BBCC133C21; Fri, 3 Aug 2012 21:03:03 -0400 (EDT) Date: Fri, 3 Aug 2012 21:03:03 -0400 From: John Leslie To: "Scheffenegger, Richard" Message-ID: <20120804010303.GC15012@verdi> References: <012C3117EDDB3C4781FD802A8C27DD4F0D4E24FC@SACEXCMBX02-PRD.hq.netapp.com> <955ED31B-9201-43FA-8C8C-13B622DB2D80@lakerest.net> <012C3117EDDB3C4781FD802A8C27DD4F0D4E3811@SACEXCMBX02-PRD.hq.netapp.com> <012C3117EDDB3C4781FD802A8C27DD4F0D4E3C80@SACEXCMBX02-PRD.hq.netapp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <012C3117EDDB3C4781FD802A8C27DD4F0D4E3C80@SACEXCMBX02-PRD.hq.netapp.com> User-Agent: Mutt/1.4.1i Cc: tsvwg@ietf.org, Randy Stewart Subject: Re: [tsvwg] draft-stewart-tsvwg-sctpecn X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Aug 2012 01:03:04 -0000 Scheffenegger, Richard wrote: > > Suppose you are restricted on bits available to signal the congestion > back to the sender, would you implement a continuously increasing > counter (that eventually wraps), or a gauge that only increases up to > a certain point before requiring an explicit reset. [tcpm] is facing this issue for TCP: I haven't posted an opinion there yet; but frankly my opinion is that a counter that wraps is a better mechanism. It end-runs a lot of race conditions. I don't know the exact details for SCTP -- but it seems avoiding race conditions would be best here, too. > Independently from this, do you see value in letting the receiver > (and implicitly, the network) explicitly know that the sender > (supposedly) did perform a congestion control reaction? There is arguably some value in that; but it tends to strike me as a MAY rather than a MUST. > Think of this scenario as when the send window (# packets) is larger > than the largest value that the counter could hold; With TCP, that > happens with windows > 1 packet; with this draft, when the window > grows beyond 2^32 packets (purely hypothetical). TCP, here, serves only as a bad example IMHO. The one-bit counter was barely adequate when first specified, and can never pass more than one event per RTT. This is already considered inadequate for things we want TCP to do today. IMHO, if there is a CWR indication at all, it deserves to be the value of the ECE counter when the window was reduced -- thus as many bits as the ECE counter. Again, this end-runs race conditions. (The mechanism is analogous to the circular-buffer algorithms from the 1960s when we dealt with shared-memory communication between processes that could interrupt each other.) -- John Leslie From rs@netapp.com Fri Aug 3 20:08:13 2012 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EDAA11E8072 for ; Fri, 3 Aug 2012 20:08:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.254 X-Spam-Level: X-Spam-Status: No, score=-10.254 tagged_above=-999 required=5 tests=[AWL=0.345, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VUEjAaBWrM91 for ; Fri, 3 Aug 2012 20:08:13 -0700 (PDT) Received: from mx2.netapp.com (mx2.netapp.com [216.240.18.37]) by ietfa.amsl.com (Postfix) with ESMTP id 1358F21F8D3B for ; Fri, 3 Aug 2012 20:08:13 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.77,709,1336374000"; d="scan'208";a="673213511" Received: from smtp2.corp.netapp.com ([10.57.159.114]) by mx2-out.netapp.com with ESMTP; 03 Aug 2012 20:07:37 -0700 Received: from vmwexceht04-prd.hq.netapp.com (vmwexceht04-prd.hq.netapp.com [10.106.77.34]) by smtp2.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id q7437axw010641; Fri, 3 Aug 2012 20:07:36 -0700 (PDT) Received: from SACEXCMBX02-PRD.hq.netapp.com ([169.254.1.34]) by vmwexceht04-prd.hq.netapp.com ([10.106.77.34]) with mapi id 14.02.0298.004; Fri, 3 Aug 2012 20:07:35 -0700 From: "Scheffenegger, Richard" To: John Leslie Thread-Topic: [tsvwg] draft-stewart-tsvwg-sctpecn Thread-Index: Ac1xCpQnt7Qi4CRkRDaO8iAwZyWYDAAwBnUAAA5sUDD//6cggIAAcueQgAAMX4CAAFO1AA== Date: Sat, 4 Aug 2012 03:07:35 +0000 Message-ID: <012C3117EDDB3C4781FD802A8C27DD4F0D4E48B4@SACEXCMBX02-PRD.hq.netapp.com> References: <012C3117EDDB3C4781FD802A8C27DD4F0D4E24FC@SACEXCMBX02-PRD.hq.netapp.com> <955ED31B-9201-43FA-8C8C-13B622DB2D80@lakerest.net> <012C3117EDDB3C4781FD802A8C27DD4F0D4E3811@SACEXCMBX02-PRD.hq.netapp.com> <012C3117EDDB3C4781FD802A8C27DD4F0D4E3C80@SACEXCMBX02-PRD.hq.netapp.com> <20120804010303.GC15012@verdi> In-Reply-To: <20120804010303.GC15012@verdi> Accept-Language: de-AT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.104.60.116] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "tsvwg@ietf.org" , Randy Stewart Subject: Re: [tsvwg] draft-stewart-tsvwg-sctpecn X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Aug 2012 03:08:13 -0000 Thanks John, I think I understand now what you are saying - at least to my understanding= , you weren't as explicit over in the TCPM WG list :) Let me discuss these considerations with my co-author, perhaps we can come = up with a proper way to encode all these signals appropriately. Any thoughts as to the exact sequence of CE marks being seen on the receive= r side? (I think that this will be too much information, better served by s= ome kind of explicit byte-congestion counter, that has similar properties t= o a packet-congestion counter). Best regards, Richard Scheffenegger > -----Original Message----- > From: John Leslie [mailto:john@jlc.net] > Sent: Freitag, 03. August 2012 18:03 > To: Scheffenegger, Richard > Cc: Randy Stewart; tsvwg@ietf.org > Subject: Re: [tsvwg] draft-stewart-tsvwg-sctpecn >=20 > Scheffenegger, Richard wrote: > > > > Suppose you are restricted on bits available to signal the congestion > > back to the sender, would you implement a continuously increasing > > counter (that eventually wraps), or a gauge that only increases up to > > a certain point before requiring an explicit reset. >=20 > [tcpm] is facing this issue for TCP: I haven't posted an opinion > there yet; but frankly my opinion is that a counter that wraps is a > better mechanism. It end-runs a lot of race conditions. >=20 > I don't know the exact details for SCTP -- but it seems avoiding > race conditions would be best here, too. >=20 > > Independently from this, do you see value in letting the receiver > > (and implicitly, the network) explicitly know that the sender > > (supposedly) did perform a congestion control reaction? >=20 > There is arguably some value in that; but it tends to strike me as > a MAY rather than a MUST. >=20 > > Think of this scenario as when the send window (# packets) is larger > > than the largest value that the counter could hold; With TCP, that > > happens with windows > 1 packet; with this draft, when the window > > grows beyond 2^32 packets (purely hypothetical). >=20 > TCP, here, serves only as a bad example IMHO. The one-bit counter > was barely adequate when first specified, and can never pass more than > one event per RTT. This is already considered inadequate for things we > want TCP to do today. >=20 > IMHO, if there is a CWR indication at all, it deserves to be the > value of the ECE counter when the window was reduced -- thus as many > bits as the ECE counter. Again, this end-runs race conditions. >=20 > (The mechanism is analogous to the circular-buffer algorithms from > the 1960s when we dealt with shared-memory communication between > processes that could interrupt each other.) >=20 > -- > John Leslie From dwing@cisco.com Mon Aug 6 18:00:11 2012 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA97921F86C3; Mon, 6 Aug 2012 18:00:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.491 X-Spam-Level: X-Spam-Status: No, score=-110.491 tagged_above=-999 required=5 tests=[AWL=0.108, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nhbQDb-ZwxT7; Mon, 6 Aug 2012 18:00:09 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 6F16D21F86C4; Mon, 6 Aug 2012 18:00:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=8113; q=dns/txt; s=iport; t=1344301209; x=1345510809; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=9N5APu8G7NqxD+F1Vdxn0nBT4c0RXwiBlkVhM0f15IY=; b=fXlxjYVYWWx0vp0yk6FMLFaJtVOum1dc3hZjH5onRAF0J2OZ4OQcnpJJ iwtmqDnSqvlhEf3oudrdz7vFnSLHscDcyOM5EVlaEj18aZOkrUrlD2tm6 cx8BkV9qF7EcBt2zietBu3UjX403rgEeSW6errvUFXx4sskm1ZCHB1f8S 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAKtnIFCrRDoH/2dsb2JhbABFqhqPN4EHgiABAQEDAQEBAQUKARcQNAsFBwEDAgkPAgQBASgHGQ4VCgkIAgQBEgsQB4dlBQybHaAzBItKhm0DiE2FDZYVgWaCfw X-IronPort-AV: E=Sophos;i="4.77,723,1336348800"; d="scan'208";a="51706635" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-3.cisco.com with ESMTP; 07 Aug 2012 01:00:09 +0000 Received: from dwingWS (sjc-vpn3-793.cisco.com [10.21.67.25]) by mtv-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q77108fq023782; Tue, 7 Aug 2012 01:00:08 GMT From: "Dan Wing" To: , References: <03ee01cd69e7$649942e0$2dcbc8a0$@com> <004001cd6b1d$405442e0$c0fcc8a0$@unizar.es> <069901cd6b81$6f1bd2a0$4d5377e0$@com> <004001cd6be8$f8e1e170$eaa5a450$@unizar.es> <090e01cd6c14$943fd750$bcbf85f0$@com> <580BEA5E3B99744AB1F5BFF5E9A3C67D14DD2452CB@HE111648.emea1.cds.t-internal.com> In-Reply-To: <580BEA5E3B99744AB1F5BFF5E9A3C67D14DD2452CB@HE111648.emea1.cds.t-internal.com> Date: Mon, 6 Aug 2012 18:00:08 -0700 Message-ID: <08b801cd7437$fd5aebf0$f810c3d0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AQGF+EuvFpZGZkinmlaOrA3LFBD+CQDG7hgjAtHnKE2XrwGWUIAAbaFAgAQRaHCADDcqAA== Content-Language: en-us Cc: tcmtf@ietf.org, tsvwg@ietf.org Subject: Re: [tsvwg] [tcmtf] M2M, WSNs and draft-saldana-tsvwg-tcmtf X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Aug 2012 01:00:12 -0000 > -----Original Message----- > From: Ruediger.Geib@telekom.de [mailto:Ruediger.Geib@telekom.de] > Sent: Sunday, July 29, 2012 11:54 PM > To: dwing@cisco.com; jsaldana@unizar.es > Cc: tcmtf@ietf.org; tsvwg@ietf.org > Subject: RE: [tsvwg] [tcmtf] M2M, WSNs and draft-saldana-tsvwg-tcmtf > > Folks, > > avoiding a DSCP rewrite at domain boundarys is probably > impossible - there are many independent DiffServ > deployments by now. > > Al Morton will present some ITU work on the issue. We propose > to apply a small standardised set of domain behaviours (also > called QoS classes) at interconnection interfaces. The benefit > is a domain remarks tranmitted/received traffic to/from the > interdomain DSCPs. Every ISP needs to solve the interworking > issue once only and should expect a reasonable end to end QoS. > > The proposal more tries to look at DiffServ router forwarding knobs: > a queuing mechanism and active queue management. My view is, these > can be optimised for an expected transport behaviour: > > UDP traffic (streaming or telephony, real time gaming) will most > likely not be retransmitted. A short queue will do, active queue > management by random drops isn't required (unless you'd like > to apply PCN marking or the like). Yes, I would like PCN and ECN marking for UDP flows, so they can react. What of SCTP-over-UDP, which is the data channel that RTCWEB is going to use? SCTP has congestion control and thus SCTP-over-UDP should be treated much more like TCP. Similarly, we have lots of existing deployment of TCP over IPsec over UDP (such as VPNs), which should also be treated like TCP. > TCP traffic interacts with router congestion indications, queues > may be a little bit deeper and active queue management may be > deployed. Today it is RED, ECN or the like in future. > > If one looks at it from that angle, the number of useful > QoS classes is small. > > Take the transport indication (TCP/UDP) as "dominating" in a > class, not a pureness requirement. What of SCTP and DCCP? I would like those protocols to be deployable at least over IPv6. With IPv6, we don't have NAPT devices that only allow TCP and UDP, and would be a shame if QoS only worked for UDP and TCP. -d > > Regards > > Ruediger > > > > -----Original Message----- > From: tsvwg-bounces@ietf.org [mailto:tsvwg-bounces@ietf.org] On Behalf > Of Dan Wing > Sent: Friday, July 27, 2012 6:27 PM > To: 'Jose Saldana' > Cc: tcmtf@ietf.org; tsvwg@ietf.org > Subject: Re: [tsvwg] [tcmtf] M2M, WSNs and draft-saldana-tsvwg-tcmtf > > > -----Original Message----- > > From: Jose Saldana [mailto:jsaldana@unizar.es] > > Sent: Friday, July 27, 2012 4:14 AM > > To: 'Dan Wing' > > Cc: tcmtf@ietf.org; tsvwg@ietf.org > > Subject: RE: [tcmtf] [tsvwg] M2M, WSNs and draft-saldana-tsvwg-tcmtf > > > > Well, perhaps a solution is the use of Diffserv bits: in the draft > for > > updating rfc4594 > > (https://datatracker.ietf.org/doc/draft-polk-tsvwg-rfc4594-update) > > there are > > classes for real-time services and for best-effort ones. I have > always > > believed that the update of rfc4594 can be beneficial for TCMTF: you > > can > > build a tunnel with flows belonging to the same traffic category. > > > > But I don't know if the best-effort class means exactly the same as > > delay-tolerant. > > > > Dan, what do you think? > > I agree that DSCP is the best tool we have to combine packets > with similar characteristics. > > A recurring problem with DSCP is they are re-written to different > values because a router was configured to rewrite them all the > time or because a queue of that traffic class had built. That > rewriting needs to be considered (or ignored) when grouping packets > that are 'similar'. IMO, the fact that a packet was in a queue > a few router hops away (and now has a different DSCP than > its friends) doesn't change that it should be grouped with all > of its friends into a multiplexing tunnel. > > -d > > > > Thanks, > > > > Jose > > > > -----Mensaje original----- > > De: tcmtf-bounces@ietf.org [mailto:tcmtf-bounces@ietf.org] En nombre > de > > Dan > > Wing > > Enviado el: viernes, 27 de julio de 2012 0:53 > > Para: 'Jose Saldana' > > CC: tcmtf@ietf.org > > Asunto: Re: [tcmtf] [tsvwg] M2M, WSNs and draft-saldana-tsvwg-tcmtf > > > > > -----Original Message----- > > > From: Jose Saldana [mailto:jsaldana@unizar.es] > > > Sent: Thursday, July 26, 2012 3:56 AM > > > To: 'Dan Wing' > > > Cc: tcmtf@ietf.org > > > Subject: RE: [tcmtf] [tsvwg] M2M, WSNs and draft-saldana-tsvwg- > tcmtf > > > > > > Dan, > > > > > > I don't know if I have really understood your question. Of course, > I > > > assume that a delay of some seconds is not important for certain > > > sensor networks. > > > But they don't need to signal that they are delay tolerant. I mean, > > > they are assumed to be from the moment they are installed. > > > > The device, doing the multiplexing, needs to know if the packets > belong > > to a > > delay-tolerant (sensor) endpoint or to a non-delay tolerant endpoint. > > > > If the device doing the multiplexing is also the gateway > communicating > > with > > the delay-tolerant (sensor) network, it certainly knows those > > devices are delay-tolerant. I believe that is your point. > > > > My point is that if the device doing the multiplexing is not directly > > connected to that network of delay-tolerant devices, it needs to > > somehow > > differentiate between the delay-tolerant devices and the non- delay- > > tolerant > > -- by being signaled or by being configured. > > > > In the future, I expect a mix of sensors on various networks that are > > not > > traditional dedicated sensor networks (e.g., WiFi, 3G), so relying on > a > > gateway to that dedicated network may not always be the way to know a > > device > > is delay tolerant. > > > > -d > > > > > Well, I think I should gather some information about typical > examples > > > of sensor networks (number of sensors, frequency of samples, packet > > > size of the samples, etc), in order to calculate in which cases the > > > bandwidth saving obtained with TCMTF can be interesting, and which > > > "multiplexing period" > > > should be used. I think that this could be a typical case in which > > > multiplexing can be done by packet size instead of using a period. > I > > > mean, when you have almost 1500 bytes (or the MTU), you send a > > packet. > > > > > > I don't know if I have answered your question, > > > > > > Jose > > > > > > -----Mensaje original----- > > > De: Dan Wing [mailto:dwing@cisco.com] > > > Enviado el: martes, 24 de julio de 2012 23:58 > > > Para: jsaldana@unizar.es > > > CC: Tomaso.deCola@dlr.de; fpb@tid.es; tcmtf@ietf.org > > > Asunto: Re: [tcmtf] [tsvwg] M2M, WSNs and draft-saldana-tsvwg-tcmtf > > > > > > ... > > > > Nevertheless, in order to get an idea of the savings, we should > > > deploy > > > > some calculations. Our research group has only done simulations > for > > > > VoIP and games. In this case, we should know: > > > > > > > > > > > > > > > > - Number of sensors in a typical scenario. > > > > > > > > - Packet size and used headers. If IPv6 is used, savings > > > > can be really big, since header compression is really > > > > good for it. > > > > > > > > - Packets per second that a single sensor can generate. > > > > > > > > > > > > > > > > And of course, the gateway should be the place for multiplexing. > > > > In this case, the flows only travel from sensors to data center. > > > > Am I right? > > > > > > I wonder if there is an easy way for the endpoints to signal that > > they > > > are delay tolerant (to allow collecting ~5 seconds of little > > packets). > > > > > > -d > > > > > > _______________________________________________ > > tcmtf mailing list > > tcmtf@ietf.org > > https://www.ietf.org/mailman/listinfo/tcmtf From Ruediger.Geib@telekom.de Mon Aug 6 23:51:08 2012 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1712021F8582; Mon, 6 Aug 2012 23:51:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.149 X-Spam-Level: X-Spam-Status: No, score=-3.149 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4nZmPCiV+Wvq; Mon, 6 Aug 2012 23:51:05 -0700 (PDT) Received: from tcmail83.telekom.de (tcmail83.telekom.de [62.225.183.131]) by ietfa.amsl.com (Postfix) with ESMTP id 04E2821F8643; Mon, 6 Aug 2012 23:50:57 -0700 (PDT) Received: from he111628.emea1.cds.t-internal.com ([10.134.93.20]) by tcmail81.telekom.de with ESMTP/TLS/AES128-SHA; 07 Aug 2012 08:50:54 +0200 Received: from HE111648.emea1.cds.t-internal.com ([10.134.93.17]) by HE111628.emea1.cds.t-internal.com ([::1]) with mapi; Tue, 7 Aug 2012 08:50:54 +0200 From: To: Date: Tue, 7 Aug 2012 08:50:52 +0200 Thread-Topic: [tsvwg] [tcmtf] M2M, WSNs and draft-saldana-tsvwg-tcmtf Thread-Index: AQGF+EuvFpZGZkinmlaOrA3LFBD+CQDG7hgjAtHnKE2XrwGWUIAAbaFAgAQRaHCADDcqAIAAWd4A Message-ID: <580BEA5E3B99744AB1F5BFF5E9A3C67D14DD650C5F@HE111648.emea1.cds.t-internal.com> References: <03ee01cd69e7$649942e0$2dcbc8a0$@com> <004001cd6b1d$405442e0$c0fcc8a0$@unizar.es> <069901cd6b81$6f1bd2a0$4d5377e0$@com> <004001cd6be8$f8e1e170$eaa5a450$@unizar.es> <090e01cd6c14$943fd750$bcbf85f0$@com> <580BEA5E3B99744AB1F5BFF5E9A3C67D14DD2452CB@HE111648.emea1.cds.t-internal.com> <08b801cd7437$fd5aebf0$f810c3d0$@com> In-Reply-To: <08b801cd7437$fd5aebf0$f810c3d0$@com> Accept-Language: en-US, de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: tcmtf@ietf.org, tsvwg@ietf.org Subject: Re: [tsvwg] [tcmtf] M2M, WSNs and draft-saldana-tsvwg-tcmtf X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Aug 2012 06:51:09 -0000 Hi Dan, if QoS is what your provider promises, then during 99,9x% of the time, you will not be aware of what your QoS class is optimised for. Unfortunately, SLA definitions are the only QoS descriptions which matter to most of us. Another issue with QoS is that one shouldn't assign application class names to QoS PHBs. I also shouldn't use transport names. Then one ends up with a rather abstract PHB descriptions and that often isn't helpful again (noone knows what to do with abstractly described things). A QoS class optimised for traffic with no or very small retransmission capacities will carry traffic which doesn't decrease if there's congestion. One could adapt queue design to this beahivour. That's what I mean by a class optimised for a UDP like transport. If one optimises a QoS class for a transport which will react on network congestion indications, the queue may look different. It may be deeper, and Active Queue Management with random dropping or marking is possibly present. TCP? SCTP? Yes, and any other benefitting from this behaviour. Marking isn't present yet, but I hope the Internet community finds way's to design and deploy it (I've been active in PCN and I follow Conex). None of these QoS classes is optimised for a particular transport. But how to give guidance which QoS class to pick? I choose transport characteristics. Others prefer application charatersitics (I prefer less QoS classes, others more). Don't be fixed on TCP or UDP - these terms are used to give orientation only. Understand the QoS class properties and keep in mind, what you get is indeed QoS, i.e. no congestion. Regards, Ruediger -----Original Message----- From: Dan Wing [mailto:dwing@cisco.com] Sent: Tuesday, August 07, 2012 3:00 AM To: Geib, R=FCdiger; jsaldana@unizar.es Cc: tcmtf@ietf.org; tsvwg@ietf.org Subject: RE: [tsvwg] [tcmtf] M2M, WSNs and draft-saldana-tsvwg-tcmtf > -----Original Message----- > From: Ruediger.Geib@telekom.de [mailto:Ruediger.Geib@telekom.de] > Sent: Sunday, July 29, 2012 11:54 PM > To: dwing@cisco.com; jsaldana@unizar.es > Cc: tcmtf@ietf.org; tsvwg@ietf.org > Subject: RE: [tsvwg] [tcmtf] M2M, WSNs and draft-saldana-tsvwg-tcmtf > > Folks, > > avoiding a DSCP rewrite at domain boundarys is probably > impossible - there are many independent DiffServ > deployments by now. > > Al Morton will present some ITU work on the issue. We propose > to apply a small standardised set of domain behaviours (also > called QoS classes) at interconnection interfaces. The benefit > is a domain remarks tranmitted/received traffic to/from the > interdomain DSCPs. Every ISP needs to solve the interworking > issue once only and should expect a reasonable end to end QoS. > > The proposal more tries to look at DiffServ router forwarding knobs: > a queuing mechanism and active queue management. My view is, these > can be optimised for an expected transport behaviour: > > UDP traffic (streaming or telephony, real time gaming) will most > likely not be retransmitted. A short queue will do, active queue > management by random drops isn't required (unless you'd like > to apply PCN marking or the like). Yes, I would like PCN and ECN marking for UDP flows, so they can react. What of SCTP-over-UDP, which is the data channel that RTCWEB is going to use? SCTP has congestion control and thus SCTP-over-UDP should be treated much more like TCP. Similarly, we have lots of existing deployment of TCP over IPsec over UDP (such as VPNs), which should also be treated like TCP. > TCP traffic interacts with router congestion indications, queues > may be a little bit deeper and active queue management may be > deployed. Today it is RED, ECN or the like in future. > > If one looks at it from that angle, the number of useful > QoS classes is small. > > Take the transport indication (TCP/UDP) as "dominating" in a > class, not a pureness requirement. What of SCTP and DCCP? I would like those protocols to be deployable at least over IPv6. With IPv6, we don't have NAPT devices that only allow TCP and UDP, and would be a shame if QoS only worked for UDP and TCP. -d > > Regards > > Ruediger > > > > -----Original Message----- > From: tsvwg-bounces@ietf.org [mailto:tsvwg-bounces@ietf.org] On Behalf > Of Dan Wing > Sent: Friday, July 27, 2012 6:27 PM > To: 'Jose Saldana' > Cc: tcmtf@ietf.org; tsvwg@ietf.org > Subject: Re: [tsvwg] [tcmtf] M2M, WSNs and draft-saldana-tsvwg-tcmtf > > > -----Original Message----- > > From: Jose Saldana [mailto:jsaldana@unizar.es] > > Sent: Friday, July 27, 2012 4:14 AM > > To: 'Dan Wing' > > Cc: tcmtf@ietf.org; tsvwg@ietf.org > > Subject: RE: [tcmtf] [tsvwg] M2M, WSNs and draft-saldana-tsvwg-tcmtf > > > > Well, perhaps a solution is the use of Diffserv bits: in the draft > for > > updating rfc4594 > > (https://datatracker.ietf.org/doc/draft-polk-tsvwg-rfc4594-update) > > there are > > classes for real-time services and for best-effort ones. I have > always > > believed that the update of rfc4594 can be beneficial for TCMTF: you > > can > > build a tunnel with flows belonging to the same traffic category. > > > > But I don't know if the best-effort class means exactly the same as > > delay-tolerant. > > > > Dan, what do you think? > > I agree that DSCP is the best tool we have to combine packets > with similar characteristics. > > A recurring problem with DSCP is they are re-written to different > values because a router was configured to rewrite them all the > time or because a queue of that traffic class had built. That > rewriting needs to be considered (or ignored) when grouping packets > that are 'similar'. IMO, the fact that a packet was in a queue > a few router hops away (and now has a different DSCP than > its friends) doesn't change that it should be grouped with all > of its friends into a multiplexing tunnel. > > -d > > > > Thanks, > > > > Jose > > > > -----Mensaje original----- > > De: tcmtf-bounces@ietf.org [mailto:tcmtf-bounces@ietf.org] En nombre > de > > Dan > > Wing > > Enviado el: viernes, 27 de julio de 2012 0:53 > > Para: 'Jose Saldana' > > CC: tcmtf@ietf.org > > Asunto: Re: [tcmtf] [tsvwg] M2M, WSNs and draft-saldana-tsvwg-tcmtf > > > > > -----Original Message----- > > > From: Jose Saldana [mailto:jsaldana@unizar.es] > > > Sent: Thursday, July 26, 2012 3:56 AM > > > To: 'Dan Wing' > > > Cc: tcmtf@ietf.org > > > Subject: RE: [tcmtf] [tsvwg] M2M, WSNs and draft-saldana-tsvwg- > tcmtf > > > > > > Dan, > > > > > > I don't know if I have really understood your question. Of course, > I > > > assume that a delay of some seconds is not important for certain > > > sensor networks. > > > But they don't need to signal that they are delay tolerant. I mean, > > > they are assumed to be from the moment they are installed. > > > > The device, doing the multiplexing, needs to know if the packets > belong > > to a > > delay-tolerant (sensor) endpoint or to a non-delay tolerant endpoint. > > > > If the device doing the multiplexing is also the gateway > communicating > > with > > the delay-tolerant (sensor) network, it certainly knows those > > devices are delay-tolerant. I believe that is your point. > > > > My point is that if the device doing the multiplexing is not directly > > connected to that network of delay-tolerant devices, it needs to > > somehow > > differentiate between the delay-tolerant devices and the non- delay- > > tolerant > > -- by being signaled or by being configured. > > > > In the future, I expect a mix of sensors on various networks that are > > not > > traditional dedicated sensor networks (e.g., WiFi, 3G), so relying on > a > > gateway to that dedicated network may not always be the way to know a > > device > > is delay tolerant. > > > > -d > > > > > Well, I think I should gather some information about typical > examples > > > of sensor networks (number of sensors, frequency of samples, packet > > > size of the samples, etc), in order to calculate in which cases the > > > bandwidth saving obtained with TCMTF can be interesting, and which > > > "multiplexing period" > > > should be used. I think that this could be a typical case in which > > > multiplexing can be done by packet size instead of using a period. > I > > > mean, when you have almost 1500 bytes (or the MTU), you send a > > packet. > > > > > > I don't know if I have answered your question, > > > > > > Jose > > > > > > -----Mensaje original----- > > > De: Dan Wing [mailto:dwing@cisco.com] > > > Enviado el: martes, 24 de julio de 2012 23:58 > > > Para: jsaldana@unizar.es > > > CC: Tomaso.deCola@dlr.de; fpb@tid.es; tcmtf@ietf.org > > > Asunto: Re: [tcmtf] [tsvwg] M2M, WSNs and draft-saldana-tsvwg-tcmtf > > > > > > ... > > > > Nevertheless, in order to get an idea of the savings, we should > > > deploy > > > > some calculations. Our research group has only done simulations > for > > > > VoIP and games. In this case, we should know: > > > > > > > > > > > > > > > > - Number of sensors in a typical scenario. > > > > > > > > - Packet size and used headers. If IPv6 is used, savings > > > > can be really big, since header compression is really > > > > good for it. > > > > > > > > - Packets per second that a single sensor can generate. > > > > > > > > > > > > > > > > And of course, the gateway should be the place for multiplexing. > > > > In this case, the flows only travel from sensors to data center. > > > > Am I right? > > > > > > I wonder if there is an easy way for the endpoints to signal that > > they > > > are delay tolerant (to allow collecting ~5 seconds of little > > packets). > > > > > > -d > > > > > > _______________________________________________ > > tcmtf mailing list > > tcmtf@ietf.org > > https://www.ietf.org/mailman/listinfo/tcmtf From prafullasarode@coraltele.com Fri Aug 10 04:34:45 2012 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C280921F8682 for ; Fri, 10 Aug 2012 04:34:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.298 X-Spam-Level: X-Spam-Status: No, score=-2.298 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_57=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rx5fDWIZzPtk for ; Fri, 10 Aug 2012 04:34:45 -0700 (PDT) Received: from mail.coraltele.com (mail.coraltele.com [122.180.79.98]) by ietfa.amsl.com (Postfix) with ESMTP id 3A1C921F8681 for ; Fri, 10 Aug 2012 04:34:43 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.coraltele.com (Postfix) with ESMTP id 286691084004 for ; Fri, 10 Aug 2012 17:04:41 +0530 (IST) X-Virus-Scanned: amavisd-new at coraltele.com Received: from mail.coraltele.com ([127.0.0.1]) by localhost (mail.coraltele.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ph7otgt7gXID for ; Fri, 10 Aug 2012 17:04:36 +0530 (IST) Received: from mail.coraltele.com (mail.coraltele.com [192.168.20.16]) by mail.coraltele.com (Postfix) with ESMTP id B7F4F1084002 for ; Fri, 10 Aug 2012 17:04:36 +0530 (IST) Date: Fri, 10 Aug 2012 17:04:36 +0530 (IST) From: Prafulla Sarode To: tsvwg@ietf.org Message-ID: In-Reply-To: Content-Type: multipart/mixed; boundary="=_06a0eff5-35d5-45c4-8962-604b39fd0c77" MIME-Version: 1.0 X-Originating-IP: [192.168.4.99] X-Mailer: Zimbra 7.0.0_GA_3077 (ZimbraWebClient - FF3.0 (Linux)/7.0.0_GA_3077) Subject: [tsvwg] When SCTP client is restarted, DATA chunks start piggy backing in heart beat and sack chunks only in direction server to client only.. X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Aug 2012 06:06:44 -0000 --=_06a0eff5-35d5-45c4-8962-604b39fd0c77 Content-Type: multipart/alternative; boundary="=_2a4150b6-4beb-4c51-95cc-563df2a71ac0" --=_2a4150b6-4beb-4c51-95cc-563df2a71ac0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Hi; I am using a linux kernel 2.6.30 on ppc machine. I have a one-to-many style server and client running on different machines. (socket(AF_INET,SOCK_SEQPACKET,IPPROTO_SCTP)) type connection. Initially every thing works fine. All messages transported properly from both direction. Now when client restarts without sending the SHUTDOWN chunk (i.e. due to eth down or some other reason), the server(application) receives the SCTP_RESTART event, when client comes up and tries the association. Now what ever message is sent by server, it will only be transmitted whenever either heartbeat,SACK, heartbeat-ack is transmitted. All the messages are delivered to client properly but are sent on the wire piggy backed on either heartbeat,sack,heartbeatack only. The messages sent by client are transmitted on wire as usual and normal. I have done more analysis and it was found that when client is restarted without the knowledge of server(without sending SHUTDOWN) and before receiving any INIT from client, if server has sent any message and then received the INIT from client at this time the server first receives the send_failed and then SCTP_RESTART event and the problem starts. If between the restart of client (without sending SHUTDOWN) and INIT after client application restart, if server has not sent any message, then even if server receives the SCTP_RESTART event there is no such problem and communication is normal. If client restarts first by sending the SHUTDOWN and then restarting application and sending INIT there is no problem. My application is 2 machines sharing same ip-address one at a time at both server and client sites(Typical hot-standby application). First client (working) has established connection with working server, when ever working client detect ethernet down it releaves the control of ip-address and restarts (As there is not ethernet available the SHUTDOWN does not reach the server), and immediately standby client becomes primary acquires the ip-address,send GARP packet and establishes the connection with the server, and server receives the SCTP_RESTART event. The problem occurs only when some message is transmitted by server between the period the old client is shutdown and new client has restarted.(sent INIT) Attaching the wirehark capture for reference. Client shared ip-address-192.168.0.111 - server ip address 192.168.0.115 frames 33 and 34 which is retransmission of the 33 data chunk are the packets transmitted between client restart. frame 35 is the first INIT of the new client(192.168.0.111). The problem can be seen in frames from server(0.115) to client (0.111) in frames 40,43,47,52,65,68,70,82 etc. Please suggest some solution. Regards PRAFULLA SARODE Coral Telecom Ltd E-2 Sect-63 Noida "PLEASURE IN THE JOB PUT PERFECTION IN THE WORK" --=_2a4150b6-4beb-4c51-95cc-563df2a71ac0 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
Hi;

I am using a linux kernel 2.6.30 on ppc machine.
I have a one-to-many style server and client running on different machines. (socket(AF_INET,SOCK_SEQPACKET,IPPROTO_SCTP)) type connection.

Initially every thing works fine. All messages transported properly from both direction.

Now when client restarts without sending the SHUTDOWN chunk (i.e. due to eth down or some other reason), the server(application) receives the SCTP_RESTART event, when client comes up and tries the association. Now what ever message is sent by server, it will only be transmitted whenever either heartbeat,SACK, heartbeat-ack is transmitted. All the messages are delivered to client properly but are sent on the wire piggy backed on either heartbeat,sack,heartbeatack only. The messages sent by client are transmitted on wire as usua l and normal.

I have done more analysis and it was found that when client is restarted without the knowledge of server(without sending SHUTDOWN) and before receiving any INIT from client, if server has sent any message and then received the INIT from client at this time the server first receives the send_failed and then SCTP_RESTART event and the problem starts.

If between the restart of client (without sending SHUTDOWN) and INIT after client application restart, if server has not sent any message, then even if server receives the SCTP_RESTART event there is no such problem and communication is normal.

If client restarts first by sending the SHUTDOWN and then restarting application and sending INIT there is no problem.

My application is 2 machines sharing same ip-address one at a time at both server and client sites(Typical hot-standby application). First client (working) has established conne ction with working server, when ever working client detect ethernet down it releaves the control of ip-address and restarts (As there is not ethernet available the SHUTDOWN does not reach the server), and immediately standby client becomes primary acquires the ip-address,send GARP packet and establishes the connection with the server, and server receives the SCTP_RESTART event.

The problem occurs only when some message is transmitted by server between the period the old client is shutdown and new client has restarted.(sent INIT)

Attaching the wirehark capture for reference.
Client shared ip-address-192.168.0.111 - server ip address 192.168.0.115
frames 33 and 34 which is retransmission of the 33 data chunk are the packets transmitted between client restart. frame 35 is the first INIT of the new client(192.168.0.111).

The problem can be seen in frames from server(0.115) to client (0.111) in frames 40,43,47,52,65,68,70,82 etc.

Please suggest s ome solution.

Regards
PRAFULLA SARODE
Coral Telecom Ltd
E-2 Sect-63 Noida

"PLEASURE IN THE JOB PUT PERFECTION IN THE WORK"

--=_2a4150b6-4beb-4c51-95cc-563df2a71ac0-- --=_06a0eff5-35d5-45c4-8962-604b39fd0c77 Content-Type: application/x-extension-pcap; name=sctp_restart_prob.pcap Content-Disposition: attachment; filename=sctp_restart_prob.pcap Content-Transfer-Encoding: base64 1MOyoQIABAAAAAAAAAAAAP//AAABAAAAN8gkUNyjDQBSAAAAUgAAAABQwneGlwBQwneGmwgARQIA RAAAQABAhLgBwKgAb8CoAHMmrCatAAAAAGpHMCoBAAAkr52kSgAA1AAAAf//0pqLRAAMAAYABQAA gAAABMAAAAQ3yCRQ16cNADIBAAAyAQAAAFDCd4abAFDCd4aXCABFAgEkAABAAECEtyHAqABzwKgA byatJqyvnaRK+++fpgIAAQQPraDrAADUAAABAAHZzUbbAAcA6GMzNcsO3H7mqsafxK3rI7sAAAAA AAAAAAAAAAAAAAAAAAAAAA+toOuvnaRKAAAAAAAAAABQJMeVAAitEwABAAHZzUbbAAImrMCoAG8A AAAAAAAAAAAAAAAAAAAAAAAAACatAQAAAAAAgAIAJB06G8p/kFVGzSI+uSeYZ1LcDYLcmjAfRYUv Ft43D3iLAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAACSvnaRKAADUAAAB///SmotEAAwA BgAFAACAAAAEwAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIAAAATAAAAEN8gkUCasDQA2AQAA NgEAAABQwneGlwBQwneGmwgARQIBKAAAQABAhLcdwKgAb8CoAHMmrCatD62g65mwBP8KAADoYzM1 yw7cfuaqxp/EresjuwAAAAAAAAAAAAAAAAAAAAAAAAAAD62g66+dpEoAAAAAAAAAAFAkx5UACK0T AAEAAdnNRtsAAiaswKgAbwAAAAAAAAAAAAAAAAAAAAAAAAAAJq0BAAAAAACAAgAkHTobyn+QVUbN Ij65J5hnUtwNgtyaMB9FhS8W3jcPeIsAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAJK+d pEoAANQAAAH//9Kai0QADAAGAAUAAIAAAATAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMA INKai0QAAAAAAAAAAQEAAwEAAAAQABEACAAAAAE3yCRQMK8NAEIAAABCAAAAAFDCd4abAFDCd4aX CABFAgA0AABAAECEuBHAqABzwKgAbyatJqyvnaRKUupv+QsAAAQDAAAQ0pqLRAAA0/AAAAAAN8gk UHa2DQBGAAAARgAAAABQwneGmwBQwneGlwgARQIAOAAAQABAhLgNwKgAc8CoAG8mrSasr52kSrjT e9gAAwAY2c1G2wAAAAAAAAABAQADBAAAAAg3yCRQN7gNAD4AAAA+AAAAAFDCd4aXAFDCd4abCABF AgAwAABAAECEuBXAqABvwKgAcyasJq0PraDrHU5JqAMAABDZzUbbAADT+AAAAAA3yCRQvbkNAE4A AABOAAAAAFDCd4abAFDCd4aXCABFAgBAAABAAECEuAXAqABzwKgAbyatJqyvnaRKtdIaqQADACDZ zUbcAAAAAQAAAAEBAAABAAAAEAANAAgAAQACN8gkUN0pDgBOAAAATgAAAABQwneGlwBQwneGmwgA RQIAQAAAQABAhLgFwKgAb8CoAHMmrCatD62g61svqyIAAwAg0pqLRQAAAAEAAAABAQAEAQAAABAA CwAIAAAAATjIJFAogQEAPgAAAD4AAAAAUMJ3hpcAUMJ3hpsIAEUCADAAAEAAQIS4FcCoAG/AqABz JqwmrQ+toOsHgClvAwAAENnNRtwAANP4AAAAADjIJFAwgwEAbgAAAG4AAAAAUMJ3hpsAUMJ3hpcI AEUCAGAAAEAAQIS35cCoAHPAqABvJq0mrK+dpErEJDizAAMAINnNRt0AAAACAAAAAQEABAMAAAAQ AAsACAAAAAEAAwAg2c1G3gAAAAMAAAABAQAAAQAAABAADQAIAAEAAzjIJFDv5wEAPgAAAD4AAAAA UMJ3hpsAUMJ3hpcIAEUCADAAAEAAQIS4FcCoAHPAqABvJq0mrK+dpEpKa+wJAwAAENKai0UAANPw AAAAADjIJFB3jgQAPgAAAD4AAAAAUMJ3hpcAUMJ3hpsIAEUCADAAAEAAQIS4FcCoAG/AqABzJqwm rQ+toOtmWriCAwAAENnNRt4AANP4AAAAADjIJFATkAQAVgAAAFYAAAAAUMJ3hpsAUMJ3hpcIAEUC AEgAAEAAQIS3/cCoAHPAqABvJq0mrK+dpEqKI8lXAAMAKNnNRt8AAAAEAAAAAQEABQYAAAAYAAEA CAAAI8AABQAIAAAAADjIJFC0mwcAPgAAAD4AAAAAUMJ3hpcAUMJ3hpsIAEUCADAAAEAAQIS4FcCo AG/AqABzJqwmrQ+toOsujIZ2AwAAENnNRt8AANP4AAAAAEnIJFCopQsAdgAAAHYAAAAAUMJ3hpsA UMJ3hpcIAEUCAGgAAEAAQIS33cCoAHPAqABvJq0mrK+dpErSDyV3AAMASNnNRuAAAAAFAAAAAQEA BQIAAAA4AAEACAAAI8AABQAIAAAAAAAOACAIAgAKBQQDgJCjGAOpg4FsBwCAMjAwNTh9ApGBScgk UGnrCwBqAAAAagAAAABQwneGlwBQwneGmwgARQIAXAAAQABAhLfpwKgAb8CoAHMmrCatD62g6wVU lIgAAwA80pqLRgAAAAIAAAABAQAFAQAAACwAAQAIAAAjwAAFAAgAAAAAAA4AEQgCgAoNGAOpg4E0 AQAAAABJyCRQirAOAD4AAAA+AAAAAFDCd4aXAFDCd4abCABFAgAwAABAAECEuBXAqABvwKgAcyas Jq0PraDrwgSJlgMAABDZzUbgAADT+AAAAABJyCRQF/kOAD4AAAA+AAAAAFDCd4abAFDCd4aXCABF AgAwAABAAECEuBXAqABzwKgAbyatJqyvnaRKY2dDEAMAABDSmotGAADT8AAAAABKyCRQGK4FAGYA AABmAAAAAFDCd4abAFDCd4aXCABFAgBYAABAAECEt+3AqABzwKgAbyatJqyvnaRKyrqxZgADADjZ zUbhAAAABgAAAAEBAAUCAAAAKAABAAgAACPAAAUACAAAAAAADgANCAIACntwAoAyAAAASsgkULO1 CAA+AAAAPgAAAABQwneGlwBQwneGmwgARQIAMAAAQABAhLgVwKgAb8CoAHMmrCatD62g64rSt2ID AAAQ2c1G4QAA0/gAAAAASsgkUHK3CABmAAAAZgAAAABQwneGmwBQwneGlwgARQIAWAAAQABAhLft wKgAc8CoAG8mrSasr52kSrWjZCcAAwA42c1G4gAAAAcAAAABAQAFAgAAACgAAQAIAAAjwAAFAAgA AAAAAA4ADQgCAAp7cAKAMQAAAErIJFAxwwsAPgAAAD4AAAAAUMJ3hpcAUMJ3hpsIAEUCADAAAEAA QIS4FcCoAG/AqABzJqwmrQ+toOuj3hh7AwAAENnNRuIAANP4AAAAAErIJFDJxAsAZgAAAGYAAAAA UMJ3hpsAUMJ3hpcIAEUCAFgAAEAAQIS37cCoAHPAqABvJq0mrK+dpEpygA5LAAMAONnNRuMAAAAI AAAAAQEABQIAAAAoAAEACAAAI8AABQAIAAAAAAAOAA0IAgAKe3ACgDAAAABLyCRQdkkAAD4AAAA+ AAAAAFDCd4aXAFDCd4abCABFAgAwAABAAECEuBXAqABvwKgAcyasJq0PraDr6wgmjwMAABDZzUbj AADT+AAAAABLyCRQe0sAAJ4AAACeAAAAAFDCd4abAFDCd4aXCABFAgCQAABAAECEt7XAqABzwKgA byatJqyvnaRKDH0NtwADADjZzUbkAAAACQAAAAEBAAUCAAAAKAABAAgAACPAAAUACAAAAAAADgAN CAIACntwAoAwAAAAAAMAONnNRuUAAAAKAAAAAQEABQIAAAAoAAEACAAAI8AABQAIAAAAAAAOAA0I AgAKe3ACgDAAAABLyCRQdzwBAGYAAABmAAAAAFDCd4aXAFDCd4abCABFAgBYAABAAECEt+3AqABv wKgAcyasJq0PraDrIjd11QADADjSmotHAAAAAwAAAAEBAAUBAAAAKAABAAgAACPAAAUACAAAAAAA DgAOCAKACgIYA6mDgQAAS8gkUEhXAwByAAAAcgAAAABQwneGlwBQwneGmwgARQIAZAAAQABAhLfh wKgAb8CoAHMmrCatD62g6y+t50sDAAAQ2c1G5QAA0/gAAAAAAAMANNKai0gAAAAEAAAAAQEABQEA AAAkAAEACAAAI8AABQAIAAAAAAAOAAwIAoAKATQBAUvIJFALWQMAPgAAAD4AAAAAUMJ3hpsAUMJ3 hpcIAEUCADAAAEAAQIS4FcCoAHPAqABvJq0mrK+dpErQjeSlAwAAENKai0gAANPcAAAAAE7IJFD1 iAgAagAAAGoAAAAAUMJ3hpcAUMJ3hpsIAEUCAFwAAEAAQIS36cCoAG/AqABzJqwmrQ+toOsGvXLR AAMAPNKai0kAAAAFAAAAAQEABQEAAAAsAAEACAAAI8AABQAIAAAAAAAOABIIAoAKBxgDqYOBHgKC iAAATsgkUFP6CABiAAAAYgAAAABQwneGmwBQwneGlwgARQIAVAAAQABAhLfxwKgAc8CoAG8mrSas r52kSlrVeLMAAwA02c1G5gAAAAsAAAABAQAFAgAAACQAAQAIAAAjwAAFAAgAAAAAAA4ACQgCAAoP AAAATsgkUM6OCwA+AAAAPgAAAABQwneGmwBQwneGlwgARQIAMAAAQABAhLgVwKgAc8CoAG8mrSas r52kSphb2lEDAAAQ0pqLSQAA09wAAAAATsgkULIBDAA+AAAAPgAAAABQwneGlwBQwneGmwgARQIA MAAAQABAhLgVwKgAb8CoAHMmrCatD62g65Ac16UDAAAQ2c1G5gAA0/gAAAAAZsgkUFI9CABWAAAA VgAAAABQwneGmwBQwneGlwgARQIASAAAQABAhLf9wKgAc8CoAG8mrSasr52kSlHYPv0AAwAo2c1G 5wAAAAwAAAABAQAFBgAAABgAAQAIAAAjwAAFAAgAAAAAZ8gkUCA2CABWAAAAVgAAAABQwneGmwBQ wneGlwgARQIASAAAQABAhLf9wKgAc8CoAG8mrSasr52kSlHYPv0AAwAo2c1G5wAAAAwAAAABAQAF BgAAABgAAQAIAAAjwAAFAAgAAAAAaMgkUJVXDABSAAAAUgAAAABQwneGlwBQwneHJQgARQIARAAA QABAhLgBwKgAb8CoAHMmrCatAAAAABTs87YBAAAkkdFPVAAA1AAAAf//UkVWnQAMAAYABQAAgAAA BMAAAARoyCRQplsMADIBAAAyAQAAAFDCd4clAFDCd4aXCABFAgEkAABAAECEtyHAqABzwKgAbyat JqyR0U9UB9QOywIAAQS0iw9eAADUAAABAAHZzUbbAAcA6OK2buLy0MOQDvPN3fvgU9IAAAAAAAAA AAAAAAAAAAAAAAAAALSLD16R0U9UD62g66+dpEpQJMfGAAdcGwABAAHZzUbbAAImrMCoAG8AAAAA AAAAAAAAAAAAAAAAAAAAACatAQAAAAAAgAIAJOLLTY8irg3O6myUechP+UNLzVJlnHIJ6CBDF+0K NHYsAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAACSR0U9UAADUAAAB//9SRVadAAwABgAF AACAAAAEwAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIAAAATAAAAEaMgkUNhdDAA2AQAANgEA AABQwneGlwBQwneHJQgARQIBKAAAQABAhLcdwKgAb8CoAHMmrCattIsPXuTiOxMKAADo4rZu4vLQ w5AO883d++BT0gAAAAAAAAAAAAAAAAAAAAAAAAAAtIsPXpHRT1QPraDrr52kSlAkx8YAB1wbAAEA AdnNRtsAAiaswKgAbwAAAAAAAAAAAAAAAAAAAAAAAAAAJq0BAAAAAACAAgAk4stNjyKuDc7qbJR5 yE/5Q0vNUmWccgnoIEMX7Qo0diwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAJJHRT1QA ANQAAAH//1JFVp0ADAAGAAUAAIAAAATAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMAIFJF Vp0AAAAAAAAAAQEAAwEAAAAQABEACAAAAAFoyCRQ8GAMADwAAAA8AAAAAFDCd4clAFDCd4aXCABF AgAkAABAAECEuCHAqABzwKgAbyatJqyR0U9UBliF9QsAAAQAAAAAAAAAAAAAaMgkUFphDAA+AAAA PgAAAABQwneHJQBQwneGlwgARQIAMAAAQABAhLgVwKgAc8CoAG8mrSaskdFPVHnxCe4DAAAQUkVW nQAA09wAAAAAiMgkUAJaAACWAAAAlgAAAABQwneHJQBQwneGlwgARQIAiAAAQABAhLe9wKgAc8Co AG8mrSaskdFPVIpLLAUEAAAwAAEALAACJqzAqABvAAAAAAAAAAAAAAAAAAAAAAAAAAAA93SJB86Y 9P2I54sAAwAY2c1G2wAAAAAAAAABAQADBAAAAAgAAwAg2c1G3AAAAAEAAAABAQAAAQAAABAADQAI AAEAAojIJFBkWwAAbgAAAG4AAAAAUMJ3hpcAUMJ3hyUIAEUCAGAAAEAAQIS35cCoAG/AqABzJqwm rbSLD14B6tgUBQAAMAABACwAAiaswKgAbwAAAAAAAAAAAAAAAAAAAAAAAAAAAPd0iQfOmPT9iOeL AwAAENnNRtwAANPoAAAAAIjIJFC4zQAATgAAAE4AAAAAUMJ3hpcAUMJ3hyUIAEUCAEAAAEAAQIS4 BcCoAG/AqABzJqwmrbSLD142sGXiAAMAIFJFVp4AAAABAAAAAQEABAEAAAAQAAsACAAAAAGIyCRQ R5IBAH4AAAB+AAAAAFDCd4clAFDCd4aXCABFAgBwAABAAECEt9XAqABzwKgAbyatJqyR0U9U/VeY kwMAABBSRVaeAADT3AAAAAAAAwAg2c1G3QAAAAIAAAABAQAEAwAAABAACwAIAAAAAQADACDZzUbe AAAAAwAAAAEBAAABAAAAEAANAAgAAQADiMgkUAuXBAA+AAAAPgAAAABQwneGlwBQwneHJQgARQIA MAAAQABAhLgVwKgAb8CoAHMmrCattIsPXmgmFo4DAAAQ2c1G3gAA0+gAAAAAisgkUBSQBABeAAAA XgAAAABQwneHJQBQwneGlwgARQIAUAAAQABAhLf1wKgAc8CoAG8mrSaskdFPVHmW2GQEAAAwAAEA LAACJqzAqABvAAAAAAAAAAAAAAAAAAAAAAAAAAAA93bCB86Y9P2I54uKyCRQG5EEAF4AAABeAAAA AFDCd4aXAFDCd4clCABFAgBQAABAAECEt/XAqABvwKgAcyasJq20iw9eQgP0mQUAADAAAQAsAAIm rMCoAG8AAAAAAAAAAAAAAAAAAAAAAAAAAAD3dsIHzpj0/Yjni4zIJFB0BwYAjgAAAI4AAAAAUMJ3 hyUAUMJ3hpcIAEUCAIAAAEAAQIS3xcCoAHPAqABvJq0mrJHRT1Tfe5yfBAAAMAABACwAAiaswKgA bwAAAAAAAAAAAAAAAAAAAAAAAAAAAPd4zgfOmPT9iOeLAAMAMNnNRt8AAAAEAAAAAQEABQoAAAAg AAEACAAAI8AABQAIAAAAAAAPAAgAAAABjMgkUJwIBgBeAAAAXgAAAABQwneGlwBQwneHJQgARQIA UAAAQABAhLf1wKgAb8CoAHMmrCattIsPXtQsvwkFAAAwAAEALAACJqzAqABvAAAAAAAAAAAAAAAA AAAAAAAAAAAA93jOB86Y9P2I54uMyCRQAQwJAD4AAAA+AAAAAFDCd4aXAFDCd4clCABFAgAwAABA AECEuBXAqABvwKgAcyasJq20iw9eIPAoegMAABDZzUbfAADT6AAAAACOyCRQTUgDAF4AAABeAAAA AFDCd4clAFDCd4aXCABFAgBQAABAAECEt/XAqABzwKgAbyatJqyR0U9UuGzGYgQAADAAAQAsAAIm rMCoAG8AAAAAAAAAAAAAAAAAAAAAAAAAAAD3epUHzpj0/Yjni47IJFBPSQMAXgAAAF4AAAAAUMJ3 hpcAUMJ3hyUIAEUCAFAAAEAAQIS39cCoAG/AqABzJqwmrbSLD16D+eqfBQAAMAABACwAAiaswKgA bwAAAAAAAAAAAAAAAAAAAAAAAAAAAPd6lQfOmPT9iOeLkMgkUP/wAQCGAAAAhgAAAABQwneHJQBQ wneGlwgARQIAeAAAQABAhLfNwKgAc8CoAG8mrSaskdFPVHg1e34EAAAwAAEALAACJqzAqABvAAAA AAAAAAAAAAAAAAAAAAAAAAAA93xzB86Y9P2I54sAAwAo2c1G4AAAAAUAAAABAQAFBgAAABgAAQAI AAAjwAAFAAgAAAAAkMgkUDDyAQBeAAAAXgAAAABQwneGlwBQwneHJQgARQIAUAAAQABAhLf1wKgA b8CoAHMmrCattIsPXjUOJIEFAAAwAAEALAACJqzAqABvAAAAAAAAAAAAAAAAAAAAAAAAAAAA93xz B86Y9P2I54uQyCRQUfUEAD4AAAA+AAAAAFDCd4aXAFDCd4clCABFAgAwAABAAECEuBXAqABvwKgA cyasJq20iw9ezHgnmgMAABDZzUbgAADT6AAAAACSyCRQYcUDAF4AAABeAAAAAFDCd4clAFDCd4aX CABFAgBQAABAAECEt/XAqABzwKgAbyatJqyR0U9U4IqgNAQAADAAAQAsAAImrMCoAG8AAAAAAAAA AAAAAAAAAAAAAAAAAAD3foUHzpj0/Yjni5LIJFBkxgMAXgAAAF4AAAAAUMJ3hpcAUMJ3hyUIAEUC AFAAAEAAQIS39cCoAG/AqABzJqwmrbSLD17bH4zJBQAAMAABACwAAiaswKgAbwAAAAAAAAAAAAAA AAAAAAAAAAAAAPd+hQfOmPT9iOeLlMgkUKiDAQBeAAAAXgAAAABQwneHJQBQwneGlwgARQIAUAAA QABAhLf1wKgAc8CoAG8mrSaskdFPVEA+6uAEAAAwAAEALAACJqzAqABvAAAAAAAAAAAAAAAAAAAA AAAAAAAA94BUB86Y9P2I54uUyCRQt4QBAF4AAABeAAAAAFDCd4aXAFDCd4clCABFAgBQAABAAECE t/XAqABvwKgAcyasJq20iw9ee6vGHQUAADAAAQAsAAImrMCoAG8AAAAAAAAAAAAAAAAAAAAAAAAA AAD3gFQHzpj0/Yjni5XIJFCpOw0AXgAAAF4AAAAAUMJ3hyUAUMJ3hpcIAEUCAFAAAEAAQIS39cCo AHPAqABvJq0mrJHRT1RfPYGCBAAAMAABACwAAiaswKgAbwAAAAAAAAAAAAAAAAAAAAAAAAAAAPeC DgfOmPT9iOeLlcgkUKE8DQBeAAAAXgAAAABQwneGlwBQwneHJQgARQIAUAAAQABAhLf1wKgAb8Co AHMmrCattIsPXmSorX8FAAAwAAEALAACJqzAqABvAAAAAAAAAAAAAAAAAAAAAAAAAAAA94IOB86Y 9P2I54uXyCRQk8IOAF4AAABeAAAAAFDCd4clAFDCd4aXCABFAgBQAABAAECEt/XAqABzwKgAbyat JqyR0U9Ux05WbQQAADAAAQAsAAImrMCoAG8AAAAAAAAAAAAAAAAAAAAAAAAAAAD3hBsHzpj0/Yjn i5fIJFCWww4AXgAAAF4AAAAAUMJ3hpcAUMJ3hyUIAEUCAFAAAEAAQIS39cCoAG/AqABzJqwmrbSL D17823qQBQAAMAABACwAAiaswKgAbwAAAAAAAAAAAAAAAAAAAAAAAAAAAPeEGwfOmPT9iOeLmcgk ULmGCwBeAAAAXgAAAABQwneHJQBQwneGlwgARQIAUAAAQABAhLf1wKgAc8CoAG8mrSaskdFPVEzf lCUEAAAwAAEALAACJqzAqABvAAAAAAAAAAAAAAAAAAAAAAAAAAAA94XaB86Y9P2I54uZyCRQwocL AF4AAABeAAAAAFDCd4aXAFDCd4clCABFAgBQAABAAECEt/XAqABvwKgAcyasJq20iw9ed0q42AUA ADAAAQAsAAImrMCoAG8AAAAAAAAAAAAAAAAAAAAAAAAAAAD3hdoHzpj0/Yjni5vIJFCWNQkApgAA AKYAAAAAUMJ3hyUAUMJ3hpcIAEUCAJgAAEAAQIS3rcCoAHPAqABvJq0mrJHRT1R07r8TBAAAMAAB ACwAAiaswKgAbwAAAAAAAAAAAAAAAAAAAAAAAAAAAPeHqAfOmPT9iOeLAAMASNnNRuEAAAAGAAAA AQEABQIAAAA4AAEACAAAI8AABQAIAAAAAAAOACAIAgALBQQDgJCjGAOpg4FsBwCAMjAwNTh9ApGB m8gkUNU2CQBeAAAAXgAAAABQwneGlwBQwneHJQgARQIAUAAAQABAhLf1wKgAb8CoAHMmrCattIsP XkGct+gFAAAwAAEALAACJqzAqABvAAAAAAAAAAAAAAAAAAAAAAAAAAAA94eoB86Y9P2I54ubyCRQ BmMJAGoAAABqAAAAAFDCd4aXAFDCd4clCABFAgBcAABAAECEt+nAqABvwKgAcyasJq20iw9eySxY uwADADxSRVafAAAAAgAAAAEBAAUBAAAALAABAAgAACPAAAUACAAAAAAADgARCAKACw0YA6mDgTQB AAAAAJvIJFAgLwoAdgAAAHYAAAAAUMJ3hyUAUMJ3hpcIAEUCAGgAAEAAQIS33cCoAHPAqABvJq0m rJHRT1SBo18dAwAAEFJFVp8AANPcAAAAAAADADjZzUbiAAAABwAAAAEBAAUCAAAAKAABAAgAACPA AAUACAAAAAAADgANCAIAC3twAoAyAAAAm8gkUEIwCgA+AAAAPgAAAABQwneGlwBQwneHJQgARQIA MAAAQABAhLgVwKgAb8CoAHMmrCattIsPXil2POMDAAAQ2c1G4gAA09gAAAAAncgkUNOzCQA+AQAA PgEAAABQwneHJQBQwneGlwgARQIBMAAAQABAhLcVwKgAc8CoAG8mrSaskdFPVI4l0FUEAAAwAAEA LAACJqzAqABvAAAAAAAAAAAAAAAAAAAAAAAAAAAA94mkB86Y9P2I54sAAwA42c1G4wAAAAgAAAAB AQAFAgAAACgAAQAIAAAjwAAFAAgAAAAAAA4ADQgCAAt7cAKAMQAAAAADADjZzUbkAAAACQAAAAEB AAUCAAAAKAABAAgAACPAAAUACAAAAAAADgANCAIAC3twAoAwAAAAAAMAONnNRuUAAAAKAAAAAQEA BQIAAAAoAAEACAAAI8AABQAIAAAAAAAOAA0IAgALe3ACgDAAAAAAAwA42c1G5gAAAAsAAAABAQAF AgAAACgAAQAIAAAjwAAFAAgAAAAAAA4ADQgCAAt7cAKAMAAAAJ3IJFA9tQkAXgAAAF4AAAAAUMJ3 hpcAUMJ3hyUIAEUCAFAAAEAAQIS39cCoAG/AqABzJqwmrbSLD17Xs/x4BQAAMAABACwAAiaswKgA bwAAAAAAAAAAAAAAAAAAAAAAAAAAAPeJpAfOmPT9iOeLncgkUJtpCwBmAAAAZgAAAABQwneGlwBQ wneHJQgARQIAWAAAQABAhLftwKgAb8CoAHMmrCattIsPXtvoK+gAAwA4UkVWoAAAAAMAAAABAQAF AQAAACgAAQAIAAAjwAAFAAgAAAAAAA4ADggCgAsCGAOpg4EAAJ3IJFDZMgwAPgAAAD4AAAAAUMJ3 hyUAUMJ3hpcIAEUCADAAAEAAQIS4FcCoAHPAqABvJq0mrJHRT1T0o5fjAwAAEFJFVqAAANPcAAAA AJ3IJFD6MwwAYgAAAGIAAAAAUMJ3hpcAUMJ3hyUIAEUCAFQAAEAAQIS38cCoAG/AqABzJqwmrbSL D14qiaSaAAMANFJFVqEAAAAEAAAAAQEABQEAAAAkAAEACAAAI8AABQAIAAAAAAAOAAwIAoALATQB AZ3IJFCwtgwAPgAAAD4AAAAAUMJ3hpcAUMJ3hyUIAEUCADAAAEAAQIS4FcCoAG/AqABzJqwmrbSL D14atPM9AwAAENnNRuYAANPYAAAAAJ3IJFCl/QwAPgAAAD4AAAAAUMJ3hyUAUMJ3hpcIAEUCADAA AEAAQIS4FcCoAHPAqABvJq0mrJHRT1S8dakXAwAAEFJFVqEAANPcAAAAAJ/IJFDw3gwAXgAAAF4A AAAAUMJ3hyUAUMJ3hpcIAEUCAFAAAEAAQIS39cCoAHPAqABvJq0mrJHRT1TzSzaVBAAAMAABACwA AiaswKgAbwAAAAAAAAAAAAAAAAAAAAAAAAAAAPeLzAfOmPT9iOeLn8gkUPPfDABeAAAAXgAAAABQ wneGlwBQwneHJQgARQIAUAAAQABAhLf1wKgAb8CoAHMmrCattIsPXsjeGmgFAAAwAAEALAACJqzA qABvAAAAAAAAAAAAAAAAAAAAAAAAAAAA94vMB86Y9P2I54uiyCRQlx0AAF4AAABeAAAAAFDCd4cl AFDCd4aXCABFAgBQAABAAECEt/XAqABzwKgAbyatJqyR0U9UCoz95QQAADAAAQAsAAImrMCoAG8A AAAAAAAAAAAAAAAAAAAAAAAAAAD3jekHzpj0/Yjni6LIJFCMHgAAXgAAAF4AAAAAUMJ3hpcAUMJ3 hyUIAEUCAFAAAEAAQIS39cCoAG/AqABzJqwmrbSLD14xGdEYBQAAMAABACwAAiaswKgAbwAAAAAA AAAAAAAAAAAAAAAAAAAAAPeN6QfOmPT9iOeLosgkUHm9CgBqAAAAagAAAABQwneGlwBQwneHJQgA RQIAXAAAQABAhLfpwKgAb8CoAHMmrCattIsPXirMsogAAwA8UkVWogAAAAUAAAABAQAFAQAAACwA AQAIAAAjwAAFAAgAAAAAAA4AEggCgAsHGAOpg4EeAoKIAACiyCRQoocLAHIAAAByAAAAAFDCd4cl AFDCd4aXCABFAgBkAABAAECEt+HAqABzwKgAbyatJqyR0U9UtZR8fQMAABBSRVaiAADT3AAAAAAA AwA02c1G5wAAAAwAAAABAQAFAgAAACQAAQAIAAAjwAAFAAgAAAAAAA4ACQgCAAsPAAAAosgkUM2L DgA+AAAAPgAAAABQwneGlwBQwneHJQgARQIAMAAAQABAhLgVwKgAb8CoAHMmrCattIsPXlJizckD AAAQ2c1G5wAA09gAAAAApMgkUB8sCABeAAAAXgAAAABQwneHJQBQwneGlwgARQIAUAAAQABAhLf1 wKgAc8CoAG8mrSaskdFPVEZIstgEAAAwAAEALAACJqzAqABvAAAAAAAAAAAAAAAAAAAAAAAAAAAA 95BhB86Y9P2I54ukyCRQKS0IAF4AAABeAAAAAFDCd4aXAFDCd4clCABFAgBQAABAAECEt/XAqABv wKgAcyasJq20iw9efd2eJQUAADAAAQAsAAImrMCoAG8AAAAAAAAAAAAAAAAAAAAAAAAAAAD3kGEH zpj0/Yjni6XIJFA3NAkAZgAAAGYAAAAAUMJ3hpcAUMJ3hyUIAEUCAFgAAEAAQIS37cCoAG/AqABz JqwmrbSLD16FWOiFAAMAOFJFVqMAAAAGAAAAAQEABQEAAAAoAAEACAAAI8AABQAIAAAAAAAOAA0I AoALRQgCgpAAAAClyCRQVwEKAHYAAAB2AAAAAFDCd4clAFDCd4aXCABFAgBoAABAAECEt93AqABz wKgAbyatJqyR0U9UCO39TQMAABBSRVajAADT3AAAAAAAAwA42c1G6AAAAA0AAAABAQAFAgAAACgA AQAIAAAjwAAFAAgAAAAAAA4ADQgCAAtNCAKBkAAAAKXIJFAjQQoAYgAAAGIAAAAAUMJ3hpcAUMJ3 hyUIAEUCAFQAAEAAQIS38cCoAG/AqABzJqwmrbSLD17BOOqWAAMANFJFVqQAAAAHAAAAAQEABQEA AAAkAAEACAAAI8AABQAIAAAAAAAOAAkIAoALWgAAAKXIJFCUCgsAPgAAAD4AAAAAUMJ3hyUAUMJ3 hpcIAEUCADAAAEAAQIS4FcCoAHPAqABvJq0mrJHRT1THYVg9AwAAEFJFVqQAANPcAAAAAKXIJFBo BQ0APgAAAD4AAAAAUMJ3hpcAUMJ3hyUIAEUCADAAAEAAQIS4FcCoAG/AqABzJqwmrbSLD17fXt62 AwAAENnNRugAANPYAAAAAKfIJFAAggwAXgAAAF4AAAAAUMJ3hyUAUMJ3hpcIAEUCAFAAAEAAQIS3 9cCoAHPAqABvJq0mrJHRT1RF9HKvBAAAMAABACwAAiaswKgAbwAAAAAAAAAAAAAAAAAAAAAAAAAA APeTlgfOmPT9iOeLp8gkUBODDABeAAAAXgAAAABQwneGlwBQwneHJQgARQIAUAAAQABAhLf1wKgA b8CoAHMmrCattIsPXn5hXlIFAAAwAAEALAACJqzAqABvAAAAAAAAAAAAAAAAAAAAAAAAAAAA95OW B86Y9P2I54upyCRQUxgOAF4AAABeAAAAAFDCd4clAFDCd4aXCABFAgBQAABAAECEt/XAqABzwKgA byatJqyR0U9UeW7SbQQAADAAAQAsAAImrMCoAG8AAAAAAAAAAAAAAAAAAAAAAAAAAAD3laQHzpj0 /Yjni6nIJFBYGQ4AXgAAAF4AAAAAUMJ3hpcAUMJ3hyUIAEUCAFAAAEAAQIS39cCoAG/AqABzJqwm rbSLD15C+/6QBQAAMAABACwAAiaswKgAbwAAAAAAAAAAAAAAAAAAAAAAAAAAAPeVpAfOmPT9iOeL q8gkULTKDQBeAAAAXgAAAABQwneHJQBQwneGlwgARQIAUAAAQABAhLf1wKgAc8CoAG8mrSaskdFP VLmV7qYEAAAwAAEALAACJqzAqABvAAAAAAAAAAAAAAAAAAAAAAAAAAAA95eTB86Y9P2I54uryCRQ rssNAF4AAABeAAAAAFDCd4aXAFDCd4clCABFAgBQAABAAECEt/XAqABvwKgAcyasJq20iw9eggDC WwUAADAAAQAsAAImrMCoAG8AAAAAAAAAAAAAAAAAAAAAAAAAAAD3l5MHzpj0/Yjni63IJFBdNAwA XgAAAF4AAAAAUMJ3hyUAUMJ3hpcIAEUCAFAAAEAAQIS39cCoAHPAqABvJq0mrJHRT1RJ6IIzBAAA MAABACwAAiaswKgAbwAAAAAAAAAAAAAAAAAAAAAAAAAAAPeZbQfOmPT9iOeLrcgkUGE1DABeAAAA XgAAAABQwneGlwBQwneHJQgARQIAUAAAQABAhLf1wKgAb8CoAHMmrCattIsPXnJ9rs4FAAAwAAEA LAACJqzAqABvAAAAAAAAAAAAAAAAAAAAAAAAAAAA95ltB86Y9P2I54s= --=_06a0eff5-35d5-45c4-8962-604b39fd0c77-- From Michael.Tuexen@lurchi.franken.de Sat Aug 11 01:26:10 2012 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3A3A21F84D5 for ; Sat, 11 Aug 2012 01:26:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.444 X-Spam-Level: X-Spam-Status: No, score=-1.444 tagged_above=-999 required=5 tests=[AWL=0.555, BAYES_00=-2.599, J_CHICKENPOX_57=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rFmGN3atidjr for ; Sat, 11 Aug 2012 01:26:10 -0700 (PDT) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by ietfa.amsl.com (Postfix) with ESMTP id DC1D921F84D3 for ; Sat, 11 Aug 2012 01:26:09 -0700 (PDT) Received: from [192.168.1.200] (p508F9531.dip.t-dialin.net [80.143.149.49]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 6166B1C0B4619; Sat, 11 Aug 2012 10:26:07 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Michael Tuexen In-Reply-To: Date: Sat, 11 Aug 2012 10:26:08 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Prafulla Sarode X-Mailer: Apple Mail (2.1278) Cc: tsvwg@ietf.org Subject: Re: [tsvwg] When SCTP client is restarted, DATA chunks start piggy backing in heart beat and sack chunks only in direction server to client only.. X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Aug 2012 08:26:10 -0000 On Aug 10, 2012, at 1:34 PM, Prafulla Sarode wrote: > Hi; >=20 > I am using a linux kernel 2.6.30 on ppc machine. > I have a one-to-many style server and client running on different = machines. (socket(AF_INET,SOCK_SEQPACKET,IPPROTO_SCTP)) type connection. >=20 > Initially every thing works fine. All messages transported properly = from both direction. >=20 > Now when client restarts without sending the SHUTDOWN chunk (i.e. due = to eth down or some other reason), the server(application) receives the = SCTP_RESTART event, when client comes up and tries the association. Now = what ever message is sent by server, it will only be transmitted = whenever either heartbeat,SACK, heartbeat-ack is transmitted. All the = messages are delivered to client properly but are sent on the wire piggy = backed on either heartbeat,sack,heartbeatack only. The messages sent by = client are transmitted on wire as usua l and normal. >=20 > I have done more analysis and it was found that when client is = restarted without the knowledge of server(without sending SHUTDOWN) and = before receiving any INIT from client, if server has sent any message = and then received the INIT from client at this time the server first = receives the send_failed and then SCTP_RESTART event and the problem = starts. >=20 > If between the restart of client (without sending SHUTDOWN) and INIT = after client application restart, if server has not sent any message, = then even if server receives the SCTP_RESTART event there is no such = problem and communication is normal. >=20 > If client restarts first by sending the SHUTDOWN and then restarting = application and sending INIT there is no problem. >=20 > My application is 2 machines sharing same ip-address one at a time at = both server and client sites(Typical hot-standby application). First = client (working) has established conne ction with working server, when = ever working client detect ethernet down it releaves the control of = ip-address and restarts (As there is not ethernet available the SHUTDOWN = does not reach the server), and immediately standby client becomes = primary acquires the ip-address,send GARP packet and establishes the = connection with the server, and server receives the SCTP_RESTART event. >=20 > The problem occurs only when some message is transmitted by server = between the period the old client is shutdown and new client has = restarted.(sent INIT) >=20 > Attaching the wirehark capture for reference. > Client shared ip-address-192.168.0.111 - server ip address = 192.168.0.115 > frames 33 and 34 which is retransmission of the 33 data chunk are the = packets transmitted between client restart. frame 35 is the first INIT = of the new client(192.168.0.111). >=20 > The problem can be seen in frames from server(0.115) to client (0.111) = in frames 40,43,47,52,65,68,70,82 etc. >=20 > Please suggest s ome solution. I don't think that this is a protocol issue, it is an implementation = issue of the Linux kernel SCTP implementation. You might want to ask this question on the = LKSCTP mailing list: lksctp-developers@lists.sourceforge.net If I remember it correctly, there were some bugs related to association = restart and they were fixed. So the first suggestion you might get it is use a more = recent version of the OS. I think the version you are using is more than 3 years old. Best regards Michael >=20 > Regards > PRAFULLA SARODE > Coral Telecom Ltd > E-2 Sect-63 Noida >=20 > "PLEASURE IN THE JOB PUT PERFECTION IN THE WORK" >=20 > From internet-drafts@ietf.org Mon Aug 13 07:00:39 2012 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 445EC21F86CB; Mon, 13 Aug 2012 07:00:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.428 X-Spam-Level: X-Spam-Status: No, score=-102.428 tagged_above=-999 required=5 tests=[AWL=0.171, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AnydvlicCQQX; Mon, 13 Aug 2012 07:00:38 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFFDA21F85DF; Mon, 13 Aug 2012 07:00:38 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.33 Message-ID: <20120813140038.14936.92566.idtracker@ietfa.amsl.com> Date: Mon, 13 Aug 2012 07:00:38 -0700 Cc: tsvwg@ietf.org Subject: [tsvwg] I-D Action: draft-ietf-tsvwg-byte-pkt-congest-08.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Aug 2012 14:00:39 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Transport Area Working Group Working Grou= p of the IETF. Title : Byte and Packet Congestion Notification Author(s) : Bob Briscoe Jukka Manner Filename : draft-ietf-tsvwg-byte-pkt-congest-08.txt Pages : 43 Date : 2012-08-13 Abstract: This document provides recommendations of best current practice for dropping or marking packets using active queue management (AQM) such as random early detection (RED) or pre-congestion notification (PCN). We give three strong recommendations: (1) packet size should be taken into account when transports read and respond to congestion indications, (2) packet size should not be taken into account when network equipment creates congestion signals (marking, dropping), and therefore (3) the byte-mode packet drop variant of the RED AQM algorithm that drops fewer small packets should not be used. This memo updates RFC 2309 to deprecate deliberate preferential treatment of small packets in AQM algorithms. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tsvwg-byte-pkt-congest There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-tsvwg-byte-pkt-congest-08 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tsvwg-byte-pkt-congest-08 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From gorry@erg.abdn.ac.uk Wed Aug 15 00:40:52 2012 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDAE121F85D2 for ; Wed, 15 Aug 2012 00:40:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.524 X-Spam-Level: X-Spam-Status: No, score=-102.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4wLL+sIp5CWZ for ; Wed, 15 Aug 2012 00:40:52 -0700 (PDT) Received: from spey.erg.abdn.ac.uk (spey.erg.abdn.ac.uk [139.133.204.173]) by ietfa.amsl.com (Postfix) with ESMTP id BDAFB21F85D0 for ; Wed, 15 Aug 2012 00:40:51 -0700 (PDT) Received: by spey.erg.abdn.ac.uk (Postfix, from userid 5001) id 582B22B4540; Wed, 15 Aug 2012 08:42:17 +0100 (BST) Received: from Gorry.local (ra-gorry.erg.abdn.ac.uk [139.133.204.42]) by spey.erg.abdn.ac.uk (Postfix) with ESMTPSA id C8FB72B403A for ; Wed, 15 Aug 2012 08:42:14 +0100 (BST) Message-ID: <502B527E.5090700@erg.abdn.ac.uk> Date: Wed, 15 Aug 2012 08:40:46 +0100 From: Gorry Fairhurst Organization: The University of Aberdeen is a charity registered in Scotland, No SC013683. User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: tsvwg@ietf.org References: <502B4E2D.7070700@abdn.ac.uk> In-Reply-To: <502B4E2D.7070700@abdn.ac.uk> X-Forwarded-Message-Id: <502B4E2D.7070700@abdn.ac.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [tsvwg] FYI: Document writeup for draft-ietf-tsvwg-byte-pkt-congest X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: gorry@erg.abdn.ac.uk List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Aug 2012 07:40:53 -0000 The following document has been revised after receiving WGLC comments. No issues were found: http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-byte-pkt-congest-08.txt This is now considered ready for publication. A copy o the writeup is below, which will shortly be submitted to our TSV ADs. Best wishes, Gorry --- As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Changes are expected over time. This version is dated 24 February 2012. (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header? This document is intended as BCP. (This was discussed at IETF-81 and that the status changed from Informational to BCP since it provides guidance to implementors and people configuring routers and hosts). (2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary This document provides recommendations of best current practice for dropping or marking packets using active queue management (AQM) such as random early detection (RED) or pre- congestion notification (PCN). We give three strong recommendations: (1) packet size should be taken into account when transports read and respond to congestion indications, (2) packet size should not be taken into account when network equipment creates congestion signals (marking, dropping), and therefore (3) the byte-mode packet drop variant of the RED AQM algorithm that drops fewer small packets should not be used. The document updates RFC 2309. Working Group Summary There was consensus to publish this as a WG document and agreement at IETF-82 that the document was now complete. Document Quality Annexe A summarises a survey by the original authors showing deployment of the techniques by router vendors. The recommendations are thought to be in line with that of IETF groups, such as TSVWF, TCPM, PCN, and are considered good advice for the general Internet. Personnel Who is the Document Shepherd? Who is the Responsible Area Director? I am the document shepherd, G Fairhurst. (3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG. The document was presented at IEWTF-82 (Taipei), with a request for WGLC. WGLC concluded with some discussion but no substantive changes on Friday 30th March 2012. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? No - the original draft had a lot of background material, much of this has been condensed or removed, resulting in a smaller document. (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place. No. (6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. None. (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why. Yes. (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. No IPR disclosures have been submitted directly on draft-ietf-tsvwg-byte-pkt-congest. (9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? The document has WG support and there is consensus to publish. (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) (11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. No. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. Not applicable. (13) Have all references within this document been identified as either normative or informative? Yes. (14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion? No. (15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. No. (16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary. One update is listed, RFC 2309, informational - replaced by this BCP. It deprecates deliberate preferential treatment of small packets in AQM algorithms. (17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226). Not applicable. (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries. None. (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc. Not applicable. From nagesh.shamnur@huawei.com Tue Aug 14 08:14:52 2012 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37B9D21F8565 for ; Tue, 14 Aug 2012 08:14:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.149 X-Spam-Level: X-Spam-Status: No, score=-5.149 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MSGID_MULTIPLE_AT=1.449, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VMNOrhlyDZSh for ; Tue, 14 Aug 2012 08:14:51 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 7A0E121F8543 for ; Tue, 14 Aug 2012 08:14:43 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AIW17003; Tue, 14 Aug 2012 07:14:43 -0800 (PST) Received: from DFWEML404-HUB.china.huawei.com (10.193.5.203) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 14 Aug 2012 08:12:26 -0700 Received: from SZXEML405-HUB.china.huawei.com (10.82.67.60) by dfweml404-hub.china.huawei.com (10.193.5.203) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 14 Aug 2012 08:12:29 -0700 Received: from blrprnc03ns (10.18.96.92) by szxeml405-hub.china.huawei.com (10.82.67.60) with Microsoft SMTP Server id 14.1.323.3; Tue, 14 Aug 2012 23:12:16 +0800 From: nagesh To: Date: Tue, 14 Aug 2012 20:42:15 +0530 Organization: Htipl Message-ID: <000901cd7a2f$310364d0$930a2e70$@shamnur@huawei.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000A_01CD7A5D.4ABBA0D0" X-Mailer: Microsoft Office Outlook 12.0 thread-index: Ac16LzBLBLOk0UvcS1a8oStJfFSDiQ== Content-Language: en-us X-Originating-IP: [10.18.96.92] X-CFilter-Loop: Reflected X-Mailman-Approved-At: Wed, 15 Aug 2012 06:13:49 -0700 Cc: rajithr@huawei.com Subject: [tsvwg] Doubt regarding the behavior of bind( ) as per RFC 6458 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: nagesh.shamnur@gmail.com List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Aug 2012 15:14:52 -0000 ------=_NextPart_000_000A_01CD7A5D.4ABBA0D0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, I have a doubt regarding what should be the behavior of the SCTP stack for bind( ) operation as explained in the RFC 6458 section 4.1.2 What RFC mentions is, if the IP address part of addr is specified as wildcard (IN6ADDR_ANY_INIT), operating system will associate the endpoint with an optimal address set of the available interfaces. Can anybody provide more insight on "optimal address set", since this point is not clear in the RFC. Thanks and Regards, Nagesh. 4.1.2. bind() ... If the IP address part of addr is specified as a wildcard (INADDR_ANY for an IPv4 address, or as IN6ADDR_ANY_INIT or in6addr_any for an IPv6 address), the operating system will associate the endpoint with an optimal address set of the available interfaces. If the IPv4 sin_port or IPv6 sin6_port is set to 0, the operating system will choose an ephemeral port for the endpoint. ------=_NextPart_000_000A_01CD7A5D.4ABBA0D0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

         &= nbsp;      I have a doubt regarding what should = be the behavior of the SCTP stack for bind( ) operation as explained in = the RFC 6458 section 4.1.2

 

         &= nbsp;      What RFC mentions is, if the IP = address part of addr is specified as wildcard (IN6ADDR_ANY_INIT), = operating system will associate the endpoint with an optimal address set = of the available interfaces.

         &= nbsp;      Can anybody provide more insight on = “optimal address set”, since this point is not clear in the = RFC.

 

Thanks and Regards,

Nagesh.

 

4= .1.2.  bind()

…….

If the IP =
address part of addr is specified as a wildcard =
(INADDR_ANY
   =
for an IPv4 address, or as IN6ADDR_ANY_INIT or in6addr_any for =
an
   IPv6 address), the operating system =
will associate the endpoint with
   an =
optimal address set of the available interfaces.  If the =
IPv4
   sin_port or IPv6 sin6_port is set to =
0, the operating system will
   =
choose an ephemeral port for the =
endpoint.
------=_NextPart_000_000A_01CD7A5D.4ABBA0D0-- From Michael.Tuexen@lurchi.franken.de Wed Aug 15 06:27:41 2012 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3120721F880D for ; Wed, 15 Aug 2012 06:27:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.068 X-Spam-Level: X-Spam-Status: No, score=-2.068 tagged_above=-999 required=5 tests=[AWL=0.531, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id thsQmpVr6m9Y for ; Wed, 15 Aug 2012 06:27:40 -0700 (PDT) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by ietfa.amsl.com (Postfix) with ESMTP id 656C421F87FD for ; Wed, 15 Aug 2012 06:27:40 -0700 (PDT) Received: from [192.168.1.200] (p508FBD23.dip.t-dialin.net [80.143.189.35]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 0E5601C0C0BCA; Wed, 15 Aug 2012 15:27:37 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=windows-1252 From: Michael Tuexen In-Reply-To: <000901cd7a2f$310364d0$930a2e70$@shamnur@huawei.com> Date: Wed, 15 Aug 2012 15:27:37 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <000901cd7a2f$310364d0$930a2e70$@shamnur@huawei.com> To: nagesh.shamnur@gmail.com X-Mailer: Apple Mail (2.1278) Cc: tsvwg@ietf.org, rajithr@huawei.com Subject: Re: [tsvwg] Doubt regarding the behavior of bind( ) as per RFC 6458 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Aug 2012 13:27:41 -0000 On Aug 14, 2012, at 5:12 PM, nagesh wrote: > Hi, > I have a doubt regarding what should be the behavior = of the SCTP stack for bind( ) operation as explained in the RFC 6458 = section 4.1.2 > =20 > What RFC mentions is, if the IP address part of addr = is specified as wildcard (IN6ADDR_ANY_INIT), operating system will = associate the endpoint with an optimal address set of the available = interfaces. > Can anybody provide more insight on =93optimal address = set=94, since this point is not clear in the RFC. Hi, let me give you one example, what FreeBSD does. If you bind a listening = socket an the host has private and public addresses, it will * respond to a received INIT chunk from a public address with an = INIT-ACK chunk containing only public addresses. * respond to a received INIT chunk from a private address with an = INIT-ACK chunk containing the public and private addresses. * respond to a received INIT chunk from a loopback address with an = INIT-ACK chunk containing the public, private and loopback addresses. So some sort of scoping is done. We had two IDs on this (one for IPv4 = and one for IPv6), but they are expired... Best regards Michael > =20 > Thanks and Regards, > Nagesh. > =20 > 4.1.2. bind() > =85=85. > If the IP address part of addr is specified as a wildcard (INADDR_ANY > for an IPv4 address, or as IN6ADDR_ANY_INIT or in6addr_any for an > IPv6 address), the operating system will associate the endpoint = with > an optimal address set of the available interfaces. If the IPv4 > sin_port or IPv6 sin6_port is set to 0, the operating system will > choose an ephemeral port for the endpoint. From john@jlc.net Wed Aug 15 12:07:30 2012 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C99B721E8034 for ; Wed, 15 Aug 2012 12:07:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.696 X-Spam-Level: X-Spam-Status: No, score=-105.696 tagged_above=-999 required=5 tests=[AWL=0.903, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TmEd1PtyZ-k9 for ; Wed, 15 Aug 2012 12:07:30 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id 3992221F867D for ; Wed, 15 Aug 2012 12:07:29 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id E1DCC33C22; Wed, 15 Aug 2012 15:07:28 -0400 (EDT) Date: Wed, 15 Aug 2012 15:07:28 -0400 From: John Leslie To: Gorry Fairhurst Message-ID: <20120815190728.GQ15012@verdi> References: <502B4E2D.7070700@abdn.ac.uk> <502B527E.5090700@erg.abdn.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <502B527E.5090700@erg.abdn.ac.uk> User-Agent: Mutt/1.4.1i Cc: tsvwg@ietf.org Subject: Re: [tsvwg] FYI: Document writeup for draft-ietf-tsvwg-byte-pkt-congest X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Aug 2012 19:07:30 -0000 Gorry Fairhurst wrote: > > The following document has been revised after receiving WGLC comments. The changes are mostly refreshing a document scheduled to expire this month. > No issues were found: Is that with WGC-hat-on? Neither my issues nor Philip Eardley's comments were addressed. In fact, not even the changes Bob Briscoe mentioned on-list have been included. > As required by RFC 4858, this is the current template for the Document > Shepherd Write-Up. > ... > (1) What type of RFC is being requested (BCP, Proposed Standard, > Internet Standard, Informational, Experimental, or Historic)? Why > is this the proper type of RFC? Is this type of RFC indicated in the > title page header? > > This document is intended as BCP. (This was discussed at IETF-81 and > that the status changed from Informational to BCP since it provides > guidance to implementors and people configuring routers and hosts). Thank you for finally answering my question about BCP status. >... > Working Group Summary > > There was consensus to publish this as a WG document and agreement at > IETF-82 that the document was now complete. Was that reviewed on-list? >... > (3) Briefly describe the review of this document that was performed by > the Document Shepherd. If this version of the document is not ready > for publication, please explain why the document is being forwarded to > the IESG. > > The document was presented at IEWTF-82 (Taipei), with a request for WGLC. > WGLC concluded with some discussion but no substantive changes on Friday > 30th March 2012. Yes, I guess that is true; but ignoring substantive comments isn't a good practice IMHO. > (4) Does the document Shepherd have any concerns about the depth or > breadth of the reviews that have been performed? > > No - the original draft had a lot of background material, much of this > has been condensed or removed, resulting in a smaller document. That is indeed what I basically asked for, but I don't see any evidence of it: - diff(07,08) 48 lines changed or deleted; 53 lines changed or added - diff(06,07) 8 lines changed or deleted; 13 lines changed or added - diff(05,06) 64 lines changed or deleted; 69 lines changed or added - diff(04,05) 823 lines changed or deleted; 864 lines changed or added (Need I go farther? That gets us back to March 2011...) > (9) How solid is the WG consensus behind this document? Does it > represent the strong concurrence of a few individuals, with others > being silent, or does the WG as a whole understand and agree with it? > > The document has WG support and there is consensus to publish. This, IMHO, doesn't answer the question. :^( Does it represent the concurrence of a few individuals, or does the WG as a whole understand and agree with it? For reference, my comments included: ] ] When I previously skimmed this document, I believed it contained only ] common ground: that AQM should drop/mark packets without favoring small ] packets, and that to whatever extent packet size _is_ considered, that ] should be a transport-layer responsibility. ] ] Alas, when I read it carefully this week, I find that Bob is actually ] saying that transport-layer should _only_ consider "congested bytes", not ] "congested packets". ] ] In fact, Bob openly endorses replacing TCP congestion-control with an ] algorithm which calculates "fair-share bytes" and doesn't back off at all ] (even in the presence of 20% packet loss) unless you're already sending ] more than this "fair-share". ] ] I do not believe that is the consensus of this WG; and I believe if ] that were the consensus it would exceed our charter. ] ] The draft contains a number of things I _do_ support; and I'd be happy ] to support a considerably shorter draft which concentrates on the AQM ] recommendation, omitting any suggestions of modifying TCP congestion ] control. and Philip's comments included: ] ] S2.2 I thought the numbered bullets could be better phrased, something like ] +this:- ] ] 1. AQM algorithms such as RED SHOULD use packet-mode drop, ie they SHOULD NOT ] +use byte-mode drop. The latter ] is more complex, ] it creates the perverse incentive to fragment segments into tiny ] pieces and it is vulnerable to floods of small- ] packets. ] ] 2. If a vendor has implemented byte-mode drop, and an operator has ] turned it on, it is RECOMMENDED to turn it off, after establishing if ] +there are any implications on ] the relative performance of ] applications using different packet sizes. ] ] 3. RED SHOULD NOT be turned off. Without RED, a drop tail ] queue biases against large packets. ] ] Nit - the following paragraph shouldn't be indented (Note well that RED's...) ] ] S3.3 ] The section could be slightly clearer. Starting with the second para, where you ] +start talking about something you don't recommend (ie you have to remember that ] +you're talking about the consequences of not following your recommendation). ] ] S3.3 ] o Also, if the network biases congestion notification by packet size ] it has to assume a baseline packet size--all proposed algorithms ] use the local MTU. Then transports have to guess which link was ] congested and what its local MTU was, in order to know how to ] tailor their congestion response to that link. ] So you're saying that for byte-mode drop, the network element has to compare the ] +size of the current pkt with the MTU, and if it's 25* smaller then reduce the ] +pkt loss probably by 25*? And if the MTU was bigger, then the current pkt would ] +be dropped with greater probability? And both of these things are hard to do. ] ] S3.4 (& knock-on effect on 3.3) ] I think this could be better. ] I agree with your arguments in S3.1 & 3.2 that dropping or marking should be ] +independent of pkt size. ] You now go into a couple of pages, which I think could be boiled down to a ] +paragraph, saying something like:- ] * the overall system (network + transport) has to be packet-size dependent in ] +order to drive out the right amount of traffic so the resource becomes ] +uncongested (since we assume all resources are in practice byte rather than ] +packet limited) ] * from S3.1 and S3.2 the IETF is convinced that the network should notify ] +independent of packet-size. ] * therefore the transport must act dependent on packet-size. ] ] It seems to me this is a necessary consequence of your earlier assumptions ] +/arguments. ] ] [On the other hand, if someone disagrees with the arguments and thinks that the ] +network should notify dependent on packet-size, then it follows that the ] +transport can act independent of packet-size.] ] ] I think in S3.3 you're trying to make another argument (?):- ] * we can either do packet-size biasing in the network element or on the end host ] +transport (see argument above) ] * packet-size biasing in the network is quite tricky, because then both the ] +network element & the transport have to make some guesses about MTU - whereas ] +with packet-size biasing in the transport, neither network element nor ] +transport needs to know what the MTU is. ] * it is also easier to implement packet-size biasing in the transport than in ] +the network. ] ] On the last bullet, I didn't really follow your argument in S3.5. Might be ] +easier to follow if S3.5 also talked about how a network element would take ] +account of pkt size? Also, does the following argument also apply?: ] * if pkt-size biasing is done in the transport, then the work (to do the ] +biasing) is spread over many end hosts, ] * whereas if pkt-size biasing is done in the network, then the work is ] +concentrated in just the congested network element, which has to operate on all ] +the traffic at line speed. (Has there perhaps been some confusion about what went into the -08 version?) -- John Leslie From grace.yufang@huawei.com Fri Aug 17 02:35:47 2012 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7636021F84D3; Fri, 17 Aug 2012 02:35:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6nkuGvDGR6Wv; Fri, 17 Aug 2012 02:35:45 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id E28B321F841A; Fri, 17 Aug 2012 02:35:42 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath) with ESMTP id AJM30514; Fri, 17 Aug 2012 01:35:42 -0800 (PST) Received: from DFWEML407-HUB.china.huawei.com (10.193.5.132) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 17 Aug 2012 02:33:53 -0700 Received: from SZXEML429-HUB.china.huawei.com (10.72.61.37) by dfweml407-hub.china.huawei.com (10.193.5.132) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 17 Aug 2012 02:34:00 -0700 Received: from SZXEML546-MBS.china.huawei.com ([169.254.4.6]) by SZXEML429-HUB.china.huawei.com ([10.72.61.37]) with mapi id 14.01.0323.003; Fri, 17 Aug 2012 17:33:49 +0800 From: Yufang To: Al Morton , "tsvwg@ietf.org" Thread-Topic: [tsvwg] Fwd: Re: [PMOL] Fwd: I-D Action: draft-sun-tsvwg-flowbased-pm-00.txt Thread-Index: AQHNcBNxwMkeNQvYckWgLO7p5C52x5dd0cfA Date: Fri, 17 Aug 2012 09:33:48 +0000 Message-ID: <038A8B767A209346A5C39B552E514A920F92B5B2@szxeml546-mbs.china.huawei.com> References: <201208011827.q71IRpOV024697@alpd052.aldc.att.com> In-Reply-To: <201208011827.q71IRpOV024697@alpd052.aldc.att.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.64.78] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: Peter McCann , "pmol@ietf.org" , Zhulei Subject: Re: [tsvwg] Fwd: Re: [PMOL] Fwd: I-D Action: draft-sun-tsvwg-flowbased-pm-00.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Aug 2012 09:35:47 -0000 Hi Morton and Andreas,=20 Thanks for your comments. I have read the RFCs and give comments as follow. We called the method we proposed FPM. 1. The differences between TWAMP and FPM: (1) Technically, although FPM is an active measurement protocol, there exis= t much difference between TWAMP and FPM. First, TWAMP and FPM both support = the on-the-spot measurement, it means that they can perform measurement onl= ine=20 when traffic of applications is running. But TWAMP is probe based, in TWAMP= , extra probe measurement packets are injected to simulate real traffic, to= carry out measurements and sample the performance of the network. The freq= uency=20 of injected packets has great impact on the accuracy of measurements. For e= xample, if TWAMP wants to measure an application that transmits packets fre= quently, it should also injected probe measurement packets (TWAMP-test pack= ets) frequently, then it may make negative impact on the real traffic of ap= plications, otherwise it can't reflect the actual service performance if th= e TWAMP-test packets are sparsely inserted. FPM is based on the running traffic of applications, it collects the statis= tics of real traffic flow. FPM needs additional OAM packets participate in = measurement. The OAM packets are used to carry statistics of the path/flow/= application, they can be small and the inserted frequency can be lower. (2) In addition, in some cases, it needs to monitor the various time-varyin= g performance indexes of the IP network, the performance measurement should= be based on real traffic and reflect the real performance of the network.= =20 IP Performance Monitoring based on flow/applications is needed in many case= s. For example, in mobile operator's backhaul network, there must be perfor= mance monitoring mechanism to check the traffic status in the network, and = the applications/traffic are divided into multiple bearers with proper mobi= le QoS parameters (e.g. QCI). If the mobile network would manage bearers as= QoS and applications, then the performance of backhaul is more like to be = based on applications or QoS. With the status information, some strategies = can be implemented, for example, eNB can implement online congestion contro= l and bandwidth adjustment strategy based on the performance monitoring res= ult. TWAMP may be able to do flow-based measurement by specifying DSCP for the T= WAMP-test packets. But it can't well support the online measurement and len= gth of test packets is changeless and not varying as the real traffic packe= ts. The average performance indexes measured by this method may not be suit= able in these cases. =20 (3) For further detailed analysis: 1) Measurement Control=20 TWAMP actually consists of two parts: TWAMP-Control and TWAMP-Test. TWAMP-C= ontrol is used to initiate, start, and stop test sessions, whereas TWAMP-Te= st is used to exchange test packets between two TWAMP entities. FPM also consists of two parts: connection control and measurement process.= The Connection control consists of two parts: Connection Activation and Co= nnection Deactivation. The Connection Activation is to setup measurements, = whereas the Connection Deactivation is to stop the measurements. Actually, similar to the session initiation of TWAMP, during the Connection= Activation process of FPM, it supports the negotiation of the measurement = flow, such as the negotiation of the sender and receiver addresses and port= numbers, protocol type, periods of the measurement, DSCP in some cases. Th= ese parameters are used to extract the packets of a specific flow while the= re are several types of flow between the sender and the receiver. =20 However, the TWAMP-Control also supports the per-session encryption and aut= hentication for the control and test traffic, while the connection control = of FPM doesn't do any security mechanism in its current release (more infor= mation about security will be provided later.). For FPM doesn't use a specific control plane, and there are great differenc= es between FPM and TWAMP in security mechanism, FPM seems simpler. 2) Packets used for measurement There are eight types of packets in TWAMP besides TWAMP-Test packet. The se= rver Greeting message, Set-Up- Response message and Server-Start message ar= e used for connection setup. Request-TW-Session message and Accept-Sessions= message are used for creating test sessions. Start-Sessions message and St= art-Ack message are used for starting test sessions. Stop-Sessions message = is used to stop the session.=20 The negotiation of test Modes is carried out during the connection setup pr= ocess, if the selected Mode is not the authenticated mode and/or encrypted = mode, the encryption and authentication are also implemented. That's why TW= AMP has so many types of control packets. There are six types of packets in FPM, which include four types of control = packets (ACT, ACT-ACK, DEA, DEA-ACK) and two types of measurement packets (= FM and BR). For each measurement, the TWAMP-control messages are usually only transmitt= ed once. So packets size of these messages has little impact on the network= . But TWAMP-test packets are constantly transmitted during a test session. = So the high transmitted frequency and/or large packet size may influence th= e real traffic. As mentioned in RFC5357, the padding size of the TWAMP-test packets is at l= east 27 octets in unauthenticated mode, and at least 56 octets in authentic= ated and encrypted modes. Then the size of the TWAMP-test packets is at lea= st 56 octets in unauthenticated mode, and at least 156 octets in authentica= ted and encrypted modes. However, the size of the FPM FM packets is only 20= octets, and size of BR packets is 36 octets. Note that here the packet siz= e doesn't include the size of the IP header. In addition, the transmission of FM packets are periodical with a specific = time interval, or a certain number of traffic packets should be sent betwee= n two contiguous FM packets.=20 In theory, the transmission frequency of TWAMP-test packets should be simil= ar as the normal service packets in order to reflect the network performanc= e more accurate. So the transmission frequency of TWAMP-test packets is cer= tainly larger than that of the FM packets. As both the measurement packets size and the packets transmission frequency= of TWAMP are larger than those of FPM, TWAMP may have more negative impact= on real traffic than FPM. 3) The granularity of test flow In TWAMP, all packets of a specific control connection have the same DSCP f= ield in the IP header. Then the only granularity of the test is (SIP, DIP, = sPort, dPort, DSCP). In FMP, flow can be defined by different combinations SIP, DIP, PT, DSCP, s= Port and dPort. Three types of combinations are suggested: (SIP, DIP, PT), = or (SIP, DIP, PT, DSCP) , or (SIP, DIP, PT, sPort, dPort). Network operator= s can fetch measurement with different granularities according to their spe= cific requirements. 4) Security mechanism =20 As in TWAMP, the measurement packets are independent of the real traffic, s= o when authenticated mode and encrypted mode are selected, an independent s= ecurity mechanism needs to be established for the test. But in FPM, the measurement packets are tightly coupled with the real servi= ce packets, so the security mechanism can be shared. Then there is no neces= sary to establish a specific security mechanism for the measurement packets= . 2. Statistics The metrics in the RFCs are sampled based on a Poisson process. The Poisson= process is used to schedule the measurements. In FPM, the schedule of the FM packets is the equivalent of the schedule of= the measurements. In current version, FM packets are scheduled periodicall= y. For each pair of FM/BR packets, a statistical sample can be achieved.=20 In fact, we have just give the measurement methodology here, and the descri= ption of statistics in FPM need to be further considered and to be explaine= d in detail. =20 (1) packet reordering In RFC 4737, it listed several reasons for packet reordering and has define= d a reordering metric. It also proposed the methods how to determining whet= her or not packet reordering has occurred and how to quantify the degree of= reordering.=20 The discussion of packet reordering in FPM (section 6.2) is not for reorder= ing metric. The reordering discussed here is between the real service packe= ts and the OAM measurement packets. If reordering occurs between the FM pac= ket and the specific service packet (the FM packet may arrive earlier than = the last service packet sent before it, or later than the first service pac= ket sent after it.), it will result in statistical error of packet loss. In= TWAMP, it doesn't have such a problem. However, FPM can use the method proposed in RFC 4737 without adding any mes= sage to determine whether service packet reordering has occurred and to qua= ntify the degree of reordering. (2) packet delay RFC2679 defines a metric for one-way delay of packets across Internet paths= . The methodology proposed in this RFC is that: the Src forms a test packet= , places a timestamp in the test packet, and sends it to the Dst. The Dst t= akes a timestamp as soon as possible upon the receipt of the packet. By sub= tracting the two timestamps, an estimate of one-way delay can be computed. = =20 It is assumed that the Src and Dst are synchronized, otherwise the error an= alysis of a given implementation of the method must take into account the c= loseness of synchronization between Src and Dst.=20 This methodology can also be applied to FPM. In FPM, it also achieves the t= wo timestamps, one-way delay can be calculated by this two timestamps. But as you mentioned the assumption that the forward delay is always equal = to the reverse delay is not really proper. =20 (3) PDV/IPDV/jitter Both RFC3393 and RFC5481 suggest to avoid using the term "jitter" and stick= to delay variation, for "jitter" has a much broader than packet transfer p= erformance.=20 I think we also need to revise the related parts of our draft. For the methodology proposed in RFC3393, the IP packet delay variation (ipd= v) is the difference between the one-way-delay of the selected packets. By = subtracting the first value of One-Way-Delay from the second value the ipdv= value of the pair of packets is obtained. RFC5481 presents the formulations of IPDV and PDV: IPDV(2) =3D D(2) - D(1) =3D (R2-T2) - (R1-T1) =3D (R2-R1) - (T2-T1), PDV(i= ) =3D D(i)-D(min) The single instance of an ipdv and pdv measurement is the same in FPM. So F= PM is easy to follow the methodology defined in RFC3393 and RFC5481. =20 Above all, the definition of the statistics and calculation methods propose= d in FPM need to be further considered and the description should also foll= ow the regulations of the IPPM RFCs. However, the needed parameters have be= en already obtained by the FPM, so it can fulfill the requirements without = adding any message or field.=20 Thanks again for your comments. And I'm looking forward to more comments. W= e may give careful modification for next version. Best Regards, Fang Yu > -----Original Message----- > From: Al Morton [mailto:acmorton@att.com] =20 > Sent: 2 Aug 2012 2:27 > To: tsvwg@ietf.org > Cc: pmol@ietf.org > Subject: [tsvwg] Fwd: Re: [PMOL] Fwd: I-D Action: draft-sun-tsvwg-flowbas= ed-pm-00.txt tsvwg, When I saw this draft >Zhu Lei - Flow-based Performance Measurement (10 min) >draft-sun-tsvwg-flowbased-pm on the I-D announcement list, I asked for and received a review from the Performance Metrics Directorate. I've inserted a few of my own comments below. We try to do early review when requested by WG chairs, and since this draft is now on the tsvwg agenda we are sharing our comments with the tsvwg list. Overall, I would like to suggest that the authors examine the IPPM measurement protocols more fully and implement them to see if their need for flow-based measurement can be met without developing new protocols. Al PMDir admin >From: Andreas Johnsson A >To: "pmol@ietf.org" >Date: Mon, 2 Jul 2012 11:31:22 +0200 > > >Hi, >I have tried to put together a short review. Please see my comments=20 >below (and please provide further comments). [ACM] =3D Al's additional comments. >Best regards, >Andreas Johnsson > >----- > >Comments on draft-sun-tsvwg-flowbased-pm-00.txt. > >1) The draft describes a new active measurement protocol with the=20 >aim of measuring delay, jitter and loss over an IP path. The=20 >protocol is similar to TWAMP (RFC5357), however the measurement=20 >setup is performed in a TCP-like manner instead of using a specific=20 >control plane. Despite its similarities to TWAMP there are no=20 >references nor does the draft contain a comparison. > >2) The draft includes a description on how to calculate statistics=20 >based on time stamps obtained by the protocol. The metrics are=20 >delay, jitter and loss. An advice is to use RFC 6390 section 5.4.5=20 >guidelines for describing the metrics. > >3) The draft does not prior art in IPPM (or elsewhere)=20 >related to delay, jitter or loss. Suggested documents are > >IPPM Delay (http://tools.ietf.org/html/rfc2679) >IPPM Loss (http://tools.ietf.org/html/rfc2680) >IPPM Delay variation (http://www.ietf.org/rfc/rfc3393.txt) [ACM] IPPM Packet Reordering RFC 4737 >ITU-T Y.1540 (http://www.itu.int/rec/T-REC-Y.1540-200711-S) > >4) I would like the authors to elaborate on their delay calculation=20 >method. The draft assumes that the forward delay is always equal to=20 >the reverse delay. How often is this the case? > >5) The jitter calculations are based upon the delay calculations.=20 >Since the delay is calculated as the RTT (minus the time a packet=20 >spends at the PM responder) divided by 2, the jitter will be the=20 >same in both directions. Does this really reflect what is happening=20 >on the path? Please elaborate on this. [ACM] In general, the statistics suggested here are not widely used, especially the jitter as delay variance. Suggest that the authors look at http://tools.ietf.org/html/rfc5481 and decide what measurement task and PDV method suits their needs. >-----Original Message----- >From: pmol-bounces@ietf.org [mailto:pmol-bounces@ietf.org] On Behalf=20 >Of Al Morton >Sent: den 29 juni 2012 13:58 >To: pmol@ietf.org >Subject: [PMOL] Fwd: I-D Action: draft-sun-tsvwg-flowbased-pm-00.txt > >After reading the abstract, ... > >Would anyone volunteer to review this in a timely way? > >Al >PMDir admin > > > >From: internet-drafts@ietf.org > >To: i-d-announce@ietf.org > >Subject: I-D Action: draft-sun-tsvwg-flowbased-pm-00.txt > >X-Test-IDTracker: no > >X-IETF-IDTracker: 4.21p1 > >Date: Fri, 29 Jun 2012 01:40:50 -0700 > >X-BeenThere: i-d-announce@ietf.org > >X-Mailman-Version: 2.1.12 > >Reply-To: internet-drafts@ietf.org > > > > > >A New Internet-Draft is available from the on-line Internet-Drafts > >directories. > > > > > > Title : Flow-based Performance Measurement > > Author(s) : Lishun Sun > > Wendong Wang > > Fang Yu > > Filename : draft-sun-tsvwg-flowbased-pm-00.txt > > Pages : 15 > > Date : 2012-06-29 > > > >Abstract: > > The performance measurements of service flow are becoming significan= t > > important for administrators monitoring the fitness of the network. > > This memo defines an end-to-end application-based performance > > measurement method, which is achieved by generating synthetic > > measurement packets, injecting them to the network and analyzing the > > statistics carried in the measurement packets. > > > > > >The IETF datatracker status page for this draft is: > >https://datatracker.ietf.org/doc/draft-sun-tsvwg-flowbased-pm > > > >There's also a htmlized version available at: > >http://tools.ietf.org/html/draft-sun-tsvwg-flowbased-pm-00 > > > > > >Internet-Drafts are also available by anonymous FTP at: > >ftp://ftp.ietf.org/internet-drafts/ > > > >_______________________________________________ > >I-D-Announce mailing list > >I-D-Announce@ietf.org > >https://www.ietf.org/mailman/listinfo/i-d-announce > >Internet-Draft directories: http://www.ietf.org/shadow.html or > >ftp://ftp.ietf.org/ietf/1shadow-sites.txt > >_______________________________________________ >PMOL mailing list >PMOL@ietf.org >https://www.ietf.org/mailman/listinfo/pmol >_______________________________________________ >PMOL mailing list >PMOL@ietf.org >https://www.ietf.org/mailman/listinfo/pmol