From karen.nielsen@tieto.com Fri Nov 1 05:00:46 2013 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 670FE21F9FB3 for ; Fri, 1 Nov 2013 05:00:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.229 X-Spam-Level: X-Spam-Status: No, score=0.229 tagged_above=-999 required=5 tests=[AWL=-1.407, BAYES_40=-0.185, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_35=0.6, J_CHICKENPOX_38=0.6, NO_RELAYS=-0.001] 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 Bs4l2l+d5PKb for ; Fri, 1 Nov 2013 05:00:43 -0700 (PDT) Received: from mail-wi0-x229.google.com (mail-wi0-x229.google.com [IPv6:2a00:1450:400c:c05::229]) by ietfa.amsl.com (Postfix) with ESMTP id C887921F9C4A for ; Fri, 1 Nov 2013 05:00:42 -0700 (PDT) Received: by mail-wi0-f169.google.com with SMTP id cb5so1060578wib.4 for ; Fri, 01 Nov 2013 05:00:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tieto.com; s=google; h=from:references:in-reply-to:mime-version:thread-index:date :message-id:subject:to:cc:content-type; bh=gEKNMpiAxbW8oozgDtGv4yBJIqxfouBYuPIOJYwCxSE=; b=RO0ZwEvrtX9JeEXkrav0M6nVYNjmZAFbtFnRrxMR0oOSC3na6+Dhf4abxydmAN5JIB n94zG7424h2vTxIbqMxqD9k64IOn+GwHqBoycO8hC508lN4+QZPY2ommWIUd+Dxu2se3 PGriSr0KWlsP35ScQZ3Uh3F4I9mSz4JFYZkvE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:references:in-reply-to:mime-version :thread-index:date:message-id:subject:to:cc:content-type; bh=gEKNMpiAxbW8oozgDtGv4yBJIqxfouBYuPIOJYwCxSE=; b=iiJgB3/s3jM74/FoCdfksFtCf0pqHnPY2g62R66+FxCY+lV9+koQCbdAqgJBpGS0/1 yilfevJOqoB1QqV6Kh/c9U7zi1nQXCZCWCZu2+KzlZO2WA6uwM9C9+AItBI9XWH/zPXi t2JtiBP/8h6Y5qwXixd0j8Rn1PuFyw7e7ldN+73qvJKntPBSBKBv40P/+hjSksXZrIHO GPujY1ZwqGiKP5V4QKDEzX0uzqdY/1v7EZtkfeak0TNdnSOivB9ZPaIy3VTO+6V/IyDj W/hAJQRIdziJ4DzlHu7JURqFBtHiSquT5cP76tfC48c0zPBICsj5Tigs0zROdfvVMvEP Rktw== X-Gm-Message-State: ALoCoQlympQSeqAOkkSomJ5hYWsHuL9CnWj3WuoDLnQMfmyA1VkMFX3m8pbsOP91/DdQFt/dKJ+jifbrNV9jakx7PrQEFGSvag== X-Received: by 10.194.206.5 with SMTP id lk5mr2115946wjc.46.1383307241629; Fri, 01 Nov 2013 05:00:41 -0700 (PDT) From: "Karen E. Egede Nielsen" References: <20131010032507.15919.27025.idtracker@ietfa.amsl.com> <067d205b8f1f18269c6375d7612d3638@mail.gmail.com> <52583A7D.4070108@erg.abdn.ac.uk> In-Reply-To: MIME-Version: 1.0 X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQG2f5johon8mzmdXU7Rrudd37O/dADqe0hfAgT8w+kCzevxewKoEBU+AlskmNMCTUvU6QIMFuSUmcgCPKA= Date: Fri, 1 Nov 2013 13:00:40 +0100 Message-ID: To: Yoshifumi Nishida , Randall Stewart Content-Type: text/plain; charset=ISO-8859-1 X-DomainID: tieto.com Cc: Michael Tuexen , tsvwg@ietf.org Subject: Re: [tsvwg] FW: [tcpm] I-D Action: draft-ietf-tcpm-newcwv-03.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, 01 Nov 2013 12:00:46 -0000 Hi, While I agree that the handling of ssthresh after idle time is a generic issue left underspecified in both TCP and SCTP CC, then I would like to stress that it is of significant bigger importance for long-lived (data path changing) MH SCTP than it is for short-lived non-multipath TCP. But with emerging, supposedly long-lived, multipath TCP, perhaps the issue will get more awareness also outside of the MH SCTP realm. Saying for SCTP (and then also for SCTP PF, but I do not believe that the discussion in any way is particular to PF-SCTP) that a successful HB will be allowed to increment the CWND (as if it was a successful data packet) - then strictly speaking such should follow ABC semantics - shouldn't ? (This in practice may give a full PMTU more due to how CWND limits are implemented, but there is still a difference in the formulation). The other issue then is what the impact of a lost HB should be ? If we model successful HBs as Data T3 retransmissions, the consequence would be also to have failing HBs impact CWND and ssthresh. This however makes it even more critical to have the ssthresh handling during idle be clarified. Otherwise a temporary network failure could cause ssthresh on an idle path, which observes a HB failure, to go down to IW and have data transmission on the path forever remain in Congestion Avoidance. There are equivalent problems with ssthresh in the situation where a single T3-retransmissions send on alternative path is lost today in SCTP (non CMT-SCTP). But TLP or other mechanisms may amend this situation. I suppose that we would not like such mechanisms to have to be run to qualify HB failures. If so we should either be very careful with letting CWND or ssthresh be impacted by HBs or adequately address the sshresh update issue. A nit: Speaking of ack clocks and retransmission data, then PF-SCTP clarifies PF-SCTP in saying that from a path counter availability perspective one cannot trust SACKs on data that have been sent on multiple paths to clear the IP Path counter. I note that from a CC perspective, however, then the approach is to have the data be accredited to the CWND (ABC count) on the path on which it was last sent (this I suppose also follows CuCv2 principles of CMT-SCTP). Possibly this could be clarified in PF-SCTP draft text: 8. ACKs for retransmissions do not transition a PF destination back to Active state, since a sender cannot disambiguate whether the ack was for the original transmission or the retransmission(s). BR, Karen PS: Sorry for the long wait. I have been away on a vacation that transformed itself to illness... See you in a few days, I hope. > -----Original Message----- > From: Yoshifumi Nishida [mailto:nishida@sfc.wide.ad.jp] > Sent: 15. oktober 2013 04:23 > To: Karen E. Egede Nielsen > Cc: Randall Stewart; Yoshifumi Nishida; Michael Tuexen; Salvatore Loreto > Subject: Re: FW: [tcpm] I-D Action: draft-ietf-tcpm-newcwv-03.txt > > Hi Karen, > > As you suggest, I think we'll need to think about how to set ssthresh properly > after idle time and it will be an important topic for CC. > But, I'm thinking this will be outside of SCTP as it is more generic issue. > Once we get some consensus on it, I think SCTP (and PF) should follow the > rule. > > For the second problem you mentioned, yes. it's related to PF. > The current PF draft suggests 2 MTU may be used as cwnd after the receipt > of HB-ACK. > This means we're treating HB packets just like data packets. > > In case of HB packet loss, in the current draft states cwnd should be set to 1 > or 2 MTU after successful HB-ACK in PF destination. > So, we basically don't care the number of failure or success of HBs and just > try to use conservative value as cwnd. > I guess this might be a point for discussion. If you have some comments on > the logic, please let me know. > > Thanks, > -- > Yoshifumi > > > On Mon, Oct 14, 2013 at 2:41 AM, Karen E. Egede Nielsen > wrote: > > Hi, > > > > For SCTP, and for quick failover in particular, then the ssthresh used > > when reverting to a previous failed path is of great significance. > > > > In our implementations today we leave ssthresh where it was. However > > we are looking to increase it up to infinite after RTO idle time. > > Depending on where the CWND is left. I.e., in our implementation CWND > > is decreased/respectively increased exponentially per RTO time idle > > time. Ssthresh should not be boosted to infinite as long as CWND is > > above IW. > > > > I think this is one of the issues that one should seek to clarify in SCTP. > > Possibly it could be done in connection with the PF draft (quick > > failover). > > But the issue is more generic, I agree. > > > > The other issue is the extent to which failing HBs, and conversely > > successful HBs, should influence the CWND. This is very relevant for > > the PF draft. > > > > TCP keep-alives do not impact the CWND, but then the TCP keep-alives > > carry no data and are, typically, send very infrequently. > > The standard path monitoring HBs of RFC4960 are also send > > infrequently, as far as I know, and it makes sense for them not to > > influence the CWND - likely it would have no significance anyway. > > I.e., the effect would have faded off when the path starts to be used > > for data. (Except for when such successful HBs result in switchbacks) > > > > With the more aggressive HBs of things are different - or are they > > different really ? - still the HBs are sent relatively infrequent and > > drop of a HB may very well be the result of a single packet loss (i.e. > > , not be congestion related) and anyway the HBs could not compete for > CWND. > > On the other hand the HBs look a lot like T3-retransmission of DATA. > > > > What is your feeling - ? - should failing HBs on a PF path keep the > > CWND down and conversely should a successful HB increase the CWND in > > accordance with ABC ? > > Then still after subsequent idle time, the CWND and ssthresh should be > > adjusted accordingly. > > > > Thanks, > > > > BR, Karen > > > > > > > >> -----Original Message----- > >> From: Karen E. Egede Nielsen [mailto:karen.nielsen@tieto.com] > >> Sent: 14. oktober 2013 11:10 > >> To: 'Yuchung Cheng'; 'Gorry Fairhurst' > >> Cc: 'McAlpine, Gary'; 'tcpm@ietf.org' > >> Subject: RE: [tcpm] I-D Action: draft-ietf-tcpm-newcwv-03.txt > >> > >> Hi, > >> > >> > > > >> > > I see the problem with pinning cwnd to a low ssthresh - and I'd > >> > > be happy to collaborate to write a draft on fixing this. I > >> > > offered to collaborate to write something, that's still open. It > >> > > can be a big issue for apps that are not even rate-limited in any way. > >> > > > >> > > However, it's not the same problem as CWV - although CWV would > >> > > likely benefit from this. > >> > > > >> Yes. But it may define the boundaries within which CWV applies, > >> assuming that this is kept outside of CWV. > >> Meaning that if the ssthresh value (relative to CWND) puts the > > connection in > >> CA and CWND <= IW, then after a certain idle time, RTO?, the > >> connection should really not be worse off than a new connection. > >> > >> > > Pacing is always going to help in these cases from the network > >> > > perspective, and probably would be a major performance for apps. > >> > > If I knew more about Pacing we can certainly write more in the > >> > > CWV > > draft. > >> > > > >> > > However, I don't think it's a solution on its own - I also think > >> > > that simply letting cwnd grow without check seems illogical - > >> > > especially when there are significant changes in available path > >> > > capacity. That's where I really think CWV is needed. > >> Agree. > >> > Absolutely. I completely agree that we need that part of cwv-draft. > >> > but the second half about reducing cwnd by X after idling Y always > >> > sounds shamanism. To me there are just two choices. > >> > > >> > 1) conservative: revert CC to as in initial slow start (cwnd=RW, > >> > ssthresh=inf) > >> > 2) keep cwnd as-is but pace (if available) > >> > >> Perhaps the solution shall consist of both of these with > >> qualification > > on idle > >> time on whether the resulting ssthresh and usable CWND from option 2) > >> puts the connection in a worse position than 1). > >> > > >> > the 2nd option follows the same rationale as RFC 2140 on persisting > >> > cwnd over connections. Yes it might be wrong at times, but the > >> > immediate threat is burst, not high cwnd. I am not sure about any > >> > good justification for a third option. > >> > > >> > note 1) may still burst if the app writes within an RTO. that > >> > happens all the time on video transfers when the receiver plays > >> > abuse receive-window to throttle sender. > >> > > >> Yes, and such may happen even at start of a new connection. This > >> issue > > is > >> thus not particular to the situation after idle. > >> > >> In SCTP the solution to such bursting has been to introduce a > >> max.burst parameter. I think that Randy S. also gave this comment as > >> the tcpm > > session > >> in summer. > >> > >> BR, Karen > >> > >> > > > >> > > Gorry > >> > > > >> > > > >> > > > >> > > On 11/10/2013 18:12, Yuchung Cheng wrote: > >> > >> > >> > >> On Fri, Oct 11, 2013 at 9:50 AM, McAlpine, Gary > >> > >> wrote: > >> > >>> > >> > >>> Hi, > >> > >>> > >> > >>> I agree with Karen. I have been investigating cases where a > >> > >>> single packet drop ultimately results in ssthresh getting set > >> > >>> to 2*MSS and the connection getting severely penalized by > >> > >>> immediately going into CA at the beginning of a slow-start. One > >> > >>> case occurs due to a feature intended to limit the severity of > >> > >>> a DOS attack by a malicious TCP that ignores the receiver's window > size (i.e. > >> > >>> limiting the max number of segments in a reassembly buffer). > >> > >>> Unfortunately, if the average segment size is small (as can > >> > >>> happen when data is being compressed on the fly by the sender) > >> > >>> and the RTT long enough, then a single packet drop in the > >> > >>> network can be followed by a tail drop at the receiver, > >> > >>> followed by slow-start with ssthresh = 2*MSS (we are working on > >> > >>> a solution to avoid this occurrence on perfectly valid > >> > >>> connections with valid traffic). We are also investigating a > >> > >>> different case that also results in ssthresh getting set to > >> > >>> 2*MSS after a > >> > single packet drop by the network. > >> > >>> > >> > >>> The problem is, once ssthresh gets set to a value too far below > >> > >>> the actual loss flight size, then it can take a very long time > >> > >>> to recover (and may never recover as long as that connection is > >> > >>> established). That would be a good thing on real DOS attacks, > >> > >>> but not so good on valid connections and traffic. > >> > >> > >> > >> I have definitely seen this problem (w/ cubic). Although I > >> > >> believe the root problem is loss is often not correlated with > >> > >> congestion these days (but due to burst), I second the idea to > >> > >> reset ssthresh after a long idle. For cubic the hystart will > >> > >> avoid ss overshoot so it's safer. > >> > >> > >> > >> imo newcwv is better than RFC2861 but I prefer to just keep cwnd > >> > >> as-is and enable pacing. After idle TCP will burst and that's > >> > >> the real issue. Any cwnd moderation helps to lower burst and > >> > >> reduce loss, so it might appear the magic factor, be 3/4, 1/2, > >> > >> 0.1322, is > > good. > >> > >> But it's papering the flaw of window-based ack-clocked design. > >> > >> > >> > >>> > >> > >>> I think the problem with ssthresh stems from it being set as a > >> > >>> function of CWND (which is required to be set to a small value > >> > >>> in any slow-start situation). I would suggest setting it as a > >> > >>> function of pipeACK and/or LossFlightSize, which should be > >> > >>> better indicators of a burst size that can be used without loss. > >> > >>> > >> > >>> Thanks, > >> > >>> Gary > >> > >>> > >> > >>> -----Original Message----- > >> > >>> From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On > >> > Behalf > >> > >>> Of Karen E. Egede Nielsen > >> > >>> Sent: Friday, October 11, 2013 3:01 AM > >> > >>> To: gorry@erg.abdn.ac.uk > >> > >>> Cc: tcpm@ietf.org > >> > >>> Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-newcwv-03.txt > >> > >>> > >> > >>> Hi, > >> > >>> > >> > >>> RFC5681 (section 4.1) stipulates that the TCP should start in > >> > >>> slow start with IW after an idle period of RTO. > >> > >>> The associated adjustment of ssthresh, however, has been left > >> > >>> under-specified. I.e., should the stthresh go to the standard > >> > >>> restart condition, which then would mean setting ssthresh equal > >> > >>> to infinite, or should the ssthresh be kept where it was left ? > >> > >>> > >> > >>> This question is very significant for a TCP connection where > >> > >>> the ssthresh is low due to the occurrence of a prior > >> > >>> retransmission- > >> timeout. > >> > >>> And it is even more critical if a sequence of 2 retransmission > >> > >>> time-outs have occurred as the ssthresh then would be left as > >> > >>> low as 2MTUs (RFC5681) > >> > >>> > >> > >>> Newcwv (section 4.4.2) suggests for an adjustment of ssthresh > >> > >>> as ssthresh = max(ssthresh, 3*cwnd/4) after the non-validated > phase. > >> > >>> This proposal will result in a severe disadvantage, compared > >> > >>> to a clean restart of the connection [ssthresh = infinite], > >> > >>> when resuming usage after an idle period on a TCP connection > >> > >>> following a > >> > retransmission-timeout. > >> > >>> > >> > >>> I wonder if there are any thoughts in TCMP, possibly in newcwv, > >> > >>> possibly in some other work item, on clarifying the ssthresh > >> > >>> handling when the adjustment ssthresh = max(ssthresh, > >> > >>> 3*cwnd/4), would bring the connection to start in congestion > avoidance. > >> > >>> > >> > >>> Thanks, > >> > >>> > >> > >>> BR, Karen > >> > >>> > >> > >>> > >> > >>> > >> > >>> Resume of traffic in a TCP contexts after a (or multiple) > >> > >>> retransmission-timeout perhaps is a special case for many > >> > >>> single TCP connection usecase scenarios (I don't know). At > >> > >>> least it is clear why one would like to overcome such > >> > >>> congestion avoidance phase by performing a clean restart. > >> > >>> But for SCTP multi-home (read multiple path) scenarios, and > >> > >>> possibly (?) for MPTCP scenarios as well, then temporary leave > >> > >>> and subsequent resume of paths where retransmission-timeout > >> > >>> have occurred is part of the standard failure recovery > >> > >>> operation of the > >> > protocol. > >> > >>> The above issue is thus, apart from it being general relevant > >> > >>> for TCP I suppose, very relevant for ongoing work in tsvwg on > >> > >>> CC during path failovers in SCTP (Quick Failover). > >> > >>> > >> > >>> -----Original Message----- > >> > >>> From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On > >> > Behalf > >> > >>> Of internet-drafts@ietf.org > >> > >>> Sent: 10. oktober 2013 05:25 > >> > >>> To: i-d-announce@ietf.org > >> > >>> Cc: tcpm@ietf.org > >> > >>> Subject: [tcpm] I-D Action: draft-ietf-tcpm-newcwv-03.txt > >> > >>> > >> > >>> > >> > >>> A New Internet-Draft is available from the on-line > >> > >>> Internet-Drafts directories. > >> > >>> This draft is a work item of the TCP Maintenance and Minor > >> > >>> Extensions Working Group of the IETF. > >> > >>> > >> > >>> Title : Updating TCP to support Rate-Limited > > Traffic > >> > >>> Author(s) : Godred Fairhurst > >> > >>> Arjuna Sathiaseelan > >> > >>> Raffaello Secchi > >> > >>> Filename : draft-ietf-tcpm-newcwv-03.txt > >> > >>> Pages : 19 > >> > >>> Date : 2013-10-09 > >> > >>> > >> > >>> Abstract: > >> > >>> This document proposes an update to RFC 5681 to address > >> > >>> issues > >> that > >> > >>> arise when TCP is used to support traffic that exhibits > > periods where > >> > >>> the sending rate is limited by the application rather than the > >> > >>> congestion window. It updates TCP to allow a TCP sender to > > restart > >> > >>> quickly following either an idle or rate-limited interval. > > This > >> > >>> method is expected to benefit applications that send > > rate-limited > >> > >>> traffic using TCP, while also providing an appropriate > > response if > >> > >>> congestion is experienced. > >> > >>> > >> > >>> It also evaluates the Experimental specification of TCP > > Congestion > >> > >>> Window Validation, CWV, defined in RFC 2861, and concludes > > that > >> RFC > >> > >>> 2861 sought to address important issues, but failed to > >> > >>> deliver > > a > >> > >>> widely used solution. This document therefore recommends > >> > >>> that > >> the > >> > >>> status of RFC 2861 is moved from Experimental to Historic, > >> > >>> and > > that > >> > >>> it is replaced by the current specification. > >> > >>> > >> > >>> NOTE: The standards status of this WG document is under > >> > >>> review > > for > >> > >>> consideration as either Experimental (EXP) or Proposed > > Standard > >> (PS). > >> > >>> This decision will be made later as the document is finalised. > >> > >>> > >> > >>> > >> > >>> The IETF datatracker status page for this draft is: > >> > >>> https://datatracker.ietf.org/doc/draft-ietf-tcpm-newcwv > >> > >>> > >> > >>> There's also a htmlized version available at: > >> > >>> http://tools.ietf.org/html/draft-ietf-tcpm-newcwv-03 > >> > >>> > >> > >>> A diff from the previous version is available at: > >> > >>> http://www.ietf.org/rfcdiff?url2=draft-ietf-tcpm-newcwv-03 > >> > >>> > >> > >>> > >> > >>> Please note that it may take a couple of minutes from the time > >> > >>> of submission until the htmlized version and diff are available > >> > >>> at tools.ietf.org. > >> > >>> > >> > >>> Internet-Drafts are also available by anonymous FTP at: > >> > >>> ftp://ftp.ietf.org/internet-drafts/ > >> > >>> > >> > >>> _______________________________________________ > >> > >>> tcpm mailing list > >> > >>> tcpm@ietf.org > >> > >>> https://www.ietf.org/mailman/listinfo/tcpm > >> > >>> _______________________________________________ > >> > >>> tcpm mailing list > >> > >>> tcpm@ietf.org > >> > >>> https://www.ietf.org/mailman/listinfo/tcpm > >> > >>> _______________________________________________ > >> > >>> tcpm mailing list > >> > >>> tcpm@ietf.org > >> > >>> https://www.ietf.org/mailman/listinfo/tcpm > >> > >> > >> > >> > >> > > From karen.nielsen@tieto.com Sun Nov 3 06:53:09 2013 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 2CF6811E827C for ; Sun, 3 Nov 2013 06:53:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.968 X-Spam-Level: X-Spam-Status: No, score=-0.968 tagged_above=-999 required=5 tests=[AWL=1.009, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] 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 d0zUJq8zXWaX for ; Sun, 3 Nov 2013 06:53:08 -0800 (PST) Received: from mail-wg0-x22c.google.com (mail-wg0-x22c.google.com [IPv6:2a00:1450:400c:c00::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 8470711E8115 for ; Sun, 3 Nov 2013 06:53:07 -0800 (PST) Received: by mail-wg0-f44.google.com with SMTP id n12so1189583wgh.35 for ; Sun, 03 Nov 2013 06:53:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tieto.com; s=google; h=from:mime-version:thread-index:date:message-id:subject:to:cc :content-type; bh=6aEPLI1EeNA83tgOyW7FbuntMPtqvGByIXMjQSeI8gU=; b=YAdnZz9R9eBSh3OcAQzE7Pli9MH93xxnUwV5+3osASjqO+OjNil0LvYJCwawZ5iN8G SOEIODKxp2c1gR6we4ERl88mUqKwZh725mhZVAfHScQw9YRNOMX0HUZBEfvIH1y6U8pr GrFVEIFID3/ldTvFqe/QnHvJA99AsppWFGW8Y= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:mime-version:thread-index:date:message-id :subject:to:cc:content-type; bh=6aEPLI1EeNA83tgOyW7FbuntMPtqvGByIXMjQSeI8gU=; b=VT6xVjW4+NgyS325O8e6ODJOPIRPb84mXlEyp8qGU2kzXBSso2Y7E9uNa08YQ8Ja9F r4mmOMSDg5oKEH4cxTGwM+McGMiJh/CkfzCptzalJnBDnB4w+LolgG2tfreAOGWuWuHs XvUhEMm1Y0vX/p328XpJHLGSbSFgTpDrPPbvAyDRWYwQFCiJ6KnVk98P3aYY7HGyC5LE Kj3BBZp/0BNhVPaI6P2b/dDPOcJCppjzWFgNWFSDgU8QOkEIFAAGMpvFA/N23OuP3Wz8 U+ajzTghp9/wg45ovYtdewi4WxmBOmXzqBIZqSMbc6EVPHpnNt3UPcgnKgdL5oHhnJ93 qMNg== X-Gm-Message-State: ALoCoQnNiUKCpo8eWcTI09y8RcguaZkTC6Y9sWkAXFJZPRjrZAfzNMgp/HdGD5UwBlBCJltnLguWQVFeyt80k/ubG3jMuNP6sQ== X-Received: by 10.180.11.37 with SMTP id n5mr8998514wib.25.1383490386581; Sun, 03 Nov 2013 06:53:06 -0800 (PST) From: "Karen E. Egede Nielsen" MIME-Version: 1.0 X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac7YpGmqFHaEh9cMR26qffqvtmaVEQ== Date: Sun, 3 Nov 2013 15:53:12 +0100 Message-ID: <12232007a37c6ddda25a0e0015075530@mail.gmail.com> To: Michael Tuexen , Randall Stewart Content-Type: multipart/alternative; boundary=001a11c25b480afa9304ea46f5bb X-DomainID: tieto.com Cc: tsvwg@ietf.org Subject: [tsvwg] draft-ietf-tsvwg-natsupp-06.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: Sun, 03 Nov 2013 14:53:09 -0000 --001a11c25b480afa9304ea46f5bb Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable HI, I have finally managed to review the SCTP Nat traversal draft, draft-ietf-tsvwg-natsupp-06.txt. For what they are worth, please accept the following comments. General: Description of SCTP NAT traversal is spread over two drafts, draft-ietf-tsvwg-natsupp-06.txt and draft-ietf-behave-sctpnat-09.txt. I believe that some of the more detailed information contained in the second draft, draft-ietf-behave-sctpnat-09.txt, needs to be replicated in draft-ietf-tsvwg-natsupp-06.txt. Especially draft-ietf-behave-sctpnat-09.tx= t is more precise when defining the messages exchange sequences and the message content on the legs of SCTP host <- > NAT <-> Internet (<-> NAT) <-> SCTP host. This informaiton is lacking from draft-ietf-tsvwg-natsupp-06.txt, even if it is absolutely crucial in order to verify and fully understand the SCTP endpoint protocol operations. I may be mistaken, but to me it looks from the message sequence diagrams of draft-ietf-behave-sctpnat-09.txt as if the SCTP NAT traversal mechanism rely on that an ASCONF message is accepted by peer, even if neither the source address of the packet nor an address in the address parameter of the ASCONF serve to identify the association. I.e., neither is yet part of the association. This is in conflict with Section 5.2 of RFC5061. I understand that the new vtag parameter may give some extra information to check with and I suppose that one may possibly wave this check of RFC5061, but I believe that it changes the security situation substantially. Details: Section 1, first paragraph: One might clarify that by pure NAT then not only, only one SCTP capable host may reside behind a NAT, but also only SH SCTP can be supported. Section 1, table 1: Unless I am mistaken (see below section 5.6 #2) then unless present proposal is extended, then full felexible MH support is not achieved by the proosed solution. Meaning that by ASCONF only one mapping entry for the peer end-point, i.e., only one peer end-point address, is created in the the NAT which fronts the secondary public address. Here I forsee that we may get into discussions as to whether SCTP MH associations are intended to deploy only one path or mulitple paths per peer address. Still the specification here puts more limitations on the paths available for the association than RFC4960, indeed some paths are explicitly excluded, and I believe that this needs to be explicitly noted somewhere in the draft. Section 5.3, 3rd paragraph, typo: In a packet containing an INIT-ACK chunk =E0 If a packet containing an INIT-ACK chunk Section 5.4: paragraph after first bullet list: When associatons are distinguished by vtags only, the semantics of OoTB packets are changed. Shall ABORTS be returned for packets that do not match from a vtag perspective, but otherwise matches an associaton ? In RFC4960 ABORTS are not returned for such packets as the packets are considered stale. Such ABORT are NICE only =96 so perhaps one will have them not be generated= ? Having said that then it is not clear to me how the NATs will handle ABORTs from external side with reflected vtag. Section 5.5: Third bullet: It refers to that the procedures for generating an ASCONF chunk can be found in RFC5061. I believe that information given in draft-ietf-behave-sctpnat-09.txt on the address to place in the ASCONF chunk and add IP and deleted IP handling need be added here. Section 5.5: Second paragraph after bullet list: It says that the peer endpoint should follow the procedures of RFC5061 when processing the ASCONF. But if the ASCONF have the format indicated in draft-ietf-behave-sctpnat-09.txt, then both the source address and the address in the ASCONF may be new to peer. Section 5.6: #1: The format of the ASCONF chunk to use when adding addresses should be detailed. #2: It seems that by the ASCONF mechanism then one entry per additional public address is added in the NAT which fronts the respective public address. Towards a MH peer endpoint it seems that one then miss the =93full mess=94 mapping entries. The =93full mess=94 entries, according to draft-ietf-behave-sctpnat-09.txt, are created for the publicc address used for INIT. This assymetri represents a limitation compared to RFC4960. A solution to the problem could be to have the ASCONF ACK be entended to include information on full set of peer addresses. The same limitation seem to be the case when a NAT looses its state, but in this situation the limitation is perhaps more acceptable. Section 8: Comments here pend resolution (or understanding) of how to process ASCONF chunks when all addresses are new to the receiver. BR, Karen --001a11c25b480afa9304ea46f5bb Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

HI,

= =A0

I have finally managed t= o review the SCTP Nat traversal draft, draft-ietf-tsvwg-natsupp-06.txt.

For what they are worth, please= accept the following comments.

=A0

Genera= l:

=A0

Description of SCTP NAT traversal is spread over= two drafts, draft-ietf-tsvwg-natsupp-06.txt and draft-ietf-behave-sctpnat-09.txt.

I believe that some of the more= detailed information contained in the second draft, draft-ietf-behave-sctpnat-09.txt, needs to be replicated in

draft-ietf-tsvwg-natsupp-06.txt= . Especially draft-ietf-behave-sctpnat-09.txt i= s more precise when defining the messages exchange sequences

and the message content on the legs of SCTP host <-= > NAT <-> Internet (<-> NAT) <-> SCTP host. This info= rmaiton is lacking from draft-ietf-tsvwg-natsup= p-06.txt,

even if it is absolutely crucia= l in order to verify and fully understand the SCTP endpoint protocol operat= ions.

=A0

<= p class=3D"MsoNormal"> I may be mistaken, but to me it looks from the message= sequence diagrams of draft-ietf-behave-sctpnat= -09.txt

=

as if the SCTP NAT traversal mechanism rely on that an= ASCONF message is accepted by peer,

even if neither the source address of the packet nor an add= ress in the address parameter of the ASCONF serve to identify the associati= on.

I.e., neither is yet part of th= e association. This is in conflict with Section 5.2 of RFC5061.

=

I understand that the new vtag = parameter may give some extra information to check with and

I suppose that one may possibly= wave this check of RFC5061, but I believe that it changes the security sit= uation substantially.

=A0

=A0

Details:

=A0

Section 1, first paragraph: One might clarify that by pure NAT then not = only, only one SCTP capable host may reside behind a NAT, but

also only SH SCTP can be s= upported.

=A0

=A0

Section 1, table 1:

Unless I am mistaken (see below section 5.6 #2) then u= nless present proposal is extended, then full felexible MH support is not a= chieved by the proosed solution.

Meaning that by ASCONF only one mapping entry for the = peer end-point, i.e., only one peer end-point address, is created in the th= e NAT which fronts

the secondary public address. Here I forsee that we ma= y get into discussions as to whether SCTP MH associations are intended to d= eploy only

= one path or mulitple paths per peer address. Still the= specification here puts more limitations on the paths available for the as= sociation than

R= FC4960, indeed some paths are explicitly excluded, and I believe that this = needs to be explicitly noted somewhere in the draft.

=A0

Section 5.3, 3rd paragraph, ty= po:

In a packet containing an INIT-ACK chunk =E0 If a packet co= ntaining an INIT-ACK chunk

= =A0

Section 5.4: paragraph after first bullet list:

When associatons are distinguished by vtags only, the = semantics of OoTB=A0 packets are changed. Shall ABORTS be returned for pack= ets that do not match from a vtag perspective,

but otherwise matches an associaton ? In RFC4960 ABORT= S are not returned for such packets as the packets are considered stale.

Such ABORT are NICE only =96 so perhaps one will have them not be g= enerated ?

H= aving said that then it is not clear to me how the NATs will handle ABORTs = from external side with reflected vtag.

=A0

Section 5.5: Third bullet:

It re= fers to that the procedures for generating an ASCONF chunk can be found in = RFC5061. I believe that information given in draft-ietf-behave-sctpnat-09.t= xt on

t= he address to place in the ASCONF chunk and add IP and deleted IP handling = need be added here.

=A0

Section 5.5: Second paragraph after bulle= t list:

It says that the peer endpoint should follow the procedure= s of RFC5061 when processing the ASCONF. But if the ASCONF have the format = indicated in draft-ietf-behave-sctpnat-09.txt,

t= hen both the source address and the address in the ASCONF may be new to pee= r. =A0

=A0

S= ection 5.6:

= #1:

The format of the ASCONF chunk to use when adding addr= esses should be detailed.

=A0

#2:

It seems that by the ASCONF mechanism the= n one entry per additional public address is added in the NAT which fronts = the respective public address.

T= owards a MH peer endpoint it seems that one then miss the =93full mess=94 m= apping entries. The =93full mess=94 entries, according to draft-ietf-behave= -sctpnat-09.txt,

a= re created for the publicc address used for INIT. This assymetri represents= a limitation compared to RFC4960.

A solution to the problem could be to have the ASCONF = ACK be entended to include information on full set of peer addresses.

The same limitation seem = to be the case when a NAT looses its state, but in this situation the limit= ation is perhaps more acceptable.

=A0

Section 8:

=A0

Comments here pend resolution (or understanding) of how to process ASCONF = chunks when all addresses are new to the receiver.

=A0

=A0BR, Karen

=A0

=A0

--001a11c25b480afa9304ea46f5bb-- From karen.nielsen@tieto.com Mon Nov 4 08:14:56 2013 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 0CF6E11E8235 for ; Mon, 4 Nov 2013 08:14:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.136 X-Spam-Level: X-Spam-Status: No, score=-1.136 tagged_above=-999 required=5 tests=[AWL=0.841, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] 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 xxrMW8wCj8Ry for ; Mon, 4 Nov 2013 08:14:55 -0800 (PST) Received: from mail-wi0-x229.google.com (mail-wi0-x229.google.com [IPv6:2a00:1450:400c:c05::229]) by ietfa.amsl.com (Postfix) with ESMTP id 9423811E82AE for ; Mon, 4 Nov 2013 08:14:54 -0800 (PST) Received: by mail-wi0-f169.google.com with SMTP id cb5so2122574wib.2 for ; Mon, 04 Nov 2013 08:14:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tieto.com; s=google; h=from:mime-version:thread-index:date:message-id:subject:to :content-type; bh=2lxhGcfVpz9tSqkHkUgDBgckeq1k+PkRMcXSR+ALU3U=; b=YnNd1T/SXjPukOzGw9RhvF3N+P55kGEq2L1m/W6UHWmIQD2zNkAM1rXoj69Etk2l8v ePmrh22UyTCVYxaWeZYpzi13htLNRPRKwcF/b6WODgUIjo2GABkI2u1l3qRGyuzLtLkU uTVzXGk/S4tN8oR8TLvYETO+7EBwRwd5RsRAA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:mime-version:thread-index:date:message-id :subject:to:content-type; bh=2lxhGcfVpz9tSqkHkUgDBgckeq1k+PkRMcXSR+ALU3U=; b=HYXTJr3jrZaS8wfhih4z3tenayu+2QWKOfyDq277MObZxoJrFlYYdcXFREkyaRfZnD 4CjJp4ni1Pl3cEv7Jg5AOWEpfiOnH8yTULLwWTxITJLBNNNfawuWQwtMZQtEKKtxEfJJ HGN94viPo2/h44b7jJa0Qu3KioGO6iG1uqcsVOeSJAuTEFqc+CyiP+TiBqbCj+FZz8kM dYIdhbrQjiKP/PKi/BNH0Rl5qaCVVavXCrKU4vMubZld8VjmrsG80idPemY4CAei4kQ2 wWWr0Sqv9q8s6fnZX7TbAo615O2a9ByqXYbIlfZfqBlIan/Za/vpFuE5i9rHTFfhBrsQ sGIQ== X-Gm-Message-State: ALoCoQkVrm5zOYKX2hgNjLLac+EbG5LCDCYf9M7EakP4WQyKHDmr35t9bH5vbVJ7TMU7bhegGhJxJxf0jxFSvH9WtUahuILzyQ== X-Received: by 10.194.187.132 with SMTP id fs4mr57928wjc.82.1383581693673; Mon, 04 Nov 2013 08:14:53 -0800 (PST) From: "Karen E. Egede Nielsen" MIME-Version: 1.0 X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac7ZeQD8dHpMkvIvTLWbzNvFCYMV6Q== Date: Mon, 4 Nov 2013 08:15:01 -0800 Message-ID: <29574887aaaa06bc270d9e779cfb760a@mail.gmail.com> To: tsvwg@ietf.org, Yoshifumi Nishida Content-Type: multipart/alternative; boundary=047d7bb04ba85e9ec404ea5c3720 X-DomainID: tieto.com Subject: [tsvwg] Proposal for socket api extension for PFAILED notification 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, 04 Nov 2013 16:14:56 -0000 --047d7bb04ba85e9ec404ea5c3720 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi, For an RFC4960 SCTP implementation UNREACHABLE event notification on the (current) Primary Path serves to tell UL of leave of the (current) Primary Path. With introduction of the Potentially Failed state in the quick failover function of SCTP, no such event may be generated. It is true that there is a =93made primary=94 event, which indirectly tell = of change of primary path, but some SCTP implementation defer the generation of this event until a new proven working primary path has been located (or set). To cater for event notification of the PFAILED state, the following optional extension to the socket api is proposed: New SCTP event type is defined. I.e., new se_type of RFC6458. Proposed name: SCTP_PEER_ADDR_CHANGE_EXT_PF. New spc_state is defined. Proposed name SCTP_ADDR_PFAILED: The address specified is Potentially Failed. When the SCTP_PEER_ADDR_CHANGE_EXT_PF event is subscribed to by UL, UL will by means of the existing sctp_paddr_change notification structure rec= eive notification of the following state transitions of a destination address: ACTIVE =E0 PFAILED : spc_state=3D SCTP_ADDR_PFAILED PFAILED =E0 ACTIVE: spc_state =3D SCTP_ADDR_AVAILABLE The proposal is backward compatible and it allows ULs who want to ignore the PFAILED events to not receive them. ULs which do not want to receive the above listed state transitions will subscribe only to existing SCTP_PEER_ADDR_CHANGE event. An alternative approach (less preferred from my perspective) is to implement the event notification as non-optional. Meaning that once the PFAILED function is enabled then the above described events will be generated as soon as UL subscribe to existing SCTP_PEER_ADDR_CHANGE event. BR, Karen --047d7bb04ba85e9ec404ea5c3720 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

Hi,

= =A0

For an RFC4960 SCTP impl= ementation UNREACHABLE event notification on the (current) Primary Path ser= ves to tell UL of leave of the (current)

Primary Path. With introduction= of the Potentially Failed state in the quick failover function of SCTP, no= such event may be generated.

=A0

It is true that there is a =93m= ade primary=94 event, which indirectly tell of change of primary path, but = some SCTP implementation defer the generation of this event

until a new proven working primary path has been locat= ed (or set).

=A0

To cater for event notif= ication of the PFAILED state, the following optional extension to the socke= t api is proposed:

=A0

New SCTP event type is defined. I.e., new se_typ= e of RFC6458.

= Proposed name: SCTP_PEER_ADDR_CHANGE_EXT_PF.

=A0

New spc_st= ate is defined. Proposed name SCTP_ADDR_PFA= ILED: The address specified is Potentially= Failed.

When the S= CTP_PEER_ADDR_CHANGE_EXT_PF event is subscribed to by UL, UL

will by means of the exist= ing =A0sctp_paddr_change notification structure receive notification of the

following state transition= s of a destination address:

ACTIVE =E0 PFAILED : spc_st= ate=3D SCTP_ADDR_PFAILED

PFAILED =E0 ACTIVE: spc_state =3D SCTP_ADDR_AVAILABLE

=A0

The proposal is backward compatible and it allows ULs who want to ignore= the PFAILED events to not

receive them. ULs which do= not want to receive the above listed state transitions will subscribe only= to existing SCTP_PEER_ADDR_CHANGE event.

=A0

An alternative approach (less preferre= d from my perspective) is to implement the event notification as non-option= al.

Meaning that once the PFAI= LED function is enabled then the above described events will be generated a= s soon as UL subscribe to

existing SCTP_PEER_ADDR_CH= ANGE event.

=A0

BR, Karen

=A0

=A0

=A0

=A0

--047d7bb04ba85e9ec404ea5c3720-- From Michael.Tuexen@lurchi.franken.de Mon Nov 4 10:50:54 2013 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 4DBB321E805F for ; Mon, 4 Nov 2013 10:50:54 -0800 (PST) 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 IsNBIS+QpNMI for ; Mon, 4 Nov 2013 10:50:53 -0800 (PST) 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 BF2C311E8117 for ; Mon, 4 Nov 2013 10:50:35 -0800 (PST) Received: from dhcp-a465.meeting.ietf.org (dhcp-a465.meeting.ietf.org [31.133.164.101]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id E8F841C0C0693; Mon, 4 Nov 2013 19:50:11 +0100 (CET) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Michael Tuexen In-Reply-To: <29574887aaaa06bc270d9e779cfb760a@mail.gmail.com> Date: Mon, 4 Nov 2013 10:50:08 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <94726BF8-7806-4EF5-999D-3F4491195889@lurchi.franken.de> References: <29574887aaaa06bc270d9e779cfb760a@mail.gmail.com> To: Karen E. Egede Nielsen X-Mailer: Apple Mail (2.1510) Cc: tsvwg@ietf.org Subject: Re: [tsvwg] Proposal for socket api extension for PFAILED notification 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, 04 Nov 2013 18:50:54 -0000 On Nov 4, 2013, at 8:15 AM, Karen E. Egede Nielsen = wrote: > Hi, > =20 > For an RFC4960 SCTP implementation UNREACHABLE event notification on = the (current) Primary Path serves to tell UL of leave of the (current) > Primary Path. With introduction of the Potentially Failed state in the = quick failover function of SCTP, no such event may be generated. > =20 > It is true that there is a =93made primary=94 event, which indirectly = tell of change of primary path, but some SCTP implementation defer the = generation of this event > until a new proven working primary path has been located (or set). I think the semantic of the event is that it is sent, when a new primary = path is set by the kernel. This can happen, because: * The peer requests this by using ASCONF. * The kernel decides that it has to change the primary path. > =20 > To cater for event notification of the PFAILED state, the following = optional extension to the socket api is proposed: > =20 > New SCTP event type is defined. I.e., new se_type of RFC6458. > Proposed name: SCTP_PEER_ADDR_CHANGE_EXT_PF. > =20 > New spc_state is defined. Proposed name SCTP_ADDR_PFAILED: The address = specified is Potentially Failed. Hmm. What about SCTP_ADDR_POTENTIALLY_FAILED or SCTP_ADDR_POT_FAILED. >=20 > When the SCTP_PEER_ADDR_CHANGE_EXT_PF event is subscribed to by UL, UL > will by means of the existing sctp_paddr_change notification = structure receive notification of the > following state transitions of a destination address: > ACTIVE =E0 PFAILED : spc_state=3D SCTP_ADDR_PFAILED > PFAILED =E0 ACTIVE: spc_state =3D SCTP_ADDR_AVAILABLE > =20 > The proposal is backward compatible and it allows ULs who want to = ignore the PFAILED events to not > receive them. ULs which do not want to receive the above listed state = transitions will subscribe only to existing SCTP_PEER_ADDR_CHANGE event. > =20 > An alternative approach (less preferred from my perspective) is to = implement the event notification as non-optional. > Meaning that once the PFAILED function is enabled then the above = described events will be generated as soon as UL subscribe to > existing SCTP_PEER_ADDR_CHANGE event. Adding a new event type just for adding a new path state seems to be = pretty invasive. I could live with it, but I would prefer just to extend SCTP_PEER_ADDR_CHANGE. Just my thought... Best regards Michael > =20 > BR, Karen > =20 > =20 > =20 > =20 From internet-drafts@ietf.org Mon Nov 4 12:25:03 2013 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 B7EF821E80FB; Mon, 4 Nov 2013 12:25:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.569 X-Spam-Level: X-Spam-Status: No, score=-102.569 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599, NO_RELAYS=-0.001, 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 2SpQP7uN3Nhd; Mon, 4 Nov 2013 12:25:03 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D039D21E80DD; Mon, 4 Nov 2013 12:24:58 -0800 (PST) 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.82 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131104202458.10115.50589.idtracker@ietfa.amsl.com> Date: Mon, 04 Nov 2013 12:24:58 -0800 Cc: tsvwg@ietf.org Subject: [tsvwg] I-D Action: draft-ietf-tsvwg-port-use-03.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Nov 2013 20:25:04 -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 : Recommendations for Transport Port Uses Author(s) : Joe Touch Filename : draft-ietf-tsvwg-port-use-03.txt Pages : 18 Date : 2013-11-04 Abstract: This document provides recommendations to application and service designers on how to use the transport protocol port number space to help in its preservation. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tsvwg-port-use There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-tsvwg-port-use-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tsvwg-port-use-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From touch@isi.edu Mon Nov 4 12:31:14 2013 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 D717F11E81BA for ; Mon, 4 Nov 2013 12:31:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.414 X-Spam-Level: X-Spam-Status: No, score=-103.414 tagged_above=-999 required=5 tests=[AWL=-0.815, 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 sIjinspBSKEX for ; Mon, 4 Nov 2013 12:31:06 -0800 (PST) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id 5C69611E8156 for ; Mon, 4 Nov 2013 12:31:05 -0800 (PST) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id rA4KUl0H008981 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 4 Nov 2013 12:30:47 -0800 (PST) Message-ID: <52780466.7020909@isi.edu> Date: Mon, 04 Nov 2013 12:32:38 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: tsvwg References: <20131104202459.10115.30846.idtracker@ietfa.amsl.com> In-Reply-To: <20131104202459.10115.30846.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20131104202459.10115.30846.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Subject: [tsvwg] Fwd: New Version Notification for draft-ietf-tsvwg-port-use-03.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, 04 Nov 2013 20:31:17 -0000 Hi, all, A new version has just been posted, as will be (has been?) presented by Gorry. A summary of the changes since -02: Sec 5 – “What is a Port” . Added discussion of how midbox devices examine ports Sec 7 – “How to Use Assigned Ports” . Added ref to RFC 6335 - IANA Port Assignment Sec 7.1 – “Do you need a port?” . Added another test: Is the service independently useful? (based on Port Experts Team experience) . Clarified security issue for new assignments . Added a test about versioning (based on Port Experts Team experience) Sec 7.6 – “Transport Protocols” . Clarified that broadcast is relevant for only IPv4 Joe -------- Original Message -------- Subject: New Version Notification for draft-ietf-tsvwg-port-use-03.txt Date: Mon, 04 Nov 2013 12:24:59 -0800 From: internet-drafts@ietf.org To: Dr. Joseph D. Touch , Joe Touch A new version of I-D, draft-ietf-tsvwg-port-use-03.txt has been successfully submitted by Joe Touch and posted to the IETF repository. Filename: draft-ietf-tsvwg-port-use Revision: 03 Title: Recommendations for Transport Port Uses Creation date: 2013-11-04 Group: tsvwg Number of pages: 18 URL: http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-port-use-03.txt Status: http://datatracker.ietf.org/doc/draft-ietf-tsvwg-port-use Htmlized: http://tools.ietf.org/html/draft-ietf-tsvwg-port-use-03 Diff: http://www.ietf.org/rfcdiff?url2=draft-ietf-tsvwg-port-use-03 Abstract: This document provides recommendations to application and service designers on how to use the transport protocol port number space to help in its preservation. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat From bob.briscoe@bt.com Mon Nov 4 14:04:20 2013 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 B258721E8102; Mon, 4 Nov 2013 14:04:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.402 X-Spam-Level: X-Spam-Status: No, score=-3.402 tagged_above=-999 required=5 tests=[AWL=0.197, BAYES_00=-2.599, 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 NievnbU1iCCr; Mon, 4 Nov 2013 14:04:15 -0800 (PST) Received: from hubrelay-by-04.bt.com (hubrelay-by-04.bt.com [62.7.242.140]) by ietfa.amsl.com (Postfix) with ESMTP id 4349821E80DB; Mon, 4 Nov 2013 14:03:54 -0800 (PST) Received: from EVMHR72-UKRD.domain1.systemhost.net (10.36.3.110) by EVMHR04-UKBR.bt.com (10.216.161.36) with Microsoft SMTP Server (TLS) id 8.3.297.1; Mon, 4 Nov 2013 22:03:48 +0000 Received: from EPHR01-UKIP.domain1.systemhost.net (147.149.196.177) by EVMHR72-UKRD.domain1.systemhost.net (10.36.3.110) with Microsoft SMTP Server (TLS) id 8.3.279.1; Mon, 4 Nov 2013 22:03:50 +0000 Received: from bagheera.jungle.bt.co.uk (132.146.168.158) by EPHR01-UKIP.domain1.systemhost.net (147.149.196.177) with Microsoft SMTP Server id 14.2.347.0; Mon, 4 Nov 2013 22:03:50 +0000 Received: from BTP075694.jungle.bt.co.uk ([10.109.157.6]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id rA4M3lo0026458; Mon, 4 Nov 2013 22:03:48 GMT Message-ID: <201311042203.rA4M3lo0026458@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 4 Nov 2013 22:03:45 +0000 To: tsvwg IETF list , AQM IETF list From: Bob Briscoe MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 Cc: draft-briscoe-tsvwg-ecn-encap-guidelines@tools.ietf.org Subject: [tsvwg] Who supports tsvwg adoption of adding ECN to L2 or tunnel protocols? 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, 04 Nov 2013 22:04:20 -0000 Folks, Pls respond if you support this being adopted as a work-group item in the IETF transport services w-g (tsvwg). The WG chairs need visibility of interest. Even better, if you're willing to read / comment / review / implement Guidelines for Adding Congestion Notification to Protocols that Encapsulate IP Abstract The purpose of this document is to guide the design of congestion notification in any lower layer or tunnelling protocol that encapsulates IP. The aim is for explicit congestion signals to propagate consistently from lower layer protocols into IP. Then the IP internetwork layer can act as a portability layer to carry congestion notification from non-IP-aware congested nodes up to the transport layer (L4). Following these guidelines should assure interworking between new lower layer congestion notification mechanisms, whether specified by the IETF or other standards bodies. [Cross-posting tsvwg & aqm, just in case] Bob Briscoe, also for co-authors Pat Thaler and John Kaippallimalil ________________________________________________________________ Bob Briscoe, BT From karen.nielsen@tieto.com Mon Nov 4 14:21:10 2013 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 2E44821E80AF for ; Mon, 4 Nov 2013 14:21:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.257 X-Spam-Level: X-Spam-Status: No, score=-1.257 tagged_above=-999 required=5 tests=[AWL=0.721, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] 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 JcAyEhH71LSW for ; Mon, 4 Nov 2013 14:21:09 -0800 (PST) Received: from mail-we0-x235.google.com (mail-we0-x235.google.com [IPv6:2a00:1450:400c:c03::235]) by ietfa.amsl.com (Postfix) with ESMTP id 503BE11E8172 for ; Mon, 4 Nov 2013 14:21:07 -0800 (PST) Received: by mail-we0-f181.google.com with SMTP id t60so2752770wes.12 for ; Mon, 04 Nov 2013 14:21:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tieto.com; s=google; h=from:references:in-reply-to:mime-version:thread-index:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=VT+1hDYqGJxnIMqIH6fiCNWvqVYR2XjO4r2v/hyVOhQ=; b=1YQ3Ka/IfQQIcdSOun0LilgKy5M0FwmLVZQQ+Vjb+uETeZfZEKkLgGCT7xGIAPQKGG GnLd4GHNE/vWesu9/3lXx1Pyyc42FQMSkOqZAhYuCkXH+0dPsWSYyhqQiDu4ZKhkVQAb AHIRkW67mSFjz7YefAvjn6+nnapsM/I5tWzFM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:references:in-reply-to:mime-version :thread-index:date:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=VT+1hDYqGJxnIMqIH6fiCNWvqVYR2XjO4r2v/hyVOhQ=; b=Z7Kun0DaXJFunFjlufo9UW0bUx6nna9vDkoHYd6Clcy+8iZ2sMz6K3dB/OLhLlLyHh +VwYAMleaI8XXH26y8Qj9M1vi8aUr6+vMAA1IDsXyq/3gf41Olgb9oddgbdbO4prOR6B vRhai7TIjRHLyHiePFUufJ6LuDM3fQvTS8+yaD9CXWaWjTsJb6uNXcqtEWZPzXObM7aw DXdXhUHCLrfBRIu4nCiF6xy9kVTs2g9WvxLLDbzinM21W0SQThPy7vNzkXZm0MVpNuCq D8jSlHzSpkWkMqDFjy3uaH5sntL0Vvef4egfYtiuBnNnfcfAxB2Ptt2Nrb9gGDG594TQ wWHQ== X-Gm-Message-State: ALoCoQl8AibRvGKekLYJpt3uXAe7xVnBudvEVqa6UJCBjU7QjzY36x3TboYIh0TrzR4/CVdFQlb/+AXmLzDwePLwbRaUjluHeg== X-Received: by 10.194.187.132 with SMTP id fs4mr3902wjc.82.1383603666422; Mon, 04 Nov 2013 14:21:06 -0800 (PST) From: "Karen E. Egede Nielsen" References: <29574887aaaa06bc270d9e779cfb760a@mail.gmail.com> <94726BF8-7806-4EF5-999D-3F4491195889@lurchi.franken.de> In-Reply-To: <94726BF8-7806-4EF5-999D-3F4491195889@lurchi.franken.de> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKFR+PEhkbL+p7N+vb+Qico/zXj2wE/rm3+mJ6+vPA= Date: Mon, 4 Nov 2013 13:55:15 -0800 Message-ID: <5ae2e62e90fc9401a06cb34c2f701240@mail.gmail.com> To: Michael Tuexen Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-DomainID: tieto.com Cc: tsvwg@ietf.org Subject: Re: [tsvwg] Proposal for socket api extension for PFAILED notification 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, 04 Nov 2013 22:21:10 -0000 Hi Michael, Thanks a lot for your feedback :-) > I think the semantic of the event is that it is sent, when a new primary path is > set by the kernel. This can happen, because: > * The peer requests this by using ASCONF. > * The kernel decides that it has to change the primary path. > > [Karen] In a standard RFC4960 switchback scenario SCTP, e.g. FreeBSD SCTP, would not generate this event for an alternative path in case SCTP temporarily was using this alternative path for data transfer as the Primary Path has entered Potentially Failed state - Correct ? > > To cater for event notification of the PFAILED state, the following optional > extension to the socket api is proposed: > > > > New SCTP event type is defined. I.e., new se_type of RFC6458. > > Proposed name: SCTP_PEER_ADDR_CHANGE_EXT_PF. > > > > New spc_state is defined. Proposed name SCTP_ADDR_PFAILED: The > address specified is Potentially Failed. > Hmm. What about SCTP_ADDR_POTENTIALLY_FAILED or > SCTP_ADDR_POT_FAILED. [Karen] I am very fine with both. I tend to like the first a little better than the second. > > > > When the SCTP_PEER_ADDR_CHANGE_EXT_PF event is subscribed to by > UL, UL > > will by means of the existing sctp_paddr_change notification > > structure receive notification of the following state transitions of a > destination address: > > ACTIVE =E0 PFAILED : spc_state=3D SCTP_ADDR_PFAILED PFAILED =E0 ACTIVE: > > spc_state =3D SCTP_ADDR_AVAILABLE > > > > The proposal is backward compatible and it allows ULs who want to > > ignore the PFAILED events to not receive them. ULs which do not want to > receive the above listed state transitions will subscribe only to existing > SCTP_PEER_ADDR_CHANGE event. > > > > An alternative approach (less preferred from my perspective) is to > implement the event notification as non-optional. > > Meaning that once the PFAILED function is enabled then the above > > described events will be generated as soon as UL subscribe to existing > SCTP_PEER_ADDR_CHANGE event. > Adding a new event type just for adding a new path state seems to be pretty > invasive. I could live with it, but I would prefer just to extend > SCTP_PEER_ADDR_CHANGE. > [Karen] I have a preference for the optional solution both from a backward compatible as well as from a functional perspective, but I will be reasonable content also with the non-optional solution. > Just my thought... > > Best regards > Michael > > > > BR, Karen > > > > > > > > From fred@cisco.com Mon Nov 4 14:39:17 2013 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 AFAF521E80E1; Mon, 4 Nov 2013 14:39:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.419 X-Spam-Level: X-Spam-Status: No, score=-110.419 tagged_above=-999 required=5 tests=[AWL=-0.047, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, SARE_SUB_OBFU_Q1=0.227, 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 NiN8pGH+rODs; Mon, 4 Nov 2013 14:39:11 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id DA25821E809F; Mon, 4 Nov 2013 14:39:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2874; q=dns/txt; s=iport; t=1383604751; x=1384814351; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=yR0YuyUT4sViaubdlhZfpFBlglGNt8cLShXpsuI9QUQ=; b=kntTcXNCapxBafXiCWLkp01QzyWlgNnl7qfnBSNicsYj+phl6NE+k/ng x6mZDnbiy9de8UPp7i8zhFUI0wnAcPomu6e898D/n+C6tLM50DpgvidZl qgb6txBGJSj9kfYu5IUdKE1FBNG3Kb0HYIeLOn48h8Lmfazb8aC3/ioq/ E=; X-Files: signature.asc : 195 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiQFAFcheFKtJXG//2dsb2JhbABZgwc4U74tgRKBJxZ0giUBAQEDAQEBASRHCwULAgEIRicLJQIEDgUOh20GDb5Gj1gHgyCBDgOQLoEwhiyBL5BagyaCKg X-IronPort-AV: E=Sophos;i="4.93,635,1378857600"; d="asc'?scan'208";a="280408696" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-1.cisco.com with ESMTP; 04 Nov 2013 22:39:10 +0000 Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id rA4MdADP006852 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 4 Nov 2013 22:39:10 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.122]) by xhc-rcd-x04.cisco.com ([fe80::200:5efe:173.37.183.34%12]) with mapi id 14.03.0123.003; Mon, 4 Nov 2013 16:39:10 -0600 From: "Fred Baker (fred)" To: Bob Briscoe Thread-Topic: [aqm] Who supports tsvwg adoption of adding ECN to L2 or tunnel protocols? Thread-Index: AQHO2a6s10fjb0a1UEK5OS95UGUypw== Date: Mon, 4 Nov 2013 22:39:09 +0000 Message-ID: References: <201311042203.rA4M3lo0026458@bagheera.jungle.bt.co.uk> In-Reply-To: <201311042203.rA4M3lo0026458@bagheera.jungle.bt.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.21.88.9] Content-Type: multipart/signed; boundary="Apple-Mail=_AD0D3F69-F2EF-4DCE-BA6B-C70B0DDB695C"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Cc: "" , tsvwg IETF list , AQM IETF list Subject: Re: [tsvwg] [aqm] Who supports tsvwg adoption of adding ECN to L2 or tunnel protocols? 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, 04 Nov 2013 22:39:17 -0000 --Apple-Mail=_AD0D3F69-F2EF-4DCE-BA6B-C70B0DDB695C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Nov 4, 2013, at 2:03 PM, Bob Briscoe wrote: > Folks, >=20 > Pls respond if you support this being adopted as a work-group item in = the IETF transport services w-g (tsvwg). The WG chairs need visibility = of interest. And don't respond if we don't support it? :-) I have a very basic question. For IP/IP tunnels, such as GRE, the ECN = flags are defined, and I would imagine that RFC 2983 could be = interpreted as saying what one does with flags (when you move the TOS = octet, move 8 bits, whether in->out or out->in). For non-IP tunnels, = with the exception of MPLS, the IETF doesn't define the header. How does one add ECN to a protocol we don't maintain? If we maintain it, = are we already done? > Even better, if you're willing to read / comment / review / implement >=20 > Guidelines for Adding Congestion Notification to Protocols that = Encapsulate IP > >=20 > Abstract >=20 > The purpose of this document is to guide the design of congestion > notification in any lower layer or tunnelling protocol that > encapsulates IP. The aim is for explicit congestion signals to > propagate consistently from lower layer protocols into IP. Then the > IP internetwork layer can act as a portability layer to carry > congestion notification from non-IP-aware congested nodes up to the > transport layer (L4). Following these guidelines should assure > interworking between new lower layer congestion notification > mechanisms, whether specified by the IETF or other standards bodies. >=20 >=20 > [Cross-posting tsvwg & aqm, just in case] >=20 >=20 > Bob Briscoe, > also for co-authors Pat Thaler and John Kaippallimalil >=20 >=20 > ________________________________________________________________ > Bob Briscoe, BT=20 > _______________________________________________ > aqm mailing list > aqm@ietf.org > https://www.ietf.org/mailman/listinfo/aqm ------------------------------------------------------ 8 issues in virtual infrastructure http://dcrocker.net/#fallacies --Apple-Mail=_AD0D3F69-F2EF-4DCE-BA6B-C70B0DDB695C Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iD8DBQFSeCIKbjEdbHIsm0MRAuWJAJwPStWpPNbsiubCQAKy/cm6paiIVACgzoCa IrBfQAS0x17h3ML0ddxCBc4= =VdNX -----END PGP SIGNATURE----- --Apple-Mail=_AD0D3F69-F2EF-4DCE-BA6B-C70B0DDB695C-- From bob.briscoe@bt.com Mon Nov 4 14:45:08 2013 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 605C121E80E1; Mon, 4 Nov 2013 14:45:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.297 X-Spam-Level: X-Spam-Status: No, score=-3.297 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_OBFU_Q1=0.227] 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 N1XYvv8IamQO; Mon, 4 Nov 2013 14:44:58 -0800 (PST) Received: from hubrelay-rd.bt.com (hubrelay-rd.bt.com [62.239.224.99]) by ietfa.amsl.com (Postfix) with ESMTP id BE2F921E80AF; Mon, 4 Nov 2013 14:44:56 -0800 (PST) Received: from EVMHR01-UKBR.domain1.systemhost.net (193.113.108.40) by EVMHR67-UKRD.bt.com (10.187.101.22) with Microsoft SMTP Server (TLS) id 8.3.297.1; Mon, 4 Nov 2013 22:44:54 +0000 Received: from EPHR01-UKIP.domain1.systemhost.net (147.149.196.177) by EVMHR01-UKBR.domain1.systemhost.net (193.113.108.40) with Microsoft SMTP Server (TLS) id 8.3.297.1; Mon, 4 Nov 2013 22:44:52 +0000 Received: from bagheera.jungle.bt.co.uk (132.146.168.158) by EPHR01-UKIP.domain1.systemhost.net (147.149.196.177) with Microsoft SMTP Server id 14.2.347.0; Mon, 4 Nov 2013 22:44:52 +0000 Received: from BTP075694.jungle.bt.co.uk ([10.109.157.6]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id rA4MinXo026739; Mon, 4 Nov 2013 22:44:50 GMT Message-ID: <201311042244.rA4MinXo026739@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 4 Nov 2013 22:44:48 +0000 To: "Fred Baker (fred)" From: Bob Briscoe In-Reply-To: References: <201311042203.rA4M3lo0026458@bagheera.jungle.bt.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 Cc: "" , tsvwg IETF list , AQM IETF list Subject: Re: [tsvwg] [aqm] Who supports tsvwg adoption of adding ECN to L2 or tunnel protocols? 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, 04 Nov 2013 22:45:08 -0000 Fred, At 22:39 04/11/2013, Fred Baker (fred) wrote: >On Nov 4, 2013, at 2:03 PM, Bob Briscoe wrote: > > > Folks, > > > > Pls respond if you support this being adopted as a work-group > item in the IETF transport services w-g (tsvwg). The WG chairs need > visibility of interest. > >And don't respond if we don't support it? :-) > >I have a very basic question. For IP/IP tunnels, such as GRE, the >ECN flags are defined, and I would imagine that RFC 2983 could be >interpreted as saying what one does with flags (when you move the >TOS octet, move 8 bits, whether in->out or out->in). For non-IP >tunnels, with the exception of MPLS, the IETF doesn't define the header. > >How does one add ECN to a protocol we don't maintain? If we maintain >it, are we already done? The idea is to issue liaison statements to make the relevant stds bodies aware of this. E.g.: - to 3GPP for GTP, - to IEEE for 802. The IETF maintains a number of the relevant tunnelling protocols it mentions, e.g. L2TP, GRE, PPTP. ________________________________________________________________ Bob Briscoe, BT From andrewmcgr@google.com Mon Nov 4 15:04:11 2013 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 75BC321E81AE for ; Mon, 4 Nov 2013 15:04:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.084 X-Spam-Level: X-Spam-Status: No, score=-0.084 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, SARE_HTML_USL_OBFU=1.666, SARE_SUB_OBFU_Q1=0.227] 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 2uK7i99B2Zfo for ; Mon, 4 Nov 2013 15:04:11 -0800 (PST) Received: from mail-qc0-x22e.google.com (mail-qc0-x22e.google.com [IPv6:2607:f8b0:400d:c01::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 7D5D121E81F2 for ; Mon, 4 Nov 2013 15:04:02 -0800 (PST) Received: by mail-qc0-f174.google.com with SMTP id v1so4290896qcw.5 for ; Mon, 04 Nov 2013 15:04:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=UgKzNxyw1zcSX2Bv5kGlsO5Fr76M4Ynb/z4RYYwowjc=; b=ZfZ4b0Pb2aOp/FO6O4173sXLhg9F/sU2FUlOS3WmlMxlwyUqJxKqR5cwhEiJ3B+ANO 1kmzEa1DktpwwyIrwBnRrJXuIvOalInzeQedsh3Ckz2FDr4RocJwVaRnkJPdGf7OCPpS WB1sj2xmPrnaC37SrPh79c4ymOh0hoOo2rm2bcI7uN6lrgVGMF/cyVGtjry5DMcP04d6 /QR5tZy5eSQo6EJiYNb7KxdRkjkyM+CIh0rrA4Zqh1aN7YhbXQJk4EUrXwPsg0lTp83V FnaVEISYzPwufdBmDH9wAz5nzp5hXVXCZMcscdCHISgoCoBBq6VNyqZiS2jH87kBAmDf hCzQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=UgKzNxyw1zcSX2Bv5kGlsO5Fr76M4Ynb/z4RYYwowjc=; b=jzKE0SMahkrnYH3vsnA3EV6rqKwTDbhi/6mIbigeuFl3IsZO+ylnHU+3GEhLuslfZu Ey47XWXUhHCNgy45dd5C7thipxdCqZ5fJR83KAh+qs1PlmK0dwBYSP2wEmglOURj8WEx xQctWFQ5BZpW+yykuXT9f96QsLbuEvxXUUsQW/vQtkySu9LQueRS5UknMSvjkXlB1irj m/WsGDQ5TJPq67D3ivotyjM+uJoAzZwrPlDRC+IaTY4zO0A7ZRo31V79EtGGV+6SKAdq znuVhm3BRM9pY77lH3hwBOWH/VS0ty1t+vLA/OkRUpNYbQCZfoNWQWhX935fRZhLq+X/ JMJA== X-Gm-Message-State: ALoCoQmbYgvOKtOqW4Jm+jbpBrodS5lPz1QYlQbcy+4v2J5Qq/LdRPQFGp9ip+vOn1U+wtiCsbgq2A7aF/NS11Ciu4X3e6YVRmlFvmgsxc0nUTdOFvGpWTR+NtU+zq5euvX0zPHR1oon3jdWiiSorzolzzK0L3Hk3hVqpdlxRirA26eDsnVJs5OzSn9wdjYvBzKYUbz3zcOm MIME-Version: 1.0 X-Received: by 10.224.22.75 with SMTP id m11mr25705540qab.27.1383606241488; Mon, 04 Nov 2013 15:04:01 -0800 (PST) Received: by 10.224.197.198 with HTTP; Mon, 4 Nov 2013 15:04:01 -0800 (PST) In-Reply-To: <201311042203.rA4M3lo0026458@bagheera.jungle.bt.co.uk> References: <201311042203.rA4M3lo0026458@bagheera.jungle.bt.co.uk> Date: Tue, 5 Nov 2013 10:04:01 +1100 Message-ID: From: Andrew Mcgregor To: Bob Briscoe Content-Type: multipart/alternative; boundary=047d7bdc78cc888b7b04ea61eed3 Cc: draft-briscoe-tsvwg-ecn-encap-guidelines@tools.ietf.org, tsvwg IETF list , AQM IETF list Subject: Re: [tsvwg] [aqm] Who supports tsvwg adoption of adding ECN to L2 or tunnel protocols? 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, 04 Nov 2013 23:04:11 -0000 --047d7bdc78cc888b7b04ea61eed3 Content-Type: text/plain; charset=ISO-8859-1 This seems like valuable work. One question is, can we put in scope notification that losses are NOT due to congestion? Willing to comment and review, at least. On 5 November 2013 09:03, Bob Briscoe wrote: > Folks, > > Pls respond if you support this being adopted as a work-group item in the > IETF transport services w-g (tsvwg). The WG chairs need visibility of > interest. > Even better, if you're willing to read / comment / review / implement > > Guidelines for Adding Congestion Notification to Protocols that > Encapsulate IP > > > Abstract > > The purpose of this document is to guide the design of congestion > notification in any lower layer or tunnelling protocol that > encapsulates IP. The aim is for explicit congestion signals to > propagate consistently from lower layer protocols into IP. Then the > IP internetwork layer can act as a portability layer to carry > congestion notification from non-IP-aware congested nodes up to the > transport layer (L4). Following these guidelines should assure > interworking between new lower layer congestion notification > mechanisms, whether specified by the IETF or other standards bodies. > > > [Cross-posting tsvwg & aqm, just in case] > > > Bob Briscoe, > also for co-authors Pat Thaler and John Kaippallimalil > > > ________________________________________________________________ > Bob Briscoe, BT > _______________________________________________ > aqm mailing list > aqm@ietf.org > https://www.ietf.org/mailman/listinfo/aqm > -- Andrew McGregor | SRE | andrewmcgr@google.com | +61 4 8143 7128 --047d7bdc78cc888b7b04ea61eed3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
This seems like valuable work. =A0One question is, can we = put in scope notification that losses are NOT due to congestion?

Willing to comment and review, at least.


On 5 November 2013 09:03, Bob Briscoe <bob.briscoe@bt.com> wrote:
Folks,

Pls respond if you support this being adopted as a work-group item in the I= ETF transport services w-g (tsvwg). The WG chairs need visibility of intere= st.
Even better, if you're willing to read / comment / review / implement
Guidelines for Adding Congestion Notification to Protocols that Encapsulate= IP
<http://tools.ietf.org/html/draft-briscoe-= tsvwg-ecn-encap-guidelines>

Abstract

=A0 =A0The purpose of this document is to guide the design of congestion =A0 =A0notification in any lower layer or tunnelling protocol that
=A0 =A0encapsulates IP. =A0The aim is for explicit congestion signals to =A0 =A0propagate consistently from lower layer protocols into IP. =A0Then t= he
=A0 =A0IP internetwork layer can act as a portability layer to carry
=A0 =A0congestion notification from non-IP-aware congested nodes up to the<= br> =A0 =A0transport layer (L4). =A0Following these guidelines should assure =A0 =A0interworking between new lower layer congestion notification
=A0 =A0mechanisms, whether specified by the IETF or other standards bodies.=


[Cross-posting tsvwg & aqm, just in case]


Bob Briscoe,
also for co-authors Pat Thaler and John Kaippallimalil


_____________________________________________________________= ___
Bob Briscoe, =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0BT
_______________________________________________
aqm mailing list
aqm@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/aqm



--
Andrew McGregor=A0|=A0SRE=A0|=A0andrewmcgr@google.com=A0|=A0+61 4 8143 7128
--047d7bdc78cc888b7b04ea61eed3-- From mattmathis@google.com Mon Nov 4 15:16:32 2013 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 7E81921E826F for ; Mon, 4 Nov 2013 15:16:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.895 X-Spam-Level: X-Spam-Status: No, score=-0.895 tagged_above=-999 required=5 tests=[AWL=-0.811, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, SARE_HTML_USL_OBFU=1.666, SARE_SUB_OBFU_Q1=0.227] 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 AI5ErC++NIfw for ; Mon, 4 Nov 2013 15:16:31 -0800 (PST) Received: from mail-ie0-x235.google.com (mail-ie0-x235.google.com [IPv6:2607:f8b0:4001:c03::235]) by ietfa.amsl.com (Postfix) with ESMTP id 9DA2521E8263 for ; Mon, 4 Nov 2013 15:16:31 -0800 (PST) Received: by mail-ie0-f181.google.com with SMTP id ar20so14000890iec.12 for ; Mon, 04 Nov 2013 15:16:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=K97CLgUclEVmjrZo3fPN6I5oOKAiBcHfb/31J0lsIMk=; b=GEfL50c5gsiTmFf37WJPaxNE3fIS7xzDVdIsYOxh5BO8ugcpAlD+dnhQeyQJyDWUMK xMCByhaKRr+o8vwiLnw78pwi/Po6Isn3IU5W65POZbrdqPTzIFy0h3NnVklGee3cqOCt 2otNmKC52nfZMsPdXOYyMnbikEiUYnuSarNwBboOWuiGy/NcovWEYK2GIVn8y+mI/E8G XKXf+1Z0F6Bu96ZTNP7SaXYBOa7cwN8mJZImnbBtjGaiCLGYEzXkzEkmzY3CDS4nGcKX 3yefHCGA7yHFBb/OKOH1Th0VcRsBxsOt1L+xwd854LX2NuV+auARHF1oIyLDr7ckV4Xh igNQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=K97CLgUclEVmjrZo3fPN6I5oOKAiBcHfb/31J0lsIMk=; b=PNfZg4nJoolEPCI3ejpHYwlw8DbB99wHxLaeGAQCyRaRL8V3DXAySC6JB9JQgXVRrJ xTIEEng9tvBpNHZojruZVmY9bBTUfZ65gqtEMV6GxFDKza67PsiCVmBJuOftRGI3Wt6s +IjOBNy4x6EWR7kA6akTW8ymehvdIbZ3GaTxQ9DiANwS72mvKgsXpy9b/rafyPBRtA/M eWK/W6Xd1Y5biMK2kGAJK73R1fST6mxSY2tt3pYGCdRObxgmhqJH1a6ceKVK2zqgWOvF Bg+dhTQsRfyMEHjEK50KwflypJSUWjOPV4Crsn3kRJF7tgngOEJfzvUkbCLRtdwABi09 Hq+g== X-Gm-Message-State: ALoCoQl0p9VsI3azIvLwd4X4Sw30jALuOsB09Uc7FcRreSnxKxOh9h+WaDShLL0jNHKHDuQCMO5OeT/HTfSMG8bHeRozX223Fz5G0K62FpDUIQL6Ylw4Ig/kUksLIJleJyFNMlugZrBMqCXpuoDfV84HiJwOsUunipHFX8JBkQ7wpUnIMIY3Ed4YN7AMU8tvzoJsEK4zeW9s MIME-Version: 1.0 X-Received: by 10.43.158.10 with SMTP id ls10mr11482691icc.20.1383606990999; Mon, 04 Nov 2013 15:16:30 -0800 (PST) Received: by 10.64.243.66 with HTTP; Mon, 4 Nov 2013 15:16:30 -0800 (PST) In-Reply-To: <201311042203.rA4M3lo0026458@bagheera.jungle.bt.co.uk> References: <201311042203.rA4M3lo0026458@bagheera.jungle.bt.co.uk> Date: Mon, 4 Nov 2013 15:16:30 -0800 Message-ID: From: Matt Mathis To: Bob Briscoe Content-Type: multipart/alternative; boundary=001a11c1ead6352a2604ea621b57 Cc: draft-briscoe-tsvwg-ecn-encap-guidelines@tools.ietf.org, tsvwg IETF list , AQM IETF list Subject: Re: [tsvwg] [aqm] Who supports tsvwg adoption of adding ECN to L2 or tunnel protocols? 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, 04 Nov 2013 23:16:32 -0000 --001a11c1ead6352a2604ea621b57 Content-Type: text/plain; charset=ISO-8859-1 I think this is valuable work. Having a single document that describes the requirements and general principles will save future tunnel inventor/implementers from rediscovering the same bugs Thanks, --MM-- The best way to predict the future is to create it. - Alan Kay Privacy matters! We know from recent events that people are using our services to speak in defiance of unjust governments. We treat privacy and security as matters of life and death, because for some users, they are. On Mon, Nov 4, 2013 at 2:03 PM, Bob Briscoe wrote: > Folks, > > Pls respond if you support this being adopted as a work-group item in the > IETF transport services w-g (tsvwg). The WG chairs need visibility of > interest. > Even better, if you're willing to read / comment / review / implement > > Guidelines for Adding Congestion Notification to Protocols that > Encapsulate IP > > > Abstract > > The purpose of this document is to guide the design of congestion > notification in any lower layer or tunnelling protocol that > encapsulates IP. The aim is for explicit congestion signals to > propagate consistently from lower layer protocols into IP. Then the > IP internetwork layer can act as a portability layer to carry > congestion notification from non-IP-aware congested nodes up to the > transport layer (L4). Following these guidelines should assure > interworking between new lower layer congestion notification > mechanisms, whether specified by the IETF or other standards bodies. > > > [Cross-posting tsvwg & aqm, just in case] > > > Bob Briscoe, > also for co-authors Pat Thaler and John Kaippallimalil > > > ________________________________________________________________ > Bob Briscoe, BT > _______________________________________________ > aqm mailing list > aqm@ietf.org > https://www.ietf.org/mailman/listinfo/aqm > --001a11c1ead6352a2604ea621b57 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I think this is valuable work. =A0Having a single document= that describes the requirements and general principles will save future tu= nnel inventor/implementers from rediscovering the same bugs

Thanks,
--MM--
The bes= t way to predict the future is to create it. =A0- Alan Kay

Privacy m= atters! =A0We know from recent events that people are using our services to= speak in defiance of unjust governments. =A0 We treat privacy and security= as matters of life and death, because for some users, they are.


On Mon, Nov 4, 2013 at 2:03 PM, Bob Bris= coe <bob.briscoe@bt.com> wrote:
Folks,

Pls respond if you support this being adopted as a work-group item in the I= ETF transport services w-g (tsvwg). The WG chairs need visibility of intere= st.
Even better, if you're willing to read / comment / review / implement
Guidelines for Adding Congestion Notification to Protocols that Encapsulate= IP
<http://tools.ietf.org/html/draft-briscoe-= tsvwg-ecn-encap-guidelines>

Abstract

=A0 =A0The purpose of this document is to guide the design of congestion =A0 =A0notification in any lower layer or tunnelling protocol that
=A0 =A0encapsulates IP. =A0The aim is for explicit congestion signals to =A0 =A0propagate consistently from lower layer protocols into IP. =A0Then t= he
=A0 =A0IP internetwork layer can act as a portability layer to carry
=A0 =A0congestion notification from non-IP-aware congested nodes up to the<= br> =A0 =A0transport layer (L4). =A0Following these guidelines should assure =A0 =A0interworking between new lower layer congestion notification
=A0 =A0mechanisms, whether specified by the IETF or other standards bodies.=


[Cross-posting tsvwg & aqm, just in case]


Bob Briscoe,
also for co-authors Pat Thaler and John Kaippallimalil


_____________________________________________________________= ___
Bob Briscoe, =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0BT
_______________________________________________
aqm mailing list
aqm@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/aqm

--001a11c1ead6352a2604ea621b57-- From Michael.Tuexen@lurchi.franken.de Mon Nov 4 15:18:28 2013 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 2325121E82AD for ; Mon, 4 Nov 2013 15:18:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] 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 jFXxkB6nLOKr for ; Mon, 4 Nov 2013 15:18:27 -0800 (PST) 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 1D72321E82AA for ; Mon, 4 Nov 2013 15:18:18 -0800 (PST) Received: from wireless-v6.meeting.ietf.org (unknown [IPv6:2001:67c:370:160:ede2:f32b:bb4e:1859]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 7BAF01C0C0692; Tue, 5 Nov 2013 00:18:17 +0100 (CET) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Michael Tuexen In-Reply-To: <5ae2e62e90fc9401a06cb34c2f701240@mail.gmail.com> Date: Mon, 4 Nov 2013 15:18:15 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <51E872B4-81DE-431F-B185-EE4273860FB1@lurchi.franken.de> References: <29574887aaaa06bc270d9e779cfb760a@mail.gmail.com> <94726BF8-7806-4EF5-999D-3F4491195889@lurchi.franken.de> <5ae2e62e90fc9401a06cb34c2f701240@mail.gmail.com> To: Karen E. Egede Nielsen X-Mailer: Apple Mail (2.1510) Cc: tsvwg@ietf.org Subject: Re: [tsvwg] Proposal for socket api extension for PFAILED notification 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, 04 Nov 2013 23:18:28 -0000 On Nov 4, 2013, at 1:55 PM, Karen E. Egede Nielsen = wrote: > Hi Michael, >=20 > Thanks a lot for your feedback :-) >=20 >> I think the semantic of the event is that it is sent, when a new = primary > path is >> set by the kernel. This can happen, because: >> * The peer requests this by using ASCONF. >> * The kernel decides that it has to change the primary path. >>>=20 > [Karen] In a standard RFC4960 switchback scenario SCTP, e.g. FreeBSD = SCTP, > would not generate this event for an alternative path in case > SCTP temporarily was using this alternative path for data transfer as = the > Primary Path has entered Potentially Failed state - Correct ? In the FreeBSD implementation when the primary path becomes UNREACHABLE, it stays to be primary, but we send data on another patch. Once the = primary patch becomes REACHABLE again, it will be used for data transmission. Since we don't change the primary path (it just moves from REACHABLE to UNREACHABLE to REACHABLE), we don't issue the event. However, other implementations might change the primary path. Then I would expect them to issue the event. So, I think you are correct. >=20 >>> To cater for event notification of the PFAILED state, the following > optional >> extension to the socket api is proposed: >>>=20 >>> New SCTP event type is defined. I.e., new se_type of RFC6458. >>> Proposed name: SCTP_PEER_ADDR_CHANGE_EXT_PF. >>>=20 >>> New spc_state is defined. Proposed name SCTP_ADDR_PFAILED: The >> address specified is Potentially Failed. >> Hmm. What about SCTP_ADDR_POTENTIALLY_FAILED or >> SCTP_ADDR_POT_FAILED. > [Karen] I am very fine with both. I tend to like the first a little = better > than the second. OK. Choice made... Lets use SCTP_ADDR_POTENTIALLY_FAILED. >=20 >>>=20 >>> When the SCTP_PEER_ADDR_CHANGE_EXT_PF event is subscribed to by >> UL, UL >>> will by means of the existing sctp_paddr_change notification >>> structure receive notification of the following state transitions of = a >> destination address: >>> ACTIVE =E0 PFAILED : spc_state=3D SCTP_ADDR_PFAILED PFAILED =E0 = ACTIVE: >>> spc_state =3D SCTP_ADDR_AVAILABLE >>>=20 >>> The proposal is backward compatible and it allows ULs who want to >>> ignore the PFAILED events to not receive them. ULs which do not want > to >> receive the above listed state transitions will subscribe only to > existing >> SCTP_PEER_ADDR_CHANGE event. >>>=20 >>> An alternative approach (less preferred from my perspective) is to >> implement the event notification as non-optional. >>> Meaning that once the PFAILED function is enabled then the above >>> described events will be generated as soon as UL subscribe to = existing >> SCTP_PEER_ADDR_CHANGE event. >> Adding a new event type just for adding a new path state seems to be > pretty >> invasive. I could live with it, but I would prefer just to extend >> SCTP_PEER_ADDR_CHANGE. >>=20 > [Karen] > I have a preference for the optional solution both from a > backward compatible as well as from a functional perspective, > but I will be reasonable content also with the non-optional solution. >=20 >> Just my thought... >>=20 >> Best regards >> Michael >>>=20 >>> BR, Karen >>>=20 >>>=20 >>>=20 >>>=20 >=20 From randall@lakerest.net Mon Nov 4 15:22:21 2013 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 C8CF321E8299 for ; Mon, 4 Nov 2013 15:22:21 -0800 (PST) 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 wmNlk3nJr5L3 for ; Mon, 4 Nov 2013 15:22:15 -0800 (PST) Received: from lakerest.net (lakerest.net [162.235.35.161]) by ietfa.amsl.com (Postfix) with ESMTP id 2DB1C21E8274 for ; Mon, 4 Nov 2013 15:21:43 -0800 (PST) Received: from dhcp-a2fe.meeting.ietf.org (dhcp-a2fe.meeting.ietf.org [31.133.162.254]) (authenticated bits=0) by lakerest.net (8.14.4/8.14.3) with ESMTP id rA4NLErd061438 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 4 Nov 2013 18:21:21 -0500 (EST) (envelope-from randall@lakerest.net) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=windows-1252 From: Randy Stewart In-Reply-To: <29574887aaaa06bc270d9e779cfb760a@mail.gmail.com> Date: Mon, 4 Nov 2013 15:21:03 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <3BF1C14E-8A80-428E-A6BC-D19F51C9E4DF@lakerest.net> References: <29574887aaaa06bc270d9e779cfb760a@mail.gmail.com> To: "Karen E. Egede Nielsen" X-Mailer: Apple Mail (2.1283) Cc: tsvwg@ietf.org Subject: Re: [tsvwg] Proposal for socket api extension for PFAILED notification 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, 04 Nov 2013 23:22:22 -0000 I also agree with Michael here. We really should not add a duplicate API with only the difference being a different state number (PF).. I would much rather see one more state defined for the existing notification. R On Nov 4, 2013, at 8:15 AM, Karen E. Egede Nielsen wrote: > Hi, > =20 > For an RFC4960 SCTP implementation UNREACHABLE event notification on = the (current) Primary Path serves to tell UL of leave of the (current) > Primary Path. With introduction of the Potentially Failed state in the = quick failover function of SCTP, no such event may be generated. > =20 > It is true that there is a =93made primary=94 event, which indirectly = tell of change of primary path, but some SCTP implementation defer the = generation of this event > until a new proven working primary path has been located (or set). > =20 > To cater for event notification of the PFAILED state, the following = optional extension to the socket api is proposed: > =20 > New SCTP event type is defined. I.e., new se_type of RFC6458. > Proposed name: SCTP_PEER_ADDR_CHANGE_EXT_PF. > =20 > New spc_state is defined. Proposed name SCTP_ADDR_PFAILED: The address = specified is Potentially Failed. >=20 > When the SCTP_PEER_ADDR_CHANGE_EXT_PF event is subscribed to by UL, UL > will by means of the existing sctp_paddr_change notification = structure receive notification of the > following state transitions of a destination address: > ACTIVE =E0 PFAILED : spc_state=3D SCTP_ADDR_PFAILED > PFAILED =E0 ACTIVE: spc_state =3D SCTP_ADDR_AVAILABLE > =20 > The proposal is backward compatible and it allows ULs who want to = ignore the PFAILED events to not > receive them. ULs which do not want to receive the above listed state = transitions will subscribe only to existing SCTP_PEER_ADDR_CHANGE event. > =20 > An alternative approach (less preferred from my perspective) is to = implement the event notification as non-optional. > Meaning that once the PFAILED function is enabled then the above = described events will be generated as soon as UL subscribe to > existing SCTP_PEER_ADDR_CHANGE event. > =20 > BR, Karen ----- Randall Stewart randall@lakerest.net From karen.nielsen@tieto.com Mon Nov 4 15:51:50 2013 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 2239621E8304 for ; Mon, 4 Nov 2013 15:51:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.346 X-Spam-Level: X-Spam-Status: No, score=-1.346 tagged_above=-999 required=5 tests=[AWL=0.631, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] 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 5tMFgQKGI0jF for ; Mon, 4 Nov 2013 15:51:48 -0800 (PST) Received: from mail-wi0-x22f.google.com (mail-wi0-x22f.google.com [IPv6:2a00:1450:400c:c05::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 1B69D11E8105 for ; Mon, 4 Nov 2013 15:51:47 -0800 (PST) Received: by mail-wi0-f175.google.com with SMTP id hm4so1361430wib.14 for ; Mon, 04 Nov 2013 15:51:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tieto.com; s=google; h=from:mime-version:thread-index:date:message-id:subject:to:cc :content-type; bh=d7UBtvPSIU1HNcEyyZgRciH8GjlYE1SKymj42+JrrIw=; b=sbfre1NRfznCLQLXuLJIwA2LAXq4o8jmZk/J7jzYU6ZKST5sQnQtR4omXz9wCWpHTi XnBoYNvtt0OqHyrcn1X+91/g7d5/6suR7b08FthoqMsHsTev1NLHPg5IwqhdXLGtIH83 3wvThMCrFJP+zmUjM5oPRq8XBJhPMdUV+vFXE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:mime-version:thread-index:date:message-id :subject:to:cc:content-type; bh=d7UBtvPSIU1HNcEyyZgRciH8GjlYE1SKymj42+JrrIw=; b=cT9944lRW8ujQ7kgxwPbshhtSp81BrVY5zHZhXNHVamWfViyFJtDB4yFeqQm9nuJbp 0nFo7bJJxYEbABrPXlkTJnGsowk8XnzPKDN0T9iIO28pf8sKamJzRlBwh4jcqT7xKrFg T+qemFxUNxhEgtmIt2Nl45rWlVIzrpx7AMjfp3jkdONSQ+90oOIVXRo8tvopzcKHaTSc YA0GCYNN1Tmv1mPwtz4M7200eflNwkBbV8T2EGtGpVp/S40m8T5Z5BqLEqrJ0MMVsYRj vYvZw6K214UJ9EGpKovDi4fC7pgU9l2nCaoF0Dmnk5PAW4jgbVtJf00bJfcq1daS9Mwl POpg== X-Gm-Message-State: ALoCoQmssJR7zPbpGm2kxvFc6KbKQBo9WVAX69nWq9vKx1RfI0o2qhuXf7K6jTBgzhc4qjd1vqnzlE3BSCx4ACt2VLuHTY3pWg== X-Received: by 10.180.149.234 with SMTP id ud10mr14245098wib.25.1383609107148; Mon, 04 Nov 2013 15:51:47 -0800 (PST) From: "Karen E. Egede Nielsen" MIME-Version: 1.0 X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac7ZuNAoLSAgniyxQr6ibLXxtyi2aQ== Date: Mon, 4 Nov 2013 15:51:53 -0800 Message-ID: <6de6099c3bd0543b17cfa5da84d327ad@mail.gmail.com> To: Randall Stewart , tsvwg@ietf.org Content-Type: multipart/alternative; boundary=001a11c384245708c904ea6299e8 X-DomainID: tieto.com Cc: Michael Tuexen Subject: [tsvwg] draft-stewart-tsvwg-sctp-ndata-03.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, 04 Nov 2013 23:51:50 -0000 --001a11c384245708c904ea6299e8 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi, Please accept the folowing comments to draft-stewart-tsvwg-sctp-ndata-03.txt. Please use as fit. General comments: ----------------------- The draft draft-stewart-tsvwg-sctp-ndata-03.txt, in my opinion, addresses an important limitation of SCTP message fragmentation The limitation is important to have removed in order to support large message transfer by SCTP without detroying concurrent transmission of data with real-time characteristics. The advanced stream scheduling modes, suggested in the draft, also seems very instrumental in order to instantiate different real time characteristics on different streams. Title: Given the scheduling aspects included in the draft, one should consider to adjust the title so that it better accommodate for the scheduling parts. Actually stream scheduling seems to be main topic of the draft with the new (or extended) data chunk format just a mean to support more flexible (interleaved) scheduling of fragments. Something else: The =93N=94 as =93New=94 in N-DATA seems not so future-pro= of. Perhaps E for word =93Extended=94 (E-DATA) would be a better naming ? It should be clarified in the Introduction that the draft makes use of the Supported Extension Parameter as defined in RFC5061. Detailed Comments: --------------------------- Section 1.1: 1. It should be clarified that the draft defines a new data chunk option as well as that it defines an advanced stream scheduler function and that these are independent functions. 2. It could be clarified that the intention is for the new data chunk to be used for *all* data transmitted on a particular association (i.e., not only fragments). 3. It could be clarified that the usage of the new data chunk will differentiable on a per association basis and that an SCTP implementation as such shall support coexistence of associations which use the existing data chunk format and associations which use the new data chunk format. Section 3.1: 1. In the third paragraph that starts with =93Sender side usage.. =94= , it should be clarified that the new data chunk is used for all data chunks and not for only data chunks that need fragmentation. 2. The situation, when the peer does not support N-DATA but the user request it, should preferably be elaborated on in this section or somewhere else in the draft. Presumably then in this situation the SCTP layer simply uses the legacy data chunk with its in-build limitations. However this should be described. 3. Information should preferably be provided to UL about whether peer supports usage of N-DATA. For a socket api compliant implementation such information could possibly be provided in an extension of SCTP_STATUS ? Section 4.1 =96 minor/editorial: 1. The text could be clarified so that it more clearly refers to =93one-to-many=94 and to =93one-to-one=94 sockets. The text could also better describe the behaviour= of the socket option on each type. 2. The second paragraph sentence: =93An N-DATA chunk aware applicatio= n should also set the fragment interleave level to 2=94 =96 should refer to appropriate option of RFC6458. Section 4.1 =96 substance: 1. I would like to press for that the ability to change the N-DATA setting on current (established) associations is removed. It looks to open up for a number of complexities both in SCTP layer as well as in O&M layer; E.g., if N-DATA feature is disabled, what about retransmissions where original was send as N-DATA. When the O&M operation is made, then how to control when it takes effect in the SCTP layer in respect to data already in SND buffer. Further the disabling only effectively can control the sending side. These details would have to be described in draft and, secondly, implemented, both of which could be somewhat of a challenge. Are there some important use-cases that demands for this =93flexibility=94 ? 2. I believe that one NEED to have the possibility, on a per association basis, to read whether the peer supports N-DATA or not. This regardless of whether it be an association belonging to a one-to-many socket or a one-to-one socket. Support for read via socket api should be described in the draft. This may be provided via an extension of SCTP_STATUS (?). Optionally one may also prescribe for such information to be returned as part of an extension of RFC3873, sctpAssocTable object. 3. Situation with association restart on SCTP level should preferably be described. Section 4.1.2: 1. Would it be reasonable to specify a subset of the listed scheduling options as something that an implementation that support N-DATA MUST support and others as MAY or optional. Alternatively one may specify that at least one of the options need to be supported ? 2. The SCTP_SS_FAIR_BANDWIDTH could be demanding from an implementation perspective. 3. It should be clarified that these scheduling options are applicable for sending normal DATA chunks also when peer does not support usage of N-DATA. Possible addition to the draft content: (?) Possibly one could contemplate to include improvement of the receiver side operation also. As follows: =B7 The SCTP receive operation could be extended to allow for specification of read stream scheduling - possibly options =96 to start wi= th (RS: Read Scheduling): o SCTP_RS_FIRST_COME: The simple first-come, first-serve algorithm is selected by using this value. It just queues messages that are readable in the order in which they have been received by the SCTP layer. o SCTP_RS_PRIORITY: SCTP operates with a number of receive queues per association according to a number of priorities set. For each priority queue simple first-come, first-serve algorithm is used .I.e., for each priority queue messages are queued as readable in the order in which they have been received by the SCTP layer .The priority can be assigned on a per stream basis. Value 0 is default priority, higher values are higher priority (or lower), lower values are lower priority (or higher). Select, poll (BSD) and epoll (Linux) mechanism must be extended to support specification, and notification, of receiving readable event on a per priority RCV queue basis. Editorial: Abstract: which which =E0 which Section 2: FSN's are unsigned number =E0 FSN's are unsigned numbers BR, Karen --001a11c384245708c904ea6299e8 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

Hi,

=A0

Please accept the folowing comments to draft-stewart-tsvwg-= sctp-ndata-03.txt.

Please use as fit.<= /p>

=A0

General comments:

-----------------------

=A0

The draft draft-stewart-tsvwg-sctp-nda= ta-03.txt, in my opinion, addresses an important limitation of SCTP message= fragmentation The

limitation is important to= have removed in order to support large message transfer by SCTP without de= troying concurrent transmission of

data with real-time charac= teristics.

=A0

The advanced stream schedu= ling modes, suggested in the draft, also seems very instrumental in order t= o instantiate different real time characteristics on

different streams. =

=A0

Title: =A0Given the scheduling aspects included in the draft, one should consi= der to adjust the title so that it better accommodate for the scheduling pa= rts. Actually stream scheduling seems to be main topic of the draft with th= e new (or extended) data chunk format just a mean to support more flexible = (interleaved) scheduling of fragments.

=A0

Something else: =A0The =93N=94 as =93New=94 in N= -DATA seems not so future-proof. Perhaps E for word =93Extended=94 (E-DATA)= would be a better naming ?

=A0

It should be clarified in the Introduction that = the draft makes use of the Supported Extension Parameter as defined in RFC5= 061.

=A0

Detailed Comments:

---------------------------

=A0

Section 1.1:

1.=A0=A0=A0=A0=A0=A0 It should be clarified that the draft defines a new d= ata chunk option as well as that it defines an advanced stream scheduler fu= nction and that these are independent functions.

2.=A0=A0=A0=A0=A0=A0 It co= uld be clarified that the intention is for the new data chunk to be used fo= r all data transmitted on a particular associatio= n (i.e., not only fragments).

3.=A0=A0=A0=A0=A0=A0 It co= uld be clarified that the usage of the new data chunk will differentiable o= n a per association basis and that an SCTP implementation as such shall sup= port coexistence of associations which use the existing data chunk format a= nd associations which use the new data chunk format.

=A0

Section 3.1:

1.=A0=A0=A0=A0=A0=A0 In the third paragraph that starts with =93Sender side usage.. =94, it sho= uld be clarified that the new data chunk is used for all data chunks and no= t for only data chunks that need fragmentation.

2.=A0=A0=A0=A0=A0=A0 The s= ituation, when the peer does not support N-DATA but the user request it, sh= ould preferably be elaborated on in this section or somewhere else in the d= raft. Presumably then in this situation the SCTP layer simply uses the lega= cy data chunk with its in-build limitations. However this should be describ= ed.

3.=A0=A0=A0=A0=A0=A0 Informa= tion should preferably be provided to UL about whether peer supports usage = of N-DATA. For a socket api compliant implementation such information could= possibly be provided in an extension of SCTP_STATUS ?

Section 4.1 =96 minor/editorial:

=A0

1.=A0=A0=A0=A0=A0=A0 The text could be clarified so that it more clearly refers to =93on= e-to-many=94 and to
=93one-to-one=94 sockets. The text could also better describe the behaviour= of the socket option on each type.

2.= =A0=A0=A0=A0=A0=A0 <= /span>The second paragraph sentence: =93= An N-DATA chunk aware application should also set the fragment interleave l= evel to 2=94 =96 should refer to appropriate option of RFC6458.

=A0

Section 4.1 =96 substance:=

=A0

1.=A0=A0=A0=A0=A0=A0 I would like to press for that the ability to= change the N-DATA setting on current (established) associations is removed= . It looks to open up for a number of complexities both in SCTP layer as we= ll as in O&M layer;=A0 E.g., =A0if N-DATA feature is disabled, what abo= ut retransmissions where original was send as N-DATA. When the O&M oper= ation is made, then how to control when it takes effect in the SCTP layer i= n respect to data already in SND buffer. Further the disabling only effecti= vely can control the sending side. These details would have to be described= in draft and, secondly, implemented, both of which could be somewhat of a = challenge. Are there some important use-cases that demands for this =93flex= ibility=94 ?

2.=A0=A0=A0=A0=A0=A0 I bel= ieve that one NEED to have the possibility, on a per association basis, to = read whether the peer supports N-DATA or not. This regardless of whether it= be an association belonging to a one-to-many socket or a one-to-one socket= . Support for read via socket api should be described in the draft. This ma= y be provided via an extension of SCTP_STATUS (?). Optionally one may also = prescribe for such information to be returned as part of an extension of RF= C3873, sctpAssocTable object.

3.=A0=A0=A0=A0=A0=A0 Situa= tion with association restart on SCTP level should preferably be described.=

=A0

Sect= ion 4.1.2:

=A0=

=A0

= 1.=A0=A0=A0=A0=A0=A0 Would it be reasonable to specify a subset of the listed scheduling option= s as something that an implementation that support N-DATA MUST support and = others as MAY or optional.=A0 Alternatively one may specify that at least o= ne of the options need to be supported ?

2.=A0=A0=A0=A0=A0=A0 The S= CTP_SS_FAIR_BANDWIDTH could be demanding from an implementation perspective= .

3.=A0=A0=A0=A0=A0=A0 It shou= ld be clarified that these scheduling options are applicable for sending no= rmal DATA chunks also when peer does not support usage of N-DATA.

=A0

Possible addition to the draft content: (?)

=A0

Possibly one could contemplate to inclu= de improvement of the receiver side operation also. As follows:

=A0

=B7=A0=A0=A0=A0=A0=A0=A0=A0 The SCTP receive operation could be extended to allow for spec= ification of read stream scheduling=A0 - possibly options =96 to start with= (RS: Read Scheduling):

o= =A0=A0 SCTP_RS_FIRST_COME: The simple first-come, fir= st-serve algorithm

is selected by using this value.=A0 It just queues messages= that are readable in the order in which they have been received by the SCT= P layer.

o= =A0=A0 SCTP_RS_PRIORITY:=A0 SCTP operates with a numb= er of receive queues per association according to a number of priorities se= t. For each priority queue simple first-come, first-serve algorithm is used= .I.e., for each priority queue messages are queued as readable in the orde= r in which they have been received by the SCTP layer .The priority can be a= ssigned on a per stream basis. Value 0 is default priority, higher values a= re higher priority (or lower), lower values are lower priority (or higher).=

Select, poll (BSD) and epoll (Linux) mechanism must be extend= ed to support specification, and notification, of receiving readable event = on a per priority RCV queue basis.

=A0

Editorial:

=A0

= Abstract: which which =E0 which

Section 2: FSN's a= re unsigned number =E0 FSN's are unsigned numbers

=A0

BR, Karen

=A0

=A0

=A0=

=A0

--001a11c384245708c904ea6299e8-- From bob.briscoe@bt.com Mon Nov 4 16:00:42 2013 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 C1E3A11E82CA; Mon, 4 Nov 2013 16:00:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.808 X-Spam-Level: X-Spam-Status: No, score=-2.808 tagged_above=-999 required=5 tests=[AWL=-0.436, BAYES_00=-2.599, HTML_MESSAGE=0.001, SARE_SUB_OBFU_Q1=0.227] 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 GCIK6iTaFY6S; Mon, 4 Nov 2013 16:00:37 -0800 (PST) Received: from hubrelay-rd.bt.com (hubrelay-rd.bt.com [62.239.224.98]) by ietfa.amsl.com (Postfix) with ESMTP id 871D511E8105; Mon, 4 Nov 2013 16:00:33 -0800 (PST) Received: from EVMHR72-UKRD.domain1.systemhost.net (10.36.3.110) by EVMHR66-UKRD.bt.com (10.187.101.21) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 5 Nov 2013 00:00:31 +0000 Received: from EPHR01-UKIP.domain1.systemhost.net (147.149.196.177) by EVMHR72-UKRD.domain1.systemhost.net (10.36.3.110) with Microsoft SMTP Server (TLS) id 8.3.279.1; Tue, 5 Nov 2013 00:00:31 +0000 Received: from bagheera.jungle.bt.co.uk (132.146.168.158) by EPHR01-UKIP.domain1.systemhost.net (147.149.196.177) with Microsoft SMTP Server id 14.2.347.0; Tue, 5 Nov 2013 00:00:30 +0000 Received: from BTP075694.jungle.bt.co.uk ([10.109.157.6]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id rA500RMV027031; Tue, 5 Nov 2013 00:00:27 GMT Message-ID: <201311050000.rA500RMV027031@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 5 Nov 2013 00:00:26 +0000 To: Andrew Mcgregor From: Bob Briscoe In-Reply-To: References: <201311042203.rA4M3lo0026458@bagheera.jungle.bt.co.uk> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_490245263==.ALT" X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 Cc: draft-briscoe-tsvwg-ecn-encap-guidelines@tools.ietf.org, tsvwg IETF list , AQM IETF list Subject: Re: [tsvwg] [aqm] Who supports tsvwg adoption of adding ECN to L2 or tunnel protocols? 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, 05 Nov 2013 00:00:42 -0000 --=====================_490245263==.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Andrew, Thx for supporting words and offer of help. At 23:04 04/11/2013, Andrew Mcgregor wrote: >This seems like valuable work. One question is, can we put in scope >notification that losses are NOT due to congestion? Eyooow. That really does not belong in this scope. This is about the interface between lower layers and the ECN field in the IP header. We can't really talk about new semantics in lower layers that aren't even defined in ECN at the IP layer. Naively, one could imagine some text treating the ECN field as 4 opaque codepoints, and propagating a similar 4 opaque codepoints from each lower layer protocol. Then if something new were defined in IP-ECN like a non-congestive loss codepoint, it could also be defined in lower layers... But that's naive, because each lower layer has it's own constraints and ways of handling concepts like "ECN-capable transport", none of which easily translates to a simple mapping of codepoints. Explicit signalling of non-congestive loss is a research problem, because... * Clearly a link cannot signal that a loss was not due to congestion using the lost frame itself (there aren't any bits :) * So the link would have to signal in another frame that didn't get corrupted. - That frame may go to another process that didn't see any loss; then what does the process do? - or the link has to use DPI to signal only in frames going to the same process as the lost frame. - that means the link has to understand all transport protocols There's other hard problems * A transmission loss doesn't always mean there is no congestion loss * At my last count, there were at least nine different reasons for packet loss. If we had 4 bits spare in each lost packet... :) Bob >Willing to comment and review, at least. > > >On 5 November 2013 09:03, Bob Briscoe ><bob.briscoe@bt.com> wrote: >Folks, > >Pls respond if you support this being adopted as a work-group item >in the IETF transport services w-g (tsvwg). The WG chairs need >visibility of interest. >Even better, if you're willing to read / comment / review / implement > >Guidelines for Adding Congestion Notification to Protocols that Encapsulate IP ><http://tools.ietf.org/html/draft-briscoe-tsvwg-ecn-encap-guidelines> > >Abstract > > The purpose of this document is to guide the design of congestion > notification in any lower layer or tunnelling protocol that > encapsulates IP. The aim is for explicit congestion signals to > propagate consistently from lower layer protocols into IP. Then the > IP internetwork layer can act as a portability layer to carry > congestion notification from non-IP-aware congested nodes up to the > transport layer (L4). Following these guidelines should assure > interworking between new lower layer congestion notification > mechanisms, whether specified by the IETF or other standards bodies. > > >[Cross-posting tsvwg & aqm, just in case] > > >Bob Briscoe, >also for co-authors Pat Thaler and John Kaippallimalil > > >________________________________________________________________ >Bob Briscoe, BT >_______________________________________________ >aqm mailing list >aqm@ietf.org >https://www.ietf.org/mailman/listinfo/aqm > > > > >-- >Andrew McGregor | SRE | >andrewmcgr@google.com | +61 4 8143 7128 >_______________________________________________ >aqm mailing list >aqm@ietf.org >https://www.ietf.org/mailman/listinfo/aqm ________________________________________________________________ Bob Briscoe, BT --=====================_490245263==.ALT Content-Type: text/html; charset="us-ascii" Andrew,

Thx for supporting words and offer of help.

At 23:04 04/11/2013, Andrew Mcgregor wrote:
This seems like valuable work.  One question is, can we put in scope notification that losses are NOT due to congestion?

Eyooow. That really does not belong in this scope.

This is about the interface between lower layers and the ECN field in the IP header. We can't really talk about new semantics in lower layers that aren't even defined in ECN at the IP layer.

Naively, one could imagine some text treating the ECN field as 4 opaque codepoints, and propagating  a similar 4 opaque codepoints from each lower layer protocol. Then if something new were defined in IP-ECN like a non-congestive loss codepoint, it could also be defined in lower layers...

But that's naive, because each lower layer has it's own constraints and ways of handling concepts like "ECN-capable transport", none of which easily translates to a simple mapping of codepoints.

Explicit signalling of non-congestive loss is a research problem, because...
* Clearly a link cannot signal that a loss was not due to congestion using the lost frame itself (there aren't any bits :)
* So the link would have to signal in another frame that didn't get corrupted.
  - That frame may go to another process that didn't see any loss; then what does the process do?
  - or the link has to use DPI to signal only in frames going to the same process as the lost frame.
  - that means the link has to understand all transport protocols

There's other hard problems
* A transmission loss doesn't always mean there is no congestion loss
* At my last count, there were at least nine different reasons for packet loss. If we had 4 bits spare in each lost packet... :)



Bob


Willing to comment and review, at least.


On 5 November 2013 09:03, Bob Briscoe <bob.briscoe@bt.com> wrote:
Folks,

Pls respond if you support this being adopted as a work-group item in the IETF transport services w-g (tsvwg). The WG chairs need visibility of interest.
Even better, if you're willing to read / comment / review / implement

Guidelines for Adding Congestion Notification to Protocols that Encapsulate IP
< http://tools.ietf.org/html/draft-briscoe-tsvwg-ecn-encap-guidelines >

Abstract

   The purpose of this document is to guide the design of congestion
   notification in any lower layer or tunnelling protocol that
   encapsulates IP.  The aim is for explicit congestion signals to
   propagate consistently from lower layer protocols into IP.  Then the
   IP internetwork layer can act as a portability layer to carry
   congestion notification from non-IP-aware congested nodes up to the
   transport layer (L4).  Following these guidelines should assure
   interworking between new lower layer congestion notification
   mechanisms, whether specified by the IETF or other standards bodies.


[Cross-posting tsvwg & aqm, just in case]


Bob Briscoe,
also for co-authors Pat Thaler and John Kaippallimalil


________________________________________________________________
Bob Briscoe,                                                  BT
_______________________________________________
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm




--
Andrew McGregor | SRE | andrewmcgr@google.com | +61 4 8143 7128
_______________________________________________
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm

________________________________________________________________
Bob Briscoe,                                                  BT --=====================_490245263==.ALT-- From michawe@ifi.uio.no Mon Nov 4 16:02:54 2013 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 01B2321E8318; Mon, 4 Nov 2013 16:02:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.652 X-Spam-Level: X-Spam-Status: No, score=-101.652 tagged_above=-999 required=5 tests=[AWL=-0.947, BAYES_00=-2.599, HTML_MESSAGE=0.001, SARE_HTML_USL_OBFU=1.666, SARE_SUB_OBFU_Q1=0.227, 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 G-3it9XUWY6O; Mon, 4 Nov 2013 16:02:49 -0800 (PST) Received: from mail-out5.uio.no (mail-out5.uio.no [IPv6:2001:700:100:10::17]) by ietfa.amsl.com (Postfix) with ESMTP id 6F02B21E833A; Mon, 4 Nov 2013 16:02:44 -0800 (PST) Received: from mail-mx4.uio.no ([129.240.10.45]) by mail-out5.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1VdU6S-0001CB-W1; Tue, 05 Nov 2013 01:02:40 +0100 Received: from dhcp-9c73.meeting.ietf.org ([31.133.156.115]) by mail-mx4.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80) (envelope-from ) id 1VdU6R-0004gn-NB; Tue, 05 Nov 2013 01:02:40 +0100 Content-Type: multipart/alternative; boundary="Apple-Mail=_CDB986EB-EC31-41E4-8F39-FF55DFD9A5CD" Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Michael Welzl In-Reply-To: Date: Mon, 4 Nov 2013 16:02:32 -0800 Message-Id: <0D37F652-8259-4A03-AA1F-4889221D84BD@ifi.uio.no> References: <201311042203.rA4M3lo0026458@bagheera.jungle.bt.co.uk> To: Bob Briscoe X-Mailer: Apple Mail (2.1510) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 4 msgs/h 1 sum rcpts/h 9 sum msgs/h 5 total rcpts 9380 max rcpts/h 40 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, HTML_MESSAGE=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: F87095E641CC2FDC768DC1C3634DD0D2BDEA6645 X-UiO-SPAM-Test: remote_host: 31.133.156.115 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 1 total 21 max/h 8 blacklist 0 greylist 0 ratelimit 0 Cc: draft-briscoe-tsvwg-ecn-encap-guidelines@tools.ietf.org, tsvwg IETF list , AQM IETF list Subject: Re: [tsvwg] [aqm] Who supports tsvwg adoption of adding ECN to L2 or tunnel protocols? 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, 05 Nov 2013 00:02:54 -0000 --Apple-Mail=_CDB986EB-EC31-41E4-8F39-FF55DFD9A5CD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 +1 On 4. nov. 2013, at 15:16, Matt Mathis wrote: > I think this is valuable work. Having a single document that = describes the requirements and general principles will save future = tunnel inventor/implementers from rediscovering the same bugs >=20 > Thanks, > --MM-- > The best way to predict the future is to create it. - Alan Kay >=20 > Privacy matters! We know from recent events that people are using our = services to speak in defiance of unjust governments. We treat privacy = and security as matters of life and death, because for some users, they = are. >=20 >=20 > On Mon, Nov 4, 2013 at 2:03 PM, Bob Briscoe = wrote: > Folks, >=20 > Pls respond if you support this being adopted as a work-group item in = the IETF transport services w-g (tsvwg). The WG chairs need visibility = of interest. > Even better, if you're willing to read / comment / review / implement >=20 > Guidelines for Adding Congestion Notification to Protocols that = Encapsulate IP > >=20 > Abstract >=20 > The purpose of this document is to guide the design of congestion > notification in any lower layer or tunnelling protocol that > encapsulates IP. The aim is for explicit congestion signals to > propagate consistently from lower layer protocols into IP. Then = the > IP internetwork layer can act as a portability layer to carry > congestion notification from non-IP-aware congested nodes up to the > transport layer (L4). Following these guidelines should assure > interworking between new lower layer congestion notification > mechanisms, whether specified by the IETF or other standards = bodies. >=20 >=20 > [Cross-posting tsvwg & aqm, just in case] >=20 >=20 > Bob Briscoe, > also for co-authors Pat Thaler and John Kaippallimalil >=20 >=20 > ________________________________________________________________ > Bob Briscoe, BT=20 > _______________________________________________ > aqm mailing list > aqm@ietf.org > https://www.ietf.org/mailman/listinfo/aqm >=20 > _______________________________________________ > aqm mailing list > aqm@ietf.org > https://www.ietf.org/mailman/listinfo/aqm --Apple-Mail=_CDB986EB-EC31-41E4-8F39-FF55DFD9A5CD Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=iso-8859-1 +1



On 4. nov. 2013, at 15:16, Matt Mathis <mattmathis@google.com> wrote:

I think this is valuable work.  Having a single document that describes the requirements and general principles will save future tunnel inventor/implementers from rediscovering the same bugs

Thanks,
--MM--
The best way to predict the future is to create it.  - Alan Kay

Privacy matters!  We know from recent events that people are using our services to speak in defiance of unjust governments.   We treat privacy and security as matters of life and death, because for some users, they are.


On Mon, Nov 4, 2013 at 2:03 PM, Bob Briscoe <bob.briscoe@bt.com> wrote:
Folks,

Pls respond if you support this being adopted as a work-group item in the IETF transport services w-g (tsvwg). The WG chairs need visibility of interest.
Even better, if you're willing to read / comment / review / implement

Guidelines for Adding Congestion Notification to Protocols that Encapsulate IP
<http://tools.ietf.org/html/draft-briscoe-tsvwg-ecn-encap-guidelines>

Abstract

   The purpose of this document is to guide the design of congestion
   notification in any lower layer or tunnelling protocol that
   encapsulates IP.  The aim is for explicit congestion signals to
   propagate consistently from lower layer protocols into IP.  Then the
   IP internetwork layer can act as a portability layer to carry
   congestion notification from non-IP-aware congested nodes up to the
   transport layer (L4).  Following these guidelines should assure
   interworking between new lower layer congestion notification
   mechanisms, whether specified by the IETF or other standards bodies.


[Cross-posting tsvwg & aqm, just in case]


Bob Briscoe,
also for co-authors Pat Thaler and John Kaippallimalil


________________________________________________________________
Bob Briscoe,                                                  BT
_______________________________________________
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm

_______________________________________________
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm

--Apple-Mail=_CDB986EB-EC31-41E4-8F39-FF55DFD9A5CD-- From rs@netapp.com Mon Nov 4 16:49:08 2013 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 9F43721E836B; Mon, 4 Nov 2013 16:49:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.288 X-Spam-Level: X-Spam-Status: No, score=-5.288 tagged_above=-999 required=5 tests=[AWL=-2.917, BAYES_00=-2.599, HTML_MESSAGE=0.001, SARE_SUB_OBFU_Q1=0.227] 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 3TOxQXRXWICE; Mon, 4 Nov 2013 16:49:04 -0800 (PST) Received: from mx11.netapp.com (mx11.netapp.com [216.240.18.76]) by ietfa.amsl.com (Postfix) with ESMTP id 89E6F11E82FF; Mon, 4 Nov 2013 16:49:02 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.93,636,1378882800"; d="scan'208,217";a="69544373" Received: from vmwexceht03-prd.hq.netapp.com ([10.106.76.241]) by mx11-out.netapp.com with ESMTP; 04 Nov 2013 16:48:44 -0800 Received: from SACEXCMBX02-PRD.hq.netapp.com ([169.254.1.86]) by vmwexceht03-prd.hq.netapp.com ([10.106.76.241]) with mapi id 14.03.0123.003; Mon, 4 Nov 2013 16:48:44 -0800 From: "Scheffenegger, Richard" To: Matt Mathis , Bob Briscoe Thread-Topic: [aqm] Who supports tsvwg adoption of adding ECN to L2 or tunnel protocols? Thread-Index: AQHO2bPschNRr0CscEy8XBGE9jPQ05oVzbZA Date: Tue, 5 Nov 2013 00:48:43 +0000 Message-ID: <012C3117EDDB3C4781FD802A8C27DD4F25E65C8E@SACEXCMBX02-PRD.hq.netapp.com> References: <201311042203.rA4M3lo0026458@bagheera.jungle.bt.co.uk> 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.117] Content-Type: multipart/alternative; boundary="_000_012C3117EDDB3C4781FD802A8C27DD4F25E65C8ESACEXCMBX02PRDh_" MIME-Version: 1.0 Cc: "draft-briscoe-tsvwg-ecn-encap-guidelines@tools.ietf.org" , tsvwg IETF list , AQM IETF list Subject: Re: [tsvwg] [aqm] Who supports tsvwg adoption of adding ECN to L2 or tunnel protocols? 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, 05 Nov 2013 00:49:08 -0000 --_000_012C3117EDDB3C4781FD802A8C27DD4F25E65C8ESACEXCMBX02PRDh_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable (aqm chair hat off) I can fully support what Matt just stated! I have read an earlier version (-01 iirc), I'll try to scan over this versi= on in the coming days. Richard Scheffenegger From: aqm-bounces@ietf.org [mailto:aqm-bounces@ietf.org] On Behalf Of Matt = Mathis Sent: Montag, 04. November 2013 15:17 To: Bob Briscoe Cc: draft-briscoe-tsvwg-ecn-encap-guidelines@tools.ietf.org; tsvwg IETF lis= t; AQM IETF list Subject: Re: [aqm] Who supports tsvwg adoption of adding ECN to L2 or tunne= l protocols? I think this is valuable work. Having a single document that describes the= requirements and general principles will save future tunnel inventor/imple= menters from rediscovering the same bugs Thanks, --MM-- The best way to predict the future is to create it. - Alan Kay Privacy matters! We know from recent events that people are using our serv= ices to speak in defiance of unjust governments. We treat privacy and sec= urity as matters of life and death, because for some users, they are. On Mon, Nov 4, 2013 at 2:03 PM, Bob Briscoe > wrote: Folks, Pls respond if you support this being adopted as a work-group item in the I= ETF transport services w-g (tsvwg). The WG chairs need visibility of intere= st. Even better, if you're willing to read / comment / review / implement Guidelines for Adding Congestion Notification to Protocols that Encapsulate= IP Abstract The purpose of this document is to guide the design of congestion notification in any lower layer or tunnelling protocol that encapsulates IP. The aim is for explicit congestion signals to propagate consistently from lower layer protocols into IP. Then the IP internetwork layer can act as a portability layer to carry congestion notification from non-IP-aware congested nodes up to the transport layer (L4). Following these guidelines should assure interworking between new lower layer congestion notification mechanisms, whether specified by the IETF or other standards bodies. [Cross-posting tsvwg & aqm, just in case] Bob Briscoe, also for co-authors Pat Thaler and John Kaippallimalil ________________________________________________________________ Bob Briscoe, BT _______________________________________________ aqm mailing list aqm@ietf.org https://www.ietf.org/mailman/listinfo/aqm --_000_012C3117EDDB3C4781FD802A8C27DD4F25E65C8ESACEXCMBX02PRDh_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

(aqm chair= hat off)

 = ;

I can full= y support what Matt just stated!

 = ;

I have rea= d an earlier version (-01 iirc), I’ll try to scan over this version i= n the coming days.

 = ;

 = ;

Richard Scheffenegger

 <= /p>

From: aqm-bounces@ietf.org [mailto:aqm-bounces@ietf.org] On Behalf Of Matt Mathis
Sent: Montag, 04. November 2013 15:17
To: Bob Briscoe
Cc: draft-briscoe-tsvwg-ecn-encap-guidelines@tools.ietf.org; tsvwg I= ETF list; AQM IETF list
Subject: Re: [aqm] Who supports tsvwg adoption of adding ECN to L2 o= r tunnel protocols?

 

I think this is valuable work.  Having a single= document that describes the requirements and general principles will save = future tunnel inventor/implementers from rediscovering the same bugs


Thanks,

--MM--
The best way to predict the future is to create it.  - Alan Kay

Privacy matters!  We know from recent events that people are using our= services to speak in defiance of unjust governments.   We treat priva= cy and security as matters of life and death, because for some users, they = are.

 

On Mon, Nov 4, 2013 at 2:03 PM, Bob Briscoe <bob.briscoe@bt.com&= gt; wrote:

Folks,

Pls respond if you support this being adopted as a work-group item in the I= ETF transport services w-g (tsvwg). The WG chairs need visibility of intere= st.
Even better, if you're willing to read / comment / review / implement

Guidelines for Adding Congestion Notification to Protocols that Encapsulate= IP
<http://tools.ietf.org/html/draft-briscoe-tsvwg-e= cn-encap-guidelines>

Abstract

   The purpose of this document is to guide the design of congest= ion
   notification in any lower layer or tunnelling protocol that    encapsulates IP.  The aim is for explicit congestion sign= als to
   propagate consistently from lower layer protocols into IP. &nb= sp;Then the
   IP internetwork layer can act as a portability layer to carry<= br>    congestion notification from non-IP-aware congested nodes up t= o the
   transport layer (L4).  Following these guidelines should = assure
   interworking between new lower layer congestion notification    mechanisms, whether specified by the IETF or other standards b= odies.


[Cross-posting tsvwg & aqm, just in case]


Bob Briscoe,
also for co-authors Pat Thaler and John Kaippallimalil


________________________________________________________________
Bob Briscoe,                  =                     &nbs= p;          BT
_______________________________________________
aqm mailing list
aqm@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/aqm

 

--_000_012C3117EDDB3C4781FD802A8C27DD4F25E65C8ESACEXCMBX02PRDh_-- From weixinpeng@huawei.com Mon Nov 4 17:08:54 2013 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 9A86211E8316; Mon, 4 Nov 2013 17:08:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, 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 McFbWub1Eir8; Mon, 4 Nov 2013 17:08:49 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 0E08611E8300; Mon, 4 Nov 2013 17:08:48 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AZV94252; Tue, 05 Nov 2013 01:08:47 +0000 (GMT) Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 5 Nov 2013 01:08:09 +0000 Received: from NKGEML403-HUB.china.huawei.com (10.98.56.34) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 5 Nov 2013 01:08:44 +0000 Received: from NKGEML507-MBX.china.huawei.com ([169.254.5.4]) by nkgeml403-hub.china.huawei.com ([10.98.56.34]) with mapi id 14.03.0158.001; Tue, 5 Nov 2013 09:08:39 +0800 From: Weixinpeng To: "tsvwg@ietf.org" , "aqm@ietf.org" Thread-Topic: Who supports tsvwg adoption of adding ECN to L2 or tunnel protocols? Thread-Index: AQHO2ar1vFFB2XF4BkqGsTlMgx3rlZoV0TJQ Date: Tue, 5 Nov 2013 01:08:38 +0000 Message-ID: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.76.176] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [tsvwg] Who supports tsvwg adoption of adding ECN to L2 or tunnel protocols? 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, 05 Nov 2013 01:08:54 -0000 I look through the whole document and I really think it's a good idea to pr= opagate congestion signals through different networks, it will be good to deal with the congestion situation especially when there= are lower layer en route. > >Date: Mon, 04 Nov 2013 22:03:45 +0000 > >To: "tsvwg IETF list" , AQM IETF list > >From: Bob Briscoe > >Subject: Who supports tsvwg adoption of adding ECN to L2 or tunnel > protocols? > >Cc: John Kaippallimalil , Pat Thaler > >, > >draft-briscoe-tsvwg-ecn-encap-guidelines@tools.ietf.org > > > >Folks, > > > >Pls respond if you support this being adopted as a work-group item in > >the IETF transport services w-g (tsvwg). The WG chairs need visibility > >of interest. > >Even better, if you're willing to read / comment / review / implement > > > >Guidelines for Adding Congestion Notification to Protocols that > >Encapsulate IP > > > > > >Abstract > > > > The purpose of this document is to guide the design of congestion > > notification in any lower layer or tunnelling protocol that > > encapsulates IP. The aim is for explicit congestion signals to > > propagate consistently from lower layer protocols into IP. Then the > > IP internetwork layer can act as a portability layer to carry > > congestion notification from non-IP-aware congested nodes up to the > > transport layer (L4). Following these guidelines should assure > > interworking between new lower layer congestion notification > > mechanisms, whether specified by the IETF or other standards bodies. > > > > > >[Cross-posting tsvwg & aqm, just in case] > > > > > >Bob Briscoe, > >also for co-authors Pat Thaler and John Kaippallimalil > > > >__________________________________________________________ > ______ > >Bob Briscoe, BT >=20 > ___________________________________________________________ > _____ > Bob Briscoe, BT From lei.zhu@huawei.com Mon Nov 4 23:50:05 2013 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 79A1611E822B; Mon, 4 Nov 2013 23:49:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.214 X-Spam-Level: X-Spam-Status: No, score=-4.214 tagged_above=-999 required=5 tests=[AWL=-2.384, BAYES_00=-2.599, CN_BODY_35=0.339, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Q1=0.227] 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 6uW8eiAwBeaH; Mon, 4 Nov 2013 23:49:37 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 9E4AB11E81AB; Mon, 4 Nov 2013 23:49:36 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AZX01520; Tue, 05 Nov 2013 07:49:28 +0000 (GMT) Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 5 Nov 2013 07:48:52 +0000 Received: from nkgeml405-hub.china.huawei.com (10.98.56.36) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 5 Nov 2013 07:49:27 +0000 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.193]) by nkgeml405-hub.china.huawei.com ([10.98.56.36]) with mapi id 14.03.0158.001; Tue, 5 Nov 2013 15:49:17 +0800 From: "Zhulei (A)" To: Bob Briscoe , tsvwg IETF list , "AQM IETF list" Thread-Topic: [aqm] Who supports tsvwg adoption of adding ECN to L2 or tunnel protocols? Thread-Index: AQHO2andeDdoGsWyNkSS9zl+hZ4GQJoWPPww Date: Tue, 5 Nov 2013 07:49:16 +0000 Message-ID: <470F27D1263A1B4EB73491ED995DE6252585DA0A@NKGEML512-MBS.china.huawei.com> References: <201311042203.rA4M3lo0026458@bagheera.jungle.bt.co.uk> In-Reply-To: <201311042203.rA4M3lo0026458@bagheera.jungle.bt.co.uk> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.65.68] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "draft-briscoe-tsvwg-ecn-encap-guidelines@tools.ietf.org" Subject: Re: [tsvwg] [aqm] Who supports tsvwg adoption of adding ECN to L2 or tunnel protocols? 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, 05 Nov 2013 07:50:06 -0000 SGkgYWxsLA0KDQpUaGlzIGRvY3VtZW50IHJlbWluZHMgb2YgdGhpbmtpbmcgb2YgbG93ZXIgbGF5 ZXIgY29uZ2VzdGlvbiBhbmQgcXVldWluZyBtZWNoYW5pc21zIGluIG5ldHdvcmssIHNvbWV0aW1l cyB3aGljaCB3b3VsZCBsZXZlcmFnZSBsYXJnZSBjb3ZlcmFnZS4gVGhlIG1vZGVzIHRvIGd1aWRl IHNlZW0gYWxsIHZhbGlkYXRlZCBhbmQgZXZlbiBoZWxwZnVsIGZvciBteSBzY2VuYXJpb3Mgb2Yg c29tZSBJUC1pbi1JUCBjYXNlIGFzIHdoYXQgaXMgc2F5aW5nIGluIGRyYWZ0LiBTbywgSSB3b3Vs ZCBiZSBnb29kIGZvciBhZG9wdGlvbiBvZiB0aGlzIGRyYWZ0IGFzIGEgd29yayBpdGVtLCBhbmQs IHdvdWxkIGxpa2UgdG8gcHJvbW90ZSBpbiB0aGlzIGRpcmVjdGlvbiBieSBzb21ldGhpbmcgZmVl ZGJhY2sgdG8gV0cuDQoNCk15IGFsd2F5cyB0aG91Z2h0IHRoYXQgdGhlIGVuY29kaW5nIG9mIEVD TiBtYXJraW5nLCBhcyBpbiBzb21lIGNhc2UgdGhlIGluZ3Jlc3Mgb2YgYSB0dW5uZWwgbWF5IG5l ZWQgdGhlIHNwYWNlKHMpIGZvciBmb2xsb3dpbmcgbGF5ZXIzIGVudGl0aWVzIHRvIGZpbGwgdGhl IEVDVCBhbmQgbG9jYXRpb24gaW5mb3JtYXRpb24gKGF0IGxlYXNlIGUuZy4gSVAgYWRkcmVzcyku IE9idmlvdXNseSwgaW5mb3JtYXRpb24gb2YgbG9jYXRpb24gd291bGQgYmUgb25seSBoZWxwZnVs IHRvIG5ldHdvcmsgb3BlcmF0b3IsIGJ1dCB0aGUgZW5kIHBvaW50IGhhbmRsaW5nIEVDTiBtYXJr aW5nLiANCg0KQmVzdCByZWdhcmRzLA0KWmh1IExlaQ0KTW9iaWxlOiArODYtMTM5MTAxNTcwMjAN Cg0KLS0tLS3Tyrz+1K28/i0tLS0tDQq3orz+yMs6IGFxbS1ib3VuY2VzQGlldGYub3JnIFttYWls dG86YXFtLWJvdW5jZXNAaWV0Zi5vcmddILT6se0gQm9iIEJyaXNjb2UNCreiy83KsbzkOiAyMDEz xOoxMdTCNcjVIDY6MDQNCsrVvP7IyzogdHN2d2cgSUVURiBsaXN0OyBBUU0gSUVURiBsaXN0DQqz rcvNOiBQYXQgVGhhbGVyOyBKb2huIEthaXBwYWxsaW1hbGlsOyBkcmFmdC1icmlzY29lLXRzdndn LWVjbi1lbmNhcC1ndWlkZWxpbmVzQHRvb2xzLmlldGYub3JnDQrW98ziOiBbYXFtXSBXaG8gc3Vw cG9ydHMgdHN2d2cgYWRvcHRpb24gb2YgYWRkaW5nIEVDTiB0byBMMiBvciB0dW5uZWwgcHJvdG9j b2xzPw0KDQpGb2xrcywNCg0KUGxzIHJlc3BvbmQgaWYgeW91IHN1cHBvcnQgdGhpcyBiZWluZyBh ZG9wdGVkIGFzIGEgd29yay1ncm91cCBpdGVtIGluIHRoZSBJRVRGIHRyYW5zcG9ydCBzZXJ2aWNl cyB3LWcgKHRzdndnKS4gVGhlIFdHIGNoYWlycyBuZWVkIHZpc2liaWxpdHkgb2YgaW50ZXJlc3Qu DQpFdmVuIGJldHRlciwgaWYgeW91J3JlIHdpbGxpbmcgdG8gcmVhZCAvIGNvbW1lbnQgLyByZXZp ZXcgLyBpbXBsZW1lbnQNCg0KR3VpZGVsaW5lcyBmb3IgQWRkaW5nIENvbmdlc3Rpb24gTm90aWZp Y2F0aW9uIHRvIFByb3RvY29scyB0aGF0IEVuY2Fwc3VsYXRlIElQIDxodHRwOi8vdG9vbHMuaWV0 Zi5vcmcvaHRtbC9kcmFmdC1icmlzY29lLXRzdndnLWVjbi1lbmNhcC1ndWlkZWxpbmVzPg0KDQpB YnN0cmFjdA0KDQogICAgVGhlIHB1cnBvc2Ugb2YgdGhpcyBkb2N1bWVudCBpcyB0byBndWlkZSB0 aGUgZGVzaWduIG9mIGNvbmdlc3Rpb24NCiAgICBub3RpZmljYXRpb24gaW4gYW55IGxvd2VyIGxh eWVyIG9yIHR1bm5lbGxpbmcgcHJvdG9jb2wgdGhhdA0KICAgIGVuY2Fwc3VsYXRlcyBJUC4gIFRo ZSBhaW0gaXMgZm9yIGV4cGxpY2l0IGNvbmdlc3Rpb24gc2lnbmFscyB0bw0KICAgIHByb3BhZ2F0 ZSBjb25zaXN0ZW50bHkgZnJvbSBsb3dlciBsYXllciBwcm90b2NvbHMgaW50byBJUC4gIFRoZW4g dGhlDQogICAgSVAgaW50ZXJuZXR3b3JrIGxheWVyIGNhbiBhY3QgYXMgYSBwb3J0YWJpbGl0eSBs YXllciB0byBjYXJyeQ0KICAgIGNvbmdlc3Rpb24gbm90aWZpY2F0aW9uIGZyb20gbm9uLUlQLWF3 YXJlIGNvbmdlc3RlZCBub2RlcyB1cCB0byB0aGUNCiAgICB0cmFuc3BvcnQgbGF5ZXIgKEw0KS4g IEZvbGxvd2luZyB0aGVzZSBndWlkZWxpbmVzIHNob3VsZCBhc3N1cmUNCiAgICBpbnRlcndvcmtp bmcgYmV0d2VlbiBuZXcgbG93ZXIgbGF5ZXIgY29uZ2VzdGlvbiBub3RpZmljYXRpb24NCiAgICBt ZWNoYW5pc21zLCB3aGV0aGVyIHNwZWNpZmllZCBieSB0aGUgSUVURiBvciBvdGhlciBzdGFuZGFy ZHMgYm9kaWVzLg0KDQoNCltDcm9zcy1wb3N0aW5nIHRzdndnICYgYXFtLCBqdXN0IGluIGNhc2Vd DQoNCg0KQm9iIEJyaXNjb2UsDQphbHNvIGZvciBjby1hdXRob3JzIFBhdCBUaGFsZXIgYW5kIEpv aG4gS2FpcHBhbGxpbWFsaWwNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpCb2IgQnJpc2NvZSwgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEJUIA0KDQpfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KYXFtIG1haWxpbmcgbGlzdA0KYXFt QGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2FxbQ0K From p.ohanlon@gmail.com Tue Nov 5 01:42:38 2013 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 659C411E8173; Tue, 5 Nov 2013 01:42:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.569 X-Spam-Level: X-Spam-Status: No, score=-2.569 tagged_above=-999 required=5 tests=[AWL=0.030, 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 cWh9oWBB6Lck; Tue, 5 Nov 2013 01:42:37 -0800 (PST) Received: from mail-we0-x22c.google.com (mail-we0-x22c.google.com [IPv6:2a00:1450:400c:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id CB4A711E80FC; Tue, 5 Nov 2013 01:42:36 -0800 (PST) Received: by mail-we0-f172.google.com with SMTP id q58so3178044wes.17 for ; Tue, 05 Nov 2013 01:42:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=0pJKqr3cnG25z/G+GY90KwNzIg5EyP2cLdmbbJDC2sw=; b=rENxcGDPlCcZv/wn9NNEk0YmPzvHiUJz9mvfV2b10nhdlhjo02+s0aU9lOX+KgeS2t ooV7irdfPbUrd4l4iwkGDzLa/9QQFOlvsELSeS8xWkzyln1S3XJu9HKIQ5RZNCDNpN86 8p6MpS/sX6zWDSJcuecSo7atxsizMAKWnR8NnI+YuqOSEos3Ollx9AZMVkYlQOP1i8kt T3kqd1zt9Vh2nbsCgGqcHVeehSBmDq0gXO2B156zz7zhi42IA3XJWNnlde1rGcTlgpSb AyBV2Pru6U3XfVgyhOMO6C2kvvAlh9b7cyvJQimDWl+ViyFCwgQJJEqd4xPkpShPh6SV tVqA== X-Received: by 10.180.39.34 with SMTP id m2mr16179787wik.26.1383644555208; Tue, 05 Nov 2013 01:42:35 -0800 (PST) Received: from black.lan ([149.241.129.101]) by mx.google.com with ESMTPSA id b7sm12452434wiz.8.2013.11.05.01.42.32 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 05 Nov 2013 01:42:34 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Piers O'Hanlon In-Reply-To: <201311042203.rA4M3lo0026458@bagheera.jungle.bt.co.uk> Date: Tue, 5 Nov 2013 09:42:31 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <8677FF97-849C-40A6-AE71-AE7ED18570E0@gmail.com> References: <201311042203.rA4M3lo0026458@bagheera.jungle.bt.co.uk> To: Bob Briscoe X-Mailer: Apple Mail (2.1283) Cc: draft-briscoe-tsvwg-ecn-encap-guidelines@tools.ietf.org, tsvwg IETF list , AQM IETF list Subject: Re: [tsvwg] Who supports tsvwg adoption of adding ECN to L2 or tunnel protocols? 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, 05 Nov 2013 09:42:38 -0000 Hi Bob, I took a brief look at the draft and it's clearly useful work. One thing that could do with clarification in the Introduction is that = ECN - by itself - doesn't necessarily lead to low loss and delay - it = should be made clear that it reflects the marking approach of the = underlying scheme/AQM. Piers On 4 Nov 2013, at 22:03, Bob Briscoe wrote: > Folks, >=20 > Pls respond if you support this being adopted as a work-group item in = the IETF transport services w-g (tsvwg). The WG chairs need visibility = of interest. > Even better, if you're willing to read / comment / review / implement >=20 > Guidelines for Adding Congestion Notification to Protocols that = Encapsulate IP > >=20 > Abstract >=20 > The purpose of this document is to guide the design of congestion > notification in any lower layer or tunnelling protocol that > encapsulates IP. The aim is for explicit congestion signals to > propagate consistently from lower layer protocols into IP. Then the > IP internetwork layer can act as a portability layer to carry > congestion notification from non-IP-aware congested nodes up to the > transport layer (L4). Following these guidelines should assure > interworking between new lower layer congestion notification > mechanisms, whether specified by the IETF or other standards bodies. >=20 >=20 > [Cross-posting tsvwg & aqm, just in case] >=20 >=20 > Bob Briscoe, > also for co-authors Pat Thaler and John Kaippallimalil >=20 >=20 > ________________________________________________________________ > Bob Briscoe, BT=20 From Dirk.Kutscher@neclab.eu Tue Nov 5 01:50:39 2013 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 0FFC111E81A5; Tue, 5 Nov 2013 01:50:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.2 X-Spam-Level: X-Spam-Status: No, score=-3.2 tagged_above=-999 required=5 tests=[AWL=0.400, BAYES_00=-2.599, 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 F9WpsJYx1RJS; Tue, 5 Nov 2013 01:50:25 -0800 (PST) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 1CD1711E8186; Tue, 5 Nov 2013 01:50:21 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 43768105F1A; Tue, 5 Nov 2013 10:44:14 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AA3b28iFxMZx; Tue, 5 Nov 2013 10:44:14 +0100 (CET) Received: from METHONE.office.hd (methone.office.hd [192.168.24.54]) by mailer1.neclab.eu (Postfix) with ESMTP id 27E19105F17; Tue, 5 Nov 2013 10:43:49 +0100 (CET) Received: from PALLENE.office.hd ([169.254.1.11]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.01.0323.003; Tue, 5 Nov 2013 10:49:34 +0100 From: Dirk Kutscher To: Piers O'Hanlon , Bob Briscoe Thread-Topic: [tsvwg] Who supports tsvwg adoption of adding ECN to L2 or tunnel protocols? Thread-Index: AQHO2gtteH36tQ1iVEKiOjJC7yWNSZoWYy5w Date: Tue, 5 Nov 2013 09:49:34 +0000 Message-ID: <82AB329A76E2484D934BBCA77E9F52496383930E@PALLENE.office.hd> References: <201311042203.rA4M3lo0026458@bagheera.jungle.bt.co.uk> <8677FF97-849C-40A6-AE71-AE7ED18570E0@gmail.com> In-Reply-To: <8677FF97-849C-40A6-AE71-AE7ED18570E0@gmail.com> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.99.203] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "draft-briscoe-tsvwg-ecn-encap-guidelines@tools.ietf.org" , tsvwg IETF list , AQM IETF list Subject: Re: [tsvwg] Who supports tsvwg adoption of adding ECN to L2 or tunnel protocols? 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, 05 Nov 2013 09:50:39 -0000 Hi, As earlier indicated, I'd like to see this document being adopted as a tsvw= g work item. I'd be happy to help with reviewing. Best regards, Dirk > -----Original Message----- > From: tsvwg-bounces@ietf.org [mailto:tsvwg-bounces@ietf.org] On Behalf > Of Piers O'Hanlon > Sent: Dienstag, 5. November 2013 10:43 > To: Bob Briscoe > Cc: draft-briscoe-tsvwg-ecn-encap-guidelines@tools.ietf.org; tsvwg IETF l= ist; > AQM IETF list > Subject: Re: [tsvwg] Who supports tsvwg adoption of adding ECN to L2 or > tunnel protocols? >=20 > Hi Bob, >=20 > I took a brief look at the draft and it's clearly useful work. >=20 > One thing that could do with clarification in the Introduction is that EC= N - by > itself - doesn't necessarily lead to low loss and delay - it should be ma= de clear > that it reflects the marking approach of the underlying scheme/AQM. >=20 > Piers >=20 > On 4 Nov 2013, at 22:03, Bob Briscoe wrote: >=20 > > Folks, > > > > Pls respond if you support this being adopted as a work-group item in t= he > IETF transport services w-g (tsvwg). The WG chairs need visibility of int= erest. > > Even better, if you're willing to read / comment / review / implement > > > > Guidelines for Adding Congestion Notification to Protocols that > > Encapsulate IP > > > > > > Abstract > > > > The purpose of this document is to guide the design of congestion > > notification in any lower layer or tunnelling protocol that > > encapsulates IP. The aim is for explicit congestion signals to > > propagate consistently from lower layer protocols into IP. Then the > > IP internetwork layer can act as a portability layer to carry > > congestion notification from non-IP-aware congested nodes up to the > > transport layer (L4). Following these guidelines should assure > > interworking between new lower layer congestion notification > > mechanisms, whether specified by the IETF or other standards bodies. > > > > > > [Cross-posting tsvwg & aqm, just in case] > > > > > > Bob Briscoe, > > also for co-authors Pat Thaler and John Kaippallimalil > > > > > > > __________________________________________________________ > ______ > > Bob Briscoe, BT From philip.eardley@bt.com Tue Nov 5 10:32:48 2013 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 85A9F11E81FD; Tue, 5 Nov 2013 10:32:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.936 X-Spam-Level: X-Spam-Status: No, score=-102.936 tagged_above=-999 required=5 tests=[AWL=-0.165, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_72=0.6, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_OBFU_Q1=0.227, 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 8xi-l2I7hLbw; Tue, 5 Nov 2013 10:32:44 -0800 (PST) Received: from smtpe1.intersmtp.com (smtp63.intersmtp.com [62.239.224.236]) by ietfa.amsl.com (Postfix) with ESMTP id 9471C21E809E; Tue, 5 Nov 2013 10:32:39 -0800 (PST) Received: from EVMHT65-UKRD.domain1.systemhost.net (10.36.3.102) by RDW083A007ED63.smtp-e3.hygiene.service (10.187.98.12) with Microsoft SMTP Server (TLS) id 8.3.298.1; Tue, 5 Nov 2013 18:32:37 +0000 Received: from EMV67-UKRD.domain1.systemhost.net ([169.254.2.147]) by EVMHT65-UKRD.domain1.systemhost.net ([10.36.3.102]) with mapi; Tue, 5 Nov 2013 18:32:37 +0000 From: To: , , Date: Tue, 5 Nov 2013 18:32:22 +0000 Thread-Topic: [tsvwg] [aqm] Who supports tsvwg adoption of adding ECN to L2 or tunnel protocols? Thread-Index: AQHO2bPschNRr0CscEy8XBGE9jPQ05oVzbZAgAEpnkM= Message-ID: References: <201311042203.rA4M3lo0026458@bagheera.jungle.bt.co.uk> , <012C3117EDDB3C4781FD802A8C27DD4F25E65C8E@SACEXCMBX02-PRD.hq.netapp.com> In-Reply-To: <012C3117EDDB3C4781FD802A8C27DD4F25E65C8E@SACEXCMBX02-PRD.hq.netapp.com> Accept-Language: en-US, en-GB Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: multipart/alternative; boundary="_000_A2E337CDB7BC4145B018B9BEE8EB3E0D3FFA6F97EDEMV67UKRDdoma_" MIME-Version: 1.0 Cc: draft-briscoe-tsvwg-ecn-encap-guidelines@tools.ietf.org, tsvwg@ietf.org, aqm@ietf.org Subject: Re: [tsvwg] [aqm] Who supports tsvwg adoption of adding ECN to L2 or tunnel protocols? 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, 05 Nov 2013 18:32:48 -0000 --_000_A2E337CDB7BC4145B018B9BEE8EB3E0D3FFA6F97EDEMV67UKRDdoma_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable agree with these comments best wishes phil ________________________________ From: tsvwg-bounces@ietf.org [tsvwg-bounces@ietf.org] On Behalf Of Scheffen= egger, Richard [rs@netapp.com] Sent: 05 November 2013 00:48 To: Matt Mathis; Briscoe,RJ,Bob,TUB8 R Cc: draft-briscoe-tsvwg-ecn-encap-guidelines@tools.ietf.org; tsvwg IETF lis= t; AQM IETF list Subject: Re: [tsvwg] [aqm] Who supports tsvwg adoption of adding ECN to L2 = or tunnel protocols? (aqm chair hat off) I can fully support what Matt just stated! I have read an earlier version (-01 iirc), I=92ll try to scan over this ver= sion in the coming days. Richard Scheffenegger From: aqm-bounces@ietf.org [mailto:aqm-bounces@ietf.org] On Behalf Of Matt = Mathis Sent: Montag, 04. November 2013 15:17 To: Bob Briscoe Cc: draft-briscoe-tsvwg-ecn-encap-guidelines@tools.ietf.org; tsvwg IETF lis= t; AQM IETF list Subject: Re: [aqm] Who supports tsvwg adoption of adding ECN to L2 or tunne= l protocols? I think this is valuable work. Having a single document that describes the= requirements and general principles will save future tunnel inventor/imple= menters from rediscovering the same bugs Thanks, --MM-- The best way to predict the future is to create it. - Alan Kay Privacy matters! We know from recent events that people are using our serv= ices to speak in defiance of unjust governments. We treat privacy and sec= urity as matters of life and death, because for some users, they are. On Mon, Nov 4, 2013 at 2:03 PM, Bob Briscoe > wrote: Folks, Pls respond if you support this being adopted as a work-group item in the I= ETF transport services w-g (tsvwg). The WG chairs need visibility of intere= st. Even better, if you're willing to read / comment / review / implement Guidelines for Adding Congestion Notification to Protocols that Encapsulate= IP Abstract The purpose of this document is to guide the design of congestion notification in any lower layer or tunnelling protocol that encapsulates IP. The aim is for explicit congestion signals to propagate consistently from lower layer protocols into IP. Then the IP internetwork layer can act as a portability layer to carry congestion notification from non-IP-aware congested nodes up to the transport layer (L4). Following these guidelines should assure interworking between new lower layer congestion notification mechanisms, whether specified by the IETF or other standards bodies. [Cross-posting tsvwg & aqm, just in case] Bob Briscoe, also for co-authors Pat Thaler and John Kaippallimalil ________________________________________________________________ Bob Briscoe, BT _______________________________________________ aqm mailing list aqm@ietf.org https://www.ietf.org/mailman/listinfo/aqm --_000_A2E337CDB7BC4145B018B9BEE8EB3E0D3FFA6F97EDEMV67UKRDdoma_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
agree with these comments
best wishes
phil
=  
From: tsvwg-bounc= es@ietf.org [tsvwg-bounces@ietf.org] On Behalf Of Scheffenegger, Richard [r= s@netapp.com]
Sent: 05 November 2013 00:48
To: Matt Mathis; Briscoe,RJ,Bob,TUB8 R
Cc: draft-briscoe-tsvwg-ecn-encap-guidelines@tools.ietf.org; tsvwg I= ETF list; AQM IETF list
Subject: Re: [tsvwg] [aqm] Who supports tsvwg adoption of adding ECN= to L2 or tunnel protocols?

(aqm chair hat off)<= /p>

 

I can fully support what Ma= tt just stated!

 

I have read an earlier vers= ion (-01 iirc), I=92ll try to scan over this version in the coming days.

 

 

Richard Scheffenegger

 

From: aqm-bounces@ietf= .org [mailto:aqm-bounces@ietf.org] On Behalf Of Matt Mathis
Sent: Montag, 04. November 2013 15:17
To: Bob Briscoe
Cc: draft-briscoe-tsvwg-ecn-encap-guidelines@tools.ietf.org; tsvwg I= ETF list; AQM IETF list
Subject: Re: [aqm] Who supports tsvwg adoption of adding ECN to L2 o= r tunnel protocols?

 

I think this is valuable work.  Having a single= document that describes the requirements and general principles will save = future tunnel inventor/implementers from rediscovering the same bugs


Thanks,

--MM--
The best way to predict the future is to create it.  - Alan Kay

Privacy matters!  We know from recent events that people are using our= services to speak in defiance of unjust governments.   We treat priva= cy and security as matters of life and death, because for some users, they = are.

 

On Mon, Nov 4, 2013 at 2:03 PM, Bob Briscoe <bob.briscoe@bt.com> wrote:

Folks,

Pls respond if you support this being adopted as a work-group item in the I= ETF transport services w-g (tsvwg). The WG chairs need visibility of intere= st.
Even better, if you're willing to read / comment / review / implement

Guidelines for Adding Congestion Notification to Protocols that Encapsulate= IP
<http://tools.ietf.org/html/draft-briscoe-tsvwg-e= cn-encap-guidelines>

Abstract

   The purpose of this document is to guide the design of congest= ion
   notification in any lower layer or tunnelling protocol that    encapsulates IP.  The aim is for explicit congestion sign= als to
   propagate consistently from lower layer protocols into IP. &nb= sp;Then the
   IP internetwork layer can act as a portability layer to carry<= br>    congestion notification from non-IP-aware congested nodes up t= o the
   transport layer (L4).  Following these guidelines should = assure
   interworking between new lower layer congestion notification    mechanisms, whether specified by the IETF or other standards b= odies.


[Cross-posting tsvwg & aqm, just in case]


Bob Briscoe,
also for co-authors Pat Thaler and John Kaippallimalil


________________________________________________________________
Bob Briscoe,                  =                     &nbs= p;          BT
_______________________________________________
aqm mailing list
aqm@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/aqm

 

--_000_A2E337CDB7BC4145B018B9BEE8EB3E0D3FFA6F97EDEMV67UKRDdoma_-- From bob.briscoe@bt.com Tue Nov 5 10:41:50 2013 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 C8F2311E81CB; Tue, 5 Nov 2013 10:41:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.285 X-Spam-Level: X-Spam-Status: No, score=-3.285 tagged_above=-999 required=5 tests=[AWL=0.087, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_OBFU_Q1=0.227] 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 GXIYLV-8kJ7f; Tue, 5 Nov 2013 10:41:43 -0800 (PST) Received: from hubrelay-rd.bt.com (hubrelay-rd.bt.com [62.239.224.99]) by ietfa.amsl.com (Postfix) with ESMTP id 3F1FC11E81EB; Tue, 5 Nov 2013 10:41:39 -0800 (PST) Received: from EVMHR72-UKRD.domain1.systemhost.net (10.36.3.110) by EVMHR67-UKRD.bt.com (10.187.101.22) with Microsoft SMTP Server (TLS) id 8.3.297.1; Tue, 5 Nov 2013 18:41:34 +0000 Received: from EPHR02-UKIP.domain1.systemhost.net (147.149.100.81) by EVMHR72-UKRD.domain1.systemhost.net (10.36.3.110) with Microsoft SMTP Server (TLS) id 8.3.279.1; Tue, 5 Nov 2013 18:41:34 +0000 Received: from bagheera.jungle.bt.co.uk (132.146.168.158) by EPHR02-UKIP.domain1.systemhost.net (147.149.100.81) with Microsoft SMTP Server id 14.2.347.0; Tue, 5 Nov 2013 18:41:33 +0000 Received: from BTP075694.jungle.bt.co.uk ([10.109.124.253]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id rA5IfUeP030224; Tue, 5 Nov 2013 18:41:31 GMT Message-ID: <201311051841.rA5IfUeP030224@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 5 Nov 2013 18:41:30 +0000 To: Piers O'Hanlon From: Bob Briscoe In-Reply-To: <8677FF97-849C-40A6-AE71-AE7ED18570E0@gmail.com> References: <201311042203.rA4M3lo0026458@bagheera.jungle.bt.co.uk> <8677FF97-849C-40A6-AE71-AE7ED18570E0@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 Cc: draft-briscoe-tsvwg-ecn-encap-guidelines@tools.ietf.org, tsvwg IETF list , AQM IETF list Subject: Re: [tsvwg] [aqm] Who supports tsvwg adoption of adding ECN to L2 or tunnel protocols? 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, 05 Nov 2013 18:41:50 -0000 Piers, I tried to state exactly how ECN can benefit (2nd para of intro below), rather than make overblown claims. You seem to be saying I didn't succeed? I can't see how to do any better. Suggestions? /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ ECN removes nearly all congestion loss and it cuts delays for two main reasons: i) it avoids the delay when recovering from congestion losses, which particularly benefits small flows, making their completion time predictably short [RFC2884] and ii) as ECN is used more widely by end-systems, it will gradually remove the need to configure a degree of delay into buffers before they start to notify congestion (the cause of bufferbloat). The latter delay is because drop involves a trade-off between sending a timely signal and trying to avoid impairment, whereas ECN is solely a signal not an impairment, so there is no harm triggering it earlier. /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ PS. Thx for supporting words. Bob At 09:42 05/11/2013, Piers O'Hanlon wrote: >Hi Bob, > >I took a brief look at the draft and it's clearly useful work. > >One thing that could do with clarification in the Introduction is >that ECN - by itself - doesn't necessarily lead to low loss and >delay - it should be made clear that it reflects the marking >approach of the underlying scheme/AQM. > >Piers > >On 4 Nov 2013, at 22:03, Bob Briscoe wrote: > > > Folks, > > > > Pls respond if you support this being adopted as a work-group > item in the IETF transport services w-g (tsvwg). The WG chairs need > visibility of interest. > > Even better, if you're willing to read / comment / review / implement > > > > Guidelines for Adding Congestion Notification to Protocols that > Encapsulate IP > > > > > > Abstract > > > > The purpose of this document is to guide the design of congestion > > notification in any lower layer or tunnelling protocol that > > encapsulates IP. The aim is for explicit congestion signals to > > propagate consistently from lower layer protocols into IP. Then the > > IP internetwork layer can act as a portability layer to carry > > congestion notification from non-IP-aware congested nodes up to the > > transport layer (L4). Following these guidelines should assure > > interworking between new lower layer congestion notification > > mechanisms, whether specified by the IETF or other standards bodies. > > > > > > [Cross-posting tsvwg & aqm, just in case] > > > > > > Bob Briscoe, > > also for co-authors Pat Thaler and John Kaippallimalil > > > > > > ________________________________________________________________ > > Bob Briscoe, BT > >_______________________________________________ >aqm mailing list >aqm@ietf.org >https://www.ietf.org/mailman/listinfo/aqm ________________________________________________________________ Bob Briscoe, BT From bob.briscoe@bt.com Tue Nov 5 10:59:31 2013 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 AE83111E81DE; Tue, 5 Nov 2013 10:59:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.288 X-Spam-Level: X-Spam-Status: No, score=-3.288 tagged_above=-999 required=5 tests=[AWL=0.084, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_OBFU_Q1=0.227] 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 DTQa1v0+7xqr; Tue, 5 Nov 2013 10:59:26 -0800 (PST) Received: from hubrelay-by-03.bt.com (hubrelay-by-03.bt.com [62.7.242.139]) by ietfa.amsl.com (Postfix) with ESMTP id B6B3021E811A; Tue, 5 Nov 2013 10:59:25 -0800 (PST) Received: from EVMHR02-UKBR.domain1.systemhost.net (193.113.108.41) by EVMHR03-UKBR.bt.com (10.216.161.35) with Microsoft SMTP Server (TLS) id 8.3.327.1; Tue, 5 Nov 2013 18:59:20 +0000 Received: from EPHR01-UKIP.domain1.systemhost.net (147.149.196.177) by EVMHR02-UKBR.domain1.systemhost.net (193.113.108.41) with Microsoft SMTP Server (TLS) id 8.3.297.1; Tue, 5 Nov 2013 18:59:23 +0000 Received: from bagheera.jungle.bt.co.uk (132.146.168.158) by EPHR01-UKIP.domain1.systemhost.net (147.149.196.177) with Microsoft SMTP Server id 14.2.347.0; Tue, 5 Nov 2013 18:59:21 +0000 Received: from BTP075694.jungle.bt.co.uk ([10.109.124.253]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id rA5IxJvZ030310; Tue, 5 Nov 2013 18:59:20 GMT Message-ID: <201311051859.rA5IxJvZ030310@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 5 Nov 2013 18:59:18 +0000 To: Joe Touch From: Bob Briscoe In-Reply-To: <52793B87.4040102@isi.edu> References: <201311042203.rA4M3lo0026458@bagheera.jungle.bt.co.uk> <52789FF5.3030907@uni-tuebingen.de> <52793B87.4040102@isi.edu> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 Cc: aqm@ietf.org, tsvwg IETF list Subject: Re: [tsvwg] [aqm] Who supports tsvwg adoption of adding ECN to L2 or tunnel protocols? 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, 05 Nov 2013 18:59:31 -0000 Joe, I envisage that a very brief standards track doc that explicitly UPDATES the relevant IETF tunnel specs will be written, and it will refer to this doc for rationale. See Appendix A (outstanding items), which I have also highlighted when presenting each time: 2. Consider whether an IETF Standard Track doc will be needed to Update the IP-in-IP protocols listed in Section 4.1--at least those that the IETF controls--and which Area it should sit under. Does that address your concern? Bob At 18:40 05/11/2013, Joe Touch wrote: >IMO, these guidelines ought to come out in a single recommendation >for tunnels; we had a draft of that in INTAREA but insufficient momentum. > >Piecemeal recommendations are likely to be ignored/lost. > >Joe > >On 11/4/2013 11:36 PM, Michael Menth wrote: >>+1 >> >>We need such guidelines for consistent congestion management. >> >>Best wishes, >> >>Michael >> >>Am 05.11.2013 00:16, schrieb Matt Mathis: >>>I think this is valuable work. Having a single document that >>>describes the requirements and general principles will save future >>>tunnel inventor/implementers from rediscovering the same bugs >>> >>>Thanks, >>>--MM-- >>>The best way to predict the future is to create it. - Alan Kay >>> >>>Privacy matters! We know from recent events that people are using our >>>services to speak in defiance of unjust governments. We treat >>>privacy and security as matters of life and death, because for some >>>users, they are. >>> >>> >>>On Mon, Nov 4, 2013 at 2:03 PM, Bob Briscoe >>> wrote: >>> >>> Folks, >>> >>> Pls respond if you support this being adopted as a work-group item >>> in the IETF transport services w-g (tsvwg). The WG chairs need >>> visibility of interest. >>> Even better, if you're willing to read / comment / review / implement >>> >>> Guidelines for Adding Congestion Notification to Protocols that >>> Encapsulate IP >>> >>> >>> Abstract >>> >>> The purpose of this document is to guide the design of congestion >>> notification in any lower layer or tunnelling protocol that >>> encapsulates IP. The aim is for explicit congestion signals to >>> propagate consistently from lower layer protocols into IP. >>> Then the >>> IP internetwork layer can act as a portability layer to carry >>> congestion notification from non-IP-aware congested nodes up to the >>> transport layer (L4). Following these guidelines should assure >>> interworking between new lower layer congestion notification >>> mechanisms, whether specified by the IETF or other standards >>> bodies. >>> >>> >>> [Cross-posting tsvwg & aqm, just in case] >>> >>> >>> Bob Briscoe, >>> also for co-authors Pat Thaler and John Kaippallimalil >>> >>> >>> ________________________________________________________________ >>> Bob Briscoe, BT >>> _______________________________________________ >>> aqm mailing list >>> aqm@ietf.org >>> https://www.ietf.org/mailman/listinfo/aqm >>> >>> >>> >>> >>>_______________________________________________ >>>aqm mailing list >>>aqm@ietf.org >>>https://www.ietf.org/mailman/listinfo/aqm >> >>-- >>Prof. Dr. habil. Michael Menth >>University of Tuebingen >>Faculty of Science >>Department of Computer Science >>Chair of Communication Networks >>Sand 13, 72076 Tuebingen, Germany >>phone: (+49)-7071/29-70505 >>fax: (+49)-7071/29-5220 >>mailto:menth@uni-tuebingen.de >>http://kn.inf.uni-tuebingen.de >> >> >> >>_______________________________________________ >>aqm mailing list >>aqm@ietf.org >>https://www.ietf.org/mailman/listinfo/aqm >_______________________________________________ >aqm mailing list >aqm@ietf.org >https://www.ietf.org/mailman/listinfo/aqm ________________________________________________________________ Bob Briscoe, BT From suresh.krishnan@ericsson.com Tue Nov 5 11:23:08 2013 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 677C421E8096; Tue, 5 Nov 2013 11:23:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.35 X-Spam-Level: X-Spam-Status: No, score=-102.35 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227, 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 VAYL2mrUL3o9; Tue, 5 Nov 2013 11:23:03 -0800 (PST) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id 441D611E8159; Tue, 5 Nov 2013 11:22:18 -0800 (PST) X-AuditID: c618062d-b7fd88e00000439f-b2-527945683726 Received: from EUSAAHC006.ericsson.se (Unknown_Domain [147.117.188.90]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id A4.85.17311.86549725; Tue, 5 Nov 2013 20:22:16 +0100 (CET) Received: from EUSAAMB108.ericsson.se ([147.117.188.125]) by EUSAAHC006.ericsson.se ([147.117.188.90]) with mapi id 14.02.0328.009; Tue, 5 Nov 2013 14:22:16 -0500 From: Suresh Krishnan To: Bob Briscoe , Joe Touch Thread-Topic: [tsvwg] [aqm] Who supports tsvwg adoption of adding ECN to L2 or tunnel protocols? Thread-Index: AQHO2lkgxGg9YUDRb0SNPOHwSlpU15oXAb0A Date: Tue, 5 Nov 2013 19:22:15 +0000 Message-ID: References: <201311042203.rA4M3lo0026458@bagheera.jungle.bt.co.uk> <52789FF5.3030907@uni-tuebingen.de> <52793B87.4040102@isi.edu> <201311051859.rA5IxJvZ030310@bagheera.jungle.bt.co.uk> In-Reply-To: <201311051859.rA5IxJvZ030310@bagheera.jungle.bt.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.134] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrLLMWRmVeSWpSXmKPExsUyuXRPlG6Ga2WQQVujjcWafZIW09d/YbRY 92cui8WxN3fZHFg82r5MZvJYsuQnk8fu91tZApijuGxSUnMyy1KL9O0SuDLOd25iLpilUbGl /xdbA+Na+S5GTg4JAROJky+OsUPYYhIX7q1n62Lk4hASOMIoce/kYWYIZxmjxKZPL8Gq2IA6 Nuz8zARiiwjYS5ze8oMFxGYWcJa4/mMlWI2wQKLEgXNfWCBqkiR+b77JDGEbSWx8/BnMZhFQ kThwfgZYDa+Ar8Tmxf2MEMuamSQaJn4AS3ACDd24fy/YMkag876fWsMEsUxc4taT+UwQZwtI LNlznhnCFpV4+fgfK4StLLHkyX6o43QkFuz+xAZha0ssW/iaGWKxoMTJmU9YJjCKzUIydhaS lllIWmYhaVnAyLKKkaO0OLUsN93IYBMjMIqOSbDp7mDc89LyEKM0B4uSOO+Xt85BQgLpiSWp 2ampBalF8UWlOanFhxiZODilGhi162Na7v38vcHJtn96+MWV1QcSHnlG9mxyPaPyzvLhndbY V1PkBe9zJSdtFSteLvxfTDtFaL6qQkKeo+Ae7iv3lpVJTrFmEu+76c3xZp7nuX0ajh87E0UC nr7dfO6y4vVQw5/lCl1+/4oCvm0QFos4dOfu6w/eqYvanaYcvbjm5pwPh8xqTwYqsRRnJBpq MRcVJwIAnY6z+3ACAAA= Cc: "aqm@ietf.org" , tsvwg IETF list Subject: Re: [tsvwg] [aqm] Who supports tsvwg adoption of adding ECN to L2 or tunnel protocols? 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, 05 Nov 2013 19:23:08 -0000 I do support this work going forward. I do understand Joe's position/desire= and while it would be preferable to have a comprehensive document, I thin= k draft-briscoe is useful by itself. FYI, Joe's draft can be found here http://tools.ietf.org/html/draft-ietf-intarea-tunnels-00 Thanks Suresh =20 > -----Original Message----- > From: tsvwg-bounces@ietf.org [mailto:tsvwg-bounces@ietf.org] On Behalf > Of Bob Briscoe > Sent: November-05-13 1:59 PM > To: Joe Touch > Cc: aqm@ietf.org; tsvwg IETF list > Subject: Re: [tsvwg] [aqm] Who supports tsvwg adoption of adding ECN to L= 2 > or tunnel protocols? >=20 > Joe, >=20 > I envisage that a very brief standards track doc that explicitly UPDATES = the > relevant IETF tunnel specs will be written, and it will refer to this doc= for > rationale. >=20 > See Appendix A (outstanding items), which I have also highlighted when > presenting each time: >=20 > 2. Consider whether an IETF Standard Track doc will be needed to > Update the IP-in-IP protocols listed in Section 4.1--at least > those that the IETF controls--and which Area it should sit under. >=20 > Does that address your concern? >=20 >=20 > Bob >=20 > At 18:40 05/11/2013, Joe Touch wrote: > >IMO, these guidelines ought to come out in a single recommendation for > >tunnels; we had a draft of that in INTAREA but insufficient momentum. > > > >Piecemeal recommendations are likely to be ignored/lost. > > > >Joe > > > >On 11/4/2013 11:36 PM, Michael Menth wrote: > >>+1 > >> > >>We need such guidelines for consistent congestion management. > >> > >>Best wishes, > >> > >>Michael > >> > >>Am 05.11.2013 00:16, schrieb Matt Mathis: > >>>I think this is valuable work. Having a single document that > >>>describes the requirements and general principles will save future > >>>tunnel inventor/implementers from rediscovering the same bugs > >>> > >>>Thanks, > >>>--MM-- > >>>The best way to predict the future is to create it. - Alan Kay > >>> > >>>Privacy matters! We know from recent events that people are using our > >>>services to speak in defiance of unjust governments. We treat > >>>privacy and security as matters of life and death, because for some > >>>users, they are. > >>> > >>> > >>>On Mon, Nov 4, 2013 at 2:03 PM, Bob Briscoe >>>> wrote: > >>> > >>> Folks, > >>> > >>> Pls respond if you support this being adopted as a work-group ite= m > >>> in the IETF transport services w-g (tsvwg). The WG chairs need > >>> visibility of interest. > >>> Even better, if you're willing to read / comment / review / > >>> implement > >>> > >>> Guidelines for Adding Congestion Notification to Protocols that > >>> Encapsulate IP > >>> > >>> >>> > > >>> > >>> Abstract > >>> > >>> The purpose of this document is to guide the design of congest= ion > >>> notification in any lower layer or tunnelling protocol that > >>> encapsulates IP. The aim is for explicit congestion signals t= o > >>> propagate consistently from lower layer protocols into IP. > >>> Then the > >>> IP internetwork layer can act as a portability layer to carry > >>> congestion notification from non-IP-aware congested nodes up t= o > the > >>> transport layer (L4). Following these guidelines should assur= e > >>> interworking between new lower layer congestion notification > >>> mechanisms, whether specified by the IETF or other standards > >>> bodies. > >>> > >>> > >>> [Cross-posting tsvwg & aqm, just in case] > >>> > >>> > >>> Bob Briscoe, > >>> also for co-authors Pat Thaler and John Kaippallimalil > >>> > >>> > >>> > __________________________________________________________ > ______ > >>> Bob Briscoe, BT > >>> _______________________________________________ > >>> aqm mailing list > >>> aqm@ietf.org > >>> https://www.ietf.org/mailman/listinfo/aqm > >>> > >>> > >>> > >>> > >>>_______________________________________________ > >>>aqm mailing list > >>>aqm@ietf.org > >>>https://www.ietf.org/mailman/listinfo/aqm > >> > >>-- > >>Prof. Dr. habil. Michael Menth > >>University of Tuebingen > >>Faculty of Science > >>Department of Computer Science > >>Chair of Communication Networks > >>Sand 13, 72076 Tuebingen, Germany > >>phone: (+49)-7071/29-70505 > >>fax: (+49)-7071/29-5220 > >>mailto:menth@uni-tuebingen.de > >>http://kn.inf.uni-tuebingen.de > >> > >> > >> > >>_______________________________________________ > >>aqm mailing list > >>aqm@ietf.org > >>https://www.ietf.org/mailman/listinfo/aqm > >_______________________________________________ > >aqm mailing list > >aqm@ietf.org > >https://www.ietf.org/mailman/listinfo/aqm >=20 > __________________________________________________________ > ______ > Bob Briscoe, BT From touch@isi.edu Tue Nov 5 12:49:06 2013 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 7195D21E8093; Tue, 5 Nov 2013 12:49:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.177 X-Spam-Level: X-Spam-Status: No, score=-103.177 tagged_above=-999 required=5 tests=[AWL=-0.805, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227, 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 QYquuis4mhyN; Tue, 5 Nov 2013 12:49:02 -0800 (PST) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id 3390811E8175; Tue, 5 Nov 2013 12:49:02 -0800 (PST) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id rA5KmDEp021494 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 5 Nov 2013 12:48:14 -0800 (PST) Message-ID: <52795A03.9010804@isi.edu> Date: Tue, 05 Nov 2013 12:50:11 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Bob Briscoe References: <201311042203.rA4M3lo0026458@bagheera.jungle.bt.co.uk> <52789FF5.3030907@uni-tuebingen.de> <52793B87.4040102@isi.edu> <201311051859.rA5IxJvZ030310@bagheera.jungle.bt.co.uk> In-Reply-To: <201311051859.rA5IxJvZ030310@bagheera.jungle.bt.co.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: aqm@ietf.org, tsvwg IETF list Subject: Re: [tsvwg] [aqm] Who supports tsvwg adoption of adding ECN to L2 or tunnel protocols? 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, 05 Nov 2013 20:49:06 -0000 On 11/5/2013 10:59 AM, Bob Briscoe wrote: > Joe, > > I envisage that a very brief standards track doc that explicitly UPDATES > the relevant IETF tunnel specs will be written, and it will refer to > this doc for rationale. Tunnels need to handle ingress/egress translation of all signals in the header. This is no different. My concern is that putting these recommendations in separate places gives an opportunity for different groups to have different interpretations of that sort of translation, and that's a bad thing IMO. Joe > > See Appendix A (outstanding items), which I have also highlighted when > presenting each time: > > 2. Consider whether an IETF Standard Track doc will be needed to > Update the IP-in-IP protocols listed in Section 4.1--at least > those that the IETF controls--and which Area it should sit under. > > Does that address your concern? > > > Bob > > At 18:40 05/11/2013, Joe Touch wrote: >> IMO, these guidelines ought to come out in a single recommendation for >> tunnels; we had a draft of that in INTAREA but insufficient momentum. >> >> Piecemeal recommendations are likely to be ignored/lost. >> >> Joe >> >> On 11/4/2013 11:36 PM, Michael Menth wrote: >>> +1 >>> >>> We need such guidelines for consistent congestion management. >>> >>> Best wishes, >>> >>> Michael >>> >>> Am 05.11.2013 00:16, schrieb Matt Mathis: >>>> I think this is valuable work. Having a single document that >>>> describes the requirements and general principles will save future >>>> tunnel inventor/implementers from rediscovering the same bugs >>>> >>>> Thanks, >>>> --MM-- >>>> The best way to predict the future is to create it. - Alan Kay >>>> >>>> Privacy matters! We know from recent events that people are using our >>>> services to speak in defiance of unjust governments. We treat >>>> privacy and security as matters of life and death, because for some >>>> users, they are. >>>> >>>> >>>> On Mon, Nov 4, 2013 at 2:03 PM, Bob Briscoe >>> > wrote: >>>> >>>> Folks, >>>> >>>> Pls respond if you support this being adopted as a work-group item >>>> in the IETF transport services w-g (tsvwg). The WG chairs need >>>> visibility of interest. >>>> Even better, if you're willing to read / comment / review / >>>> implement >>>> >>>> Guidelines for Adding Congestion Notification to Protocols that >>>> Encapsulate IP >>>> >>>> >>>> >>>> Abstract >>>> >>>> The purpose of this document is to guide the design of >>>> congestion >>>> notification in any lower layer or tunnelling protocol that >>>> encapsulates IP. The aim is for explicit congestion signals to >>>> propagate consistently from lower layer protocols into IP. >>>> Then the >>>> IP internetwork layer can act as a portability layer to carry >>>> congestion notification from non-IP-aware congested nodes up >>>> to the >>>> transport layer (L4). Following these guidelines should assure >>>> interworking between new lower layer congestion notification >>>> mechanisms, whether specified by the IETF or other standards >>>> bodies. >>>> >>>> >>>> [Cross-posting tsvwg & aqm, just in case] >>>> >>>> >>>> Bob Briscoe, >>>> also for co-authors Pat Thaler and John Kaippallimalil >>>> >>>> >>>> ________________________________________________________________ >>>> Bob Briscoe, BT >>>> _______________________________________________ >>>> aqm mailing list >>>> aqm@ietf.org >>>> https://www.ietf.org/mailman/listinfo/aqm >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> aqm mailing list >>>> aqm@ietf.org >>>> https://www.ietf.org/mailman/listinfo/aqm >>> >>> -- >>> Prof. Dr. habil. Michael Menth >>> University of Tuebingen >>> Faculty of Science >>> Department of Computer Science >>> Chair of Communication Networks >>> Sand 13, 72076 Tuebingen, Germany >>> phone: (+49)-7071/29-70505 >>> fax: (+49)-7071/29-5220 >>> mailto:menth@uni-tuebingen.de >>> http://kn.inf.uni-tuebingen.de >>> >>> >>> >>> _______________________________________________ >>> aqm mailing list >>> aqm@ietf.org >>> https://www.ietf.org/mailman/listinfo/aqm >> _______________________________________________ >> aqm mailing list >> aqm@ietf.org >> https://www.ietf.org/mailman/listinfo/aqm > > ________________________________________________________________ > Bob Briscoe, BT From andrewmcgr@google.com Tue Nov 5 14:59:53 2013 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 CE1A221E80BD for ; Tue, 5 Nov 2013 14:59:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.39 X-Spam-Level: X-Spam-Status: No, score=-1.39 tagged_above=-999 required=5 tests=[AWL=0.360, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, SARE_SUB_OBFU_Q1=0.227] 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 Yi5D7YaXvs2V for ; Tue, 5 Nov 2013 14:59:53 -0800 (PST) Received: from mail-qa0-x231.google.com (mail-qa0-x231.google.com [IPv6:2607:f8b0:400d:c00::231]) by ietfa.amsl.com (Postfix) with ESMTP id 80B0A21E80D8 for ; Tue, 5 Nov 2013 14:59:52 -0800 (PST) Received: by mail-qa0-f49.google.com with SMTP id cm18so1501698qab.15 for ; Tue, 05 Nov 2013 14:59:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Lf/5G9teQxJ988SAafneSc1NNFqkvD0m7fJmlBGuul0=; b=fowY2i8ff1U6odbN0fhgy08Ln3NP4i+OCl2yRDiCKOykD0YAZWe3lsiJIdOvEjD2gb trHgDkqJa8nCJZHK4KOI3BDkMPVcTZRRLlwT67KOhocCaIQuw/ZaIPmFQlw7ZmYL/zEF UCk7iSyiLx7Dsy1M3ECrrKnNKYo1A/dhk0JNfYC8G9mRqroS/vdmWWcSrjhulUA3cH6r sjm2hVcPcehkCDJ/uyNZHQ9/OmjY1L00/+MZlHOjGbn66HMoJfyPrEBeau2DBvQ4PR6H vbO+Uu2WdsLEUM2KAaFzXwT3710S+wkSCWD/mmj50ROaeMyNO913U7R2reyZ9Ur1jjU+ qlVQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Lf/5G9teQxJ988SAafneSc1NNFqkvD0m7fJmlBGuul0=; b=RKM7aHZ4BKyq9ZchdqgyhUI5F8nUnIO6BA1NXPnMDu9uf7+nW0Q1RVq2RugdxzbW8c vl6CCUAHFE+PGRaDMpawGcPDH9Ih93HioyPlfMKVs/CqmFSDeRKWcI2tSQEVxoM2eKcM 0kFXVIHYiSHw2yVNOSKqAhSV9rxpDuSqTU73qtKMOA0I61MHpGYAqtGeVYhnv8d/iHC5 x12yDaOsP6nHuGC5lkAW4mcrMRnTuEe690remYi7fwJRkXagp/owmDI1gkVi1iUn2bKn jZzmvW2jEWITAEz6v1tUN5IQuTQfyoLby4DxxjMvZu+YK1mYTfTS3aYox35ItEAYlTiL SLpQ== X-Gm-Message-State: ALoCoQlewL2Ej7BAe1d3BmKGYV9cBirXp2sU0NVLi9VD/5MyyiAVAotoD/d7oCFGM3b0oFg9JnypH2TsSndO4O1WxOOljt3Ftw5ljeMsUsTrZ3u9D9/VrCLeh74yB5Rmu2jCvcsPCrPGAQMr1queWWqEDPSACHru2zy4ZZXhXNcSyoLjHoIAdd7s/qIDrVqyJKXXoqJjNdgG MIME-Version: 1.0 X-Received: by 10.224.11.7 with SMTP id r7mr1227819qar.91.1383692391960; Tue, 05 Nov 2013 14:59:51 -0800 (PST) Received: by 10.224.197.198 with HTTP; Tue, 5 Nov 2013 14:59:51 -0800 (PST) In-Reply-To: <201311050000.rA500RMV027031@bagheera.jungle.bt.co.uk> References: <201311042203.rA4M3lo0026458@bagheera.jungle.bt.co.uk> <201311050000.rA500RMV027031@bagheera.jungle.bt.co.uk> Date: Wed, 6 Nov 2013 09:59:51 +1100 Message-ID: From: Andrew Mcgregor To: Bob Briscoe Content-Type: multipart/alternative; boundary=001a11c2c12680725d04ea75fd14 Cc: draft-briscoe-tsvwg-ecn-encap-guidelines@tools.ietf.org, tsvwg IETF list , AQM IETF list Subject: Re: [tsvwg] [aqm] Who supports tsvwg adoption of adding ECN to L2 or tunnel protocols? 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, 05 Nov 2013 22:59:53 -0000 --001a11c2c12680725d04ea75fd14 Content-Type: text/plain; charset=ISO-8859-1 That's about what I thought the answer would be... but it's worth having that in the record :-) On 5 November 2013 11:00, Bob Briscoe wrote: > Andrew, > > Thx for supporting words and offer of help. > > > At 23:04 04/11/2013, Andrew Mcgregor wrote: > > This seems like valuable work. One question is, can we put in scope > notification that losses are NOT due to congestion? > > > Eyooow. That really does not belong in this scope. > > This is about the interface between lower layers and the ECN field in the > IP header. We can't really talk about new semantics in lower layers that > aren't even defined in ECN at the IP layer. > > Naively, one could imagine some text treating the ECN field as 4 opaque > codepoints, and propagating a similar 4 opaque codepoints from each lower > layer protocol. Then if something new were defined in IP-ECN like a > non-congestive loss codepoint, it could also be defined in lower layers... > > But that's naive, because each lower layer has it's own constraints and > ways of handling concepts like "ECN-capable transport", none of which > easily translates to a simple mapping of codepoints. > > Explicit signalling of non-congestive loss is a research problem, > because... > * Clearly a link cannot signal that a loss was not due to congestion using > the lost frame itself (there aren't any bits :) > * So the link would have to signal in another frame that didn't get > corrupted. > - That frame may go to another process that didn't see any loss; then > what does the process do? > - or the link has to use DPI to signal only in frames going to the same > process as the lost frame. > - that means the link has to understand all transport protocols > > There's other hard problems > * A transmission loss doesn't always mean there is no congestion loss > * At my last count, there were at least nine different reasons for packet > loss. If we had 4 bits spare in each lost packet... :) > > > > Bob > > > > Willing to comment and review, at least. > > > On 5 November 2013 09:03, Bob Briscoe wrote: > Folks, > > Pls respond if you support this being adopted as a work-group item in the > IETF transport services w-g (tsvwg). The WG chairs need visibility of > interest. > Even better, if you're willing to read / comment / review / implement > > Guidelines for Adding Congestion Notification to Protocols that > Encapsulate IP > < http://tools.ietf.org/html/draft-briscoe-tsvwg-ecn-encap-guidelines > > > Abstract > > The purpose of this document is to guide the design of congestion > notification in any lower layer or tunnelling protocol that > encapsulates IP. The aim is for explicit congestion signals to > propagate consistently from lower layer protocols into IP. Then the > IP internetwork layer can act as a portability layer to carry > congestion notification from non-IP-aware congested nodes up to the > transport layer (L4). Following these guidelines should assure > interworking between new lower layer congestion notification > mechanisms, whether specified by the IETF or other standards bodies. > > > [Cross-posting tsvwg & aqm, just in case] > > > Bob Briscoe, > also for co-authors Pat Thaler and John Kaippallimalil > > > ________________________________________________________________ > Bob Briscoe, BT > _______________________________________________ > aqm mailing list > aqm@ietf.org > https://www.ietf.org/mailman/listinfo/aqm > > > > > -- > Andrew McGregor | SRE | andrewmcgr@google.com | +61 4 8143 7128 > _______________________________________________ > aqm mailing list > aqm@ietf.org > https://www.ietf.org/mailman/listinfo/aqm > > ________________________________________________________________ > Bob Briscoe, BT > -- Andrew McGregor | SRE | andrewmcgr@google.com | +61 4 8143 7128 --001a11c2c12680725d04ea75fd14 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
That's about what I thought the answer would be... but= it's worth having that in the record :-)


On 5 November 2013 11:00, Bob Briscoe= <bob.briscoe@bt.com> wrote:
Andrew,

Thx for supporting words and offer of help.


At 23:04 04/11/2013, Andrew Mcgregor wrote:
This seems like valuable work.=A0 One question is, can we put in scope notification that losses are NOT due to congestion?

Eyooow. That really does not belong in this scope.

This is about the interface between lower layers and the ECN field in the IP header. We can't really talk about new semantics in lower layers tha= t aren't even defined in ECN at the IP layer.

Naively, one could imagine some text treating the ECN field as 4 opaque codepoints, and propagating=A0 a similar 4 opaque codepoints from each lower layer protocol. Then if something new were defined in IP-ECN like a non-congestive loss codepoint, it could also be defined in lower layers...

But that's naive, because each lower layer has it's own constraints= and ways of handling concepts like "ECN-capable transport", none of which easily translates to a simple mapping of codepoints.

Explicit signalling of non-congestive loss is a research problem, because...
* Clearly a link cannot signal that a loss was not due to congestion using the lost frame itself (there aren't any bits :)
* So the link would have to signal in another frame that didn't get corrupted.
=A0 - That frame may go to another process that didn't see any loss; then what does the process do?
=A0 - or the link has to use DPI to signal only in frames going to the same process as the lost frame.
=A0 - that means the link has to understand all transport protocols

There's other hard problems
* A transmission loss doesn't always mean there is no congestion loss
* At my last count, there were at least nine different reasons for packet loss. If we had 4 bits spare in each lost packet... :)



Bob



Willing to comment and review, at least.


On 5 November 2013 09:03, Bob Briscoe <bob.briscoe@bt.= com> wrote:
Folks,

Pls respond if you support this being adopted as a work-group item= in the IETF transport services w-g (tsvwg). The WG chairs need visibility of interest.
Even better, if you're willing to read / comment / review / implement

Guidelines for Adding Congestion Notification to Protocols that Encapsulate IP
< http://tools.ietf.org/html/draft-briscoe-tsvwg-ecn-encap-guidelines >

Abstract

=A0=A0 The purpose of this document is to guide the design of congestion
=A0=A0 notification in any lower layer or tunnelling protocol that
=A0=A0 encapsulates IP.=A0 The aim is for explicit congestion signals to
=A0=A0 propagate consistently from lower layer protocols into IP.=A0 Then the
=A0=A0 IP internetwork layer can act as a portability layer to carry
=A0=A0 congestion notification from non-IP-aware congested nodes up to the
=A0=A0 transport layer (L4).=A0 Following these guidelines should assure
=A0=A0 interworking between new lower layer congestion notification
=A0=A0 mechanisms, whether specified by the IETF or other standards bodies.


[Cross-posting tsvwg & aqm, just in case]


Bob Briscoe,
also for co-authors Pat Thaler and John Kaippallimalil


________________________________________________________________
Bob Briscoe,=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0 BT
_______________________________________________
aqm mailing list
aqm@ietf.org=
https://www.ietf.org/mailman/listinfo/aqm




--
Andrew McGregor | SRE | andrewmcgr@googl= e.com | +61 4 8143 7128
_______________________________________________
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm

________________________________________________________________
Bob Briscoe,=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0 BT




--
Andrew McGregor=A0|=A0SRE=A0|=A0andrewmcgr@google.com=A0|=A0+61 4 8143 7128
--001a11c2c12680725d04ea75fd14-- From bob.briscoe@bt.com Tue Nov 5 16:07:04 2013 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 8BDA411E8169 for ; Tue, 5 Nov 2013 16:07:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.395 X-Spam-Level: X-Spam-Status: No, score=-3.395 tagged_above=-999 required=5 tests=[AWL=0.204, BAYES_00=-2.599, 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 nuDFvYa9WqCl for ; Tue, 5 Nov 2013 16:06:58 -0800 (PST) Received: from hubrelay-rd.bt.com (hubrelay-rd.bt.com [62.239.224.99]) by ietfa.amsl.com (Postfix) with ESMTP id D7BA511E811A for ; Tue, 5 Nov 2013 16:06:57 -0800 (PST) Received: from EVMHR72-UKRD.domain1.systemhost.net (10.36.3.110) by EVMHR67-UKRD.bt.com (10.187.101.22) with Microsoft SMTP Server (TLS) id 8.3.297.1; Wed, 6 Nov 2013 00:06:56 +0000 Received: from EPHR02-UKIP.domain1.systemhost.net (147.149.100.81) by EVMHR72-UKRD.domain1.systemhost.net (10.36.3.110) with Microsoft SMTP Server (TLS) id 8.3.279.1; Wed, 6 Nov 2013 00:06:55 +0000 Received: from bagheera.jungle.bt.co.uk (132.146.168.158) by EPHR02-UKIP.domain1.systemhost.net (147.149.100.81) with Microsoft SMTP Server id 14.2.347.0; Wed, 6 Nov 2013 00:06:54 +0000 Received: from BTP075694.jungle.bt.co.uk ([10.109.231.97]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id rA606qbT031059; Wed, 6 Nov 2013 00:06:53 GMT Message-ID: <201311060006.rA606qbT031059@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 6 Nov 2013 00:06:50 +0000 To: Fred Baker From: Bob Briscoe MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 Cc: tsvwg IETF list Subject: [tsvwg] draft-briscoe-ecn-encap-guidelines: (im)mutable glitch 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, 06 Nov 2013 00:07:04 -0000 Fred, I checked the security considerations text, and it says mutable. Only my slide said immutable. Bob ________________________________________________________________ Bob Briscoe, BT From wwwrun@rfc-editor.org Tue Nov 5 17:33:39 2013 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 2BBEB21E81B2; Tue, 5 Nov 2013 17:33:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.133 X-Spam-Level: X-Spam-Status: No, score=-102.133 tagged_above=-999 required=5 tests=[AWL=-0.133, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, NO_RELAYS=-0.001, 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 Pmd69oBtw-zT; Tue, 5 Nov 2013 17:33:38 -0800 (PST) Received: from rfc-editor.org (unknown [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 98A5A21E81B1; Tue, 5 Nov 2013 17:33:30 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 2E1B375E001; Tue, 5 Nov 2013 17:24:05 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20131106012405.2E1B375E001@rfc-editor.org> Date: Tue, 5 Nov 2013 17:24:05 -0800 (PST) Cc: drafts-update-ref@iana.org, tsvwg@ietf.org, rfc-editor@rfc-editor.org Subject: [tsvwg] RFC 7053 on SACK-IMMEDIATELY Extension for the Stream Control Transmission Protocol 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, 06 Nov 2013 01:33:39 -0000 A new Request for Comments is now available in online RFC libraries. RFC 7053 Title: SACK-IMMEDIATELY Extension for the Stream Control Transmission Protocol Author: M. Tuexen, I. Ruengeler, R. Stewart Status: Standards Track Stream: IETF Date: November 2013 Mailbox: tuexen@fh-muenster.de, i.ruengeler@fh-muenster.de, randall@lakerest.net Pages: 8 Characters: 15773 Updates: RFC4960 I-D Tag: draft-ietf-tsvwg-sctp-sack-immediately-04.txt URL: http://www.rfc-editor.org/rfc/rfc7053.txt This document updates RFC 4960 by defining a method for the sender of a DATA chunk to indicate that the corresponding Selective Acknowledgment (SACK) chunk should be sent back immediately and should not be delayed. It is done by specifying a bit in the DATA chunk header, called the (I)mmediate bit, which can get set by either the Stream Control Transmission Protocol (SCTP) implementation or the application using an SCTP stack. Since unknown flags in chunk headers are ignored by SCTP implementations, this extension does not introduce any interoperability problems. This document is a product of the Transport Area Working Group Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/search/rfc_search.php For downloading RFCs, see http://www.rfc-editor.org/rfc.html Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From wwwrun@rfc-editor.org Wed Nov 6 08:09:13 2013 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 BCBBE11E8132 for ; Wed, 6 Nov 2013 08:09:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.442 X-Spam-Level: X-Spam-Status: No, score=-102.442 tagged_above=-999 required=5 tests=[AWL=0.158, BAYES_00=-2.599, NO_RELAYS=-0.001, 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 Zh6UVHRlAKOn for ; Wed, 6 Nov 2013 08:09:12 -0800 (PST) Received: from rfc-editor.org (unknown [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id DCB0111E80EC for ; Wed, 6 Nov 2013 08:09:12 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 306FB72E001; Wed, 6 Nov 2013 07:59:40 -0800 (PST) To: randall@lakerest.net, spencerdawkins.ietf@gmail.com, mls.ietf@gmail.com, gorry@erg.abdn.ac.uk, david.black@emc.com, jmpolk@cisco.com From: RFC Errata System Message-Id: <20131106155940.306FB72E001@rfc-editor.org> Date: Wed, 6 Nov 2013 07:59:40 -0800 (PST) Cc: karen.nielsen@tieto.com, tsvwg@ietf.org, rfc-editor@rfc-editor.org Subject: [tsvwg] [Technical Errata Reported] RFC4960 (3788) 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, 06 Nov 2013 16:09:13 -0000 The following errata report has been submitted for RFC4960, "Stream Control Transmission Protocol". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=4960&eid=3788 -------------------------------------- Type: Technical Reported by: Karen Nielsen Section: 8.1 Original Text ------------- An endpoint shall keep a counter on the total number of consecutive retransmissions to its peer (this includes retransmissions to all the destination transport addresses of the peer if it is multi-homed), including unacknowledged HEARTBEAT chunks. Corrected Text -------------- An endpoint shall keep a counter on the total number of consecutive retransmissions to its peer (this includes data retransmissions to all the destination transport addresses of the peer if it is multi-homed),including the number of unacknowledged HEARTBEAT chunks observed on the path which currently is used for data transfer. Unacknowledged HEARTBEAT chunks observed on paths different from the path currently used for data transfer shall not increment the association error counter, as this could lead to association closure even if the path which currently is used for data transfer is available (but idle). Notes ----- RFC4960 Endpoint Failure detection mechanism is deficient in that HB failures on some failing paths may take the association down, even if other paths are working perfectly, but simply at the time no data or HBs are being sent on the working paths. The situation occurs when the association is idle (no data is being transmitted) and the HBI settings on the failing paths are much more aggressive than the HBI set on the working paths. RFC6458 allows for specification of the HBI on a per destination address whereby such in-homogeneous setting of the HBI can occur. The solution proposed to the issue is to demand that HB failures observed on paths different from the path currently used for data transfer do not contribute to the association error counter. HB failures observed on the path currently used for data transfer, when this path is idle, shall contribute to the association error counter. Thereby supporting Endpoint Failure detection when the association is idle. When the association is transmitting data, the fate of the data transmissions and retransmissions will serve to instantiate Endpoint Failure detection. Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC4960 (draft-ietf-tsvwg-2960bis-05) -------------------------------------- Title : Stream Control Transmission Protocol Publication Date : September 2007 Author(s) : R. Stewart, Ed. Category : PROPOSED STANDARD Source : Transport Area Working Group Area : Transport Stream : IETF Verifying Party : IESG From jmpolk@cisco.com Wed Nov 6 13:56:24 2013 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 9C58821E814D for ; Wed, 6 Nov 2013 13:56:23 -0800 (PST) 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=[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 Y8J9NSTrDuLo for ; Wed, 6 Nov 2013 13:56:11 -0800 (PST) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 1287321E809E for ; Wed, 6 Nov 2013 13:56:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=255; q=dns/txt; s=iport; t=1383774970; x=1384984570; h=message-id:date:to:from:subject:mime-version; bh=AHoPpyr1E6Roe5Zemd1gPXKs6x2lO6LaIUrBOUMqFbI=; b=W0JGSB/iWUkA4P1R1SZaOETTd/tqozZrBKosp5CYIar5CziyKWZ/lCTH AGEplm6/QEM8lH4gH/xQDWxbHAznWYkOsOa49PfeBTKbd6fwZ3lHKOLzm Dg+yJNevx9YagUllZmqzV7m5H+lhrhsdbLNkg53i2GhjQkXsIRkXEiNsH Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgsFABO6elKrRDoI/2dsb2JhbABbgwfBXhZ0gmQCViUVHwqIV51eoUePdoQaA4lAoFaDRR0 X-IronPort-AV: E=Sophos;i="4.93,647,1378857600"; d="scan'208";a="93517778" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-1.cisco.com with ESMTP; 06 Nov 2013 21:56:10 +0000 Received: from jmpolk-WS.cisco.com (sjc-vpn5-1071.cisco.com [10.21.92.47]) (authenticated bits=0) by mtv-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id rA6Lu2l3007644 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 6 Nov 2013 21:56:08 GMT Message-Id: <201311062156.rA6Lu2l3007644@mtv-core-3.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 06 Nov 2013 15:56:02 -0600 To: tsvwg@ietf.org From: James Polk Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Authenticated-User: jmpolk Subject: [tsvwg] TSVWG meeting note taker - volunteers please! 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, 06 Nov 2013 21:56:24 -0000 TSVWG The chairs are looking for volunteers to take notes during our WG meeting on Friday at 0900-1100. Please contact me if you want, or feel some responsibility, to perform this task. Thank you (in advance) James/David/Gorry TSVWG chairs From randall@lakerest.net Wed Nov 6 14:30:41 2013 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 B77A121E80BE for ; Wed, 6 Nov 2013 14:30:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.98 X-Spam-Level: X-Spam-Status: No, score=-1.98 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_SORBS_WEB=0.619] 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 QRs1RhqjD6t8 for ; Wed, 6 Nov 2013 14:30:35 -0800 (PST) Received: from lakerest.net (lakerest.net [162.235.35.161]) by ietfa.amsl.com (Postfix) with ESMTP id BDFDA11E814D for ; Wed, 6 Nov 2013 14:30:22 -0800 (PST) Received: from [10.20.199.102] ([204.239.250.1]) (authenticated bits=0) by lakerest.net (8.14.4/8.14.3) with ESMTP id rA6MUBZI088693 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Wed, 6 Nov 2013 17:30:13 -0500 (EST) (envelope-from randall@lakerest.net) From: Randy Stewart Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 6 Nov 2013 14:29:50 -0800 Message-Id: <421B5DF5-A872-4EDC-8735-EEBF189052ED@lakerest.net> To: tsvwg list Mime-Version: 1.0 (Apple Message framework v1283) X-Mailer: Apple Mail (2.1283) Subject: [tsvwg] Review of draft-multicast-udp_guidelines 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, 06 Nov 2013 22:30:41 -0000 All I agreed to give a review of this document at tsvwg yesterday, so while = I await my plane to SFO here goes: Abstract: What is pont-to-point ? 2.1 " When the multicast traffic exits the administrative domain of a single network or the bi-laterally agreed path between networks, or is tunneled across the unicast Internet either to another multicast network or to an end device, the application SHOULD provide a = TCPcompatible aggregate flow over the end-to-end path to each leaf. " Thats a *lot* for one sentence, maybe you could pare this down a bit and get rid of the case list, you already state the scope earlier and I don't think you need to illustrate it every time. 2.1.4 You might also note that some providers always drop fragments not just NAT's and F/W's IANA Considerations Probably you should not leave the boiler plate here. Security considerations Again, bolier plate but worse no other words. ***************************************************** Now my overall opinion is that this document is rather rough yet; It is = hard to read due to sentences (like the one illustrated above) that run on and on and = probably should be re-written to be a bit more easy to understand. Especially if = this is to be general advice to application writers which it seems it is. Best regards R ----- Randall Stewart randall@lakerest.net From bob.briscoe@bt.com Wed Nov 6 14:50:51 2013 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 840AE21E811F; Wed, 6 Nov 2013 14:50:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.288 X-Spam-Level: X-Spam-Status: No, score=-3.288 tagged_above=-999 required=5 tests=[AWL=0.084, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_OBFU_Q1=0.227] 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 g2ExicdKjX-g; Wed, 6 Nov 2013 14:50:46 -0800 (PST) Received: from hubrelay-rd.bt.com (hubrelay-rd.bt.com [62.239.224.99]) by ietfa.amsl.com (Postfix) with ESMTP id 47B1321E809E; Wed, 6 Nov 2013 14:50:28 -0800 (PST) Received: from EVMHR72-UKRD.domain1.systemhost.net (10.36.3.110) by EVMHR68-UKRD.bt.com (10.187.101.23) with Microsoft SMTP Server (TLS) id 8.3.279.1; Wed, 6 Nov 2013 22:50:20 +0000 Received: from EPHR02-UKIP.domain1.systemhost.net (147.149.100.81) by EVMHR72-UKRD.domain1.systemhost.net (10.36.3.110) with Microsoft SMTP Server (TLS) id 8.3.279.1; Wed, 6 Nov 2013 22:50:20 +0000 Received: from bagheera.jungle.bt.co.uk (132.146.168.158) by EPHR02-UKIP.domain1.systemhost.net (147.149.100.81) with Microsoft SMTP Server id 14.2.347.0; Wed, 6 Nov 2013 22:50:19 +0000 Received: from BTP075694.jungle.bt.co.uk ([10.111.16.29]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id rA6MoGY0003371; Wed, 6 Nov 2013 22:50:17 GMT Message-ID: <201311062250.rA6MoGY0003371@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 6 Nov 2013 22:50:14 +0000 To: Joe Touch From: Bob Briscoe In-Reply-To: <52795A03.9010804@isi.edu> References: <201311042203.rA4M3lo0026458@bagheera.jungle.bt.co.uk> <52789FF5.3030907@uni-tuebingen.de> <52793B87.4040102@isi.edu> <201311051859.rA5IxJvZ030310@bagheera.jungle.bt.co.uk> <52795A03.9010804@isi.edu> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 Cc: aqm@ietf.org, tsvwg IETF list Subject: Re: [tsvwg] [aqm] Who supports tsvwg adoption of adding ECN to L2 or tunnel protocols? 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, 06 Nov 2013 22:50:51 -0000 Joe, The approach of a BCP just about ECN doesn't preclude any of the following options for stds track docs: a) one RFC updating all tunnel specs about ECN b) one RFC updating all tunnel specs about ECN and Diffserv (the two fields that propagate up as well as down). c) one RFC updating all tunnel specs about everything d) one RFC per each tunnel spec to wrap up all updates around at the time These choices are for the relevant ADs and WGs to make. Writing a BCP in TSV gives the raw info that any of these approaches can use. Bob At 20:50 05/11/2013, Joe Touch wrote: >On 11/5/2013 10:59 AM, Bob Briscoe wrote: >>Joe, >> >>I envisage that a very brief standards track doc that explicitly UPDATES >>the relevant IETF tunnel specs will be written, and it will refer to >>this doc for rationale. > >Tunnels need to handle ingress/egress translation of all signals in >the header. This is no different. > >My concern is that putting these recommendations in separate places >gives an opportunity for different groups to have different >interpretations of that sort of translation, and that's a bad thing IMO. > >Joe > > >> >>See Appendix A (outstanding items), which I have also highlighted when >>presenting each time: >> >> 2. Consider whether an IETF Standard Track doc will be needed to >> Update the IP-in-IP protocols listed in Section 4.1--at least >> those that the IETF controls--and which Area it should sit under. >> >>Does that address your concern? >> >> >>Bob >> >>At 18:40 05/11/2013, Joe Touch wrote: >>>IMO, these guidelines ought to come out in a single recommendation for >>>tunnels; we had a draft of that in INTAREA but insufficient momentum. >>> >>>Piecemeal recommendations are likely to be ignored/lost. >>> >>>Joe >>> >>>On 11/4/2013 11:36 PM, Michael Menth wrote: >>>>+1 >>>> >>>>We need such guidelines for consistent congestion management. >>>> >>>>Best wishes, >>>> >>>>Michael >>>> >>>>Am 05.11.2013 00:16, schrieb Matt Mathis: >>>>>I think this is valuable work. Having a single document that >>>>>describes the requirements and general principles will save future >>>>>tunnel inventor/implementers from rediscovering the same bugs >>>>> >>>>>Thanks, >>>>>--MM-- >>>>>The best way to predict the future is to create it. - Alan Kay >>>>> >>>>>Privacy matters! We know from recent events that people are using our >>>>>services to speak in defiance of unjust governments. We treat >>>>>privacy and security as matters of life and death, because for some >>>>>users, they are. >>>>> >>>>> >>>>>On Mon, Nov 4, 2013 at 2:03 PM, Bob Briscoe >>>>> wrote: >>>>> >>>>> Folks, >>>>> >>>>> Pls respond if you support this being adopted as a work-group item >>>>> in the IETF transport services w-g (tsvwg). The WG chairs need >>>>> visibility of interest. >>>>> Even better, if you're willing to read / comment / review / >>>>>implement >>>>> >>>>> Guidelines for Adding Congestion Notification to Protocols that >>>>> Encapsulate IP >>>>> >>>>> >>>>> >>>>> Abstract >>>>> >>>>> The purpose of this document is to guide the design of >>>>>congestion >>>>> notification in any lower layer or tunnelling protocol that >>>>> encapsulates IP. The aim is for explicit congestion signals to >>>>> propagate consistently from lower layer protocols into IP. >>>>> Then the >>>>> IP internetwork layer can act as a portability layer to carry >>>>> congestion notification from non-IP-aware congested nodes up >>>>>to the >>>>> transport layer (L4). Following these guidelines should assure >>>>> interworking between new lower layer congestion notification >>>>> mechanisms, whether specified by the IETF or other standards >>>>> bodies. >>>>> >>>>> >>>>> [Cross-posting tsvwg & aqm, just in case] >>>>> >>>>> >>>>> Bob Briscoe, >>>>> also for co-authors Pat Thaler and John Kaippallimalil >>>>> >>>>> >>>>> ________________________________________________________________ >>>>> Bob Briscoe, BT >>>>> _______________________________________________ >>>>> aqm mailing list >>>>> aqm@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/aqm >>>>> >>>>> >>>>> >>>>> >>>>>_______________________________________________ >>>>>aqm mailing list >>>>>aqm@ietf.org >>>>>https://www.ietf.org/mailman/listinfo/aqm >>>> >>>>-- >>>>Prof. Dr. habil. Michael Menth >>>>University of Tuebingen >>>>Faculty of Science >>>>Department of Computer Science >>>>Chair of Communication Networks >>>>Sand 13, 72076 Tuebingen, Germany >>>>phone: (+49)-7071/29-70505 >>>>fax: (+49)-7071/29-5220 >>>>mailto:menth@uni-tuebingen.de >>>>http://kn.inf.uni-tuebingen.de >>>> >>>> >>>> >>>>_______________________________________________ >>>>aqm mailing list >>>>aqm@ietf.org >>>>https://www.ietf.org/mailman/listinfo/aqm >>>_______________________________________________ >>>aqm mailing list >>>aqm@ietf.org >>>https://www.ietf.org/mailman/listinfo/aqm >> >>________________________________________________________________ >>Bob Briscoe, BT >_______________________________________________ >aqm mailing list >aqm@ietf.org >https://www.ietf.org/mailman/listinfo/aqm ________________________________________________________________ Bob Briscoe, BT From touch@isi.edu Wed Nov 6 15:00:51 2013 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 5BAE911E8156; Wed, 6 Nov 2013 15:00:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.157 X-Spam-Level: X-Spam-Status: No, score=-103.157 tagged_above=-999 required=5 tests=[AWL=-0.785, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227, 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 L6bzKPZG1XIX; Wed, 6 Nov 2013 15:00:33 -0800 (PST) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id 32F2411E8190; Wed, 6 Nov 2013 15:00:05 -0800 (PST) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id rA6MxdN0027097 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 6 Nov 2013 14:59:39 -0800 (PST) Message-ID: <527ACA56.8010902@isi.edu> Date: Wed, 06 Nov 2013 15:01:42 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Bob Briscoe References: <201311042203.rA4M3lo0026458@bagheera.jungle.bt.co.uk> <52789FF5.3030907@uni-tuebingen.de> <52793B87.4040102@isi.edu> <201311051859.rA5IxJvZ030310@bagheera.jungle.bt.co.uk> <52795A03.9010804@isi.edu> <201311062250.rA6MoGY0003371@bagheera.jungle.bt.co.uk> In-Reply-To: <201311062250.rA6MoGY0003371@bagheera.jungle.bt.co.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: aqm@ietf.org, tsvwg IETF list Subject: Re: [tsvwg] [aqm] Who supports tsvwg adoption of adding ECN to L2 or tunnel protocols? 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, 06 Nov 2013 23:00:51 -0000 Hi, Bob, IMO, the desciption of how IP header info (which is what I presume you're suggesting) to impact L2s (which include tunnels) belongs in a tunnel doc, which AFAICT belongs in INTAREA. The tunnel landscape is already quite complex. I have no idea why TSV would be involved in this except if you're talking about TCP ECH markings, but IMO the relationship of the TCP mark to the IP mark might belong in TSV. However, I do not think TSV should be promoting having signals "jump" layers, i.e., from TCP ECN to its impact on tunnels or L2. Joe On 11/6/2013 2:50 PM, Bob Briscoe wrote: > Joe, > > The approach of a BCP just about ECN doesn't preclude any of the > following options for stds track docs: > a) one RFC updating all tunnel specs about ECN > b) one RFC updating all tunnel specs about ECN and Diffserv (the two > fields that propagate up as well as down). > c) one RFC updating all tunnel specs about everything > d) one RFC per each tunnel spec to wrap up all updates around at the time > > These choices are for the relevant ADs and WGs to make. > Writing a BCP in TSV gives the raw info that any of these approaches can > use. > > > > Bob > > At 20:50 05/11/2013, Joe Touch wrote: > > >> On 11/5/2013 10:59 AM, Bob Briscoe wrote: >>> Joe, >>> >>> I envisage that a very brief standards track doc that explicitly UPDATES >>> the relevant IETF tunnel specs will be written, and it will refer to >>> this doc for rationale. >> >> Tunnels need to handle ingress/egress translation of all signals in >> the header. This is no different. >> >> My concern is that putting these recommendations in separate places >> gives an opportunity for different groups to have different >> interpretations of that sort of translation, and that's a bad thing IMO. >> >> Joe >> >> >>> >>> See Appendix A (outstanding items), which I have also highlighted when >>> presenting each time: >>> >>> 2. Consider whether an IETF Standard Track doc will be needed to >>> Update the IP-in-IP protocols listed in Section 4.1--at least >>> those that the IETF controls--and which Area it should sit >>> under. >>> >>> Does that address your concern? >>> >>> >>> Bob >>> >>> At 18:40 05/11/2013, Joe Touch wrote: >>>> IMO, these guidelines ought to come out in a single recommendation for >>>> tunnels; we had a draft of that in INTAREA but insufficient momentum. >>>> >>>> Piecemeal recommendations are likely to be ignored/lost. >>>> >>>> Joe >>>> >>>> On 11/4/2013 11:36 PM, Michael Menth wrote: >>>>> +1 >>>>> >>>>> We need such guidelines for consistent congestion management. >>>>> >>>>> Best wishes, >>>>> >>>>> Michael >>>>> >>>>> Am 05.11.2013 00:16, schrieb Matt Mathis: >>>>>> I think this is valuable work. Having a single document that >>>>>> describes the requirements and general principles will save future >>>>>> tunnel inventor/implementers from rediscovering the same bugs >>>>>> >>>>>> Thanks, >>>>>> --MM-- >>>>>> The best way to predict the future is to create it. - Alan Kay >>>>>> >>>>>> Privacy matters! We know from recent events that people are using >>>>>> our >>>>>> services to speak in defiance of unjust governments. We treat >>>>>> privacy and security as matters of life and death, because for some >>>>>> users, they are. >>>>>> >>>>>> >>>>>> On Mon, Nov 4, 2013 at 2:03 PM, Bob Briscoe >>>>> > wrote: >>>>>> >>>>>> Folks, >>>>>> >>>>>> Pls respond if you support this being adopted as a work-group >>>>>> item >>>>>> in the IETF transport services w-g (tsvwg). The WG chairs need >>>>>> visibility of interest. >>>>>> Even better, if you're willing to read / comment / review / >>>>>> implement >>>>>> >>>>>> Guidelines for Adding Congestion Notification to Protocols that >>>>>> Encapsulate IP >>>>>> >>>>>> >>>>>> >>>>>> Abstract >>>>>> >>>>>> The purpose of this document is to guide the design of >>>>>> congestion >>>>>> notification in any lower layer or tunnelling protocol that >>>>>> encapsulates IP. The aim is for explicit congestion >>>>>> signals to >>>>>> propagate consistently from lower layer protocols into IP. >>>>>> Then the >>>>>> IP internetwork layer can act as a portability layer to carry >>>>>> congestion notification from non-IP-aware congested nodes up >>>>>> to the >>>>>> transport layer (L4). Following these guidelines should >>>>>> assure >>>>>> interworking between new lower layer congestion notification >>>>>> mechanisms, whether specified by the IETF or other standards >>>>>> bodies. >>>>>> >>>>>> >>>>>> [Cross-posting tsvwg & aqm, just in case] >>>>>> >>>>>> >>>>>> Bob Briscoe, >>>>>> also for co-authors Pat Thaler and John Kaippallimalil >>>>>> >>>>>> >>>>>> ________________________________________________________________ >>>>>> Bob Briscoe, BT >>>>>> _______________________________________________ >>>>>> aqm mailing list >>>>>> aqm@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/aqm >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> aqm mailing list >>>>>> aqm@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/aqm >>>>> >>>>> -- >>>>> Prof. Dr. habil. Michael Menth >>>>> University of Tuebingen >>>>> Faculty of Science >>>>> Department of Computer Science >>>>> Chair of Communication Networks >>>>> Sand 13, 72076 Tuebingen, Germany >>>>> phone: (+49)-7071/29-70505 >>>>> fax: (+49)-7071/29-5220 >>>>> mailto:menth@uni-tuebingen.de >>>>> http://kn.inf.uni-tuebingen.de >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> aqm mailing list >>>>> aqm@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/aqm >>>> _______________________________________________ >>>> aqm mailing list >>>> aqm@ietf.org >>>> https://www.ietf.org/mailman/listinfo/aqm >>> >>> ________________________________________________________________ >>> Bob Briscoe, BT >> _______________________________________________ >> aqm mailing list >> aqm@ietf.org >> https://www.ietf.org/mailman/listinfo/aqm > > ________________________________________________________________ > Bob Briscoe, BT From bob.briscoe@bt.com Wed Nov 6 15:38:13 2013 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 4967421E80BD for ; Wed, 6 Nov 2013 15:38:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.79 X-Spam-Level: X-Spam-Status: No, score=-2.79 tagged_above=-999 required=5 tests=[AWL=-0.418, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227] 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 ZQmVUjIK5TYh for ; Wed, 6 Nov 2013 15:37:57 -0800 (PST) Received: from hubrelay-rd.bt.com (hubrelay-rd.bt.com [62.239.224.98]) by ietfa.amsl.com (Postfix) with ESMTP id 5769C11E8193 for ; Wed, 6 Nov 2013 15:37:55 -0800 (PST) Received: from EVMHR72-UKRD.domain1.systemhost.net (10.36.3.110) by EVMHR65-UKRD.bt.com (10.187.101.20) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 6 Nov 2013 23:37:53 +0000 Received: from EPHR02-UKIP.domain1.systemhost.net (147.149.100.81) by EVMHR72-UKRD.domain1.systemhost.net (10.36.3.110) with Microsoft SMTP Server (TLS) id 8.3.279.1; Wed, 6 Nov 2013 23:37:53 +0000 Received: from bagheera.jungle.bt.co.uk (132.146.168.158) by EPHR02-UKIP.domain1.systemhost.net (147.149.100.81) with Microsoft SMTP Server id 14.2.347.0; Wed, 6 Nov 2013 23:37:52 +0000 Received: from BTP075694.jungle.bt.co.uk ([10.111.16.29]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id rA6Nbocn003604; Wed, 6 Nov 2013 23:37:51 GMT Message-ID: <201311062337.rA6Nbocn003604@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 6 Nov 2013 23:37:49 +0000 To: Joe Touch From: Bob Briscoe In-Reply-To: <527ACA56.8010902@isi.edu> References: <201311042203.rA4M3lo0026458@bagheera.jungle.bt.co.uk> <52789FF5.3030907@uni-tuebingen.de> <52793B87.4040102@isi.edu> <201311051859.rA5IxJvZ030310@bagheera.jungle.bt.co.uk> <52795A03.9010804@isi.edu> <201311062250.rA6MoGY0003371@bagheera.jungle.bt.co.uk> <527ACA56.8010902@isi.edu> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 Cc: tsvwg IETF list Subject: Re: [tsvwg] [aqm] Who supports tsvwg adoption of adding ECN to L2 or tunnel protocols? 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, 06 Nov 2013 23:38:13 -0000 Joe, At 23:01 06/11/2013, Joe Touch wrote: >Hi, Bob, > >IMO, the desciption of how IP header info (which is what I presume >you're suggesting) to impact L2s (which include tunnels) belongs in >a tunnel doc, which AFAICT belongs in INTAREA. The tunnel landscape >is already quite complex. > >I have no idea why TSV would be involved in this except if you're >talking about TCP ECH markings, but IMO the relationship of the TCP >mark to the IP mark might belong in TSV. > >However, I do not think TSV should be promoting having signals >"jump" layers, i.e., from TCP ECN to its impact on tunnels or L2. Eh? I don't recognise this sentence as a characterisation of this draft: TSV is the place where there's expertise and interest in Diffserv & ECN. These two propagate up the layers, as well as down, and ECN has a dependency on whether the transport is ECN-capable. That places these two outside the comfort zone of most tunnel protocol designers. Bob >Joe > >On 11/6/2013 2:50 PM, Bob Briscoe wrote: >>Joe, >> >>The approach of a BCP just about ECN doesn't preclude any of the >>following options for stds track docs: >>a) one RFC updating all tunnel specs about ECN >>b) one RFC updating all tunnel specs about ECN and Diffserv (the two >>fields that propagate up as well as down). >>c) one RFC updating all tunnel specs about everything >>d) one RFC per each tunnel spec to wrap up all updates around at the time >> >>These choices are for the relevant ADs and WGs to make. >>Writing a BCP in TSV gives the raw info that any of these approaches can >>use. >> >> >> >>Bob >> >>At 20:50 05/11/2013, Joe Touch wrote: >> >> >>>On 11/5/2013 10:59 AM, Bob Briscoe wrote: >>>>Joe, >>>> >>>>I envisage that a very brief standards track doc that explicitly UPDATES >>>>the relevant IETF tunnel specs will be written, and it will refer to >>>>this doc for rationale. >>> >>>Tunnels need to handle ingress/egress translation of all signals in >>>the header. This is no different. >>> >>>My concern is that putting these recommendations in separate places >>>gives an opportunity for different groups to have different >>>interpretations of that sort of translation, and that's a bad thing IMO. >>> >>>Joe >>> >>> >>>> >>>>See Appendix A (outstanding items), which I have also highlighted when >>>>presenting each time: >>>> >>>> 2. Consider whether an IETF Standard Track doc will be needed to >>>> Update the IP-in-IP protocols listed in Section 4.1--at least >>>> those that the IETF controls--and which Area it should sit >>>>under. >>>> >>>>Does that address your concern? >>>> >>>> >>>>Bob >>>> >>>>At 18:40 05/11/2013, Joe Touch wrote: >>>>>IMO, these guidelines ought to come out in a single recommendation for >>>>>tunnels; we had a draft of that in INTAREA but insufficient momentum. >>>>> >>>>>Piecemeal recommendations are likely to be ignored/lost. >>>>> >>>>>Joe >>>>> >>>>>On 11/4/2013 11:36 PM, Michael Menth wrote: >>>>>>+1 >>>>>> >>>>>>We need such guidelines for consistent congestion management. >>>>>> >>>>>>Best wishes, >>>>>> >>>>>>Michael >>>>>> >>>>>>Am 05.11.2013 00:16, schrieb Matt Mathis: >>>>>>>I think this is valuable work. Having a single document that >>>>>>>describes the requirements and general principles will save future >>>>>>>tunnel inventor/implementers from rediscovering the same bugs >>>>>>> >>>>>>>Thanks, >>>>>>>--MM-- >>>>>>>The best way to predict the future is to create it. - Alan Kay >>>>>>> >>>>>>>Privacy matters! We know from recent events that people are using >>>>>>>our >>>>>>>services to speak in defiance of unjust governments. We treat >>>>>>>privacy and security as matters of life and death, because for some >>>>>>>users, they are. >>>>>>> >>>>>>> >>>>>>>On Mon, Nov 4, 2013 at 2:03 PM, Bob Briscoe >>>>>>> wrote: >>>>>>> >>>>>>> Folks, >>>>>>> >>>>>>> Pls respond if you support this being adopted as a work-group >>>>>>>item >>>>>>> in the IETF transport services w-g (tsvwg). The WG chairs need >>>>>>> visibility of interest. >>>>>>> Even better, if you're willing to read / comment / review / >>>>>>>implement >>>>>>> >>>>>>> Guidelines for Adding Congestion Notification to Protocols that >>>>>>> Encapsulate IP >>>>>>> >>>>>>> >>>>>>> >>>>>>> Abstract >>>>>>> >>>>>>> The purpose of this document is to guide the design of >>>>>>>congestion >>>>>>> notification in any lower layer or tunnelling protocol that >>>>>>> encapsulates IP. The aim is for explicit congestion >>>>>>>signals to >>>>>>> propagate consistently from lower layer protocols into IP. >>>>>>> Then the >>>>>>> IP internetwork layer can act as a portability layer to carry >>>>>>> congestion notification from non-IP-aware congested nodes up >>>>>>>to the >>>>>>> transport layer (L4). Following these guidelines should >>>>>>>assure >>>>>>> interworking between new lower layer congestion notification >>>>>>> mechanisms, whether specified by the IETF or other standards >>>>>>> bodies. >>>>>>> >>>>>>> >>>>>>> [Cross-posting tsvwg & aqm, just in case] >>>>>>> >>>>>>> >>>>>>> Bob Briscoe, >>>>>>> also for co-authors Pat Thaler and John Kaippallimalil >>>>>>> >>>>>>> >>>>>>> ________________________________________________________________ >>>>>>> Bob Briscoe, BT >>>>>>> _______________________________________________ >>>>>>> aqm mailing list >>>>>>> aqm@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/aqm >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>_______________________________________________ >>>>>>>aqm mailing list >>>>>>>aqm@ietf.org >>>>>>>https://www.ietf.org/mailman/listinfo/aqm >>>>>> >>>>>>-- >>>>>>Prof. Dr. habil. Michael Menth >>>>>>University of Tuebingen >>>>>>Faculty of Science >>>>>>Department of Computer Science >>>>>>Chair of Communication Networks >>>>>>Sand 13, 72076 Tuebingen, Germany >>>>>>phone: (+49)-7071/29-70505 >>>>>>fax: (+49)-7071/29-5220 >>>>>>mailto:menth@uni-tuebingen.de >>>>>>http://kn.inf.uni-tuebingen.de >>>>>> >>>>>> >>>>>> >>>>>>_______________________________________________ >>>>>>aqm mailing list >>>>>>aqm@ietf.org >>>>>>https://www.ietf.org/mailman/listinfo/aqm >>>>>_______________________________________________ >>>>>aqm mailing list >>>>>aqm@ietf.org >>>>>https://www.ietf.org/mailman/listinfo/aqm >>>> >>>>________________________________________________________________ >>>>Bob Briscoe, BT >>>_______________________________________________ >>>aqm mailing list >>>aqm@ietf.org >>>https://www.ietf.org/mailman/listinfo/aqm >> >>________________________________________________________________ >>Bob Briscoe, BT > >________________________________________________________________ >Bob Briscoe, BT From touch@isi.edu Wed Nov 6 15:48:07 2013 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 89C2D21E814C for ; Wed, 6 Nov 2013 15:48:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.138 X-Spam-Level: X-Spam-Status: No, score=-103.138 tagged_above=-999 required=5 tests=[AWL=-0.766, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227, 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 H75UOPucXjlz for ; Wed, 6 Nov 2013 15:48:03 -0800 (PST) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id 18BCE21E8064 for ; Wed, 6 Nov 2013 15:47:58 -0800 (PST) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id rA6NlHw7012309 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 6 Nov 2013 15:47:18 -0800 (PST) Message-ID: <527AD581.9060603@isi.edu> Date: Wed, 06 Nov 2013 15:49:21 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Bob Briscoe References: <201311042203.rA4M3lo0026458@bagheera.jungle.bt.co.uk> <52789FF5.3030907@uni-tuebingen.de> <52793B87.4040102@isi.edu> <201311051859.rA5IxJvZ030310@bagheera.jungle.bt.co.uk> <52795A03.9010804@isi.edu> <201311062250.rA6MoGY0003371@bagheera.jungle.bt.co.uk> <527ACA56.8010902@isi.edu> <201311062337.rA6Nbocn003604@bagheera.jungle.bt.co.uk> In-Reply-To: <201311062337.rA6Nbocn003604@bagheera.jungle.bt.co.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tsvwg IETF list Subject: Re: [tsvwg] [aqm] Who supports tsvwg adoption of adding ECN to L2 or tunnel protocols? 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, 06 Nov 2013 23:48:07 -0000 On 11/6/2013 3:37 PM, Bob Briscoe wrote: > Joe, > > At 23:01 06/11/2013, Joe Touch wrote: >> Hi, Bob, >> Annotating for reference below: A. >> IMO, the desciption of how IP header info (which is what I presume >> you're suggesting) to impact L2s (which include tunnels) belongs in a >> tunnel doc, which AFAICT belongs in INTAREA. The tunnel landscape is >> already quite complex. B.1 >> I have no idea why TSV would be involved in this except if you're >> talking about TCP ECH markings, but IMO the relationship of the TCP >> mark to the IP mark might belong in TSV. B.2 >> However, I do not think TSV should be promoting having signals "jump" >> layers, i.e., from TCP ECN to its impact on tunnels or L2. > > Eh? I don't recognise this sentence as a characterisation of this draft: > Agreed. B.2 refers to B.1. I.e., the logic may have been obscure, but IMO: IP signaling expertise, and the interaction between IP signals and tunnels/L2 exists in INT TCP signaling expertise exists in TSV > TSV is the place where there's expertise and interest in Diffserv & ECN. > These two propagate up the layers, as well as down, and ECN has a > dependency on whether the transport is ECN-capable. That places these > two outside the comfort zone of most tunnel protocol designers. Perhaps, but that presumes you're taking about TCP-IP interactions. If your focus is IP-tunnel/L2 interactions, IMO that is the core zone of INT and outside the area of most in TSV (excepting primarily those who are also already squarely in INT too). Thus my conclusions: - if this is TCP-IP (which it's not), then TSV - if this is IP-Tunnel/L2, then INT - if this is TCP-tunnel/L2, then please don't ;-) JOe > > > > Bob > > >> Joe >> >> On 11/6/2013 2:50 PM, Bob Briscoe wrote: >>> Joe, >>> >>> The approach of a BCP just about ECN doesn't preclude any of the >>> following options for stds track docs: >>> a) one RFC updating all tunnel specs about ECN >>> b) one RFC updating all tunnel specs about ECN and Diffserv (the two >>> fields that propagate up as well as down). >>> c) one RFC updating all tunnel specs about everything >>> d) one RFC per each tunnel spec to wrap up all updates around at the >>> time >>> >>> These choices are for the relevant ADs and WGs to make. >>> Writing a BCP in TSV gives the raw info that any of these approaches can >>> use. >>> >>> >>> >>> Bob >>> >>> At 20:50 05/11/2013, Joe Touch wrote: >>> >>> >>>> On 11/5/2013 10:59 AM, Bob Briscoe wrote: >>>>> Joe, >>>>> >>>>> I envisage that a very brief standards track doc that explicitly >>>>> UPDATES >>>>> the relevant IETF tunnel specs will be written, and it will refer to >>>>> this doc for rationale. >>>> >>>> Tunnels need to handle ingress/egress translation of all signals in >>>> the header. This is no different. >>>> >>>> My concern is that putting these recommendations in separate places >>>> gives an opportunity for different groups to have different >>>> interpretations of that sort of translation, and that's a bad thing >>>> IMO. >>>> >>>> Joe >>>> >>>> >>>>> >>>>> See Appendix A (outstanding items), which I have also highlighted when >>>>> presenting each time: >>>>> >>>>> 2. Consider whether an IETF Standard Track doc will be needed to >>>>> Update the IP-in-IP protocols listed in Section 4.1--at least >>>>> those that the IETF controls--and which Area it should sit >>>>> under. >>>>> >>>>> Does that address your concern? >>>>> >>>>> >>>>> Bob >>>>> >>>>> At 18:40 05/11/2013, Joe Touch wrote: >>>>>> IMO, these guidelines ought to come out in a single recommendation >>>>>> for >>>>>> tunnels; we had a draft of that in INTAREA but insufficient momentum. >>>>>> >>>>>> Piecemeal recommendations are likely to be ignored/lost. >>>>>> >>>>>> Joe >>>>>> >>>>>> On 11/4/2013 11:36 PM, Michael Menth wrote: >>>>>>> +1 >>>>>>> >>>>>>> We need such guidelines for consistent congestion management. >>>>>>> >>>>>>> Best wishes, >>>>>>> >>>>>>> Michael >>>>>>> >>>>>>> Am 05.11.2013 00:16, schrieb Matt Mathis: >>>>>>>> I think this is valuable work. Having a single document that >>>>>>>> describes the requirements and general principles will save future >>>>>>>> tunnel inventor/implementers from rediscovering the same bugs >>>>>>>> >>>>>>>> Thanks, >>>>>>>> --MM-- >>>>>>>> The best way to predict the future is to create it. - Alan Kay >>>>>>>> >>>>>>>> Privacy matters! We know from recent events that people are using >>>>>>>> our >>>>>>>> services to speak in defiance of unjust governments. We treat >>>>>>>> privacy and security as matters of life and death, because for some >>>>>>>> users, they are. >>>>>>>> >>>>>>>> >>>>>>>> On Mon, Nov 4, 2013 at 2:03 PM, Bob Briscoe >>>>>>> > wrote: >>>>>>>> >>>>>>>> Folks, >>>>>>>> >>>>>>>> Pls respond if you support this being adopted as a work-group >>>>>>>> item >>>>>>>> in the IETF transport services w-g (tsvwg). The WG chairs need >>>>>>>> visibility of interest. >>>>>>>> Even better, if you're willing to read / comment / review / >>>>>>>> implement >>>>>>>> >>>>>>>> Guidelines for Adding Congestion Notification to Protocols that >>>>>>>> Encapsulate IP >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Abstract >>>>>>>> >>>>>>>> The purpose of this document is to guide the design of >>>>>>>> congestion >>>>>>>> notification in any lower layer or tunnelling protocol that >>>>>>>> encapsulates IP. The aim is for explicit congestion >>>>>>>> signals to >>>>>>>> propagate consistently from lower layer protocols into IP. >>>>>>>> Then the >>>>>>>> IP internetwork layer can act as a portability layer to >>>>>>>> carry >>>>>>>> congestion notification from non-IP-aware congested nodes up >>>>>>>> to the >>>>>>>> transport layer (L4). Following these guidelines should >>>>>>>> assure >>>>>>>> interworking between new lower layer congestion notification >>>>>>>> mechanisms, whether specified by the IETF or other standards >>>>>>>> bodies. >>>>>>>> >>>>>>>> >>>>>>>> [Cross-posting tsvwg & aqm, just in case] >>>>>>>> >>>>>>>> >>>>>>>> Bob Briscoe, >>>>>>>> also for co-authors Pat Thaler and John Kaippallimalil >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> ________________________________________________________________ >>>>>>>> Bob Briscoe, BT >>>>>>>> _______________________________________________ >>>>>>>> aqm mailing list >>>>>>>> aqm@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/aqm >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> aqm mailing list >>>>>>>> aqm@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/aqm >>>>>>> >>>>>>> -- >>>>>>> Prof. Dr. habil. Michael Menth >>>>>>> University of Tuebingen >>>>>>> Faculty of Science >>>>>>> Department of Computer Science >>>>>>> Chair of Communication Networks >>>>>>> Sand 13, 72076 Tuebingen, Germany >>>>>>> phone: (+49)-7071/29-70505 >>>>>>> fax: (+49)-7071/29-5220 >>>>>>> mailto:menth@uni-tuebingen.de >>>>>>> http://kn.inf.uni-tuebingen.de >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> aqm mailing list >>>>>>> aqm@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/aqm >>>>>> _______________________________________________ >>>>>> aqm mailing list >>>>>> aqm@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/aqm >>>>> >>>>> ________________________________________________________________ >>>>> Bob Briscoe, BT >>>> _______________________________________________ >>>> aqm mailing list >>>> aqm@ietf.org >>>> https://www.ietf.org/mailman/listinfo/aqm >>> >>> ________________________________________________________________ >>> Bob Briscoe, BT >> >> ________________________________________________________________ >> Bob Briscoe, BT From gorry@erg.abdn.ac.uk Wed Nov 6 20:43:58 2013 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 B89F711E81EB for ; Wed, 6 Nov 2013 20:43:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.203 X-Spam-Level: X-Spam-Status: No, score=-105.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, 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 TveZ4HTOd1pT for ; Wed, 6 Nov 2013 20:43:52 -0800 (PST) Received: from spey.erg.abdn.ac.uk (spey.erg.abdn.ac.uk [139.133.204.173]) by ietfa.amsl.com (Postfix) with ESMTP id B53D711E80F5 for ; Wed, 6 Nov 2013 20:43:52 -0800 (PST) Received: by spey.erg.abdn.ac.uk (Postfix, from userid 5001) id E51672B44AE; Thu, 7 Nov 2013 04:43:51 +0000 (GMT) Received: from [31.133.160.97] (dhcp-a061.meeting.ietf.org [31.133.160.97]) by spey.erg.abdn.ac.uk (Postfix) with ESMTPA id 403382B43B3; Thu, 7 Nov 2013 04:43:51 +0000 (GMT) From: Gorry Content-Type: text/plain; charset=us-ascii X-Mailer: iPad Mail (11B511) Message-Id: <682574E6-F434-4644-8094-346096470F57@erg.abdn.ac.uk> Date: Wed, 6 Nov 2013 20:43:51 -0800 To: "tsvwg@ietf.org" Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (1.0) Subject: [tsvwg] Adoption of behave requirements update and sctpnat 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, 07 Nov 2013 04:43:58 -0000 TSVWG plans to adopt the following drafts that were formerly adopted by th= e behave WG: draft-ietf-behave-requirements-update draft-ietf-behave-sctpnat Please send any comments or questions on the transfer of the adoption of the= se drafts to the chairs by 15th November 2013. Gorry Co-chair TSVWG= From p.ohanlon@gmail.com Thu Nov 7 05:26:49 2013 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 C183211E8259; Thu, 7 Nov 2013 05:26:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.461 X-Spam-Level: X-Spam-Status: No, score=-2.461 tagged_above=-999 required=5 tests=[AWL=-0.089, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227] 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 LD36NPhhnXv1; Thu, 7 Nov 2013 05:26:49 -0800 (PST) Received: from mail-we0-x232.google.com (mail-we0-x232.google.com [IPv6:2a00:1450:400c:c03::232]) by ietfa.amsl.com (Postfix) with ESMTP id F12FB11E8255; Thu, 7 Nov 2013 05:26:40 -0800 (PST) Received: by mail-we0-f178.google.com with SMTP id q59so530960wes.9 for ; Thu, 07 Nov 2013 05:26:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=dkvGq4ZGYFJ4ermv6u0gFf1qF4dUttQSRuppSTA5ufM=; b=iEH1Jqahpm2Tb2WzmFOyJoukuQsk+TVAMfggM0CZOPgQnWfd7gfiTvza4d9DJVf0m4 21qnxWa9dyLNqaScM+Q6yappPjoi/FSPy6kguon0VYdsKwtIfihgtzkc9ddRvsc1jrGR kul+hl/yifsaH/ovhMLDvBpHz+oX2rwwrZ/ffFlaj7ZYh7NN9iG8mGqIt0sB8rOKo53J Z4oi3bPgOw5Hlib04vCU2BwCtdJsEUKOg/jtQSjaDmiTL74hzIZjeAeqENDNavAx7bN1 tJUTd9PNRfiNpV7SA9pE9I2T3Pa1h9m7jOLtL7wOhG7tIw7/PQJy9ZM0RoODMldT15LB TYqA== X-Received: by 10.194.1.162 with SMTP id 2mr48481wjn.91.1383830799927; Thu, 07 Nov 2013 05:26:39 -0800 (PST) Received: from [149.241.130.95] ([149.241.130.95]) by mx.google.com with ESMTPSA id y11sm6881221wie.7.2013.11.07.05.26.37 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 07 Nov 2013 05:26:38 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Piers O'Hanlon In-Reply-To: <201311051841.rA5IfUeP030224@bagheera.jungle.bt.co.uk> Date: Thu, 7 Nov 2013 13:26:36 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <6DB095B2-E77B-457F-81D2-5E9CC940871B@gmail.com> References: <201311042203.rA4M3lo0026458@bagheera.jungle.bt.co.uk> <8677FF97-849C-40A6-AE71-AE7ED18570E0@gmail.com> <201311051841.rA5IfUeP030224@bagheera.jungle.bt.co.uk> To: Bob Briscoe X-Mailer: Apple Mail (2.1283) Cc: draft-briscoe-tsvwg-ecn-encap-guidelines@tools.ietf.org, tsvwg IETF list , AQM IETF list Subject: Re: [tsvwg] [aqm] Who supports tsvwg adoption of adding ECN to L2 or tunnel protocols? 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, 07 Nov 2013 13:26:49 -0000 Bob, I was thinking that it would be good to add the following = clarifications: Given a suitable marking scheme ECN provides for the removal of nearly = all congestion loss and it reduces delays for two main reasons:=20 i) It avoids the delay when recovering from congestion losses, which = particularly benefits small flows, making their=20 completion time predictably short [RFC2884] ii) As ECN is used more widely by end-systems, it will gradually = remove the need to configure a degree of delay into buffers before they start to notify congestion (the cause of = bufferbloat).=20 The latter delay is because a drop involves a trade-off between sending = a timely signal and trying to avoid impairment, whereas ECN is solely a = signal not an impairment, so there is no harm triggering it earlier. Cheers, Piers On 5 Nov 2013, at 18:41, Bob Briscoe wrote: > Piers, >=20 > I tried to state exactly how ECN can benefit (2nd para of intro = below), rather than make overblown claims. You seem to be saying I = didn't succeed? I can't see how to do any better. Suggestions? >=20 > = /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\= /\/\/\/\/\/\/\ > ECN removes nearly all congestion loss and it cuts delays for two main = reasons: i) it avoids the delay when recovering from congestion losses, = which particularly benefits small flows, making their completion time = predictably short [RFC2884] and ii) as ECN is used more widely by = end-systems, it will gradually remove the need to configure a degree of = delay into buffers before they start to notify congestion (the cause of = bufferbloat). The latter delay is because drop involves a trade-off = between sending a timely signal and trying to avoid impairment, whereas = ECN is solely a signal not an impairment, so there is no harm triggering = it earlier. > = /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\= /\/\/\/\/\/\/\ >=20 > PS. Thx for supporting words. >=20 > Bob >=20 > At 09:42 05/11/2013, Piers O'Hanlon wrote: >> Hi Bob, >>=20 >> I took a brief look at the draft and it's clearly useful work. >>=20 >> One thing that could do with clarification in the Introduction is = that ECN - by itself - doesn't necessarily lead to low loss and delay - = it should be made clear that it reflects the marking approach of the = underlying scheme/AQM. >>=20 >> Piers >>=20 >> On 4 Nov 2013, at 22:03, Bob Briscoe wrote: >>=20 >> > Folks, >> > >> > Pls respond if you support this being adopted as a work-group item = in the IETF transport services w-g (tsvwg). The WG chairs need = visibility of interest. >> > Even better, if you're willing to read / comment / review / = implement >> > >> > Guidelines for Adding Congestion Notification to Protocols that = Encapsulate IP >> > = >> > >> > Abstract >> > >> > The purpose of this document is to guide the design of congestion >> > notification in any lower layer or tunnelling protocol that >> > encapsulates IP. The aim is for explicit congestion signals to >> > propagate consistently from lower layer protocols into IP. Then = the >> > IP internetwork layer can act as a portability layer to carry >> > congestion notification from non-IP-aware congested nodes up to = the >> > transport layer (L4). Following these guidelines should assure >> > interworking between new lower layer congestion notification >> > mechanisms, whether specified by the IETF or other standards = bodies. >> > >> > >> > [Cross-posting tsvwg & aqm, just in case] >> > >> > >> > Bob Briscoe, >> > also for co-authors Pat Thaler and John Kaippallimalil >> > >> > >> > ________________________________________________________________ >> > Bob Briscoe, BT >>=20 >> _______________________________________________ >> aqm mailing list >> aqm@ietf.org >> https://www.ietf.org/mailman/listinfo/aqm >=20 > ________________________________________________________________ > Bob Briscoe, BT=20 From touch@isi.edu Thu Nov 7 07:50:55 2013 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 F26D121E8167 for ; Thu, 7 Nov 2013 07:50:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.675 X-Spam-Level: X-Spam-Status: No, score=-103.675 tagged_above=-999 required=5 tests=[AWL=-1.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 kx4se1Wf3M2R for ; Thu, 7 Nov 2013 07:50:48 -0800 (PST) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id DE3B621E817F for ; Thu, 7 Nov 2013 07:50:46 -0800 (PST) Received: from [192.168.1.93] (pool-71-105-87-112.lsanca.dsl-w.verizon.net [71.105.87.112]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id rA7FoAK9005039 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 7 Nov 2013 07:50:13 -0800 (PST) Message-ID: <527BB6B5.1010404@isi.edu> Date: Thu, 07 Nov 2013 07:50:13 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Randy Stewart , tsvwg list References: <421B5DF5-A872-4EDC-8735-EEBF189052ED@lakerest.net> In-Reply-To: <421B5DF5-A872-4EDC-8735-EEBF189052ED@lakerest.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Subject: Re: [tsvwg] Review of draft-multicast-udp_guidelines 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, 07 Nov 2013 15:50:55 -0000 On 11/6/2013 2:29 PM, Randy Stewart wrote: > All > > I agreed to give a review of this document at tsvwg yesterday, so while I await > my plane to SFO here goes: > > Abstract: > > What is pont-to-point ? > > 2.1 > " > When the multicast traffic exits the administrative domain of a > single network or the bi-laterally agreed path between networks, or > is tunneled across the unicast Internet either to another multicast > network or to an end device, the application SHOULD provide a TCPcompatible > aggregate flow over the end-to-end path to each leaf. > " > > Thats a *lot* for one sentence, maybe you could pare this down a bit > and get rid of the case list, you already state the scope earlier and > I don't think you need to illustrate it every time. > > 2.1.4 > > You might also note that some providers always drop fragments not just > NAT's and F/W's > > IANA Considerations > > Probably you should not leave the boiler plate here. This might be a good place to put some recommendations on how to ask for various multicast codepoints, including multicast addresses and multicast services. The latter is partly addressed in draft-ietf-tsvwg-port-use. Joe From bob.briscoe@bt.com Thu Nov 7 10:39:57 2013 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 6154B21E814E; Thu, 7 Nov 2013 10:39:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.778 X-Spam-Level: X-Spam-Status: No, score=-2.778 tagged_above=-999 required=5 tests=[AWL=-0.406, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227] 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 A6C9uWQVBfhs; Thu, 7 Nov 2013 10:39:51 -0800 (PST) Received: from hubrelay-rd.bt.com (hubrelay-rd.bt.com [62.239.224.98]) by ietfa.amsl.com (Postfix) with ESMTP id B58A721E816A; Thu, 7 Nov 2013 10:38:59 -0800 (PST) Received: from EVMHR02-UKBR.domain1.systemhost.net (193.113.108.41) by EVMHR66-UKRD.bt.com (10.187.101.21) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 7 Nov 2013 18:38:52 +0000 Received: from EPHR01-UKIP.domain1.systemhost.net (147.149.196.177) by EVMHR02-UKBR.domain1.systemhost.net (193.113.108.41) with Microsoft SMTP Server (TLS) id 8.3.297.1; Thu, 7 Nov 2013 18:38:48 +0000 Received: from bagheera.jungle.bt.co.uk (132.146.168.158) by EPHR01-UKIP.domain1.systemhost.net (147.149.196.177) with Microsoft SMTP Server id 14.2.347.0; Thu, 7 Nov 2013 18:38:46 +0000 Received: from BTP075694.jungle.bt.co.uk ([10.109.144.199]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id rA7Icg2o008256; Thu, 7 Nov 2013 18:38:43 GMT Message-ID: <201311071838.rA7Icg2o008256@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 7 Nov 2013 18:38:42 +0000 To: Piers O'Hanlon From: Bob Briscoe In-Reply-To: <6DB095B2-E77B-457F-81D2-5E9CC940871B@gmail.com> References: <201311042203.rA4M3lo0026458@bagheera.jungle.bt.co.uk> <8677FF97-849C-40A6-AE71-AE7ED18570E0@gmail.com> <201311051841.rA5IfUeP030224@bagheera.jungle.bt.co.uk> <6DB095B2-E77B-457F-81D2-5E9CC940871B@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 Cc: draft-briscoe-tsvwg-ecn-encap-guidelines@tools.ietf.org, tsvwg IETF list , AQM IETF list Subject: Re: [tsvwg] [aqm] Who supports tsvwg adoption of adding ECN to L2 or tunnel protocols? 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, 07 Nov 2013 18:39:57 -0000 Piers, OK. Text altered (even tho some of the gains are much less sensitive to marking scheme, the point is of course generally true). Bob At 13:26 07/11/2013, Piers O'Hanlon wrote: >Bob, > >I was thinking that it would be good to add the following clarifications: > >Given a suitable marking scheme ECN provides for the removal of >nearly all congestion loss and it reduces delays for two main reasons: > i) It avoids the delay when recovering from congestion losses, > which particularly benefits small flows, making their > completion time predictably short [RFC2884] > ii) As ECN is used more widely by end-systems, it will gradually > remove the need to configure a degree of delay > into buffers before they start to notify congestion (the > cause of bufferbloat). >The latter delay is because a drop involves a trade-off between >sending a timely signal and trying to avoid impairment, whereas ECN >is solely a signal not an impairment, so there is no harm triggering >it earlier. > >Cheers, > >Piers > >On 5 Nov 2013, at 18:41, Bob Briscoe wrote: > > > Piers, > > > > I tried to state exactly how ECN can benefit (2nd para of intro > below), rather than make overblown claims. You seem to be saying I > didn't succeed? I can't see how to do any better. Suggestions? > > > > > /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ > > ECN removes nearly all congestion loss and it cuts delays for two > main reasons: i) it avoids the delay when recovering from > congestion losses, which particularly benefits small flows, making > their completion time predictably short [RFC2884] and ii) as ECN is > used more widely by end-systems, it will gradually remove the need > to configure a degree of delay into buffers before they start to > notify congestion (the cause of bufferbloat). The latter delay is > because drop involves a trade-off between sending a timely signal > and trying to avoid impairment, whereas ECN is solely a signal not > an impairment, so there is no harm triggering it earlier. > > > /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ > > > > PS. Thx for supporting words. > > > > Bob > > > > At 09:42 05/11/2013, Piers O'Hanlon wrote: > >> Hi Bob, > >> > >> I took a brief look at the draft and it's clearly useful work. > >> > >> One thing that could do with clarification in the Introduction > is that ECN - by itself - doesn't necessarily lead to low loss and > delay - it should be made clear that it reflects the marking > approach of the underlying scheme/AQM. > >> > >> Piers > >> > >> On 4 Nov 2013, at 22:03, Bob Briscoe wrote: > >> > >> > Folks, > >> > > >> > Pls respond if you support this being adopted as a work-group > item in the IETF transport services w-g (tsvwg). The WG chairs need > visibility of interest. > >> > Even better, if you're willing to read / comment / review / implement > >> > > >> > Guidelines for Adding Congestion Notification to Protocols > that Encapsulate IP > >> > > >> > > >> > Abstract > >> > > >> > The purpose of this document is to guide the design of congestion > >> > notification in any lower layer or tunnelling protocol that > >> > encapsulates IP. The aim is for explicit congestion signals to > >> > propagate consistently from lower layer protocols into IP. Then the > >> > IP internetwork layer can act as a portability layer to carry > >> > congestion notification from non-IP-aware congested nodes up to the > >> > transport layer (L4). Following these guidelines should assure > >> > interworking between new lower layer congestion notification > >> > mechanisms, whether specified by the IETF or other standards bodies. > >> > > >> > > >> > [Cross-posting tsvwg & aqm, just in case] > >> > > >> > > >> > Bob Briscoe, > >> > also for co-authors Pat Thaler and John Kaippallimalil > >> > > >> > > >> > ________________________________________________________________ > >> > Bob Briscoe, BT > >> > >> _______________________________________________ > >> aqm mailing list > >> aqm@ietf.org > >> https://www.ietf.org/mailman/listinfo/aqm > > > > ________________________________________________________________ > > Bob Briscoe, BT > >_______________________________________________ >aqm mailing list >aqm@ietf.org >https://www.ietf.org/mailman/listinfo/aqm ________________________________________________________________ Bob Briscoe, BT From bob.briscoe@bt.com Thu Nov 7 12:03:37 2013 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 BAA6111E82A3; Thu, 7 Nov 2013 12:03:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.766 X-Spam-Level: X-Spam-Status: No, score=-2.766 tagged_above=-999 required=5 tests=[AWL=-0.394, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227] 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 UVJ-4Qk7eMgB; Thu, 7 Nov 2013 12:03:32 -0800 (PST) Received: from hubrelay-rd.bt.com (hubrelay-rd.bt.com [62.239.224.98]) by ietfa.amsl.com (Postfix) with ESMTP id 65BC821F99F8; Thu, 7 Nov 2013 12:03:14 -0800 (PST) Received: from EVMHR01-UKBR.domain1.systemhost.net (193.113.108.40) by EVMHR66-UKRD.bt.com (10.187.101.21) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 7 Nov 2013 20:03:12 +0000 Received: from EPHR01-UKIP.domain1.systemhost.net (147.149.196.177) by EVMHR01-UKBR.domain1.systemhost.net (193.113.108.40) with Microsoft SMTP Server (TLS) id 8.3.297.1; Thu, 7 Nov 2013 20:03:12 +0000 Received: from bagheera.jungle.bt.co.uk (132.146.168.158) by EPHR01-UKIP.domain1.systemhost.net (147.149.196.177) with Microsoft SMTP Server id 14.2.347.0; Thu, 7 Nov 2013 20:03:12 +0000 Received: from BTP075694.jungle.bt.co.uk ([10.109.144.199]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id rA7K38dj008566; Thu, 7 Nov 2013 20:03:09 GMT Message-ID: <201311072003.rA7K38dj008566@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 7 Nov 2013 20:03:08 +0000 To: tsv-area IETF list , AQM IETF list , tsvwg IETF list From: Bob Briscoe MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 Subject: [tsvwg] Immediate ECN: Autotuning AQM for RTT 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, 07 Nov 2013 20:03:37 -0000 Folks, "Immediate ECN" slides: PS. This talk fell off the end of the TSVAREA agenda. It's mostly relevant to AQM, but I didn't originally bring it to AQM, because it affects 3 wgs: tsvwg, aqm & tcpm. In the AQM wg, there was dismay about CableLabs not including anything about ECN in DOCSIS3.1. This talk is about AQM dynamics; and how ECN can take out the 100ms of delay that CoDel and PIE introduce - it's essentially about auto-tuning for RTT. It gives an interim recommendation for hardware designers that there should be a second instance of the AQM algo for ECN packets so that it can be configured with different parameters (think of WRED instead of RED). Specifically, for ECN packets: interval = 0 (for CoDel) max_burst = 0 (for PIE) Bob PS. We have a paper under submission, which we can supply on request. We plan to document this in the IETF too. ________________________________________________________________ Bob Briscoe, BT From internet-drafts@ietf.org Thu Nov 7 14:35:17 2013 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 4CAEE11E8282; Thu, 7 Nov 2013 14:35:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.572 X-Spam-Level: X-Spam-Status: No, score=-102.572 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, NO_RELAYS=-0.001, 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 fxF64LRc4Shq; Thu, 7 Nov 2013 14:35:13 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9505C11E8127; Thu, 7 Nov 2013 14:35:13 -0800 (PST) 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.83 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131107223513.21885.75316.idtracker@ietfa.amsl.com> Date: Thu, 07 Nov 2013 14:35:13 -0800 Cc: tsvwg@ietf.org Subject: [tsvwg] I-D Action: draft-ietf-tsvwg-byte-pkt-congest-12.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Nov 2013 22:35:18 -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-12.txt Pages : 48 Date : 2013-11-07 Abstract: This document provides recommendations of best current practice for dropping or marking packets using any active queue management (AQM) algorithm, including random early detection (RED), BLUE, pre- congestion notification (PCN) and newer schemes such as CoDel (Controlled Delay) and PIE (Proportional Integral controller Enhanced). We give three strong recommendations: (1) packet size should be taken into account when transports detect 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) in the specific case of RED, the byte- mode packet drop variant 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-12 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tsvwg-byte-pkt-congest-12 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From fred@cisco.com Fri Nov 8 11:49:56 2013 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 AD56A21E81FF; Fri, 8 Nov 2013 11:49:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.3 X-Spam-Level: X-Spam-Status: No, score=-110.3 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, SARE_SUB_OBFU_Q1=0.227, 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 szmBjGR9CZBL; Fri, 8 Nov 2013 11:49:43 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 3DEF721E8195; Fri, 8 Nov 2013 11:49:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2062; q=dns/txt; s=iport; t=1383940153; x=1385149753; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=KN9MDTSa2wA4qNUCkB6WLItKeImvaw2siNQUSG5qO8U=; b=OEpRXHjy5999X5hYYOcRBQcpx8AX6jsznLOMqQVfoEkKZifn8/B6/W6v 652w20ChC1xv/Ul+GOlfEkqkQXe1JlfCV/AJVM6T9Yp8aTZHxZ2lJZpac 7jOhoKZP9Df4jvAz/t6EMKyTd78ImOBVEdUXMfImmGc8Uou272g+al3s+ k=; X-Files: signature.asc : 195 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjQFAAk/fVKtJXHA/2dsb2JhbABZgweBC7wdgWiBEYExFnSCJQEBAQR5EAIBCBguMiUCBA4TDYdmvUWPZweDIIEQA5AwgTCGL5ILgyaCKg X-IronPort-AV: E=Sophos;i="4.93,661,1378857600"; d="asc'?scan'208";a="282550953" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-2.cisco.com with ESMTP; 08 Nov 2013 19:49:06 +0000 Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id rA8Jn6Jq027658 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 8 Nov 2013 19:49:06 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.122]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.03.0123.003; Fri, 8 Nov 2013 13:49:05 -0600 From: "Fred Baker (fred)" To: Andrew McGregor Thread-Topic: [aqm] Who supports tsvwg adoption of adding ECN to L2 or tunnel protocols? Thread-Index: AQHO3LuUWaKyBh1riEa3sG4KFle+eg== Date: Fri, 8 Nov 2013 19:49:05 +0000 Message-ID: <145AB1C0-B108-4196-AD5C-3667103FB4D8@cisco.com> References: <201311042203.rA4M3lo0026458@bagheera.jungle.bt.co.uk> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.21.148.94] Content-Type: multipart/signed; boundary="Apple-Mail=_B2184D50-10C6-4503-A028-FC8AAE7A6A38"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Cc: AQM IETF list , "" , tsvwg IETF list Subject: Re: [tsvwg] [aqm] Who supports tsvwg adoption of adding ECN to L2 or tunnel protocols? 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, 08 Nov 2013 19:49:56 -0000 --Apple-Mail=_B2184D50-10C6-4503-A028-FC8AAE7A6A38 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 At 23:04 04/11/2013, Andrew Mcgregor wrote: > This seems like valuable work. One question is, can we put in scope = notification that losses are NOT due to congestion? Speaking for myself, I'm not sure how I would do that. A loss (or mark) due to congestion is pretty simple. The switch knows = what it did.=20 To know that a packet was lost for reasons other than congestion, I need = to somehow know what packets I should expect, and infer that something = that I expected didn't happen. In TCP, we know about data segments = because they are enumerated - I know what the next octet sequence number = to expect, and it doesn't arrive. Control segments (SYN, ACK, FIN, RST, = and so on) are not enumerated in that sense - if my peer sends ten = identical acks and nine arrive, I as the receiver have no way to know = that. At the link layer, most link protocols in use today (PPP, = Ethernet, and so on) do not enumerate packets in flight - they are = simply there. I *might* be able to see a burst of noise on the line, but = only if it looks like it might be the start of a packet and then doesn't = end with the right checksum. Even if I can see it, I have no way to know = whether the noise garbled one packet or many. If you want to do some research and come up with a solution, be my = guest. But in a standard discussed in 2013... let's not. --Apple-Mail=_B2184D50-10C6-4503-A028-FC8AAE7A6A38 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iD8DBQFSfUAxbjEdbHIsm0MRApMhAJwOogQqdCvBmF4cfltYOtnMSOoIxQCg6YeQ kgevVsY3Rao+Xmqzx1iDL8M= =mNKB -----END PGP SIGNATURE----- --Apple-Mail=_B2184D50-10C6-4503-A028-FC8AAE7A6A38-- From andrewmcgr@google.com Fri Nov 8 12:39:00 2013 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 B1E6E21E8123 for ; Fri, 8 Nov 2013 12:39:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.57 X-Spam-Level: X-Spam-Status: No, score=-1.57 tagged_above=-999 required=5 tests=[AWL=0.180, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, SARE_SUB_OBFU_Q1=0.227] 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 j9OjMZVA5skW for ; Fri, 8 Nov 2013 12:38:57 -0800 (PST) Received: from mail-qe0-x22e.google.com (mail-qe0-x22e.google.com [IPv6:2607:f8b0:400d:c02::22e]) by ietfa.amsl.com (Postfix) with ESMTP id EA53721E8121 for ; Fri, 8 Nov 2013 12:38:23 -0800 (PST) Received: by mail-qe0-f46.google.com with SMTP id s14so2431216qeb.5 for ; Fri, 08 Nov 2013 12:38:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=lGq7IcjcYp/CfTe//QXENfxO0jdsm0PM94eEI+2CwYo=; b=f8yS/oWgZwUfLB4RwFgQRf8eA0RScrIndtL5+XKQsp1SwMht2d6i2aMbIp2m0I96Y3 6JREQcoOdYbX3C7gHyaUqUM14XRcU9LqrqCLfS3/pRHiaXiFYZq6VB54VTRY3AtS8B/L r4oR57Ip43oZhpcfjyfdhk42okyxo+nhUG5wQWGzSlUrjLDbC6kvmBPqkygaxxdGQDHM iFWC2frO+cHh48oq3GUWEK6yA3LLI/NgMbPyG6+3ZmHYJ4dsAUdPyK2cCVzIorjwBZKz FgugmQNXqG/LqHSE1sv3UA7LG5di7gzaoCBpWCZvZGpEr7NyOQ/kEEdV2dOnG1xxBXy9 quQg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=lGq7IcjcYp/CfTe//QXENfxO0jdsm0PM94eEI+2CwYo=; b=f9G/Gyf2LahI6V+EUOLBBbp8l+aqwygFHb9m00QSaugcBOkc9W9WY8j2XNNPQ15/YT c1v8CovQj9/0eis4xETU2rl5y28axKiem0dtF/ECCkCFSsIKp04jRHc/xb6SXDiyfRPh YQb697UgX5sIgW+nhcXlCWjqWRUdJ3HQ7s3aqX6lmexzoNJJIsff5VvxuXKn4g/SRF/M UiyqjQDmBCuu4hFtz7VgfX8S2LHn2y8xktAxi5pnso9xAFg3NEm4msOzHCOlRyBU2aKZ 69O/NiCr9L4mUovgwn2KDtySnWWesBo3SOWBD6xSCUP3LDV3CwmfY0sU+9Z5EtIBesB3 4fzg== X-Gm-Message-State: ALoCoQkkMUFhlQzFptjJtS3ccR1y+MmykWx6i+3tCPFwDIa+cjjZKj841/Z7rq1/Nt628loCoD+LWz72iz95izxwn3qLMBhRj8H9huTG9GXBuwN0SthT5k1id7SzmQ7dA5OF0/RHzs07GZITUoaW7DNZx4cKRnYRclArWdUetXpU9t7L8Pr3azOMUoHtYBRLDufL771eNXBJ MIME-Version: 1.0 X-Received: by 10.49.97.6 with SMTP id dw6mr25676406qeb.47.1383943101974; Fri, 08 Nov 2013 12:38:21 -0800 (PST) Received: by 10.224.197.198 with HTTP; Fri, 8 Nov 2013 12:38:21 -0800 (PST) In-Reply-To: <145AB1C0-B108-4196-AD5C-3667103FB4D8@cisco.com> References: <201311042203.rA4M3lo0026458@bagheera.jungle.bt.co.uk> <145AB1C0-B108-4196-AD5C-3667103FB4D8@cisco.com> Date: Fri, 8 Nov 2013 12:38:21 -0800 Message-ID: From: Andrew Mcgregor To: "Fred Baker (fred)" Content-Type: multipart/alternative; boundary=047d7bb0432afbaeb204eab05c51 Cc: tsvwg IETF list , "" , AQM IETF list , Andrew McGregor Subject: Re: [tsvwg] [aqm] Who supports tsvwg adoption of adding ECN to L2 or tunnel protocols? 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, 08 Nov 2013 20:39:00 -0000 --047d7bb0432afbaeb204eab05c51 Content-Type: text/plain; charset=ISO-8859-1 I agree, non-congestive loss notification is a research problem. So, out of scope for the IETF right now but I hope someone thinks about it (I will, as a background task). On 8 November 2013 11:49, Fred Baker (fred) wrote: > > At 23:04 04/11/2013, Andrew Mcgregor wrote: > > This seems like valuable work. One question is, can we put in scope > notification that losses are NOT due to congestion? > > Speaking for myself, I'm not sure how I would do that. > > A loss (or mark) due to congestion is pretty simple. The switch knows what > it did. > > To know that a packet was lost for reasons other than congestion, I need > to somehow know what packets I should expect, and infer that something that > I expected didn't happen. In TCP, we know about data segments because they > are enumerated - I know what the next octet sequence number to expect, and > it doesn't arrive. Control segments (SYN, ACK, FIN, RST, and so on) are not > enumerated in that sense - if my peer sends ten identical acks and nine > arrive, I as the receiver have no way to know that. At the link layer, most > link protocols in use today (PPP, Ethernet, and so on) do not enumerate > packets in flight - they are simply there. I *might* be able to see a burst > of noise on the line, but only if it looks like it might be the start of a > packet and then doesn't end with the right checksum. Even if I can see it, > I have no way to know whether the noise garbled one packet or many. > > If you want to do some research and come up with a solution, be my guest. > But in a standard discussed in 2013... let's not. > > _______________________________________________ > aqm mailing list > aqm@ietf.org > https://www.ietf.org/mailman/listinfo/aqm > > -- Andrew McGregor | SRE | andrewmcgr@google.com | +61 4 8143 7128 --047d7bb0432afbaeb204eab05c51 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I agree, non-congestive loss notification is a research pr= oblem. =A0So, out of scope for the IETF right now but I hope someone thinks= about it (I will, as a background task).
<= br>
On 8 November 2013 11:49, Fred Baker (fred) = <f= red@cisco.com> wrote:

At 23:04 04/11/2013, Andrew Mcgregor wrote:
> This seems like valuable work. =A0One question is, can we put in scope= notification that losses are NOT due to congestion?

Speaking for myself, I'm not sure how I would do that.

A loss (or mark) due to congestion is pretty simple. The switch knows what = it did.

To know that a packet was lost for reasons other than congestion, I need to= somehow know what packets I should expect, and infer that something that I= expected didn't happen. In TCP, we know about data segments because th= ey are enumerated - I know what the next octet sequence number to expect, a= nd it doesn't arrive. Control segments (SYN, ACK, FIN, RST, and so on) = are not enumerated in that sense - if my peer sends ten identical acks and = nine arrive, I as the receiver have no way to know that. At the link layer,= most link protocols in use today (PPP, Ethernet, and so on) do not enumera= te packets in flight - they are simply there. I *might* be able to see a bu= rst of noise on the line, but only if it looks like it might be the start o= f a packet and then doesn't end with the right checksum. Even if I can = see it, I have no way to know whether the noise garbled one packet or many.=

If you want to do some research and come up with a solution, be my guest. B= ut in a standard discussed in 2013... let's not.

_______________________________________________
aqm mailing list
aqm@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/aqm




--
Andrew McGregor=A0|<= /span>=A0SRE=A0|=A0andrewmcgr@google.com=A0|=A0+61 4 8143 7128
--047d7bb0432afbaeb204eab05c51-- From g.white@CableLabs.com Fri Nov 8 22:54:28 2013 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 3A28411E813A; Fri, 8 Nov 2013 22:54:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.236 X-Spam-Level: X-Spam-Status: No, score=-0.236 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, SARE_SUB_OBFU_Q1=0.227] 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 vCAe85yhVPLt; Fri, 8 Nov 2013 22:54:23 -0800 (PST) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by ietfa.amsl.com (Postfix) with ESMTP id B0CB111E80E7; Fri, 8 Nov 2013 22:54:23 -0800 (PST) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.7/8.14.7) with ESMTP id rA96sJdF008677; Fri, 8 Nov 2013 23:54:19 -0700 Received: from exchange.cablelabs.com (10.5.0.19) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/407/kyzyl.cablelabs.com); Fri, 08 Nov 2013 23:54:18 -0700 (MST) X-Virus-Status: clean(F-Secure/fsigk_smtp/407/kyzyl.cablelabs.com) Received: from EXCHANGE.cablelabs.com ([fe80::797a:96d1:3c53:18ee]) by EXCHANGE.cablelabs.com ([fe80::797a:96d1:3c53:18ee%11]) with mapi id 14.03.0146.000; Fri, 8 Nov 2013 23:54:19 -0700 From: Greg White To: Bob Briscoe , tsv-area IETF list , AQM IETF list , tsvwg IETF list Thread-Topic: [tsvwg] Immediate ECN: Autotuning AQM for RTT Thread-Index: AQHO2/R7zNZxx+pCdEmOwIOO+63dlZocaFeA Date: Sat, 9 Nov 2013 06:54:18 +0000 Message-ID: In-Reply-To: <201311072003.rA7K38dj008566@bagheera.jungle.bt.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.8.130913 x-originating-ip: [10.5.0.27] Content-Type: text/plain; charset="us-ascii" Content-ID: <4D0B19D98793114197CBFB5D06EF689F@cablelabs.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Approved: ondar Subject: Re: [tsvwg] Immediate ECN: Autotuning AQM for RTT 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, 09 Nov 2013 06:54:28 -0000 This is very interesting work. There are a lot of unanswered questions about ecn / no-ecn coexistence and differential treatment in an AQM, and this could provide some answers. To those who groaned that ECN was not included in DOCSIS 3.1, read these slides (and Naeem Khademi's). Bob, CoDel uses "interval" both as a hold-off for the first packet drop and as the numerator in the invsqrt drop scheduling. Setting interval =3D = 0 would result in ECN being signaled on *every* ECN capable packet when the sojourn time is above threshold. This jibes with some of your charts for RED, but others show a ramp up in mark probability rather than a step function. Could you clarify? Setting max_burst =3D 0 in PIE would not result in the step function behavior. -Greg On 11/7/13, 1:03 PM, "Bob Briscoe" wrote: >Folks, > >"Immediate ECN" slides: > > > >PS. This talk fell off the end of the TSVAREA agenda. It's mostly >relevant to AQM, but I didn't originally bring it to AQM, because it >affects 3 wgs: tsvwg, aqm & tcpm. > >In the AQM wg, there was dismay about CableLabs not including >anything about ECN in DOCSIS3.1. This talk is about AQM dynamics; and >how ECN can take out the 100ms of delay that CoDel and PIE introduce >- it's essentially about auto-tuning for RTT. > >It gives an interim recommendation for hardware designers that there >should be a second instance of the AQM algo for ECN packets so that >it can be configured with different parameters (think of WRED instead of >RED). > >Specifically, for ECN packets: >interval =3D 0 (for CoDel) >max_burst =3D 0 (for PIE) > > >Bob > >PS. We have a paper under submission, which we can supply on request. >We plan to document this in the IETF too. > > > > >________________________________________________________________ >Bob Briscoe, BT=20 From ropan@cisco.com Fri Nov 8 23:27:01 2013 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 9B87A21E80F5; Fri, 8 Nov 2013 23:27:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.485 X-Spam-Level: X-Spam-Status: No, score=-10.485 tagged_above=-999 required=5 tests=[AWL=-0.113, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, SARE_SUB_OBFU_Q1=0.227] 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 XQ+O8WZ1c+pT; Fri, 8 Nov 2013 23:26:57 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 398F221E80F7; Fri, 8 Nov 2013 23:26:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2169; q=dns/txt; s=iport; t=1383982004; x=1385191604; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=/vpEnBrsNnzpJqprwmMdgr2Q7HT/AEkMVf9UhLZlggc=; b=CFfy2kNfHWh4G64KGlcSkZBHQyeBhNW5KnwmxTvYwt0wnHHQxGyrb5yn U94fzZDkRHlZJCkO0jaqrHJ2p9yNfWkpQhD1YolBCtV0ZplPhlHdhZ8C0 1WFfIesQvrlMDJ6pdN8fJInjPlLxd1mcge4bd70fHX1KGaM74NkdB+KRi g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgkFABjjfVKtJXHB/2dsb2JhbABZgwc4U75QSoEqFnSCJwECAgEBATc0HQEINjcLJQIEARKIAQ29B49uhDADmA+BL5BbgyaCKg X-IronPort-AV: E=Sophos;i="4.93,666,1378857600"; d="scan'208";a="282819352" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-4.cisco.com with ESMTP; 09 Nov 2013 07:26:40 +0000 Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id rA97QegQ027898 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 9 Nov 2013 07:26:40 GMT Received: from xmb-aln-x15.cisco.com ([169.254.9.147]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.03.0123.003; Sat, 9 Nov 2013 01:26:40 -0600 From: "Rong Pan (ropan)" To: Bob Briscoe , tsv-area IETF list , AQM IETF list , tsvwg IETF list Thread-Topic: [aqm] Immediate ECN: Autotuning AQM for RTT Thread-Index: AQHO2/SBttchdmU52kqbSkB491ElhpocT9oA Date: Sat, 9 Nov 2013 07:26:39 +0000 Message-ID: In-Reply-To: <201311072003.rA7K38dj008566@bagheera.jungle.bt.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.1.120420 x-originating-ip: [10.21.114.54] Content-Type: text/plain; charset="us-ascii" Content-ID: <33D401EC59EEEF4D98A6A1BA5C6A87CD@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Sat, 09 Nov 2013 08:26:04 -0800 Subject: Re: [tsvwg] [aqm] Immediate ECN: Autotuning AQM for RTT 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, 09 Nov 2013 07:27:01 -0000 I just got a better understanding of Bob's proposal. Great direction indeed! I fully agreed that doing the smoothing at the end hosts and simple network congestion signals is the best way to achieve low averaging latency.=20 We do need these three working groups working together to get this done. But since folks usually attend all these three meetings at IETF, I am hopeful that IETF can make it happen with all our efforts together here. Bob,=20 a technical question. If we do no averaging for ECN, and hosts use the tradition ECN-capable TCP, I am afraid its window might get cut too much to achieve any reasonable throughput. Any thought on how to handle that? Or maybe you already covered in your slides and I missed it? Thanks, Rong On 11/7/13 12:03 PM, "Bob Briscoe" wrote: >Folks, > >"Immediate ECN" slides: > > > >PS. This talk fell off the end of the TSVAREA agenda. It's mostly >relevant to AQM, but I didn't originally bring it to AQM, because it >affects 3 wgs: tsvwg, aqm & tcpm. > >In the AQM wg, there was dismay about CableLabs not including >anything about ECN in DOCSIS3.1. This talk is about AQM dynamics; and >how ECN can take out the 100ms of delay that CoDel and PIE introduce >- it's essentially about auto-tuning for RTT. > >It gives an interim recommendation for hardware designers that there >should be a second instance of the AQM algo for ECN packets so that >it can be configured with different parameters (think of WRED instead of >RED). > >Specifically, for ECN packets: >interval =3D 0 (for CoDel) >max_burst =3D 0 (for PIE) > > >Bob > >PS. We have a paper under submission, which we can supply on request. >We plan to document this in the IETF too. > > > > >________________________________________________________________ >Bob Briscoe, BT > >_______________________________________________ >aqm mailing list >aqm@ietf.org >https://www.ietf.org/mailman/listinfo/aqm From gorry@erg.abdn.ac.uk Mon Nov 11 07:05:17 2013 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 7E8D111E817D for ; Mon, 11 Nov 2013 07:05:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.551 X-Spam-Level: X-Spam-Status: No, score=-105.551 tagged_above=-999 required=5 tests=[AWL=-0.811, BAYES_20=-0.74, 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 edQ6kvqUGwzW for ; Mon, 11 Nov 2013 07:05:12 -0800 (PST) Received: from spey.erg.abdn.ac.uk (spey.erg.abdn.ac.uk [139.133.204.173]) by ietfa.amsl.com (Postfix) with ESMTP id B670611E817A for ; Mon, 11 Nov 2013 07:05:12 -0800 (PST) Received: from www.erg.abdn.ac.uk (blake.erg.abdn.ac.uk [139.133.210.30]) by spey.erg.abdn.ac.uk (Postfix) with ESMTPSA id 1D8BD2B435B for ; Mon, 11 Nov 2013 15:05:11 +0000 (GMT) Received: from 212.159.18.54 (SquirrelMail authenticated user gorry) by www.erg.abdn.ac.uk with HTTP; Mon, 11 Nov 2013 15:05:11 -0000 Message-ID: Date: Mon, 11 Nov 2013 15:05:11 -0000 From: gorry@erg.abdn.ac.uk To: tsvwg@ietf.org User-Agent: SquirrelMail/1.4.22 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Subject: [tsvwg] Draft copies of notes from meetings uploaded 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, 11 Nov 2013 15:05:17 -0000 Please check the notes from last weeks meetings uploaded at: http://www.ietf.org/proceedings/88/minutes/minutes-88-tsvwg If you are a draft author, please scan the notes to help prepare an updated version of your draft or raise any issues on this list. If you see things that should be corrected please email the list/chairs. Gorry, James & David TSVWG co-Chairs From bob.briscoe@bt.com Mon Nov 11 08:18:24 2013 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 69DB521E8064; Mon, 11 Nov 2013 08:18:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.748 X-Spam-Level: X-Spam-Status: No, score=-2.748 tagged_above=-999 required=5 tests=[AWL=-0.376, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227] 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 5mbiYKnv2su4; Mon, 11 Nov 2013 08:18:19 -0800 (PST) Received: from hubrelay-rd.bt.com (hubrelay-rd.bt.com [62.239.224.98]) by ietfa.amsl.com (Postfix) with ESMTP id 2EC5A11E8122; Mon, 11 Nov 2013 08:18:18 -0800 (PST) Received: from EVMHR71-UKRD.domain1.systemhost.net (10.36.3.109) by EVMHR65-UKRD.bt.com (10.187.101.20) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 11 Nov 2013 16:18:16 +0000 Received: from EPHR02-UKIP.domain1.systemhost.net (147.149.100.81) by EVMHR71-UKRD.domain1.systemhost.net (10.36.3.109) with Microsoft SMTP Server (TLS) id 8.3.279.1; Mon, 11 Nov 2013 16:18:16 +0000 Received: from bagheera.jungle.bt.co.uk (132.146.168.158) by EPHR02-UKIP.domain1.systemhost.net (147.149.100.81) with Microsoft SMTP Server id 14.2.347.0; Mon, 11 Nov 2013 16:18:09 +0000 Received: from BTP075694.jungle.bt.co.uk ([10.111.171.204]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id rABGI8D4031128; Mon, 11 Nov 2013 16:18:09 GMT Message-ID: <201311111618.rABGI8D4031128@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 11 Nov 2013 16:17:59 +0000 To: "Rong Pan (ropan)" From: Bob Briscoe In-Reply-To: References: <201311072003.rA7K38dj008566@bagheera.jungle.bt.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 Cc: tsv-area IETF list , AQM IETF list , tsvwg IETF list Subject: Re: [tsvwg] [aqm] Immediate ECN: Autotuning AQM for RTT 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, 11 Nov 2013 16:18:24 -0000 Rong, At 07:26 09/11/2013, Rong Pan (ropan) wrote: >I just got a better understanding of Bob's proposal. Great direction >indeed! I fully agreed that doing the smoothing at the end hosts and >simple network congestion signals is the best way to achieve low averaging >latency. > >We do need these three working groups working together to get this done. >But since folks usually attend all these three meetings at IETF, I am >hopeful that IETF can make it happen with all our efforts together here. It seems the IETF is willing to move quickly on this. We brought this work to the IETF earlier than I would normally have liked, given the urgency. We will try continue to move quickly, but it would be great if different groups could work in parallel. For instance, if your group and/or others could focus on testing this out with PIE. more... >Bob, > >a technical question. If we do no averaging for ECN, and hosts use the >tradition ECN-capable TCP, I am afraid its window might get cut too much >to achieve any reasonable throughput. Any thought on how to handle that? >Or maybe you already covered in your slides and I missed it? Bear in mind that altho traditional ECN hosts (we call them classic ECN) cut their rate by half in response to one CE mark they only do this once per RTT, then they ignore all the other marks in the same RTT. DCTCP only cuts its rate a little per mark, but it does so for every mark. So it's not obvious what the outcome will be, but I'm hopeful that classic ECN hosts will achieve sufficient througput when competing with DCTCP, for some definition of 'sufficient'. Testing incremental deployment cases like this is next on our list of experiments to do. I intended to say this on slide 13 (there's a brief footnote to this effect), but I had to cut short, because I had to squeeze a 20min presentation into the last 15 mins of tsvwg. Regards Bob >Thanks, > >Rong > > > >On 11/7/13 12:03 PM, "Bob Briscoe" wrote: > > >Folks, > > > >"Immediate ECN" slides: > > > > > > > >PS. This talk fell off the end of the TSVAREA agenda. It's mostly > >relevant to AQM, but I didn't originally bring it to AQM, because it > >affects 3 wgs: tsvwg, aqm & tcpm. > > > >In the AQM wg, there was dismay about CableLabs not including > >anything about ECN in DOCSIS3.1. This talk is about AQM dynamics; and > >how ECN can take out the 100ms of delay that CoDel and PIE introduce > >- it's essentially about auto-tuning for RTT. > > > >It gives an interim recommendation for hardware designers that there > >should be a second instance of the AQM algo for ECN packets so that > >it can be configured with different parameters (think of WRED instead of > >RED). > > > >Specifically, for ECN packets: > >interval = 0 (for CoDel) > >max_burst = 0 (for PIE) > > > > > >Bob > > > >PS. We have a paper under submission, which we can supply on request. > >We plan to document this in the IETF too. > > > > > > > > > >________________________________________________________________ > >Bob Briscoe, BT > > > >_______________________________________________ > >aqm mailing list > >aqm@ietf.org > >https://www.ietf.org/mailman/listinfo/aqm ________________________________________________________________ Bob Briscoe, BT From bob.briscoe@bt.com Mon Nov 11 08:18:34 2013 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 DF68521E81E8; Mon, 11 Nov 2013 08:18:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.238 X-Spam-Level: X-Spam-Status: No, score=-3.238 tagged_above=-999 required=5 tests=[AWL=0.134, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_OBFU_Q1=0.227] 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 rl-sd5K6thnZ; Mon, 11 Nov 2013 08:18:29 -0800 (PST) Received: from hubrelay-rd.bt.com (hubrelay-rd.bt.com [62.239.224.99]) by ietfa.amsl.com (Postfix) with ESMTP id 627CF21E81D6; Mon, 11 Nov 2013 08:18:28 -0800 (PST) Received: from EVMHR71-UKRD.domain1.systemhost.net (10.36.3.109) by EVMHR68-UKRD.bt.com (10.187.101.23) with Microsoft SMTP Server (TLS) id 8.3.279.1; Mon, 11 Nov 2013 16:18:26 +0000 Received: from EPHR01-UKIP.domain1.systemhost.net (147.149.196.177) by EVMHR71-UKRD.domain1.systemhost.net (10.36.3.109) with Microsoft SMTP Server (TLS) id 8.3.279.1; Mon, 11 Nov 2013 16:18:25 +0000 Received: from bagheera.jungle.bt.co.uk (132.146.168.158) by EPHR01-UKIP.domain1.systemhost.net (147.149.196.177) with Microsoft SMTP Server id 14.2.347.0; Mon, 11 Nov 2013 16:18:22 +0000 Received: from BTP075694.jungle.bt.co.uk ([10.111.171.204]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id rABGILbC031136; Mon, 11 Nov 2013 16:18:21 GMT Message-ID: <201311111618.rABGILbC031136@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 11 Nov 2013 16:02:36 +0000 To: Greg White From: Bob Briscoe In-Reply-To: References: <201311072003.rA7K38dj008566@bagheera.jungle.bt.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 Cc: tsv-area IETF list , AQM IETF list , tsvwg IETF list Subject: Re: [tsvwg] Immediate ECN: Autotuning AQM for RTT 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, 11 Nov 2013 16:18:35 -0000 Greg, At 06:54 09/11/2013, Greg White wrote: >This is very interesting work. There are a lot of unanswered questions >about ecn / no-ecn coexistence and differential treatment in an AQM, and >this could provide some answers. > >To those who groaned that ECN was not included in DOCSIS 3.1, read these >slides (and Naeem Khademi's). Indeed. However, I think it would be safe to recommend that ECN support should at least be implemented and separately configurable, then it can be turned on or off by operators later. I'm aware that this doubles the amount of configuration, but we've had some success already (with RED) in relating all the ECN parameters to the drop parameters by a formula, so hopefully the vendor could configure the ECN parameters automatically based on the drop parameters. >Bob, CoDel uses "interval" both as a hold-off for the first packet drop >and as the numerator in the invsqrt drop scheduling. Setting interval = 0 >would result in ECN being signaled on *every* ECN capable packet when the >sojourn time is above threshold. This jibes with some of your charts >for RED, but others show a ramp up in mark probability rather than a step >function. Could you clarify? We've only looked at WRED in detail, because it was much more interesting (to us) to reconfigure existing implementations than have to wait for new code to be implemented and tested. The suggestions for PIE and CoDel are just conceptual at this stage - we've done no implementation of this idea with either. (I said this verbally when presenting the slides, but I should have put it in writing too). Please read my suggestions for PIE and CoDel in this light. I'm not surprised that CoDel derives other parameters from 'interval' that should have been declared and set separately. Andrew McGregor also pointed out to me that CoDel sets threshold = 0.2*interval, so threshold would have to be declared separately as well. This starts to reveal just how many magic numbers there really are in the CoDel algorithm. >Setting max_burst = 0 in PIE would not result in the step function >behavior. It's not meant to result in a step-function. In the WRED example, it solely avoids the delay of queue averaging, so that once the /instantaneous/ queue exceeds min_thresh it marks with increasing probability (not intended to be a step). Similarly with PIE, the formula: p = p + alpha*(est_del-target_del) + beta*(est_del-est_del_old); would still gradually increase the probability of drop (not a step function), but it would start to do so as soon as the queue exceeded target_del, rather than waiting for max_burst. Is that what you meant? Bob >-Greg > > >On 11/7/13, 1:03 PM, "Bob Briscoe" wrote: > > >Folks, > > > >"Immediate ECN" slides: > > > > > > > >PS. This talk fell off the end of the TSVAREA agenda. It's mostly > >relevant to AQM, but I didn't originally bring it to AQM, because it > >affects 3 wgs: tsvwg, aqm & tcpm. > > > >In the AQM wg, there was dismay about CableLabs not including > >anything about ECN in DOCSIS3.1. This talk is about AQM dynamics; and > >how ECN can take out the 100ms of delay that CoDel and PIE introduce > >- it's essentially about auto-tuning for RTT. > > > >It gives an interim recommendation for hardware designers that there > >should be a second instance of the AQM algo for ECN packets so that > >it can be configured with different parameters (think of WRED instead of > >RED). > > > >Specifically, for ECN packets: > >interval = 0 (for CoDel) > >max_burst = 0 (for PIE) > > > > > >Bob > > > >PS. We have a paper under submission, which we can supply on request. > >We plan to document this in the IETF too. > > > > > > > > > >________________________________________________________________ > >Bob Briscoe, BT ________________________________________________________________ Bob Briscoe, BT From vbannai@paypal.com Mon Nov 11 09:54:11 2013 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 F210011E81C4 for ; Mon, 11 Nov 2013 09:54:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.049 X-Spam-Level: X-Spam-Status: No, score=-0.049 tagged_above=-999 required=5 tests=[AWL=-0.417, BAYES_00=-2.599, HTML_MESSAGE=0.001, SARE_FORGED_PAYPAL_C=1.3, SARE_HTML_USL_OBFU=1.666] 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 iH4vk2ZyVKPb for ; Mon, 11 Nov 2013 09:54:06 -0800 (PST) Received: from phx-mipot-002.corp.ebay.com (phx-mipot-002.corp.ebay.com [216.113.172.65]) by ietfa.amsl.com (Postfix) with ESMTP id BE87D11E81C6 for ; Mon, 11 Nov 2013 09:54:06 -0800 (PST) DomainKey-Signature: s=paypalcorp; d=paypal.com; c=nofws; q=dns; h=X-EBay-Corp:X-IronPort-AV:Received:Received:From:To:CC: Subject:Thread-Topic:Thread-Index:Date:Message-ID: In-Reply-To:Accept-Language:Content-Language: X-MS-Has-Attach:X-MS-TNEF-Correlator:user-agent: x-originating-ip:Content-Type:MIME-Version:X-CFilter; b=uO4RhENJWJzCmibD1WGZl+AZA7pOV4RIryCDKIB2rney1asjeiuy/Uvr aMWzOGjL7KyKTAgancQtfrpXDmJ8TSQJ1oiCdY2u1nWwBfeNpWUtrYYIo NexAsKR/X99cbJ9McwlYBcI1nG/ySHoNt1+smG4rDk4ZeROcxA+VsHnpT 8=; DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=paypal.com; i=@paypal.com; q=dns/txt; s=paypalcorp; t=1384192446; x=1415728446; h=from:to:cc:subject:date:message-id:in-reply-to: mime-version; bh=Cssz+TJ2zCNz+5DXIRhGVRuUADFFPBNbXbMd3TUTuHc=; b=KFxIY7moqXiKHyCvqXyq22gy6zwoXWzukgyBxuz4tQIyfrRf0Fzonzin YK3OWJMiI3WDIZU7KAlqpKe3/qOIRrSp9yoFHKzI5M03uZAvh82R/lCD6 yyQL6VmtLdkfRGTxxETMrYB8WhuuJDUh4bq7f7rcvxwnDnsJ/XlMeBCDX E=; X-EBay-Corp: Yes X-IronPort-AV: E=Sophos;i="4.93,679,1378882800"; d="scan'208,217";a="177798497" Received: from phx-vteml-004.corp.ebay.com (HELO PHX-EXMHT-001.corp.ebay.com) ([10.58.40.103]) by phx-mipot-002.corp.ebay.com with ESMTP; 11 Nov 2013 09:54:06 -0800 Received: from PHX-EXRDA-S12.corp.ebay.com ([169.254.13.58]) by PHX-EXMHT-001.corp.ebay.com ([10.58.12.70]) with mapi id 14.03.0158.001; Mon, 11 Nov 2013 10:54:06 -0700 From: "Bannai, Vinay" To: "tsvwg@ietf.org" Thread-Topic: Who supports tsvwg adoption of adding ECN to L2 or tunnel protocols? Thread-Index: AQHO3pDt+rFctRFdvkiXdz7/nqOocJogLu4AgAAAfYA= Date: Mon, 11 Nov 2013 17:54:05 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.8.130913 x-originating-ip: [10.58.61.242] Content-Type: multipart/alternative; boundary="_000_CEA6599111FD3vbannaipaypalcom_" MIME-Version: 1.0 X-CFilter: Scanned Cc: "draft-briscoe-tsvwg-ecn-encap-guidelines@tools.ietf.org" Subject: Re: [tsvwg] Who supports tsvwg adoption of adding ECN to L2 or tunnel protocols? 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, 11 Nov 2013 17:54:11 -0000 --_000_CEA6599111FD3vbannaipaypalcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I support this draft. -- Vinay Bannai 408-967-7784 Cloud Engineering Date: Mon, 04 Nov 2013 22:03:45 +0000 To: "tsvwg IETF list" >, AQM IETF lis= t > From: Bob Briscoe > Subject: Who supports tsvwg adoption of adding ECN to L2 or tunnel protocol= s? Cc: John Kaippallimalil >, Pat Thaler >, draft-briscoe-tsvwg-ecn-encap-guidelines@tools.ietf.org Folks, Pls respond if you support this being adopted as a work-group item in the I= ETF transport services w-g (tsvwg). The WG chairs need visibility of intere= st. Even better, if you're willing to read / comment / review / implement Guidelines for Adding Congestion Notification to Protocols that Encapsulate= IP Abstract The purpose of this document is to guide the design of congestion notification in any lower layer or tunnelling protocol that encapsulates IP. The aim is for explicit congestion signals to propagate consistently from lower layer protocols into IP. Then the IP internetwork layer can act as a portability layer to carry congestion notification from non-IP-aware congested nodes up to the transport layer (L4). Following these guidelines should assure interworking between new lower layer congestion notification mechanisms, whether specified by the IETF or other standards bodies. [Cross-posting tsvwg & aqm, just in case] Bob Briscoe, also for co-authors Pat Thaler and John Kaippallimalil ________________________________________________________________ Bob Briscoe, BT ________________________________________________________________ Bob Briscoe, BT -- Vinay Bannai Email: vbannai@gmail.com Google Voice: 415 938 7576 --_000_CEA6599111FD3vbannaipaypalcom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable

I support this draft. 

-- 
Vinay Bannai
408-967-7784
Cloud Engineering

Date: Mon, 04 Nov 2013 22:03:45 +0000
To: "tsvwg IETF list" <tsvwg@ietf.org>, AQM IETF list <aqm@ietf.org>
From: Bob Briscoe <bob.briscoe@bt.com>
Subject: Who supports tsvwg adoption of adding ECN to L2 or tunnel protocol= s?
Cc: John Kaippallimalil <John.Kaippallimalil@huawei.com>, Pat Tha= ler <pthaler@b= roadcom.com>, draft-briscoe-tsvwg-ecn-encap-guidelines@tools.ietf.org

Folks,

Pls respond if you support this being adopted as a work-group item in the I= ETF transport services w-g (tsvwg). The WG chairs need visibility of intere= st.
Even better, if you're willing to read / comment / review / implement

Guidelines for Adding Congestion Notification to Protocols that Encapsulate= IP
<http://tools.ietf.org/html/draft-briscoe-= tsvwg-ecn-encap-guidelines>

Abstract

   The purpose of this document is to guide the design of congest= ion
   notification in any lower layer or tunnelling protocol that    encapsulates IP.  The aim is for explicit congestion sign= als to
   propagate consistently from lower layer protocols into IP. &nb= sp;Then the
   IP internetwork layer can act as a portability layer to carry<= br>    congestion notification from non-IP-aware congested nodes up t= o the
   transport layer (L4).  Following these guidelines should = assure
   interworking between new lower layer congestion notification    mechanisms, whether specified by the IETF or other standards b= odies.


[Cross-posting tsvwg & aqm, just in case]


Bob Briscoe,
also for co-authors Pat Thaler and John Kaippallimalil

_____________________________________________________________= ___
Bob Briscoe,                  =                     &nbs= p;          BT

_____________________________________________________________= ___
Bob Briscoe,                  =                     &nbs= p;          BT  



--
Vinay Bannai
Email: vbannai@gmail.com
Google Voice: 415 938 7576
 --_000_CEA6599111FD3vbannaipaypalcom_-- From mirja.kuehlewind@ikr.uni-stuttgart.de Mon Nov 11 10:34:27 2013 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 AE00F21E80CF for ; Mon, 11 Nov 2013 10:34:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3] 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 nDLDzGhZJdun for ; Mon, 11 Nov 2013 10:34:23 -0800 (PST) Received: from mailsrv.ikr.uni-stuttgart.de (mailsrv.ikr.uni-stuttgart.de [129.69.170.2]) by ietfa.amsl.com (Postfix) with ESMTP id 434AE21E80C0 for ; Mon, 11 Nov 2013 10:34:23 -0800 (PST) Received: from netsrv1.ikr.uni-stuttgart.de (netsrv1-c [10.11.12.12]) by mailsrv.ikr.uni-stuttgart.de (Postfix) with ESMTP id E52BC60236; Mon, 11 Nov 2013 19:34:21 +0100 (CET) Received: from vpn-2-cl195 (vpn-2-cl195 [10.41.21.195]) by netsrv1.ikr.uni-stuttgart.de (Postfix) with ESMTP id DF03760235; Mon, 11 Nov 2013 19:34:21 +0100 (CET) From: Mirja =?iso-8859-1?q?K=FChlewind?= To: tsvwg@ietf.org Date: Mon, 11 Nov 2013 19:34:21 +0100 User-Agent: KMail/1.9.10 (enterprise35 0.20101217.1207316) References: <201311042203.rA4M3lo0026458@bagheera.jungle.bt.co.uk> In-Reply-To: <201311042203.rA4M3lo0026458@bagheera.jungle.bt.co.uk> X-KMail-QuotePrefix: > MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <201311111934.21649.mirja.kuehlewind@ikr.uni-stuttgart.de> Subject: Re: [tsvwg] Who supports tsvwg adoption of adding ECN to L2 or tunnel protocols? 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, 11 Nov 2013 18:34:27 -0000 Hi, I support this being a working group item. It's value work and the draft is already in very good shape. Mirja On Monday 04 November 2013 23:03:45 Bob Briscoe wrote: > Folks, > > Pls respond if you support this being adopted as a work-group item in > the IETF transport services w-g (tsvwg). The WG chairs need > visibility of interest. > Even better, if you're willing to read / comment / review / implement > > Guidelines for Adding Congestion Notification to Protocols that Encapsulate > IP > > Abstract > > The purpose of this document is to guide the design of congestion > notification in any lower layer or tunnelling protocol that > encapsulates IP. The aim is for explicit congestion signals to > propagate consistently from lower layer protocols into IP. Then the > IP internetwork layer can act as a portability layer to carry > congestion notification from non-IP-aware congested nodes up to the > transport layer (L4). Following these guidelines should assure > interworking between new lower layer congestion notification > mechanisms, whether specified by the IETF or other standards bodies. > > > [Cross-posting tsvwg & aqm, just in case] > > > Bob Briscoe, > also for co-authors Pat Thaler and John Kaippallimalil > > > ________________________________________________________________ > Bob Briscoe, BT From gorry@erg.abdn.ac.uk Mon Nov 11 10:48:32 2013 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 D37D921E80CD for ; Mon, 11 Nov 2013 10:48:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.454 X-Spam-Level: X-Spam-Status: No, score=-106.454 tagged_above=-999 required=5 tests=[AWL=0.145, 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 VRqGvFyAPIfZ for ; Mon, 11 Nov 2013 10:48:28 -0800 (PST) Received: from spey.erg.abdn.ac.uk (spey.erg.abdn.ac.uk [139.133.204.173]) by ietfa.amsl.com (Postfix) with ESMTP id 738C121E8218 for ; Mon, 11 Nov 2013 10:48:26 -0800 (PST) Received: from www.erg.abdn.ac.uk (blake.erg.abdn.ac.uk [139.133.210.30]) by spey.erg.abdn.ac.uk (Postfix) with ESMTPSA id 29AB92B435B for ; Mon, 11 Nov 2013 18:48:25 +0000 (GMT) Received: from 212.159.18.54 (SquirrelMail authenticated user gorry) by www.erg.abdn.ac.uk with HTTP; Mon, 11 Nov 2013 18:48:25 -0000 Message-ID: <8daaaa67ba71d3e35630009cfb39243a.squirrel@www.erg.abdn.ac.uk> In-Reply-To: <201311111934.21649.mirja.kuehlewind@ikr.uni-stuttgart.de> References: <201311042203.rA4M3lo0026458@bagheera.jungle.bt.co.uk> <201311111934.21649.mirja.kuehlewind@ikr.uni-stuttgart.de> Date: Mon, 11 Nov 2013 18:48:25 -0000 From: gorry@erg.abdn.ac.uk To: tsvwg@ietf.org User-Agent: SquirrelMail/1.4.22 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Subject: Re: [tsvwg] Who supports tsvwg adoption of adding ECN to L2 or tunnel protocols? 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, 11 Nov 2013 18:48:33 -0000 OK, there seems to be a little confusion here (especially for people who were not at the meeting). Just to be clear the WG Chairs did NOT start an adoption call for this as a TSVWG work item, and no decision was made at the IETF meeting in Vancouver regarding this draft. If the Chairs and ADs decide this is a topic where the WG can do work, we'll then ask for support from within the working group. Gorry > Hi, > > I support this being a working group item. It's value work and the draft > is > already in very good shape. > > Mirja > > > On Monday 04 November 2013 23:03:45 Bob Briscoe wrote: >> Folks, >> >> Pls respond if you support this being adopted as a work-group item in >> the IETF transport services w-g (tsvwg). The WG chairs need >> visibility of interest. >> Even better, if you're willing to read / comment / review / implement >> >> Guidelines for Adding Congestion Notification to Protocols that >> Encapsulate >> IP >> >> Abstract >> >> The purpose of this document is to guide the design of congestion >> notification in any lower layer or tunnelling protocol that >> encapsulates IP. The aim is for explicit congestion signals to >> propagate consistently from lower layer protocols into IP. Then the >> IP internetwork layer can act as a portability layer to carry >> congestion notification from non-IP-aware congested nodes up to the >> transport layer (L4). Following these guidelines should assure >> interworking between new lower layer congestion notification >> mechanisms, whether specified by the IETF or other standards bodies. >> >> >> [Cross-posting tsvwg & aqm, just in case] >> >> >> Bob Briscoe, >> also for co-authors Pat Thaler and John Kaippallimalil >> >> >> ________________________________________________________________ >> Bob Briscoe, BT > > From g.white@CableLabs.com Mon Nov 11 10:57:31 2013 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 2D71C21E8224; Mon, 11 Nov 2013 10:57:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.236 X-Spam-Level: X-Spam-Status: No, score=-0.236 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, SARE_SUB_OBFU_Q1=0.227] 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 QozbaJe2ryM1; Mon, 11 Nov 2013 10:57:24 -0800 (PST) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by ietfa.amsl.com (Postfix) with ESMTP id 6E7F811E80E6; Mon, 11 Nov 2013 10:57:09 -0800 (PST) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.7/8.14.7) with ESMTP id rABIv4to029629; Mon, 11 Nov 2013 11:57:04 -0700 Received: from exchange.cablelabs.com (10.5.0.19) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/407/kyzyl.cablelabs.com); Mon, 11 Nov 2013 11:57:04 -0700 (MST) X-Virus-Status: clean(F-Secure/fsigk_smtp/407/kyzyl.cablelabs.com) Received: from EXCHANGE.cablelabs.com ([fe80::797a:96d1:3c53:18ee]) by EXCHANGE.cablelabs.com ([fe80::797a:96d1:3c53:18ee%11]) with mapi id 14.03.0146.000; Mon, 11 Nov 2013 11:57:04 -0700 From: Greg White To: Bob Briscoe Thread-Topic: [tsvwg] Immediate ECN: Autotuning AQM for RTT Thread-Index: AQHO2/R7zNZxx+pCdEmOwIOO+63dlZocaFeAgARD+QD//7tjAA== Date: Mon, 11 Nov 2013 18:57:03 +0000 Message-ID: In-Reply-To: <201311111618.rABGILbC031136@bagheera.jungle.bt.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.8.130913 x-originating-ip: [10.5.0.27] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <7BE71D21E1C7ED42B7253AF79810863D@cablelabs.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Approved: ondar Cc: tsv-area IETF list , AQM IETF list , tsvwg IETF list Subject: Re: [tsvwg] Immediate ECN: Autotuning AQM for RTT 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, 11 Nov 2013 18:57:31 -0000 On 11/11/13, 9:02 AM, "Bob Briscoe" wrote: >Greg, > >At 06:54 09/11/2013, Greg White wrote: >>This is very interesting work. There are a lot of unanswered questions >>about ecn / no-ecn coexistence and differential treatment in an AQM, and >>this could provide some answers. >> >>To those who groaned that ECN was not included in DOCSIS 3.1, read these >>slides (and Naeem Khademi's). > >Indeed. However, I think it would be safe to recommend that ECN >support should at least be implemented and separately configurable, >then it can be turned on or off by operators later. > >I'm aware that this doubles the amount of configuration, but we've >had some success already (with RED) in relating all the ECN >parameters to the drop parameters by a formula, so hopefully the >vendor could configure the ECN parameters automatically based on the >drop parameters. I don't have a lot of confidence that I can recommend something to be burned into silicon at this point (and doing it in software is a non-starter). The "turned on or off by operators later" would be a given, but if implemented based on what we know now, I don't have a lot of confidence that the switch would be ever set to the "turned on" state. I can't recommend that vendors add gates for a feature that my intuition tells me would never be used. If separately configurable means something that would increase the probability of the feature being used, then that's great, but what specifically are we talking about? It could be a lot of gates. Also, you've suggested *not* differentiating between "classic ECN" and "immediate ECN" in the ECT flags, but this is just a suggestion at this point. Again, not something I feel confident about taking for granted. We'll continue to track this discussion though. >>Bob, CoDel uses "interval" both as a hold-off for the first packet drop >>and as the numerator in the invsqrt drop scheduling. Setting interval = =3D >>0 >>would result in ECN being signaled on *every* ECN capable packet when the >>sojourn time is above threshold. This jibes with some of your charts >>for RED, but others show a ramp up in mark probability rather than a step >>function. Could you clarify? > >We've only looked at WRED in detail, because it was much more >interesting (to us) to reconfigure existing implementations than have >to wait for new code to be implemented and tested. > >The suggestions for PIE and CoDel are just conceptual at this stage - >we've done no implementation of this idea with either. (I said this >verbally when presenting the slides, but I should have put it in >writing too). Please read my suggestions for PIE and CoDel in this light. > >I'm not surprised that CoDel derives other parameters from 'interval' >that should have been declared and set separately. Andrew McGregor >also pointed out to me that CoDel sets threshold =3D 0.2*interval, so >threshold would have to be declared separately as well. This starts >to reveal just how many magic numbers there really are in the CoDel >algorithm. In the ns2 CoDel code that we've used (from Kathie), there are two independent parameters, threshold and interval, and the defaults are 5ms for threshold and 100ms for interval, so I don=B9t know where the "threshol= d =3D 0.2*interval" is coming from (maybe it is different in the current linu= x or openWRT distros). To be more clear about my earlier statement, CoDel actually uses "interval" to control a single aspect of the drop policy, however, the code (and descriptions of it) imply that there are two different functions, and my comments above were written in that vein. However, here's how I would describe it more succinctly: the "next drop time" is always set according to interval/sqrt(count). In the specific case of sojourn time crossing above threshold from below, count happens to equal 1, so the first drop is set at one interval in the future. This is what is sometimes described as the "hold off" period. That said, there are some "magic numbers" in the algorithm, specifically the part that regulates very low drop probabilities (e.g. 8*interval, count *=3D 0.9844), but that=B9s about it. I=B9m still thinking about how to achieve differential treatment of marking vs dropping in CoDel in a logical way. > > >>Setting max_burst =3D 0 in PIE would not result in the step function >>behavior. > >It's not meant to result in a step-function. > >In the WRED example, it solely avoids the delay of queue averaging, >so that once the /instantaneous/ queue exceeds min_thresh it marks >with increasing probability (not intended to be a step). > >Similarly with PIE, the formula: > p =3D p + alpha*(est_del-target_del) + beta*(est_del-est_del_old)= ; >would still gradually increase the probability of drop (not a step >function), but it would start to do so as soon as the queue exceeded >target_del, rather than waiting for max_burst. > >Is that what you meant? Yes, that is what I meant. However, it seemed to me that what you were proposing was to move the intelligence to the transport, and keep the queue simple. In that regard, would a very simple threshold: always mark when instantaneous queue exceeds the threshold, never mark when it doesn=B9t, be an acceptable way t= o do things? This would be easily implementable, and could be straightforwardly combined (I think) with any AQM that is controlling drops (including CoDel).=20 -Greg > > >Bob > > >>-Greg >> >> >>On 11/7/13, 1:03 PM, "Bob Briscoe" wrote: >> >> >Folks, >> > >> >"Immediate ECN" slides: >> > >> > >> > >> >PS. This talk fell off the end of the TSVAREA agenda. It's mostly >> >relevant to AQM, but I didn't originally bring it to AQM, because it >> >affects 3 wgs: tsvwg, aqm & tcpm. >> > >> >In the AQM wg, there was dismay about CableLabs not including >> >anything about ECN in DOCSIS3.1. This talk is about AQM dynamics; and >> >how ECN can take out the 100ms of delay that CoDel and PIE introduce >> >- it's essentially about auto-tuning for RTT. >> > >> >It gives an interim recommendation for hardware designers that there >> >should be a second instance of the AQM algo for ECN packets so that >> >it can be configured with different parameters (think of WRED instead >>of >> >RED). >> > >> >Specifically, for ECN packets: >> >interval =3D 0 (for CoDel) >> >max_burst =3D 0 (for PIE) >> > >> > >> >Bob >> > >> >PS. We have a paper under submission, which we can supply on request. >> >We plan to document this in the IETF too. >> > >> > >> > >> > >> >________________________________________________________________ >> >Bob Briscoe, BT > >________________________________________________________________ >Bob Briscoe, BT > From bob.briscoe@bt.com Tue Nov 12 03:21:11 2013 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 72FFD21E805D; Tue, 12 Nov 2013 03:21:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.241 X-Spam-Level: X-Spam-Status: No, score=-3.241 tagged_above=-999 required=5 tests=[AWL=0.130, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_OBFU_Q1=0.227] 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 SbNd7ef0QCmD; Tue, 12 Nov 2013 03:21:06 -0800 (PST) Received: from hubrelay-by-04.bt.com (hubrelay-by-04.bt.com [62.7.242.140]) by ietfa.amsl.com (Postfix) with ESMTP id 7BF4811E80E3; Tue, 12 Nov 2013 03:21:05 -0800 (PST) Received: from EVMHR01-UKBR.domain1.systemhost.net (193.113.108.40) by EVMHR04-UKBR.bt.com (10.216.161.36) with Microsoft SMTP Server (TLS) id 8.3.297.1; Tue, 12 Nov 2013 11:21:00 +0000 Received: from EPHR01-UKIP.domain1.systemhost.net (147.149.196.177) by EVMHR01-UKBR.domain1.systemhost.net (193.113.108.40) with Microsoft SMTP Server (TLS) id 8.3.297.1; Tue, 12 Nov 2013 11:21:03 +0000 Received: from bagheera.jungle.bt.co.uk (132.146.168.158) by EPHR01-UKIP.domain1.systemhost.net (147.149.196.177) with Microsoft SMTP Server id 14.2.347.0; Tue, 12 Nov 2013 11:20:59 +0000 Received: from BTP075694.jungle.bt.co.uk ([10.215.131.145]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id rACBKvrp001693; Tue, 12 Nov 2013 11:20:57 GMT Message-ID: <201311121120.rACBKvrp001693@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 12 Nov 2013 11:20:57 +0000 To: "Fred Baker (fred)" From: Bob Briscoe In-Reply-To: References: <201311042203.rA4M3lo0026458@bagheera.jungle.bt.co.uk> <145AB1C0-B108-4196-AD5C-3667103FB4D8@cisco.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_129284674==.ALT" X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 Cc: "" , tsvwg IETF list , AQM IETF list Subject: Re: [tsvwg] [aqm] Who supports tsvwg adoption of adding ECN to L2 or tunnel protocols? 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, 12 Nov 2013 11:21:11 -0000 --=====================_129284674==.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Fred, For the record, Andrew and I spent an evening to see if we could come up with a solution to indicate non-congestive loss. We started with a list of 9 different causes of loss (from my PhD thesis). We worked through a number of ideas, but they all exhibit varying degrees of problems. So we all agree indicating non-congestive loss is a research problem for now... Bob At 20:38 08/11/2013, Andrew Mcgregor wrote: >I agree, non-congestive loss notification is a research >problem. So, out of scope for the IETF right now but I hope someone >thinks about it (I will, as a background task). > > >On 8 November 2013 11:49, Fred Baker (fred) ><fred@cisco.com> wrote: > >At 23:04 04/11/2013, Andrew Mcgregor wrote: > > This seems like valuable work. One question is, can we put in > scope notification that losses are NOT due to congestion? > >Speaking for myself, I'm not sure how I would do that. > >A loss (or mark) due to congestion is pretty simple. The switch >knows what it did. > >To know that a packet was lost for reasons other than congestion, I >need to somehow know what packets I should expect, and infer that >something that I expected didn't happen. In TCP, we know about data >segments because they are enumerated - I know what the next octet >sequence number to expect, and it doesn't arrive. Control segments >(SYN, ACK, FIN, RST, and so on) are not enumerated in that sense - >if my peer sends ten identical acks and nine arrive, I as the >receiver have no way to know that. At the link layer, most link >protocols in use today (PPP, Ethernet, and so on) do not enumerate >packets in flight - they are simply there. I *might* be able to see >a burst of noise on the line, but only if it looks like it might be >the start of a packet and then doesn't end with the right checksum. >Even if I can see it, I have no way to know whether the noise >garbled one packet or many. > >If you want to do some research and come up with a solution, be my >guest. But in a standard discussed in 2013... let's not. > >_______________________________________________ >aqm mailing list >aqm@ietf.org >https://www.ietf.org/mailman/listinfo/aqm > > > > >-- >Andrew McGregor | SRE | >andrewmcgr@google.com | +61 4 8143 7128 >_______________________________________________ >aqm mailing list >aqm@ietf.org >https://www.ietf.org/mailman/listinfo/aqm ________________________________________________________________ Bob Briscoe, BT --=====================_129284674==.ALT Content-Type: text/html; charset="us-ascii" Fred,

For the record, Andrew and I spent an evening to see if we could come up with a solution to indicate non-congestive loss. We started with a list of 9 different causes of loss (from my PhD thesis). We worked through a number of ideas, but they all exhibit varying degrees of problems.

So we all agree indicating non-congestive loss is a research problem for now...


Bob

At 20:38 08/11/2013, Andrew Mcgregor wrote:
I agree, non-congestive loss notification is a research problem.  So, out of scope for the IETF right now but I hope someone thinks about it (I will, as a background task).


On 8 November 2013 11:49, Fred Baker (fred) <fred@cisco.com> wrote:

At 23:04 04/11/2013, Andrew Mcgregor wrote:
> This seems like valuable work.  One question is, can we put in scope notification that losses are NOT due to congestion?

Speaking for myself, I'm not sure how I would do that.

A loss (or mark) due to congestion is pretty simple. The switch knows what it did.

To know that a packet was lost for reasons other than congestion, I need to somehow know what packets I should expect, and infer that something that I expected didn't happen. In TCP, we know about data segments because they are enumerated - I know what the next octet sequence number to expect, and it doesn't arrive. Control segments (SYN, ACK, FIN, RST, and so on) are not enumerated in that sense - if my peer sends ten identical acks and nine arrive, I as the receiver have no way to know that. At the link layer, most link protocols in use today (PPP, Ethernet, and so on) do not enumerate packets in flight - they are simply there. I *might* be able to see a burst of noise on the line, but only if it looks like it might be the start of a packet and then doesn't end with the right checksum. Even if I can see it, I have no way to know whether the noise garbled one packet or many.

If you want to do some research and come up with a solution, be my guest. But in a standard discussed in 2013... let's not.

_______________________________________________
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm




--
Andrew McGregor | SRE | andrewmcgr@google.com | +61 4 8143 7128
_______________________________________________
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm

________________________________________________________________
Bob Briscoe,                                                  BT --=====================_129284674==.ALT-- From rs@netapp.com Tue Nov 12 05:18:39 2013 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 1204111E814F; Tue, 12 Nov 2013 05:18:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.585 X-Spam-Level: X-Spam-Status: No, score=-9.585 tagged_above=-999 required=5 tests=[AWL=0.787, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, SARE_SUB_OBFU_Q1=0.227] 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 jv4KBCmxp3qI; Tue, 12 Nov 2013 05:18:33 -0800 (PST) Received: from mx12.netapp.com (mx12.netapp.com [216.240.18.77]) by ietfa.amsl.com (Postfix) with ESMTP id E843B11E8158; Tue, 12 Nov 2013 05:18:33 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.93,684,1378882800"; d="scan'208";a="114455222" Received: from vmwexceht04-prd.hq.netapp.com ([10.106.77.34]) by mx12-out.netapp.com with ESMTP; 12 Nov 2013 05:18:32 -0800 Received: from SACEXCMBX02-PRD.hq.netapp.com ([169.254.1.86]) by vmwexceht04-prd.hq.netapp.com ([10.106.77.34]) with mapi id 14.03.0123.003; Tue, 12 Nov 2013 05:18:31 -0800 From: "Scheffenegger, Richard" To: Greg White , Bob Briscoe Thread-Topic: [tsvwg] Immediate ECN: Autotuning AQM for RTT Thread-Index: AQHO2/SJueB8pq8PMUCFvNdOsi72LJoc/zgAgAO92wCAADC+gIAAo9PQ Date: Tue, 12 Nov 2013 13:18:28 +0000 Message-ID: <012C3117EDDB3C4781FD802A8C27DD4F25E8908F@SACEXCMBX02-PRD.hq.netapp.com> References: <201311111618.rABGILbC031136@bagheera.jungle.bt.co.uk> 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.106.53.53] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: tsv-area IETF list , AQM IETF list , tsvwg IETF list Subject: Re: [tsvwg] Immediate ECN: Autotuning AQM for RTT 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, 12 Nov 2013 13:18:39 -0000 Hi Greg et.al., (chair hat off) > I don't have a lot of confidence that I can recommend something to be > burned into silicon at this point (and doing it in software is a non- > starter). The "turned on or off by operators later" would be a given, bu= t > if implemented based on what we know now, I don't have a lot of confidenc= e > that the switch would be ever set to the "turned on" state. I can't > recommend that vendors add gates for a feature that my intuition tells me > would never be used. If separately configurable means something that > would increase the probability of the feature being used, then that's > great, but what specifically are we talking about? It could be a lot of > gates. So, as I am not a HW guy, how many gates does one need for (W)RED, PIE, CoD= el? Apparently, as state needs to be kept separately for ECN and non-ECN flows,= additional memory plus some way of switching between which memory is used = for what packet is necessary; however, the hardcoded algos should be the sa= me (as far as some tuneables are stored in memory instead of hardwired gate= s). > Also, you've suggested *not* differentiating between "classic ECN" and > "immediate ECN" in the ECT flags, but this is just a suggestion at this > point. Again, not something I feel confident about taking for granted. > We'll continue to track this discussion though. As Bob pointed out in another email, classic ECN will react to any number o= f marks within one RTT (of that particular flow) with only a single halving= of the congestion window. Most other transports that have been modeled aft= er TCP/ECN will behave similarly. Immediate ECN will react to each mark to = a smaller extent, and only a full window (RTT) of marks will reduce the win= dow by half. Thus immediate ECN would be much more aggressive when used wit= h traditional RED, ie. push the AQM to higher marking probabilities. One venue that presents itself here, of course, is to use 2nd order effect = - i.e. the exact marking pattern - to achive reasonable fairness between tr= ansports making use of immediate and classic reactions. However, I can not = say offhand, if this would be a practical method (may require too much stat= e in the scheduling/aqm, including fine grained flow separation). > However, it seemed to me that what you were proposing was to move the > intelligence to the transport, and keep the queue simple. In that regard, > would a very simple threshold: always mark when instantaneous queue > exceeds the threshold, never mark when it doesn=B9t, be an acceptable way= to > do things? >=20 > This would be easily implementable, and could be straightforwardly > combined (I think) with any AQM that is controlling drops (including > CoDel). That is what DCTCP currently does. However, a simple step function is incom= patible with classic ECN.=20 While reading Bob's earlier comment on classic vs immediate ECN, I thought = that probably an exponential increase in marking probability, above a speci= fic threshold (lower than drop) could "autotune" to a reasonable marking ra= te, without necessarily locking classic out when immediate is used. If the = linear/step function employed with RED (and shown on Bobs slides) is a good= enough approximation needs to be verified. However, the details will proba= bly also depend on the mixure of number of classic vs. immediate ECN flows = at the bottleneck, and their respective RTTs... Finally, as the gateways (switches) cannot rely on ECN to work (either on t= he required timescales, as the RTT is too large for small buffers, or the t= ransport/sender is not reacting), even ECN traffic has to be exposed to dro= ps - and ideally here not to the tail-drop variant. Richard Scheffenegger From fred@cisco.com Tue Nov 12 09:20:16 2013 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 E049711E8122; Tue, 12 Nov 2013 09:20:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.31 X-Spam-Level: X-Spam-Status: No, score=-110.31 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, SARE_SUB_OBFU_Q1=0.227, 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 1glmsO9LD9au; Tue, 12 Nov 2013 09:20:12 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id C420B11E8171; Tue, 12 Nov 2013 09:20:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11813; q=dns/txt; s=iport; t=1384276812; x=1385486412; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=WD60/Y04B0Fqlxq0qyUZUILpWe12H4jxE1H2+Uh/4OQ=; b=mKFA/uONtWK9YOzW1oN9efcA1CV4OLb2caBV2y+qEwV2Ur/ayw2BewiE L6FgAhSNAll9av5W56Ll1Ttb1w3jfH7Weq5U56F9ouhhaH9UZkL7Bg07u gTceulmgGW9kqa49QhPrrcomyMaxmquaO+o8WVFzJLxaJAkosVlti48yk o=; X-Files: signature.asc : 195 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhIFACViglKtJV2Y/2dsb2JhbABagkNEOFO/FoEqFnSCJQEBAQMBAQEBawsFCwIBCBguJwslAgQOBQ4Nh2AGDb8PBI9bBAeDIIERA5AwgTCGL5IKgyaCKg X-IronPort-AV: E=Sophos;i="4.93,686,1378857600"; d="asc'?scan'208,217";a="283751498" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-2.cisco.com with ESMTP; 12 Nov 2013 17:20:11 +0000 Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id rACHKBV3023566 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 12 Nov 2013 17:20:11 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.122]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.03.0123.003; Tue, 12 Nov 2013 11:20:10 -0600 From: "Fred Baker (fred)" To: Bob Briscoe Thread-Topic: [aqm] Who supports tsvwg adoption of adding ECN to L2 or tunnel protocols? Thread-Index: AQHO38twDsbxdPtw6UOkQQuUi2YoxQ== Date: Tue, 12 Nov 2013 17:20:10 +0000 Message-ID: <9A8352AB-7EA4-42ED-AFD8-E127B51E5922@cisco.com> References: <201311042203.rA4M3lo0026458@bagheera.jungle.bt.co.uk> <145AB1C0-B108-4196-AD5C-3667103FB4D8@cisco.com> <201311121120.rACBKvrp001693@bagheera.jungle.bt.co.uk> In-Reply-To: <201311121120.rACBKvrp001693@bagheera.jungle.bt.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.19.64.121] Content-Type: multipart/signed; boundary="Apple-Mail=_FF882833-DA3B-4593-BE2D-0AF2C7A7F58A"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Cc: "" , tsvwg IETF list , AQM IETF list Subject: Re: [tsvwg] [aqm] Who supports tsvwg adoption of adding ECN to L2 or tunnel protocols? 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, 12 Nov 2013 17:20:17 -0000 --Apple-Mail=_FF882833-DA3B-4593-BE2D-0AF2C7A7F58A Content-Type: multipart/alternative; boundary="Apple-Mail=_FAC78530-5001-407F-AC1D-579788339EED" --Apple-Mail=_FAC78530-5001-407F-AC1D-579788339EED Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Thanks.=20 Personally, I think it is two problems. One, which I imagine is the one = you worked on, is the question of detection; we can detect loss at an = endpoint (it doesn't see something it expects to see) but not reliably = (it might not be expecting something, but an outside observer expects it = to see something, and it doesn't see it). The other is the question of = what one does about it. If it is an unreliable interface injecting = packet errors, one can route around it. If it's a wireless interface = (unreliable in the sense that the probability of error is = non-negligible), one might route around it, or one might impose some = variation on ARQ or FEC, as we do in WiFi and other technologies. If = it's another source of non-congestive loss, I suspect that the solution = is somehow tailored to the mode of operation. I can tell you that we have a capability for video streaming = applications in which we enumerate packets and literally send two = streams on disjoint paths. At the receiving end, we discard the second = instance of a packet that arrives. In the event of loss in the network, = we expect that to reduce the probability of non-delivery to a negligible = value. Solutions like that can be a cost-effective solution to = non-congestive loss, I should think. On Nov 12, 2013, at 3:20 AM, Bob Briscoe wrote: > Fred, >=20 > For the record, Andrew and I spent an evening to see if we could come = up with a solution to indicate non-congestive loss. We started with a = list of 9 different causes of loss (from my PhD thesis). We worked = through a number of ideas, but they all exhibit varying degrees of = problems. >=20 > So we all agree indicating non-congestive loss is a research problem = for now... >=20 >=20 > Bob >=20 > At 20:38 08/11/2013, Andrew Mcgregor wrote: >> I agree, non-congestive loss notification is a research problem. So, = out of scope for the IETF right now but I hope someone thinks about it = (I will, as a background task). >>=20 >>=20 >> On 8 November 2013 11:49, Fred Baker (fred) wrote: >>=20 >> At 23:04 04/11/2013, Andrew Mcgregor wrote: >> > This seems like valuable work. One question is, can we put in = scope notification that losses are NOT due to congestion? >>=20 >> Speaking for myself, I'm not sure how I would do that. >>=20 >> A loss (or mark) due to congestion is pretty simple. The switch knows = what it did. >>=20 >> To know that a packet was lost for reasons other than congestion, I = need to somehow know what packets I should expect, and infer that = something that I expected didn't happen. In TCP, we know about data = segments because they are enumerated - I know what the next octet = sequence number to expect, and it doesn't arrive. Control segments (SYN, = ACK, FIN, RST, and so on) are not enumerated in that sense - if my peer = sends ten identical acks and nine arrive, I as the receiver have no way = to know that. At the link layer, most link protocols in use today (PPP, = Ethernet, and so on) do not enumerate packets in flight - they are = simply there. I *might* be able to see a burst of noise on the line, but = only if it looks like it might be the start of a packet and then doesn't = end with the right checksum. Even if I can see it, I have no way to know = whether the noise garbled one packet or many. >>=20 >> If you want to do some research and come up with a solution, be my = guest. But in a standard discussed in 2013... let's not. >>=20 >> _______________________________________________ >> aqm mailing list >> aqm@ietf.org >> https://www.ietf.org/mailman/listinfo/aqm >>=20 >>=20 >>=20 >>=20 >> --=20 >> Andrew McGregor | SRE | andrewmcgr@google.com | +61 4 8143 7128 >> _______________________________________________ >> aqm mailing list >> aqm@ietf.org >> https://www.ietf.org/mailman/listinfo/aqm > ________________________________________________________________ > Bob Briscoe, BT >=20 Make things as simple as possible, but not simpler. Albert Einstein --Apple-Mail=_FAC78530-5001-407F-AC1D-579788339EED Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii bob.briscoe@bt.com> = wrote:


Fred,

For the record, Andrew and I spent an evening to see if we could come up with a solution to indicate non-congestive loss. We started with a list of 9 different causes of loss (from my PhD thesis). We worked through a number of ideas, but they all exhibit varying degrees of problems.

So we all agree indicating non-congestive loss is a research problem for now...


Bob

At 20:38 08/11/2013, Andrew Mcgregor wrote:
I agree, = non-congestive loss notification is a research problem.  So, out of scope for the IETF right now but I hope someone thinks about it (I will, as a background task).


On 8 November 2013 11:49, Fred Baker (fred) <fred@cisco.com> wrote:

At 23:04 04/11/2013, Andrew Mcgregor wrote:
> This seems like valuable work.  One question is, can = we put in scope notification that losses are NOT due to congestion?

Speaking for myself, I'm not sure how I would do that.

A loss (or mark) due to congestion is pretty simple. The switch = knows what it did.

To know that a packet was lost for reasons other than = congestion, I need to somehow know what packets I should expect, and infer that something that I expected didn't happen. In TCP, we know about data segments because they are enumerated - I know what the next octet sequence number to expect, and it doesn't arrive. Control segments (SYN, ACK, FIN, RST, and so on) are not enumerated in that sense - if my peer sends ten identical acks and nine arrive, I as the receiver have no way to know that. At the link layer, most link protocols in use today (PPP, Ethernet, and so on) do not enumerate packets in flight - they are = simply there. I *might* be able to see a burst of noise on the line, but only = if it looks like it might be the start of a packet and then doesn't end = with the right checksum. Even if I can see it, I have no way to know whether the noise garbled one packet or many.

If you want to do some research and come up with a solution, be = my guest. But in a standard discussed in 2013... let's not.

_______________________________________________
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm




--
Andrew McGregor | SRE | andrewmcgr@google.com | +61 = 4 8143 7128
_______________________________________________
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm

________________________________________________________________
Bob = Briscoe,           =             &n= bsp;           &nbs= p;            =   BT


  • Make things as simple as possible, but = not simpler.
    • Albert Einstein

    = --Apple-Mail=_FAC78530-5001-407F-AC1D-579788339EED-- --Apple-Mail=_FF882833-DA3B-4593-BE2D-0AF2C7A7F58A Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iD8DBQFSgmNHbjEdbHIsm0MRApgFAJoDYJrdGlk8DEEhNTTpmQBfYjw0mgCfa8NU JSxcxv+wFmayw2t6bPvn+bI= =x9nx -----END PGP SIGNATURE----- --Apple-Mail=_FF882833-DA3B-4593-BE2D-0AF2C7A7F58A-- From bob.briscoe@bt.com Tue Nov 12 14:20:53 2013 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 114EC21E8090; Tue, 12 Nov 2013 14:20:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.745 X-Spam-Level: X-Spam-Status: No, score=-2.745 tagged_above=-999 required=5 tests=[AWL=-0.373, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227] 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 ElDKZbE7AdQv; Tue, 12 Nov 2013 14:20:48 -0800 (PST) Received: from hubrelay-rd.bt.com (hubrelay-rd.bt.com [62.239.224.98]) by ietfa.amsl.com (Postfix) with ESMTP id A953921E8095; Tue, 12 Nov 2013 14:20:47 -0800 (PST) Received: from EVMHR02-UKBR.domain1.systemhost.net (193.113.108.41) by EVMHR66-UKRD.bt.com (10.187.101.21) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 12 Nov 2013 22:20:45 +0000 Received: from EPHR02-UKIP.domain1.systemhost.net (147.149.100.81) by EVMHR02-UKBR.domain1.systemhost.net (193.113.108.41) with Microsoft SMTP Server (TLS) id 8.3.297.1; Tue, 12 Nov 2013 22:20:45 +0000 Received: from bagheera.jungle.bt.co.uk (132.146.168.158) by EPHR02-UKIP.domain1.systemhost.net (147.149.100.81) with Microsoft SMTP Server id 14.2.347.0; Tue, 12 Nov 2013 22:20:43 +0000 Received: from BTP075694.jungle.bt.co.uk ([10.215.131.145]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id rACMKfo9003510; Tue, 12 Nov 2013 22:20:41 GMT Message-ID: <201311122220.rACMKfo9003510@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 12 Nov 2013 22:20:41 +0000 To: Greg White From: Bob Briscoe In-Reply-To: References: <201311111618.rABGILbC031136@bagheera.jungle.bt.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 Cc: tsv-area IETF list , AQM IETF list , tsvwg IETF list Subject: Re: [tsvwg] [aqm] Immediate ECN: Autotuning AQM for RTT 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, 12 Nov 2013 22:20:53 -0000 Greg, inline... At 18:57 11/11/2013, Greg White wrote: >On 11/11/13, 9:02 AM, "Bob Briscoe" wrote: > > >Greg, > > > >At 06:54 09/11/2013, Greg White wrote: > >>This is very interesting work. There are a lot of unanswered questions > >>about ecn / no-ecn coexistence and differential treatment in an AQM, and > >>this could provide some answers. > >> > >>To those who groaned that ECN was not included in DOCSIS 3.1, read these > >>slides (and Naeem Khademi's). > > > >Indeed. However, I think it would be safe to recommend that ECN > >support should at least be implemented and separately configurable, > >then it can be turned on or off by operators later. > > > >I'm aware that this doubles the amount of configuration, but we've > >had some success already (with RED) in relating all the ECN > >parameters to the drop parameters by a formula, so hopefully the > >vendor could configure the ECN parameters automatically based on the > >drop parameters. > >I don't have a lot of confidence that I can recommend something to be >burned into silicon at this point (and doing it in software is a >non-starter). The "turned on or off by operators later" would be a given, >but if implemented based on what we know now, I don't have a lot of >confidence that the switch would be ever set to the "turned on" state. I >can't recommend that vendors add gates for a feature that my intuition >tells me would never be used. If separately configurable means something >that would increase the probability of the feature being used, then that's >great, but what specifically are we talking about? It could be a lot of >gates. > >Also, you've suggested *not* differentiating between "classic ECN" and >"immediate ECN" in the ECT flags, but this is just a suggestion at this >point. Again, not something I feel confident about taking for granted. >We'll continue to track this discussion though. Understood. Given the cable industry has decided to move on=20 this early schedule, we can now do the necessary=20 research so that competing access technologies can properly exploit ECN ;) more... > >>Bob, CoDel uses "interval" both as a hold-off for the first packet drop > >>and as the numerator in the invsqrt drop scheduling. Setting interval = =3D > >>0 > >>would result in ECN being signaled on *every* ECN capable packet when= the > >>sojourn time is above threshold. This jibes with some of your charts > >>for RED, but others show a ramp up in mark probability rather than a= step > >>function. Could you clarify? > > > >We've only looked at WRED in detail, because it was much more > >interesting (to us) to reconfigure existing implementations than have > >to wait for new code to be implemented and tested. > > > >The suggestions for PIE and CoDel are just conceptual at this stage - > >we've done no implementation of this idea with either. (I said this > >verbally when presenting the slides, but I should have put it in > >writing too). Please read my suggestions for PIE and CoDel in this light. > > > >I'm not surprised that CoDel derives other parameters from 'interval' > >that should have been declared and set separately. Andrew McGregor > >also pointed out to me that CoDel sets threshold =3D 0.2*interval, so > >threshold would have to be declared separately as well. This starts > >to reveal just how many magic numbers there really are in the CoDel > >algorithm. > > >In the ns2 CoDel code that we've used (from Kathie), there are two >independent parameters, threshold and interval, and the defaults are 5ms >for threshold and 100ms for interval, so I don=B9t know where the= "threshold >=3D 0.2*interval" is coming from (maybe it is different in the current= linux >or openWRT distros). Sorry, altho it turns out I was wrong anyway (see below), I meant to say: 0.05 * interval (=3D interval / 20) I was working from memory and I knew there was a 2 in there somewhere. Andrew McGregor said at the mic in tsvwg last=20 Friday that threshold was defined relative to=20 interval, and I remembered it from when I first=20 looked at the CoDel code. However, I've just=20 checked and even Andrew's ns3 port of CoDel sets=20 threshold to 5ms, independent of the setting of=20 interval. So consider this a memory thow-back on everyone's part and ignore= it. >To be more clear about my earlier statement, CoDel actually uses >"interval" to control a single aspect of the drop policy, however, the >code (and descriptions of it) imply that there are two different >functions, and my comments above were written in that vein. However, >here's how I would describe it more succinctly: the "next drop time" is >always set according to interval/sqrt(count). In the specific case of >sojourn time crossing above threshold from below, count happens to equal >1, so the first drop is set at one interval in the future. This is what >is sometimes described as the "hold off" period. OK. From an admittedly hasty scan through Andrew=20 McGregor's port of CoDel to ns3 (not the Linux=20 code), it seems to introduce this hold-off time=20 in the ControlLaw() function, but it only calls=20 ControlLaw() from the ShouldDrop() function if=20 the queue has remained above threshold for duration interval. That implies that CoDel holds off signalling=20 anything for 2 * interval, ie 200ms for the=20 default setting of interval =3D 100ms. >That said, there are some "magic numbers" in the algorithm, specifically >the part that regulates very low drop probabilities (e.g. 8*interval, >count *=3D 0.9844), but that=B9s about it. And the following magic numbers, of course: * threshold [5ms] * the power used in the control law [0.5 in the sqrt function] >I=B9m still thinking about how to achieve differential treatment of marking >vs dropping in CoDel in a logical way. That would only be possible if CoDel's control=20 law for drop was based on some understandable=20 logic in the first place. I've started another=20 thread on that, based on analysis I've just done of CoDel's control law. A naive answer would be to create a second=20 variable for the interval used in ControlLaw(),=20 let's call it I. Then solely set interval =3D 0. But that would still leave a signalling delay of=20 I. As you say, CoDel's control law for increasing=20 the dropping frequency is also based on the assumption that I =3D RTT =3D= 100ms. By my analysis (in the other email), the=20 rationale for CoDel's current control law seems=20 incorrect, which is probably why we're finding=20 it's tough to base any new thinking on it. > > > > > >>Setting max_burst =3D 0 in PIE would not result in the step function > >>behavior. > > > >It's not meant to result in a step-function. > > > >In the WRED example, it solely avoids the delay of queue averaging, > >so that once the /instantaneous/ queue exceeds min_thresh it marks > >with increasing probability (not intended to be a step). > > > >Similarly with PIE, the formula: > > p =3D p + alpha*(est_del-target_del) += beta*(est_del-est_del_old); > >would still gradually increase the probability of drop (not a step > >function), but it would start to do so as soon as the queue exceeded > >target_del, rather than waiting for max_burst. > > > >Is that what you meant? > > >Yes, that is what I meant. > >However, it seemed to me that what you were proposing was to move the >intelligence to the transport, and keep the queue simple. In that regard, >would a very simple threshold: always mark when instantaneous queue >exceeds the threshold, never mark when it doesn=B9t, be an acceptable way= to >do things? > >This would be easily implementable, and could be straightforwardly >combined (I think) with any AQM that is controlling drops (including >CoDel). A simple step threshold would be fine if all=20 traffic used ECN. DCTCP proves that such a really=20 dumb AQM works well if complemented by a smarter=20 TCP (which proved to me that our problem is with TCP). But I don't think it's so easy to combine such a=20 simple AQM for ECN traffic, with a complex AQM like CoDel for drop. The logic I started from was: * If starvation is going to happen, it will happen over time * So we should be able to design two AQMs (for=20 ECN and drop) that will not cause each other to=20 starve, by only considering where they eventually=20 converge to - solely in the presence of stable=20 long-running flows. We can elide dynamics, like=20 smoothing, that disappear over time. * CoDel looks for the min queuing delay over=20 interval, so we can elide that part of its=20 behaviour. But the control law continues to=20 increase drop with time, irrespective of how the=20 queue is growing (as long as it is greater than=20 threshold). Then, when drop is high enough,=20 assuming responsive flows, the CoDel queue will=20 fall below threshold and switch back to=20 non-dropping mode. Then the cycle will repeat.=20 It's not easy to elide away behaviour that=20 stabilises by continually switching between two=20 discrete modes, rather than stabilising in one mode. This is what the short-term memory within CoDel=20 does - if it returns to dropping mode soon enough=20 after leaving it, it starts dropping from where=20 it left off. So it's actually continually=20 switching in and out of dropping mode, which=20 makes it much harder to think about analytically.=20 And much harder to design a complementary ECN behaviour for it. ________ I prefer the principle: "Design for=20 Verifiability", which is why I always have an=20 allergic reaction to CoDel. See John Doyle's=20 paper below, which uses TCP and AQM design as a=20 case study for how to use and abuse this principle: Doyle, J.C., Carlson, J., Low, S.H., Paganini,=20 F., Vinnicombe, G., Willinger, W., Hickey, J.,=20 Parrilo, P. & Vandenberghe, L., "Robustness and=20 the Internet: Theoretical Foundations," Caltech Draft Paper (March 2002) The IRTF network complexity research group is=20 trying to make this stuff understandable by us mere IETFers. Bob >-Greg > > > > > > > >Bob > > > > > >>-Greg > >> > >> > >>On 11/7/13, 1:03 PM, "Bob Briscoe" wrote: > >> > >> >Folks, > >> > > >> >"Immediate ECN" slides: > >> > > >> > > >> > > >> >PS. This talk fell off the end of the TSVAREA agenda. It's mostly > >> >relevant to AQM, but I didn't originally bring it to AQM, because it > >> >affects 3 wgs: tsvwg, aqm & tcpm. > >> > > >> >In the AQM wg, there was dismay about CableLabs not including > >> >anything about ECN in DOCSIS3.1. This talk is about AQM dynamics; and > >> >how ECN can take out the 100ms of delay that CoDel and PIE introduce > >> >- it's essentially about auto-tuning for RTT. > >> > > >> >It gives an interim recommendation for hardware designers that there > >> >should be a second instance of the AQM algo for ECN packets so that > >> >it can be configured with different parameters (think of WRED instead > >>of > >> >RED). > >> > > >> >Specifically, for ECN packets: > >> >interval =3D 0 (for CoDel) > >> >max_burst =3D 0 (for PIE) > >> > > >> > > >> >Bob > >> > > >> >PS. We have a paper under submission, which we can supply on request. > >> >We plan to document this in the IETF too. > >> > > >> > > >> > > >> > > >> >________________________________________________________________ > >> >Bob Briscoe, BT > > > >________________________________________________________________ > >Bob Briscoe, BT > > > >_______________________________________________ >aqm mailing list >aqm@ietf.org >https://www.ietf.org/mailman/listinfo/aqm ________________________________________________________________ Bob Briscoe, BT=20 From bob.briscoe@bt.com Tue Nov 12 15:03:48 2013 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 652F211E8102; Tue, 12 Nov 2013 15:03:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.742 X-Spam-Level: X-Spam-Status: No, score=-2.742 tagged_above=-999 required=5 tests=[AWL=-0.370, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227] 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 EquY7NDhynvd; Tue, 12 Nov 2013 15:03:43 -0800 (PST) Received: from hubrelay-rd.bt.com (hubrelay-rd.bt.com [62.239.224.98]) by ietfa.amsl.com (Postfix) with ESMTP id 8146F21E80A5; Tue, 12 Nov 2013 15:03:32 -0800 (PST) Received: from EVMHR01-UKBR.domain1.systemhost.net (193.113.108.40) by EVMHR66-UKRD.bt.com (10.187.101.21) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 12 Nov 2013 23:03:30 +0000 Received: from EPHR02-UKIP.domain1.systemhost.net (147.149.100.81) by EVMHR01-UKBR.domain1.systemhost.net (193.113.108.40) with Microsoft SMTP Server (TLS) id 8.3.297.1; Tue, 12 Nov 2013 23:03:27 +0000 Received: from bagheera.jungle.bt.co.uk (132.146.168.158) by EPHR02-UKIP.domain1.systemhost.net (147.149.100.81) with Microsoft SMTP Server id 14.2.347.0; Tue, 12 Nov 2013 23:03:22 +0000 Received: from BTP075694.jungle.bt.co.uk ([10.215.131.145]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id rACN3LUX003607; Tue, 12 Nov 2013 23:03:21 GMT Message-ID: <201311122303.rACN3LUX003607@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 12 Nov 2013 23:03:20 +0000 To: "Scheffenegger, Richard" From: Bob Briscoe In-Reply-To: <012C3117EDDB3C4781FD802A8C27DD4F25E8908F@SACEXCMBX02-PRD.h q.netapp.com> References: <201311111618.rABGILbC031136@bagheera.jungle.bt.co.uk> <012C3117EDDB3C4781FD802A8C27DD4F25E8908F@SACEXCMBX02-PRD.hq.netapp.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 Cc: tsv-area IETF list , AQM IETF list , tsvwg IETF list Subject: Re: [tsvwg] [aqm] Immediate ECN: Autotuning AQM for RTT 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, 12 Nov 2013 23:03:48 -0000 Richard, I've replied separately to Greg - apologies for splitting the thread.= Inline... At 13:18 12/11/2013, Scheffenegger, Richard wrote: >Hi Greg et.al., > >(chair hat off) > > > I don't have a lot of confidence that I can recommend something to be > > burned into silicon at this point (and doing it in software is a non- > > starter). The "turned on or off by operators later" would be a given,= but > > if implemented based on what we know now, I don't have a lot of= confidence > > that the switch would be ever set to the "turned on" state. I can't > > recommend that vendors add gates for a feature that my intuition tells= me > > would never be used. If separately configurable means something that > > would increase the probability of the feature being used, then that's > > great, but what specifically are we talking about? It could be a lot of > > gates. > >So, as I am not a HW guy, how many gates does one need for (W)RED, PIE,= CoDel? > >Apparently, as state needs to be kept separately=20 >for ECN and non-ECN flows, additional memory=20 >plus some way of switching between which memory=20 >is used for what packet is necessary; however,=20 >the hardcoded algos should be the same (as far=20 >as some tuneables are stored in memory instead of hardwired gates). I'll let the hw people answer that, but it seems a reasonable point. > > Also, you've suggested *not* differentiating between "classic ECN" and > > "immediate ECN" in the ECT flags, but this is just a suggestion at this > > point. Again, not something I feel confident about taking for granted. > > We'll continue to track this discussion though. > >As Bob pointed out in another email, classic ECN=20 >will react to any number of marks within one RTT=20 >(of that particular flow) with only a single=20 >halving of the congestion window. Most other=20 >transports that have been modeled after TCP/ECN=20 >will behave similarly. Immediate ECN will react=20 >to each mark to a smaller extent, and only a=20 >full window (RTT) of marks will reduce the=20 >window by half. Thus immediate ECN would be much=20 >more aggressive when used with traditional RED,=20 >ie. push the AQM to higher marking probabilities. The paper (available on request, because still=20 under submission) records experiments that show=20 we can get equal rates between otherwise=20 equivalent ECN and drop flows as long as the=20 parameters of the two ramps are connected by a=20 formula. This formula was found by fitting to the=20 very clear curve visible along the ridge of the=20 3-D plot on our slide 11=20 . I'm sure this will not be the whole story, but=20 it's a good start. I believe that such parameter=20 settings only lead to equal rates between an ECN=20 and a drop flow for one of each type of flow. I=20 won't be particularly worried if the relative=20 rates stray from precise equality under different=20 conditions, as long as there is no starvation,=20 and they remain in the same ball-park. >One venue that presents itself here, of course,=20 >is to use 2nd order effect - i.e. the exact=20 >marking pattern - to achive reasonable fairness=20 >between transports making use of immediate and=20 >classic reactions. However, I can not say=20 >offhand, if this would be a practical method=20 >(may require too much state in the=20 >scheduling/aqm, including fine grained flow separation). Hopefully we won't need to go there. > > However, it seemed to me that what you were proposing was to move the > > intelligence to the transport, and keep the queue simple. In that= regard, > > would a very simple threshold: always mark when instantaneous queue > > exceeds the threshold, never mark when it doesn=B9t, be an acceptable= way to > > do things? > > > > This would be easily implementable, and could be straightforwardly > > combined (I think) with any AQM that is controlling drops (including > > CoDel). > >That is what DCTCP currently does. I wasn't aware that DCTCP was already being used=20 alongside non-ECN traffic. Is this what you meant? >However, a simple step function is incompatible with classic ECN. I think you mean classic ECN TCP flows. If so, I=20 wouldn't state this quite so strongly (yet). I=20 suspect there will be conditions where a classic=20 ECN TCP will be somewhat disadvantaged. However, we need experiments to see: * whether the disadvantage is slight, * how many classic ECN hosts might be affected, * and the likelihood that their owners would=20 rapidly upgrade them (AFAIK, their owners must=20 have already intervened manually for ECN hosts to=20 already be in the wild, given I believe ECN is=20 turned off by default in TCP clients under the major operating systems). >While reading Bob's earlier comment on classic=20 >vs immediate ECN, I thought that probably an=20 >exponential increase in marking probability,=20 >above a specific threshold (lower than drop)=20 >could "autotune" to a reasonable marking rate,=20 >without necessarily locking classic out when=20 >immediate is used. If the linear/step function=20 >employed with RED (and shown on Bobs slides) is=20 >a good enough approximation needs to be=20 >verified. However, the details will probably=20 >also depend on the mixure of number of classic=20 >vs. immediate ECN flows at the bottleneck, and their respective RTTs... Agreed. >Finally, as the gateways (switches) cannot rely=20 >on ECN to work (either on the required=20 >timescales, as the RTT is too large for small=20 >buffers, or the transport/sender is not=20 >reacting), even ECN traffic has to be exposed to drops Agreed > - and ideally here not to the tail-drop variant. It may not be necessary to switch an ECN flow to=20 AQM-generated drops - it may be sufficient to=20 switch both ECN and drop traffic to tail drop at=20 the same time - when load exceeds the operating=20 region of the AQM as a whole. But, you may be right - needs more= experiments. Bob >Richard Scheffenegger > > >_______________________________________________ >aqm mailing list >aqm@ietf.org >https://www.ietf.org/mailman/listinfo/aqm ________________________________________________________________ Bob Briscoe, BT=20 From ilpo.jarvinen@helsinki.fi Tue Nov 12 15:20:41 2013 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 80D5921E8089; Tue, 12 Nov 2013 15:20:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.072 X-Spam-Level: X-Spam-Status: No, score=-6.072 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Q1=0.227] 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 TA-rg+51T2Wc; Tue, 12 Nov 2013 15:20:34 -0800 (PST) Received: from courier.cs.helsinki.fi (courier.cs.helsinki.fi [128.214.9.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8083911E814D; Tue, 12 Nov 2013 15:20:33 -0800 (PST) Received: from melkinpaasi.cs.helsinki.fi (melkinpaasi.cs.helsinki.fi [128.214.9.14]) (TLS: TLSv1/SSLv3,256bits,AES256-SHA) by mail.cs.helsinki.fi with esmtp; Wed, 13 Nov 2013 01:20:16 +0200 id 00068157.5282B7B0.00003231 Date: Wed, 13 Nov 2013 01:20:16 +0200 (EET) From: "=?ISO-8859-15?Q?Ilpo_J=E4rvinen?=" X-X-Sender: ijjarvin@melkinpaasi.cs.helsinki.fi To: Bob Briscoe In-Reply-To: <201311122220.rACMKfo9003510@bagheera.jungle.bt.co.uk> Message-ID: References: <201311111618.rABGILbC031136@bagheera.jungle.bt.co.uk> <201311122220.rACMKfo9003510@bagheera.jungle.bt.co.uk> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-CS-Test-DKIM: none Cc: tsv-area IETF list , AQM IETF list , tsvwg IETF list Subject: Re: [tsvwg] [aqm] Immediate ECN: Autotuning AQM for RTT 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, 12 Nov 2013 23:20:41 -0000 On Tue, 12 Nov 2013, Bob Briscoe wrote: > Greg, inline... > > At 18:57 11/11/2013, Greg White wrote: > > > > On 11/11/13, 9:02 AM, "Bob Briscoe" wrote: > > > > >Greg, > > > > > >At 06:54 09/11/2013, Greg White wrote: > > > > > >>Bob, CoDel uses "interval" both as a hold-off for the first packet drop > > >>and as the numerator in the invsqrt drop scheduling. Setting interval = > > >>0 > > >>would result in ECN being signaled on *every* ECN capable packet when the > > >>sojourn time is above threshold. This jibes with some of your charts > > >>for RED, but others show a ramp up in mark probability rather than a step > > >>function. Could you clarify? > > > > > >We've only looked at WRED in detail, because it was much more > > >interesting (to us) to reconfigure existing implementations than have > > >to wait for new code to be implemented and tested. > > > > > >The suggestions for PIE and CoDel are just conceptual at this stage - > > >we've done no implementation of this idea with either. (I said this > > >verbally when presenting the slides, but I should have put it in > > >writing too). Please read my suggestions for PIE and CoDel in this light. > > > > > >I'm not surprised that CoDel derives other parameters from 'interval' > > >that should have been declared and set separately. Andrew McGregor > > >also pointed out to me that CoDel sets threshold = 0.2*interval, so > > >threshold would have to be declared separately as well. This starts > > >to reveal just how many magic numbers there really are in the CoDel > > >algorithm. Btw, Van & Kathleen say about this in ID: "A CoDel control law more independent of interval is future work." I suppose it still is... > > To be more clear about my earlier statement, CoDel actually uses > > "interval" to control a single aspect of the drop policy, however, the > > code (and descriptions of it) imply that there are two different > > functions, and my comments above were written in that vein. However, > > here's how I would describe it more succinctly: the "next drop time" is > > always set according to interval/sqrt(count). In the specific case of > > sojourn time crossing above threshold from below, count happens to equal > > 1, so the first drop is set at one interval in the future. This is what > > is sometimes described as the "hold off" period. > > OK. From an admittedly hasty scan through Andrew McGregor's port of CoDel to > ns3 (not the Linux code), it seems to introduce this hold-off time in the > ControlLaw() function, but it only calls ControlLaw() from the ShouldDrop() > function if the queue has remained above threshold for duration interval. > > That implies that CoDel holds off signalling anything for 2 * interval, ie > 200ms for the default setting of interval = 100ms. There are two calls to it at least in the ID. CoDel is also implemented like that in ns2, Linux, and (based on very brief check) also in ns3. The first call happens exactly at interval, not two away from crossing the target (/threshold) delay. Both calls are preceded by a "drop" (/signal). -- i. From fred@cisco.com Wed Nov 13 10:49:05 2013 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 633C011E8120; Wed, 13 Nov 2013 10:49:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.033 X-Spam-Level: X-Spam-Status: No, score=-110.033 tagged_above=-999 required=5 tests=[AWL=-0.261, BAYES_00=-2.599, J_CHICKENPOX_16=0.6, RCVD_IN_DNSWL_HI=-8, SARE_SUB_OBFU_Q1=0.227, 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 YesKSumrdCJu; Wed, 13 Nov 2013 10:48:59 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 36F8221F9D7C; Wed, 13 Nov 2013 10:48:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4521; q=dns/txt; s=iport; t=1384368539; x=1385578139; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=FU2+omyjlRJJaO4P0SSQ56FmlEMzHm8t5qjGEDM+PVQ=; b=JgyKBja1fL/ftJWu0FJSM06olEX2gAYtnkg+wxMtql4Dk1kqRzjcNHL6 ILAd2ZogKa8Iy6/73kxrFmvTh1LxWNokHHmEow+osR310uUh/PNp6t+An POBfVIUioaPmBXpPnQUhGOq0AiHtHF490lteGM0mqVmckNrMKTtq9usNm 0=; X-Files: signature.asc : 195 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgsFAD7Ig1KtJV2b/2dsb2JhbABbgwc4U78rgScWdIIlAQEBAwF5BQsCAQhGMiUCBA4FDguHYgYNwBePXweDIIERA5AwgTCGMJILgyiCKg X-IronPort-AV: E=Sophos;i="4.93,693,1378857600"; d="asc'?scan'208";a="284191058" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-1.cisco.com with ESMTP; 13 Nov 2013 18:48:57 +0000 Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id rADImuWx002728 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 13 Nov 2013 18:48:56 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.122]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.03.0123.003; Wed, 13 Nov 2013 12:48:56 -0600 From: "Fred Baker (fred)" To: "Scheffenegger, Richard" Thread-Topic: [tsvwg] Immediate ECN: Autotuning AQM for RTT Thread-Index: AQHO4KEBV7BAWUD5Q0OJOx469YFWCQ== Date: Wed, 13 Nov 2013 18:48:56 +0000 Message-ID: References: <201311111618.rABGILbC031136@bagheera.jungle.bt.co.uk> <012C3117EDDB3C4781FD802A8C27DD4F25E8908F@SACEXCMBX02-PRD.hq.netapp.com> In-Reply-To: <012C3117EDDB3C4781FD802A8C27DD4F25E8908F@SACEXCMBX02-PRD.hq.netapp.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.19.64.121] Content-Type: multipart/signed; boundary="Apple-Mail=_3DBFD422-2C1D-4CE8-A19B-BE57478A0706"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Cc: tsvwg IETF list , tsv-area IETF list , AQM IETF list Subject: Re: [tsvwg] Immediate ECN: Autotuning AQM for RTT 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, 13 Nov 2013 18:49:06 -0000 --Apple-Mail=_3DBFD422-2C1D-4CE8-A19B-BE57478A0706 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On Nov 12, 2013, at 5:18 AM, "Scheffenegger, Richard" = wrote: > So, as I am not a HW guy, how many gates does one need for (W)RED, = PIE, CoDel? I'm not a hardware guy either, but I think a predictor would be the = registers and calculations implied in the data path (a supporting = software/firmware process can use RISC approaches to implement = non-data-path components). The calculations of importance are = multiplies, divides, and square roots, each of which can take an = interesting amount of silicon if literally implemented in hardware.=20 For the hardware engineer, there are a number of analogs that can be = used to simplify life. For example, where an algorithm calls for some = number of milliseconds, s/he can divide down the clock rate of the chip = and consider that to be a stated number of clock ticks rather than = implementing a millisecond clock. Where an algorithm calls for a random = number, there are ways the engineer can use noise to create it = (http://en.wikipedia.org/wiki/Hardware_random_number_generator). With RED, there are two basic calculations: maintaining the mean queue = depth, which might mean an exponentially-weighted moving average with = samples taken on events or at times, and determining the mark/drop = probability as max(0, = (mean_queue_depth-min_threshold)/(max_threshold-min_threshold)). An EWMA = can be implemented using adds and shifts, so it's not a big deal. I'm = not the guy that has done our chips, so I'm speaking out of turn, but I = would expect that the divide in the mark/drop probability can be = simplified to not require an actual division circuit. We need a random = number; that comes down to a register. With PIE, the data path calculation is "once per interval, pick up a = random number, compare it to a threshold, and possibly mark/drop a = packet". That comes down to a register for the random number generator. = The math in the background process is "interesting", but - it's in the = background process. Use RISC approaches. With CoDel, the key issue is the sqrt. As the algorithm is described, it = happens in the data path - upon interval expiration, a packet is = dropped, and a new interval is calculated in inverse proportion to the = square root of the number of drops since the dropping state was entered. = I'll argue that the actual value could be calculated in the background = and placed into a register to be copied to the interval register the = next time a packet is actually dropped. The square root calculation = itself can be pretty simple. Most chips these days have an instruction = to tell you the bit number of the most significant "one" in a register, = and have barrel shifters. OK, pick up the number, determine its most = significant bit number, shift that right one bit (divide by two), shift = the argument of the sqrt right the resulting number of bits, and then do = one or two Newton-Raphston iterations. So a reasonable approximation to = the sqrt can be implemented using RISC approaches. My take is that one can use silicon real estate if there is another = reason to have the circuits, but the algorithms on the table can be = implemented in microcode given the ability to run a supporting = background process on a RISC computer. Appendix on EWMAs using adds and shifts: An EWMA calculates new_mean =3D W*sample + (1-W)*old_mean, 0 <=3D W <=3D 1 in successive steps, calculating the mean of a set of samples. Let's constrain W to 2^(-N) for some value of N. Now, store the mean shifted left N bits. The calculation becomes=20 mean :=3D sample + mean - (mean shifted right N bits). Any time you need to use the mean, either you shift it right N bits, or = you shift the rest of the calculation left N bits. --Apple-Mail=_3DBFD422-2C1D-4CE8-A19B-BE57478A0706 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iD8DBQFSg8mVbjEdbHIsm0MRAlvtAJ9KD5J4+q/uk62dLjKXI6U+8qSxYQCgrh/+ pxOe71JFKQak4qF9nhbyga4= =oXmU -----END PGP SIGNATURE----- --Apple-Mail=_3DBFD422-2C1D-4CE8-A19B-BE57478A0706-- From fred@cisco.com Wed Nov 13 12:19:29 2013 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 712B421E8162; Wed, 13 Nov 2013 12:19:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.325 X-Spam-Level: X-Spam-Status: No, score=-110.325 tagged_above=-999 required=5 tests=[AWL=0.047, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, SARE_SUB_OBFU_Q1=0.227, 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 0uE4WvdMs6b9; Wed, 13 Nov 2013 12:19:23 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 9371911E8136; Wed, 13 Nov 2013 12:19:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2228; q=dns/txt; s=iport; t=1384373941; x=1385583541; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=P5ckJkLXRaB9/x6j6JuIFz3h/RpyZVgt7Np9A/xoBWQ=; b=YZTFVm8DQaG812dzSwrzNM2MhPmsC9BPQHPK0A6NaQ1/QnKfQEnxv8tl KDKgL9AZBxbCUkpPziJp+zlsMINQGWPO4YN5lc4ITs1hcZDiPILtWEAlj 9aZBmjrdmxSJdmgKVr8pzPy8UYvM9tH9GND9lyMJVajrLPLi/Wk6RRy/w Y=; X-Files: signature.asc : 195 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgIFAA3eg1KtJV2Y/2dsb2JhbABZgweBC78sgSgWdIIlAQEBAwF5BQsCAQgOODIlAgQOBQ6HbQbASo4hgT4HgyCBEQOQMIEwhjCSC4MogWlB X-IronPort-AV: E=Sophos;i="4.93,693,1378857600"; d="asc'?scan'208";a="284455038" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-3.cisco.com with ESMTP; 13 Nov 2013 20:19:01 +0000 Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id rADKJ0EN016315 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 13 Nov 2013 20:19:00 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.122]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.03.0123.003; Wed, 13 Nov 2013 14:19:00 -0600 From: "Fred Baker (fred)" To: Richard Scheffenegger Thread-Topic: [aqm] [tsvwg] Immediate ECN: Autotuning AQM for RTT Thread-Index: AQHO4K2WdTQM8Xyau0qmjVP5kkPTjg== Date: Wed, 13 Nov 2013 20:19:00 +0000 Message-ID: <2457257D-7DC7-4760-BAC2-EF46B8E04D45@cisco.com> References: <201311111618.rABGILbC031136@bagheera.jungle.bt.co.uk> <012C3117EDDB3C4781FD802A8C27DD4F25E8908F@SACEXCMBX02-PRD.hq.netapp.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.19.64.121] Content-Type: multipart/signed; boundary="Apple-Mail=_261738D0-DE20-459B-A0E9-2547D83D83F4"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Cc: tsv-area IETF list , tsvwg IETF list , AQM IETF list Subject: Re: [tsvwg] [aqm] Immediate ECN: Autotuning AQM for RTT 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, 13 Nov 2013 20:19:29 -0000 --Apple-Mail=_261738D0-DE20-459B-A0E9-2547D83D83F4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On Nov 13, 2013, at 10:48 AM, Fred Baker (fred) wrote: > With CoDel, the key issue is the sqrt. As the algorithm is described, = it happens in the data path - upon interval expiration, a packet is = dropped, and a new interval is calculated in inverse proportion to the = square root of the number of drops since the dropping state was entered. = I'll argue that the actual value could be calculated in the background = and placed into a register to be copied to the interval register the = next time a packet is actually dropped. The square root calculation = itself can be pretty simple. Most chips these days have an instruction = to tell you the bit number of the most significant "one" in a register, = and have barrel shifters. OK, pick up the number, determine its most = significant bit number, shift that right one bit (divide by two), shift = the argument of the sqrt right the resulting number of bits, and then do = one or two Newton-Raphston iterations. So a reasonable approximation to = the sqrt can be implemented using RISC approaches. The sort could also be implemented as a table, given some assumptions. = use the number of drops since the epoch as an index and read the sqrt = (or actually, the calculation that results from it). At some point, we = reach the minimum interval that is acceptable - we are perhaps dropping = every packet, or dropping some limit percentage. At that point, there = isn't a real value in tracking the actual value, as the interval ceases = decreasing. --Apple-Mail=_261738D0-DE20-459B-A0E9-2547D83D83F4 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iD8DBQFSg96wbjEdbHIsm0MRAv9bAKDUreayW8Ky+S4HGT6u3KFHsRv04ACgtjih 2rxVVEI/guxHEUPqNFNitpk= =YbJq -----END PGP SIGNATURE----- --Apple-Mail=_261738D0-DE20-459B-A0E9-2547D83D83F4-- From fred@cisco.com Wed Nov 13 14:22:56 2013 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 8E91221E8171; Wed, 13 Nov 2013 14:22:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.326 X-Spam-Level: X-Spam-Status: No, score=-110.326 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, SARE_SUB_OBFU_Q1=0.227, 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 epK98Y5c1QAP; Wed, 13 Nov 2013 14:22:51 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id DDF0521E80CF; Wed, 13 Nov 2013 14:22:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1117; q=dns/txt; s=iport; t=1384381371; x=1385590971; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=iyTJ7IRFixcRu34+T9i+YOagO0XT9MV+mkWSgvg7r/M=; b=BHp+JJx34PLD+B8sFXSiLyebfEi6FBmik1KITyF6QQlgirx0pQl+YKf8 r4yYEV6mZauGYOyRWt8QLwpnsVUz2g+hXorWNxUx0R9zkbZJWU1KBYu3Y qMVtxw+u2PxDfIuTQmX0drYzQP47i32kRLfKNwSE+cAYBwyvj8D+pxCKD g=; X-Files: signature.asc : 195 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgIFAGn6g1KtJXG8/2dsb2JhbABZgweBC78sgSgWdIIlAQEBAwEnUgULAgEIRjIlAgQOBQ6HbQbAMY9fB4MggREDkDCBMIYwkguDKIIq X-IronPort-AV: E=Sophos;i="4.93,695,1378857600"; d="asc'?scan'208";a="284565200" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-4.cisco.com with ESMTP; 13 Nov 2013 22:22:50 +0000 Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id rADMMnMS004192 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 13 Nov 2013 22:22:50 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.122]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.03.0123.003; Wed, 13 Nov 2013 16:22:49 -0600 From: "Fred Baker (fred)" To: "" Thread-Topic: [aqm] [tsvwg] Immediate ECN: Autotuning AQM for RTT Thread-Index: AQHO4L7ihqXe1x/pYE67TZ+HW0tSpQ== Date: Wed, 13 Nov 2013 22:22:48 +0000 Message-ID: References: <201311132148.rADLmFMd043739@gateway1.ipv6.occnc.com> In-Reply-To: <201311132148.rADLmFMd043739@gateway1.ipv6.occnc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.19.64.121] Content-Type: multipart/signed; boundary="Apple-Mail=_17D15C2E-54A9-463B-83C3-E50C6ABFFFA3"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Cc: tsvwg IETF list , tsv-area IETF list , AQM IETF list Subject: Re: [tsvwg] [aqm] Immediate ECN: Autotuning AQM for RTT 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, 13 Nov 2013 22:22:56 -0000 --Apple-Mail=_17D15C2E-54A9-463B-83C3-E50C6ABFFFA3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Nov 13, 2013, at 1:48 PM, Curtis Villamizar = wrote: > Having briefly reviewed the execise with hardware guys quite a few > times, the answer seems to come out to epsilon where epsilon -> 0 > compared to other things the forwarding engine already needs to do. Pretty much. I was just trying to point out the issues that drive that = cost, even if epsilon, and in so doing provide a useful response. --Apple-Mail=_17D15C2E-54A9-463B-83C3-E50C6ABFFFA3 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iD8DBQFSg/u2bjEdbHIsm0MRAtrfAKDlfwt/fgQHIyAnUe8Xi9ZX3JjCJQCePnVv NM9Msv+N8wGCNojzcMy+bh8= =FQpA -----END PGP SIGNATURE----- --Apple-Mail=_17D15C2E-54A9-463B-83C3-E50C6ABFFFA3-- From wwwrun@rfc-editor.org Sat Nov 16 16:52:52 2013 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 EA43111E8105 for ; Sat, 16 Nov 2013 16:52:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.111 X-Spam-Level: X-Spam-Status: No, score=-101.111 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, NO_RELAYS=-0.001, 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 iUw9KK3p-mgb for ; Sat, 16 Nov 2013 16:52:52 -0800 (PST) Received: from rfc-editor.org (unknown [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 9382A11E80E2 for ; Sat, 16 Nov 2013 16:52:52 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 5ED9D75E001; Sat, 16 Nov 2013 16:42:47 -0800 (PST) To: randall@lakerest.net, spencerdawkins.ietf@gmail.com, mls.ietf@gmail.com, gorry@erg.abdn.ac.uk, david.black@emc.com, jmpolk@cisco.com From: RFC Errata System Message-Id: <20131117004247.5ED9D75E001@rfc-editor.org> Date: Sat, 16 Nov 2013 16:42:47 -0800 (PST) Cc: bstevieg@gmail.com, tsvwg@ietf.org, rfc-editor@rfc-editor.org Subject: [tsvwg] [Technical Errata Reported] RFC4960 (3804) 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: Sun, 17 Nov 2013 00:52:53 -0000 The following errata report has been submitted for RFC4960, "Stream Control Transmission Protocol". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=4960&eid=3804 -------------------------------------- Type: Technical Reported by: Stephen Galvan Jr Section: 3.3.2 Original Text ------------- Corrected Text -------------- Notes ----- something was placed in the ending line that made it almost unreadable. Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC4960 (draft-ietf-tsvwg-2960bis-05) -------------------------------------- Title : Stream Control Transmission Protocol Publication Date : September 2007 Author(s) : R. Stewart, Ed. Category : PROPOSED STANDARD Source : Transport Area Working Group Area : Transport Stream : IETF Verifying Party : IESG From david.black@emc.com Mon Nov 18 12:22:37 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A1041AE373 for ; Mon, 18 Nov 2013 12:22:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.526 X-Spam-Level: X-Spam-Status: No, score=-2.526 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.525, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aviYAv0Y3o3r for ; Mon, 18 Nov 2013 12:22:35 -0800 (PST) Received: from mailuogwdur.emc.com (mailuogwdur.emc.com [128.221.224.79]) by ietfa.amsl.com (Postfix) with ESMTP id 2D17C1AE371 for ; Mon, 18 Nov 2013 12:22:34 -0800 (PST) Received: from maildlpprd52.lss.emc.com (maildlpprd52.lss.emc.com [10.106.48.156]) by mailuogwprd54.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id rAIKMNA9008033 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 18 Nov 2013 15:22:23 -0500 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd54.lss.emc.com rAIKMNA9008033 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1384806143; bh=bX+ECWOXn6coo4Rh22YvYMmWiUs=; h=From:To:Date:Subject:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=NHswVw36UbQqZ1eh+377mzELt6Y6DuGAZrW99bewbiCie7gzs6W3zTeTZdBTSQYJ0 n1bSKDVGDnuLJW3sVLharpGTrVU3pBkzKaxrkl3KdwUiPb9gwRHs1bRec1GenLhpZD NVbOFJYWNp5inJYa9XYYhBnubAFh9xdVB6phXs9M= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd54.lss.emc.com rAIKMNA9008033 Received: from mailusrhubprd53.lss.emc.com (mailusrhubprd53.lss.emc.com [10.106.48.18]) by maildlpprd52.lss.emc.com (RSA Interceptor) for ; Mon, 18 Nov 2013 15:22:07 -0500 Received: from mxhub21.corp.emc.com (mxhub21.corp.emc.com [128.222.70.133]) by mailusrhubprd53.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id rAIKM626030836 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 18 Nov 2013 15:22:06 -0500 Received: from mx15a.corp.emc.com ([169.254.1.239]) by mxhub21.corp.emc.com ([128.222.70.133]) with mapi; Mon, 18 Nov 2013 15:22:06 -0500 From: "Black, David" To: "tsvwg@ietf.org" Date: Mon, 18 Nov 2013 15:21:56 -0500 Thread-Topic: NOMCOM - final call for feedback, nominee list Thread-Index: Ac7kfmqZ4P0tQKE1TsSOwriasfHubgAHV0ug Message-ID: <8D3D17ACE214DC429325B2B98F3AE712026ACFC4D2@MX15A.corp.emc.com> References: <20131116200445.11352.46676.idtracker@ietfa.amsl.com> In-Reply-To: <20131116200445.11352.46676.idtracker@ietfa.amsl.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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd53.lss.emc.com X-RSA-Classifications: DLM_1, public Subject: [tsvwg] NOMCOM - final call for feedback, nominee list X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Nov 2013 20:22:37 -0000 SGVscCB0aGUgTm9tY29tOiAgdGhpcyBpcyB0aGUgbGFzdCBjYWxsIGZvciBnZW5lcmFsIGZlZWRi YWNrIG9uDQpub21pbmVlcy4gVGhpcyBlbWFpbCBpbmNsdWRlcyB0aGUgd2lsbGluZyBub21pbmVl IGxpc3QgZm9yIHlvdXINCmNvbnZlbmllbmNlLCBhcyBwZXIgUkZDIDU2ODAuIFdHIGNoYWlycywg cGxlYXNlIGZvcndhcmQgdGhpcw0KZW1haWwgdG8geW91ciBXR3MuDQoNCldBUk5JTkcgLSBETyBO T1QgcmVwbHkgdG8gdGhpcyBlbWFpbCB3aXRoIGZlZWRiYWNrIC0gdGhlDQphbm5vdW5jZW1lbnQg dG9vbCBwcm92aWRlcyBhbiB1bnByZWRpY3RhYmxlIFJlcGx5LVRvIGZpZWxkLg0KWW91IG1heSBz ZW5kIG1haWwgdG8gbm9tY29tMTMsIGJ1dCBwbGVhc2UgZG8gY29udGludWUNCnJlYWRpbmcgZm9y IGFkZGl0aW9uYWwgaW5mby4NCg0KVGhlIGRlYWRsaW5lIGlzIG1pZG5pZ2h0IChhbnkgdGltZXpv bmUpIFdlZCBOb3YgMjAuDQoNCkVudGVyIHlvdXIgZmVlZGJhY2sgaW50byB0aGUgZW5jcnlwdGVk IG5vbWNvbSB0b29sIGF0Og0KDQpodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL25vbWNvbS8y MDEzL2ZlZWRiYWNrLw0KDQpBbGwgZmVlZGJhY2sgaXMgY29uZmlkZW50aWFsLg0KDQpTZWxlY3Qg aW5kaXZpZHVhbCBub21pbmVlcywgb3Igc2VsZWN0IGFuIGFyZWEgKGUuZy4gSU5UIE11bHRpcGxl KSBpZiB5b3UNCndhbnQgdG8gZ2l2ZSBmZWVkYmFjayBvbiBtdWx0aXBsZSBub21pbmVlcyBmb3Ig dGhhdCBhcmVhIGluIG9uZSBlbnRyeS4NCg0KVGhlIE5vbWNvbSB3aWxsIGdyZWF0bHkgYXBwcmVj aWF0ZSB5b3VyIGNvbmNyZXRlIGFuZCBkZXRhaWxlZA0KdGhvdWdodHMgb24gbm9taW5lZXMuDQoN CllvdSBuZWVkIHRvIGhhdmUgYSBkYXRhdHJhY2tlciBhY2NvdW50IGluIG9yZGVyIHRvIGVudGVy IGZlZWRiYWNrLg0KVGhpcyBpcyB0aGUgc2l0ZSB0byBhY2Nlc3MgZWl0aGVyIHRvIGNyZWF0ZSBh IGRhdGF0cmFja2VyIGFjY291bnQgb3IgdG8NCnJlc2V0IHRoZSBwYXNzd29yZCBvbiBhbiBleGlz dGluZyBhY2NvdW50Og0KDQpodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2FjY291bnRzLw0K DQpBcyB3ZSBhbm5vdW5jZWQgbGFzdCB3ZWVrLCB3ZSBhcmUgc2hhcmluZyB0aGUgbmFtZXMgb2Yg dGhlIHdpbGxpbmcNCm5vbWluZWVzIGluIHRoaXMgZW1haWwsIGFzIHBhcnQgb2Ygb3VyIHVzZSBv ZiBSRkMgNTY4MCBPcGVuIExpc3QgaW4gdGhpcw0Kbm9tY29tIGN5Y2xlLiAgVGhlc2UgbmFtZXMg KGFwcGVhcmluZyBhdCB0aGUgZW5kIG9mIHRoZSBlbWFpbCkNCmhhdmUgYmVlbiBhdmFpbGFibGUg d2l0aGluIHRoZSBkYXRhdHJhY2tlciBzaW5jZSBvdXIgZmlyc3QgY2FsbCBmb3INCmZlZWRiYWNr OyB3ZSBob3BlIHNvbWUgcGVvcGxlIHdpbGwgYmUgZXh0cmEgZW5jb3VyYWdlZCB0byBwcm92aWRl DQpmZWVkYmFjayBieSBzZWVpbmcgdGhlIG5hbWVzIHByaW9yIHRvIGRhdGF0cmFja2VyIGxvZ2lu LiAgIEFsbCB5b3VyDQpmZWVkYmFjayBtdXN0IGJlIGVudGVyZWQgaW4gdGhlIGVuY3J5cHRlZCBu b21jb20gc2l0ZSAob3IgbWFpbGVkIHRvDQpub21jb20tY2hhaXItMjAxM0BpZXRmLm9yZyBvciBu b21jb20xM0BpZXRmLm9yZykuICBZb3UgbWF5IGFzayB0aGUNCmNoYWlyIG9yIGFueSBhbm90aGVy IG5vbWNvbSBtZW1iZXIgdG8gc3VibWl0IHlvdXIgZmVlZGJhY2sgd2l0aG91dA0KeW91ciBuYW1l IGF0dGFjaGVkLCBpZiB5b3Ugd291bGQgcHJlZmVyLg0KDQpBZ2FpbiwgeW91ciBmZWVkYmFjayBp cyBhYnNvbHV0ZWx5IGNvbmZpZGVudGlhbCwgaG93ZXZlciBkZWxpdmVyZWQuDQoNClRoYW5rcyB2 ZXJ5IG11Y2ggZnJvbSBhbGwgb2YgdXMgZm9yIHlvdXIgdGltZSBhbmQgZm9yIGhlbHBpbmcgdGhl DQpOb21jb20gdG8gZG8gdGhlIGJlc3QgcG9zc2libGUgam9iLiAgQWxzbyBlbm9ybW91cyB0aGFu a3MgdG8gdGhlDQp3aWxsaW5nIG5vbWluZWVzLg0KDQpOYW1lcyBiZWxvdy4NCg0KQWxsaXNvbiBm b3IgdGhlIE5vbWNvbQ0KDQpBUFANCkpvZSBIaWxkZWJyYW5kDQpCYXJyeSBMZWliYSAoaW5jdW1i ZW50KQ0KWW9zaGlybyBZb25leWENCg0KSU5UDQpEb25hbGQgRWFzdGxha2UNCldlc2xleSBHZW9y Z2UNCkJyaWFuIEhhYmVybWFuIChpbmN1bWJlbnQpDQpPbGUgVHJvYW4NCg0KT1BTDQpCZW5vaXQg Q2xhaXNlIChpbmN1bWJlbnQpDQpMaW5kYSBEdW5iYXINClZpY3RvciBLdWFyc2luZ2gNCkJpbGwg TWFubmluZw0KDQpSQUkNCkJlbiBDYW1wYmVsbA0KQWxpc3NhIENvb3Blcg0KS2VpdGggRHJhZ2UN CkRhbiBSb21hc2NhbnUNCg0KUlRHDQpMb2EgQW5kZXJzc29uDQpBbGlhIEF0bGFzDQpEZWJvcmFo IEJydW5nYXJkDQpTdGV3YXJ0IEJyeWFudCAoaW5jdW1iZW50KQ0KRG9uYWxkIEVhc3RsYWtlDQpT dXNhbiBIYXJlcw0KS2V5dXIgUGF0ZWwNCg0KU0VDDQpEZXJlayBBdGtpbnMNCkRvbmFsZCBFYXN0 bGFrZQ0KSmVmZiBIb2RnZXMNCkxlaWYgSm9oYW5zc29uDQpBbGV4ZXkgTWVsbmlrb3YNCkthdGhs ZWVuIE1vcmlhcnR5DQpFcmljIFJlc2NvcmxhDQoNClRTVg0KTWFydGluIFN0aWVtZXJsaW5nIChp bmN1bWJlbnQpDQpEYXZlIFRhaHQNCg0KSUFCDQpCZXJuYXJkIEFib2JhIChpbmN1bWJlbnQpDQpM b2EgQW5kZXJzc29uDQpBbGlhcyBBdGxhcw0KTWFyeSBCYXJuZXMNCk1hcmMgQmxhbmNoZXQgKGlu Y3VtYmVudCkNClJvc3MgQ2FsbG9uIChpbmN1bWJlbnQpDQpIYWdvIERhZmFsbGENCkxpbmRhIER1 bmJhcg0KUm9uaSBFdmVuDQpKaW0gR2V0dHlzDQpUZWQgSGFyZGllDQpTdXNhbiBIYXJlcw0KSm9l IEhpbGRlYnJhbmQNClNoZW5nIEppYW5nDQpFbGlvdCBMZWFyIChpbmN1bWJlbnQpDQpMYXJyeSBN YXNpbnRlcg0KUy4gTW9vbmVzYW15DQpLYXRobGVlbiBNb3JpYXJ0eQ0KS2F2ZWggUmFuamJhcg0K Um9iZXJ0IFNwYXJrcw0KVGluYSBUc291DQpCcmlhbiBUcmFtbWVsbA0KDQpJQU9DL0lFVEYgVHJ1 c3QNCkdsZW5uIERlZW4NClRvYmlhcyBHb25kcm9tDQpDaHJpcyBHcmlmZml0aHMgKGluY3VtYmVu dCkNCkpvaG4gTGV2aW5lDQpUaW5hIFRzb3UNCg0K From internet-drafts@ietf.org Tue Nov 19 21:29:49 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 245C21AE313; Tue, 19 Nov 2013 21:29:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PMp8tm96_sHP; Tue, 19 Nov 2013 21:29:47 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D7D51AE30B; Tue, 19 Nov 2013 21:29:47 -0800 (PST) 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.83.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131120052947.13956.44214.idtracker@ietfa.amsl.com> Date: Tue, 19 Nov 2013 21:29:47 -0800 Cc: tsvwg@ietf.org Subject: [tsvwg] I-D Action: draft-ietf-tsvwg-behave-requirements-update-00.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Nov 2013 05:29:49 -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 : Network Address Translation (NAT) Behavioral Requirement= s Updates Author(s) : Reinaldo Penno Simon Perreault Sarat Kamiset Mohamed Boucadair Kengo Naito Filename : draft-ietf-tsvwg-behave-requirements-update-00.txt Pages : 13 Date : 2013-11-19 Abstract: This document clarifies and updates several requirements of RFC4787, RFC5382 and RFC5508 based on operational and development experience. The focus of this document is NAPT44. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tsvwg-behave-requirements-update There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-tsvwg-behave-requirements-update-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From dave.taht@gmail.com Mon Nov 25 17:49:33 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2D001AE104; Mon, 25 Nov 2013 17:49:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.101 X-Spam-Level: X-Spam-Status: No, score=-0.101 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mq0PsumatAcV; Mon, 25 Nov 2013 17:49:30 -0800 (PST) Received: from mail-we0-x233.google.com (mail-we0-x233.google.com [IPv6:2a00:1450:400c:c03::233]) by ietfa.amsl.com (Postfix) with ESMTP id CE14D1AE0F2; Mon, 25 Nov 2013 17:49:29 -0800 (PST) Received: by mail-we0-f179.google.com with SMTP id q59so4616936wes.38 for ; Mon, 25 Nov 2013 17:49:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=IFnV8dyjCOi8AaqYyFFRBPjJlVL+FXugSIq73UzhOLo=; b=bjcbDo1jbAgFiHLkB9QI420L1NoigUw6veoejj/jP3uDqAzRHtP6h0MmOja5wotNFR GgsZJxRK/ELvpixUkJw8FFkjPiDgZqvSvVhA9dtx2MMExsT3tvb+ir0Inc+AUj25pFWq sfGMwEK5qz6FIL9XBrJ+YtY670K6STCTRXmmsdpI4NtsFQAlx0qCi8xUcG0L7PO//hPo H5k/ycO2BFJfTTuGnOywYjAuHeE8IiZ1Wuc5ClHClVOxexra9R9QhNxEkTiQUg6XKtlz 1En+/L1I9ioPU0TWJfBHDJbruCtBI/LkV8oxVafA9DcHfpu9HUFR9Aa2WZHfz5iFR5N7 wJrw== MIME-Version: 1.0 X-Received: by 10.194.186.167 with SMTP id fl7mr23786wjc.85.1385430569410; Mon, 25 Nov 2013 17:49:29 -0800 (PST) Received: by 10.217.51.5 with HTTP; Mon, 25 Nov 2013 17:49:29 -0800 (PST) Date: Mon, 25 Nov 2013 17:49:29 -0800 Message-ID: From: Dave Taht To: "aqm@ietf.org" , "tsvwg@ietf.org" , bloat , "iccrg@irtf.org" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: [tsvwg] Clearing up misunderstandings about Linux versioning X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Nov 2013 01:49:33 -0000 I am in the process of trying to reproduce the recent rite papers on immediate congestion notification and the iccrg ARED work and need to explain something to researchers so that I don't have to work so hard. Linux kernel releases are numbered X.Y.Z-Q. All kernel versions contain bugs. Linux 3.2.0 was, IMHO, the nadir of the network stack in Linux. The "X" is the major version number. It's only changed 3 times. "Y", is the minor version number. These come out roughly quarterly and consist of new development of "features". "Z" is critical patches backported from newer releases. -Q is usually the vendor's kernel build number which often contains more patches. These numbers, clearly identified, in every academic paper on networking, and every presentation, ever published, would make me a happier guy. A pointer to the git tree actually used would make me even happier, with all the patches (like DCTCP in this case) applied, would cause me to dance for joy, and sing hallelujah! Anyway, on the "Z" part of X.Y.Z: Periodically a "long term stable" release is picked and receives updates for as long as someone is funded to do it. *the only things that enter into a long term stable release* are fixes for security bugs, crash bugs, and truly egregious bugs that can be somewhat easily fixed. But the rest of the development goes into X.Y+1. Sane people never run a X.Y.0 release on hardware/data they care about. So... anyway... when I was told that the recent paper on DCTCP had been done against Linux 3.2.18, "which came out in july, 2013!" ... I was partially happy - pretty stable release - but my heart sank as I knew that very, very, very few of the relevant fixes for bufferbloat and the tcp stack had landed in anything prior to Linux 3.6. Those fixes had mostly qualified as "features". Several in fact have been in such continuous development that I'd not want to generalize from fq_codel in 3.5 vs what's in 3.8 now, as one example. So it's my hope that folk will try to follow more closely the X.Y series of kernels rather than the 3.2.Z series of kernels in the future. I'm very happy with what happened in the 3.12 series in particular and look forward to work against it in the near future. The 3.13 work is just beginning, too. In the hope that the showing the mechanics of researching what fixes did land in an old stable release would help on future papers, here's how to look: git clone git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable= .git git clone linux-stable linux-3.2.18 cd linux-3.2.18 git checkout v3.2.18 git checkout -b ritepaper git log net include/net # just the networking bits, not the driver bits for this example BQL, enhanced SFQ, SFQRED, codel, fq_codel, tcp small queues, retirement of some odd tcp logic, and hundreds of other changes were made to the the stack since 3.2.0, and were NOT backported to 3.2.Z. Some very relevant bugfixes did indeed land in 3.2.18 that were not in 3.2! If you have an experiment that used TCP that is against an even older release, perhaps some of these major bugs might explain your results. Here's a sampling: commit 4b9b05fd95c502521eaef111ba0f83c58b391587 Author: Eric Dumazet Date: Wed May 2 02:28:41 2012 +0000 tcp: change tcp_adv_win_scale and tcp_rmem[2] This also means tcp advertises a too optimistic window for a given allocated rcvspace : When receiving frames, sk_rmem_alloc can hit sk_rcvbuf limit and we call tcp_prune_queue()/tcp_collapse() too often, especially when application is slow to drain its receive queue or in case of losses (netperf is fast, scp is slow). This is a major latency source. icommit b713f6c7d317c136f03c132203d0900f4a0de084 Author: Yuchung Cheng Date: Mon Apr 30 06:00:18 2012 +0000 tcp: fix infinite cwnd in tcp_complete_cwr() [ Upstream commit 1cebce36d660c83bd1353e41f3e66abd4686f215 ] When the cwnd reduction is done, ssthresh may be infinite if TCP enters CWR via ECN or F-RTO. If cwnd is not undone, i.e., undo_marker is set, tcp_complete_cwr() falsely set cwnd to the infinite ssthresh value. The correct operation is to keep cwnd intact because it has been updated in ECN or F-RTO. commit 65355aea86b2a70cbc7cbe14466702bc5a4e2217 Author: Neal Cardwell Date: Tue Apr 10 07:59:20 2012 +0000 tcp: fix tcp_rcv_rtt_update() use of an unscaled RTT sample [ Upstream commit 18a223e0b9ec8979320ba364b47c9772391d6d05 ] Fix a code path in tcp_rcv_rtt_update() that was comparing scaled and unscaled RTT samples. The intent in the code was to only use the 'm' measurement if it was a new minimum. However, since 'm' had not yet been shifted left 3 bits but 'new_sample' had, this comparison would nearly always succeed, leading us to erroneously set our receive-side RTT estimate to the 'm' sample when that sample could be nearly 8x too high to use. The overall effect is to often cause the receive-side RTT estimate to be significantly too large (up to 40% too large for brief periods in my tests). commit 1ee5fa1e9970a16036e37c7b9d5ce81c778252fc [PATCH] sch_red: fix red_change() Now RED is classful, we must check q->qdisc->q.qlen, and if queue is em= pt we start an idle period, not end it. --=20 Dave T=E4ht Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.= html From wwwrun@rfc-editor.org Fri Nov 29 10:44:24 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DA261ADEAE for ; Fri, 29 Nov 2013 10:44:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hRzj_BW3gcwe for ; Fri, 29 Nov 2013 10:44:22 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:126c::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id A0FB01ACCE6 for ; Fri, 29 Nov 2013 10:44:22 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 997A4726001; Fri, 29 Nov 2013 10:44:03 -0800 (PST) To: michelle.cotton@icann.org, lars.eggert@nokia.com, touch@isi.edu, magnus.westerlund@ericsson.com, cheshire@apple.com, spencerdawkins.ietf@gmail.com, mls.ietf@gmail.com, gorry@erg.abdn.ac.uk, david.black@emc.com, jmpolk@cisco.com From: RFC Errata System Message-Id: <20131129184403.997A4726001@rfc-editor.org> Date: Fri, 29 Nov 2013 10:44:03 -0800 (PST) Cc: gorry@erg.abdn.ac.uk, tsvwg@ietf.org, rfc-editor@rfc-editor.org Subject: [tsvwg] [Technical Errata Reported] RFC6335 (3813) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Nov 2013 18:44:24 -0000 The following errata report has been submitted for RFC6335, "Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6335&eid=3813 -------------------------------------- Type: Technical Reported by: Gorry Fairhurst Section: 2.2 Original Text ------------- All standards assigned Service Codes, including all values assigned by IANA, are required to use a value that may be represented using a subset of the ASCII character set. Corrected Text -------------- Requests for a Service Code in the IANA Considerations section of a Standards-Track specification are to be assigned from the Specifications-Required portion of the Service Code registry. These assignments are required to use a value that may be represented using a subset of the ASCII character set (see section 5). Notes ----- RFC 5595 did not clearly specify the intended update to RFC 4340. Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC6335 (draft-ietf-tsvwg-iana-ports-10) -------------------------------------- Title : Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry Publication Date : August 2011 Author(s) : M. Cotton, L. Eggert, J. Touch, M. Westerlund, S. Cheshire Category : BEST CURRENT PRACTICE Source : Transport Area Working Group Area : Transport Stream : IETF Verifying Party : IESG From wwwrun@rfc-editor.org Fri Nov 29 10:47:10 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CA5D1ACCE6 for ; Fri, 29 Nov 2013 10:47:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1vIAMUyecNbZ for ; Fri, 29 Nov 2013 10:47:09 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:126c::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 2E0161ACC82 for ; Fri, 29 Nov 2013 10:47:09 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 0AC28726001; Fri, 29 Nov 2013 10:46:51 -0800 (PST) To: michelle.cotton@icann.org, lars.eggert@nokia.com, touch@isi.edu, magnus.westerlund@ericsson.com, cheshire@apple.com, spencerdawkins.ietf@gmail.com, mls.ietf@gmail.com, gorry@erg.abdn.ac.uk, david.black@emc.com, jmpolk@cisco.com From: RFC Errata System Message-Id: <20131129184651.0AC28726001@rfc-editor.org> Date: Fri, 29 Nov 2013 10:46:51 -0800 (PST) Cc: gorry@erg.abdn.ac.uk, tsvwg@ietf.org, rfc-editor@rfc-editor.org Subject: [tsvwg] [Technical Errata Reported] RFC6335 (3814) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Nov 2013 18:47:10 -0000 The following errata report has been submitted for RFC6335, "Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6335&eid=3814 -------------------------------------- Type: Technical Reported by: Gorry Fairhurst Section: 10.3.1 Original Text ------------- Service codes are assigned on a "first come, first served" basis according to Section 19.8 of the DCCP specification [RFC4340]. Corrected Text -------------- Service Codes are generally assigned on a "first come, first served" basis, according to the rules specified in Section 19.8 of the DCCP specification [RFC4340]. This also defines exceptions to this policy. [RFC5595] updated the policy to require Service Codes assignments in a Standards-Track specification to be assigned from the Specifications-Required portion of the Service Code registry. Notes ----- RFC 6335 should have noted in Section 10.3.1: Exceptions to the FCFS policy are documented in RFC 4340. RFC 5595 updated the usage of the SC values described in RFC 4340. Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC6335 (draft-ietf-tsvwg-iana-ports-10) -------------------------------------- Title : Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry Publication Date : August 2011 Author(s) : M. Cotton, L. Eggert, J. Touch, M. Westerlund, S. Cheshire Category : BEST CURRENT PRACTICE Source : Transport Area Working Group Area : Transport Stream : IETF Verifying Party : IESG From gorry@erg.abdn.ac.uk Fri Nov 29 10:56:56 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C9B11ADF4F for ; Fri, 29 Nov 2013 10:56:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pDxFnznu9efO for ; Fri, 29 Nov 2013 10:56:54 -0800 (PST) Received: from spey.erg.abdn.ac.uk (spey.erg.abdn.ac.uk [139.133.204.173]) by ietfa.amsl.com (Postfix) with ESMTP id D379D1AE03A for ; Fri, 29 Nov 2013 10:56:53 -0800 (PST) Received: from www.erg.abdn.ac.uk (blake.erg.abdn.ac.uk [139.133.210.30]) by spey.erg.abdn.ac.uk (Postfix) with ESMTPSA id D1E1B2B44C8; Fri, 29 Nov 2013 18:56:51 +0000 (GMT) Received: from 212.159.18.54 (SquirrelMail authenticated user gorry) by www.erg.abdn.ac.uk with HTTP; Fri, 29 Nov 2013 18:56:51 -0000 Message-ID: <897b067e38c3a6e990209b47e852a8b0.squirrel@www.erg.abdn.ac.uk> In-Reply-To: <20131129184403.997A4726001@rfc-editor.org> References: <20131129184403.997A4726001@rfc-editor.org> Date: Fri, 29 Nov 2013 18:56:51 -0000 From: gorry@erg.abdn.ac.uk To: "RFC Errata System" User-Agent: SquirrelMail/1.4.22 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: magnus.westerlund@ericsson.com, tsvwg@ietf.org, touch@isi.edu, gorry@erg.abdn.ac.uk, mls.ietf@gmail.com, lars.eggert@nokia.com, jmpolk@cisco.com, michelle.cotton@icann.org, rfc-editor@rfc-editor.org Subject: Re: [tsvwg] [Technical Errata Reported] RFC6335 (3813) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Nov 2013 18:56:56 -0000 Please disregard this Errata. It is was submitted by mistake. A corrected entry has replaced this. Gorry > The following errata report has been submitted for RFC6335, > "Internet Assigned Numbers Authority (IANA) Procedures for the Management > of the Service Name and Transport Protocol Port Number Registry". > > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=6335&eid=3813 > > -------------------------------------- > Type: Technical > Reported by: Gorry Fairhurst > > Section: 2.2 > > Original Text > ------------- > All standards assigned Service Codes, including > all values assigned by IANA, are required to use a value that may be > represented using a subset of the ASCII character set. > > > Corrected Text > -------------- > Requests for a Service Code in the IANA Considerations section of a > Standards-Track specification are to be assigned from the > Specifications-Required portion of the Service Code registry. > These assignments are required to use a value that may be > represented using a subset of the ASCII character set (see section 5). > > > Notes > ----- > RFC 5595 did not clearly specify the intended update to RFC 4340. > > Instructions: > ------------- > This errata is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party (IESG) > can log in to change the status and edit the report, if necessary. > > -------------------------------------- > RFC6335 (draft-ietf-tsvwg-iana-ports-10) > -------------------------------------- > Title : Internet Assigned Numbers Authority (IANA) > Procedures for the Management of the Service Name and Transport Protocol > Port Number Registry > Publication Date : August 2011 > Author(s) : M. Cotton, L. Eggert, J. Touch, M. Westerlund, S. > Cheshire > Category : BEST CURRENT PRACTICE > Source : Transport Area Working Group > Area : Transport > Stream : IETF > Verifying Party : IESG >