From gorry@erg.abdn.ac.uk Mon Jan 9 06:41:34 2012 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AE6D21F87A9 for ; Mon, 9 Jan 2012 06:41:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[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 5Ow+rf9QeAfU for ; Mon, 9 Jan 2012 06:41:33 -0800 (PST) Received: from erg.abdn.ac.uk (dee.erg.abdn.ac.uk [IPv6:2001:630:241:204:203:baff:fe9a:8c9b]) by ietfa.amsl.com (Postfix) with ESMTP id C18B621F8629 for ; Mon, 9 Jan 2012 06:41:27 -0800 (PST) Received: from gorry-mac.erg.abdn.ac.uk (gorry-mac.erg.abdn.ac.uk [139.133.207.5]) (authenticated bits=0) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id q09EfMHd000304 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 9 Jan 2012 14:41:22 GMT Message-ID: <4F0AFC93.9030708@erg.abdn.ac.uk> Date: Mon, 09 Jan 2012 14:41:23 +0000 From: Gorry Fairhurst Organization: The University of Aberdeen is a charity registered in Scotland, No SC013683. User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: tsvwg WG Subject: Request to publish: draft-ietf-tsvwg-source-quench as a PS. Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ERG-MailScanner: Found to be clean X-ERG-MailScanner-From: gorry@erg.abdn.ac.uk X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: gorry@erg.abdn.ac.uk List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2012 14:41:34 -0000 This email includes a write-up of the IETF TSV WG document on "Deprecation of ICMP Source Quench messages". This write-up will be forwarded to our ADs with a recommendation for publication as an RFC. Thanks to all who contributed to this work. Best wishes, Gorry (TSVWG Co-Chair) --- As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Document: Deprecation of ICMP Source Quench messages Intended status: Proposed Standards Shepherd: G Fairhurst (TSVWG Co-Chair) This version is dated September 17, 2008. (1.a) Who is the Document Shepherd for this document? Has the Document Shepherd personally reviewed this version of the document and, in particular, does he or she believe this version is ready for forwarding to the IESG for publication? I (Gorry Fairgurst) will be the document shepherd and I judge that this document is ready for publication. (1.b) Has the document had adequate review both from key WG members and from key non-WG members? Does the Document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? The document has been reviewed in WGLC, and was discussed at TSVWG meetings. (1.c) Does the Document Shepherd have concerns that the document needs more review from a particular or broader perspective, e.g., security, operational complexity, someone familiar with AAA, internationalization or XML? No concerns. (1.d) Does the Document Shepherd have any specific concerns or issues with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. Has an IPR disclosure related to this document been filed? If so, please include a reference to the disclosure and summarize the WG discussion and conclusion on this issue. I have no concerns with deprecation of this specific method. The method has for a long time not been used in the general Internet and lacks the safeguards needed for any future endpoint congestion notification. Therefore it was concluded that the previously defined mechanism can not be usefully used in the Internet. This was supported by the WGLC on 18th October 2011, which focussed on the the use of RFC 2119 keywords. All issues were resolved buy publication of draft -03 on 22nd December 2011. (1.e) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? This review lead to refinement of RFC 2119 wording, but to no significant changes in the intended scope. There were no known issues with publication of this document. (1.f) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is entered into the ID Tracker.) There are no known objections to publication. (1.g) Has the Document Shepherd personally verified that the document satisfies all ID nits? (See the Internet-Drafts Checklist and http://tools.ietf.org/tools/idnits/). Boilerplate checks are not enough; this check needs to be thorough. Has the document met all formal review criteria it needs to, such as the MIB Doctor, media type and URI type reviews? Yes. (1.h) Has the document split its references into normative and informative? Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the strategy for their completion? Are there normative references that are downward references, as described in [RFC3967]? If so, list these downward references to support the Area Director in the Last Call procedure for them [RFC3967]. Yes. (1.i) Has the Document Shepherd verified that the document IANA consideration section exists and is consistent with the body of the document? If the document specifies protocol extensions, are reservations requested in appropriate IANA registries? Are the IANA registries clearly identified? If the document creates a new registry, does it define the proposed initial contents of the registry and an allocation procedure for future registrations? Does it suggest a reasonable name for the new registry? See [RFC5226]. If the document describes an Expert Review process has Shepherd conferred with the Responsible Area Director so that the IESG can appoint the needed Expert during the IESG Evaluation? The IANA change is simply to mark a registry with a note. (1.j) Has the Document Shepherd verified that sections of the document that are written in a formal language, such as XML code, BNF rules, MIB definitions, etc., validate correctly in an automated checker? Not applicable. (1.k) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up? Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary This document provides a Standards-Track document that formally deprecates the use of ICMP Source Quench messages by all IETF-defined transport protocols. This formally updates RFC 792, RFC 1122, and RFC 1812. Additionally, it requests that the status of RFC 1016 be changed to "Historic". Working Group Summary This document arrived at the TSV WG following related discussions in the TCPM WG. The decision to adopt this reflected current deployment experience, and that any update should be directed to all IETF transports. There was consensus to adopt this and it has received review and discussion in the WG. The WG supports publication of this document. Document Quality The document standardises current understanding of how congestion control should be designed and the new language reflects the lack of actual use of this mechanism in deployed network and current best practice. -- Prof Gorry Fairhurst, School of Engineering, University of Aberdeen. The University of Aberdeen is a charity registered in Scotland, No SC013683. From mvproshin@gmail.com Tue Jan 17 02:11:28 2012 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0F6421F84B2 for ; Tue, 17 Jan 2012 02:11:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.109 X-Spam-Level: X-Spam-Status: No, score=-2.109 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, HTML_MESSAGE=0.001, 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 tuXvi8rn0CFA for ; Tue, 17 Jan 2012 02:11:24 -0800 (PST) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id F0D9121F8478 for ; Tue, 17 Jan 2012 02:11:23 -0800 (PST) Received: by werp11 with SMTP id p11so429797wer.31 for ; Tue, 17 Jan 2012 02:11:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=+jTMHSK9vrD35hCvPrj4cgf6CZ8n+g2Nlk5hows3wIY=; b=bB27G1LO9Zax1TBTM48MAzstsNOb+845GoHp8BbjBh6bJxrWHDOcRRrcPJfs85GSxP AdXuh++13sp7oYtCHGyuKN/eHp4G0LLMuNaEZXOLx3ONbh4XeIe3Fw+wscdkwr/MRE0T FIib1IeWjoDuwndpZFytKF1IifKxbZMVuNWk0= MIME-Version: 1.0 Received: by 10.216.131.21 with SMTP id l21mr4109304wei.39.1326795082727; Tue, 17 Jan 2012 02:11:22 -0800 (PST) Received: by 10.216.1.131 with HTTP; Tue, 17 Jan 2012 02:11:22 -0800 (PST) In-Reply-To: <201112211355.39643.michael.larsen@tieto.com> References: <201112211355.39643.michael.larsen@tieto.com> Date: Tue, 17 Jan 2012 14:11:22 +0400 Message-ID: Subject: Re: Fast Retransmission in SCTP From: Maxim Proshin To: Michael Vittrup Larsen Content-Type: multipart/alternative; boundary=0016e6d5669c987f5104b6b68dd7 Cc: =?ISO-8859-1?Q?Michael_T=FCxen?= , tsvwg@ietf.org 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, 17 Jan 2012 10:11:29 -0000 --0016e6d5669c987f5104b6b68dd7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, it seems that your point is reasonable but it still requires some clarfifications: 1. You are talking about "current primary path failovers". What if the user defined a destination? Should SCTP send fast retransmissions to the primary destination anyway? 2. It is unclear how the Karns algorithm can affect RTO calculation during FR. If the primary destination is just changed and gaps are detected for the previous primary destination, it means that RTO could not be changed (at least due to Karns algorithm). Could you please clarify scenarious where it could happen? In your item 1 you are talking about an alternative path and conservative RTO. I think you mean the previous primary destination then it is unclear why its RTO is conservative. 3. I agree with the drawback about CWND. But as usually there are pros and cons. How do you propose to calculate CWND in this case? Should it be recalculated for the previous primary destination and new one (or defined by the user and primary one)? Looks like it should be recalculated but in such case it impacts SCTP performance and conflicts with RFC. It seems there are also problematic scenarious if CWND is recalculated. What if the number of bytes in in-flight for the new primary destination is equal to CWND, how fast retransmissions from the previous primary one should be made in such case, should it be postponed? Moreover changing the primary destination is not normally done often and amount of fast retransmissions to the previous primary destination will not give a big impact on CWND in comparison with all data. BR, Maxim 2011/12/21 Michael Vittrup Larsen > I don't believe this is a correct interpretation of the articles from > Armando > et. al ([4] of RFC4460). I believe the correct interpretation is > > "fast retransmissions should be sent to the destination to which > we currently are sending data" > > Note that this is not the same as "...to the same destination where initi= al > transmissions were sent" in case of current primary path failovers. In > fact, > if we send fast retransmissions "...to the same destination where initial > transmissions were sent" we may in fact be sending these on a path > different > from where we currently are sending data - and this is exactly (to my > understanding) what the change in SCTP fast retransmission in RFC4960 is > all > about. > > To see why we need to look behind the words used by RFC4960 and into the > articles and the reasoning in the articles: > > 1) Sending fast retransmissions (FR) on a path different from where we > currently are sending new data may be subject to excessive RTO values on > the > alternative path. Successful FRs do not update the RTT of the alternative > path > due to Karns algorithm and the RTO on the alternative path is therefore > conservative for the majority of the association and sending FRs on such = a > path is not optimal. > > 2) FRs do not benefit the cwnd of the path where we are sending new data > but > instead the cwnd of the alternative path, which is less attractive. > > 3) Possible timeouts of FRs sent on the alternative path will delay cwnd > increments on the path where we are sending new data. Since these timeout= s > are > conservative the delay may be excessive. > > Neither [4] nor RFC4960 explicitly in text describes the FR policy in cas= e > where a change of the current primary data transfer path has occurred. Bu= t > in > essence the above reasoning/discovery of [4] clearly dictates what the > correct > interpretation should be. > > > Regards, > Michael > > On Friday, December 09, 2011 11:34:34 Michael T=FCxen wrote: > > On Dec 9, 2011, at 8:27 AM, Maxim Proshin wrote: > > > Hi experts, > > > > > > here I would like to discuss the Fast Retransmission algorithm in RFC > > > 4960. Frankly this RFC does not describe clearly how to send (to whic= h > > > destination) fast retransmissions but we can find some information in > > > RFC 4460 which says: > > > > > > " > > > 2.39. Retransmission Policy > > > > > > 2.39.1. Description of the Problem > > > > > > The current retransmission policy (send all retransmissions an > > > alternate destination) in the specification has performance issues > > > under certain loss conditions with multihomed endpoints. Instead, > > > fast retransmissions should be sent to the same destination, and only > > > timeout retransmissions should be sent to an alternate destination [4= ]. > > > " > > > > > > Reading this article my first feeling was that fast retransmissions > > > should be sent to the same destination where initial transmissions we= re > > > sent. > > > > > > So my first question is > > > > > > is my RFC interpretation correct or not? > > > > Yes. Fast retransmissions should be send to the same destination as the > > initial transmission. Timer based retransmissions should use an alterna= te > > destination. > > > > > Meanwhile, there are some more articles about retransmision policies > > > where RFC's authors also participated. For instance, "Retransmission > > > Policies With Transport Layer Multihoming" describes some improvement= s > > > in fast retransmission policy in respect to RFC 2960 and I think that > > > they were considered during RFC 4960 preparation. This analysis also > > > proposes to send fast retransmissions to the same destination: " > > > In this solution, all retransmissions are sent to the > > > same destination as their original transmissions. > > > ... > > > Instead of all > > > retransmissions following the Retransmit to Same Destination > > > policy of Solution 1, only Fast Retransmissions > > > should follow this policy. > > > " > > > > > > It seems that this statement confirms my initial feeling described > above. > > > But at the same time it says about primary path: " > > > Using the same destination for retransmissions has > > > the added advantage that the primary destination's cwnd > > > bene ts from successful retransmissions. > > > " > > > and it results is some doubts. On the one hand fast retransmissions > > > should be sent to the same destination, on the other it should be sen= t > > > to the primary destination. In usual case "the same" and primary > > > destinations are equal. But RFC 4960 doesn't prevent primary > destination > > > changing by the user so it can be changed in run-time. > > > > > > So my second question is > > > > > > if the primary destination is changed in run-time, where SCTP should > > > sent fast retransmissions which were detected for the previous prima= ry > > > destination? > > > > Changing the primary is normally not done at a high rate. So you are > > looking at the case where fast retransmission occur and the user change= d > > the primary in between. > > > > I guess there is no special case on the RFC for that. So the fast > > retransmission would go to the destination to which it was initially > sent. > > The same applies if the user specified a destination and therefore the > > primary was not used. > > > > > The mentioned above article describes one advantage in respect to > sending > > > to the primay destination, this is about cwnd benets from successful > > > retransmission. But I think that in case of fast retransmission it wi= ll > > > not be observed or the advantage is very very low. > > > > > > At the same time sending to the primary destination results in a big > > > disadvantage: SCTP should recalculate cwnd if it sends fast > > > retransmissions to the primary destination because RFC 4960 says: " > > > When a Fast Retransmit is being performed, the sender SHOULD ignore t= he > > > value of cwnd " > > > I think the reason is that it was considered during initial > transmission. > > > > If you do a fast retransmit, you assume that the packet has left the > > network. So you would have to subtract and add it. This means ignoring.= .. > > > > Best regards > > Michael > > > > > What do you think about this? > > > > > > I'm not sure whether it was discussed already or not. If yes, please > > > provide me with discussion's results. > > -- > > *************************************************************************= **************** > Michael Vittrup Larsen > Software Architect > > Tieto Denmark A/S > IP Solutions, Telecom & Media > Skanderborgvej 232, 8260 Viby J, DK-Denmark > Direct Phone / Mobile +45 3091 8469 > E-mail: michael.larsen@tieto.com > > *************************************************************************= **************** > www.tieto.com > > Please note: The information contained in this message may be legally > privileged and confidential and protected from disclosure. If the reader = of > this message is not the intended recipient, you are hereby notified that > any > unauthorised use, distribution or copying of this communication is strict= ly > prohibited. If you have received this communication in error, please > notify us > immediately by replying to the message and deleting it from your computer= . > Thank You. > --=20 BR, Max --0016e6d5669c987f5104b6b68dd7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi,

it seems that your point is reasonable but it still = requires some clarfifications:

1. You are talking = about "current primary path failovers". What if the user defined = a destination? Should SCTP send fast retransmissions to the primary destina= tion anyway?

2. It is unclear how the Karns algorithm can affect RTO= calculation during FR. If the primary destination is just changed and gaps= are detected for the previous primary destination, it means that RTO could= not be changed (at least due to Karns algorithm). Could you please clarify= scenarious where it could happen? In your item 1 you are talking about an = alternative path and conservative RTO. I think you mean the previous primar= y destination then it is unclear why its RTO is conservative.

3. I agree with the drawback about CWND. But as usually= there are pros and cons. How do you propose to calculate CWND in this case= ? Should it be recalculated for the previous primary destination and new on= e (or defined by the user and primary one)? Looks like it should be recalcu= lated but in such case it impacts SCTP performance and conflicts with RFC. = It seems there are also problematic scenarious if CWND is recalculated. Wha= t if the number of bytes in in-flight for the new primary destination is eq= ual to CWND, how fast retransmissions from the previous primary one should = be made in such case, should it be postponed? Moreover changing the primary= destination is not normally done often and amount of fast retransmissions = to the previous primary destination will not give a big impact on CWND in c= omparison with all data.=A0

BR, Maxim

2011= /12/21 Michael Vittrup Larsen <michael.larsen@tieto.com>
I don't believe this is a correct interpretation of t= he articles from Armando
et. al ([4] of RFC4460). =A0I believe the correct interpretation is

=A0"fast retransmissions should be sent to the destination to which =A0 we currently are sending data"

Note that this is not the same as "...to the same destination where in= itial
transmissions were sent" in case of current primary path failovers. = =A0In fact,
if we send fast retransmissions "...to the same destination where init= ial
transmissions were sent" we may in fact be sending these on a path dif= ferent
from where we currently are sending data - and this is exactly (to my
understanding) what the change in SCTP fast retransmission in RFC4960 is al= l
about.

To see why we need to look behind the words used by RFC4960 and into = the
articles and the reasoning in the articles:

1) Sending fast retransmissions (FR) on a path different from where we
currently are sending new data may be subject to excessive RTO values= on the
alternative path. Successful FRs do not update the RTT of the alternative p= ath
due to Karns algorithm and the RTO on the alternative path is therefore
conservative for the majority of the association and send= ing FRs on such a
path is not optimal.

2) FRs do not benefit the cwnd of the path where we are sending new data bu= t
instead the cwnd of the alternative path, which is less attractive.
3) Possible timeouts of FRs sent on the alternative path will delay cwnd
increments on the path where we are sending new da= ta. Since these timeouts are
conservative the delay may be excessive.

Neither [4] nor RFC4960 explicitly in text describes the FR policy in case<= br> where a change of the current primary data transfer path has occurred. But = in
essence the above reasoning/discovery of [4] clearly dictates what the corr= ect
interpretation should be.


Regards,
Michael

On Friday, December 09, 2011 11:34:34 Michael T=FCxen wrote:
> On Dec 9, 2011, at 8:27 = AM, Maxim Proshin wrote:
> > Hi experts,
> >
> > here I would like to discuss the Fast Retransmission algorithm in= RFC
> > 4960. Frankly this RFC does not describe clearly how to send (to = which
> > destination) fast retransmissions but we can find some informatio= n in
> > RFC 4460 which says:
> >
> > "
> > 2.39. Retransmission Policy
> >
> > 2.39.1. Description of the Problem
> >
> > The current retransmission policy (send all retransmissions an > > alternate destination) in the specification has performance issue= s
> > under certain loss conditions with multihomed endpoints. Instead,=
> > fast retransmissions should be sent to the same destination, and = only
> > timeout retransmissions should be sent to an alternate destinatio= n [4].
> > "
> >
> > Reading this article my first feeling was that fast retransmissio= ns
> > should be sent to the same destination where initial transmission= s were
> > sent.
> >
> > So my first question is
> >
> > =A0is my RFC interpretation correct or not?
>
> Yes. Fast retransmissions should be send to the same destination as th= e
> initial transmission. Timer based retransmissions should use an altern= ate
> destination.
>
> > Meanwhile, there are some more articles about retransmision polic= ies
> > where RFC's authors also participated. For instance, "Re= transmission
> > Policies With Transport Layer Multihoming" describes some im= provements
> > in fast retransmission policy in respect to RFC 2960 and I think = that
> > they were considered during RFC 4960 preparation. This analysis a= lso
> > proposes to send fast retransmissions to the same destination: &q= uot;
> > In this solution, all retransmissions are sent to the
> > same destination as their original transmissions.
> > ...
> > Instead of all
> > retransmissions following the Retransmit to Same Destination
> > policy of Solution 1, only Fast Retransmissions
> > should follow this policy.
> > "
> >
> > It seems that this statement confirms my initial feeling describe= d above.
> > But at the same time it says about primary path: "
> > Using the same destination for retransmissions has
> > the added advantage that the primary destination's cwnd
> > bene ts from successful retransmissions.
> > "
> > and it results is some doubts. On the one hand fast retransmissio= ns
> > should be sent to the same destination, on the other it should be= sent
> > to the primary destination. In usual case "the same" an= d primary
> > destinations are equal. But RFC 4960 doesn't prevent primary = destination
> > changing by the user so it can be changed in run-time.
> >
> > So my second question is
> >
> > =A0if the primary destination is changed in run-time, where SCTP = should
> > =A0sent fast retransmissions which were detected for the previous= primary
> > =A0destination?
>
> Changing the primary is normally not done at a high rate. So you are > looking at the case where fast retransmission occur and the user chang= ed
> the primary in between.
>
> I guess there is no special case on the RFC for that. So the fast
> retransmission would go to the destination to which it was initially s= ent.
> The same applies if the user specified a destination and therefore the=
> primary was not used.
>
> > The mentioned above article describes one advantage in respect to= sending
> > to the primay destination, this is about cwnd benets from success= ful
> > retransmission. But I think that in case of fast retransmission i= t will
> > not be observed or the advantage is very very low.
> >
> > At the same time sending to the primary destination results in a = big
> > disadvantage: SCTP should recalculate cwnd if it sends fast
> > retransmissions to the primary destination because RFC 4960 says:= "
> > When a Fast Retransmit is being performed, the sender SHOULD igno= re the
> > value of cwnd "
> > I think the reason is that it was considered during initial trans= mission.
>
> If you do a fast retransmit, you assume that the packet has left the > network. So you would have to subtract and add it. This means ignoring= ...
>
> Best regards
> Michael
>
> > What do you think about this?
> >
> > I'm not sure whether it was discussed already or not. If yes,= please
> > provide me with discussion's results.

--
***********************= ******************************************************************
Michael Vittrup Larsen
Software Architect

Tieto Denmark A/S
IP Solutions, Telecom & Media
Skanderborgvej 232, 8260 Viby J, DK-Denmark
Direct Phone / Mobile +45 3091 8469
E-mail: michael.larsen@tieto.co= m
***************************************************************************= **************
www.tieto.com

Please note: The information contained in this message may be legally
privileged and confidential and protected from disclosure. If the reader of=
this message is not the intended recipient, you are hereby notified that an= y
unauthorised use, distribution or copying of this communication is strictly=
prohibited. If you have received this communication in error, please notify= us
immediately by replying to the message and deleting it from your computer.<= br> Thank You.



--
= BR, Max
--0016e6d5669c987f5104b6b68dd7-- From randall@lakerest.net Tue Jan 17 04:02:45 2012 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BD8321F8565 for ; Tue, 17 Jan 2012 04:02:45 -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 tPl1lPwg5Z3c for ; Tue, 17 Jan 2012 04:02:41 -0800 (PST) Received: from lakerest.net (lakerest.net [70.155.160.98]) by ietfa.amsl.com (Postfix) with ESMTP id C5C9321F8599 for ; Tue, 17 Jan 2012 04:02:40 -0800 (PST) Received: from [10.1.1.141] (bsd3.lakerest.net [70.155.160.101]) (authenticated bits=0) by lakerest.net (8.14.4/8.14.3) with ESMTP id q0HC1KwH066960 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 17 Jan 2012 07:01:21 -0500 (EST) (envelope-from randall@lakerest.net) Subject: Re: Fast Retransmission in SCTP Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=windows-1252 From: Randy Stewart In-Reply-To: Date: Tue, 17 Jan 2012 07:01:20 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <7CC7D166-F6A9-4F91-A9D1-376AEC9CBEF8@lakerest.net> References: <201112211355.39643.michael.larsen@tieto.com> To: Maxim Proshin X-Mailer: Apple Mail (2.1251.1) Cc: =?iso-8859-1?Q?Michael_T=FCxen?= , tsvwg@ietf.org 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, 17 Jan 2012 12:02:45 -0000 Maxim: Being one of the authors of the paper and research and having done a few other things on SCTP.. I will add my 2 cents ;-)=85 mostly=20 in-line .. but out of line here too :-) In general sending FR to where they originally were sent is a good idea. The reason being is the ACK clock is not broken.. you just noticed something was lost. Once you move it to another destination you are = moving it to somewhere that is what the first Michael below describes=85 and=20= further more, if you do that, you can *not* do more than one fast = retransmit per packet. So if you have an unlucky packet that gets dropped twice but = you have not loss the ack-clock, you are going to take a full scale time-out = in order to get it through. I have seen this happen in real networks and have found it best then to keep the packet on the path it was originally sent on in general. Now all of that is in *general true* for when a) You have NOT switched primary's b) You still have an ACK-Clock. If on the other hand, the user has switched primary's or the primary has died and move to another path. You may not wish to follow that advice. The RFC very specifically left loose not adding any MUST so that an = implementation can have some freedom if it wants to worry about these corner cases. = This is a good thing.. since there are several corner cases that one can dream up that = then the standard advice.. keep the packet on the same path originally sent on.. = would *not* be a good choice. =20 On Jan 17, 2012, at 5:11 AM, Maxim Proshin wrote: > Hi, >=20 > it seems that your point is reasonable but it still requires some = clarfifications: >=20 > 1. You are talking about "current primary path failovers". What if the = user defined a destination? Should SCTP send fast retransmissions to the = primary destination anyway? I personally would still hold the original path if the user swapped = paths since the ack clock will slowly shut down. Unless of course you know that there is = nothing left on that old path of course.. again this is quite a corner case. = Most FR's will happen with no switches, no deaths, just a momentary drop by a router in = the network to slow us down a bit. >=20 > 2. It is unclear how the Karns algorithm can affect RTO calculation = during FR. If the primary destination is just changed and gaps are = detected for the previous primary destination, it means that RTO could = not be changed (at least due to Karns algorithm). Could you please = clarify scenarious where it could happen? In your item 1 you are talking = about an alternative path and conservative RTO. I think you mean the = previous primary destination then it is unclear why its RTO is = conservative. >=20 > 3. I agree with the drawback about CWND. But as usually there are pros = and cons. How do you propose to calculate CWND in this case? Should it = be recalculated for the previous primary destination and new one (or = defined by the user and primary one)? Looks like it should be = recalculated but in such case it impacts SCTP performance and conflicts = with RFC. It seems there are also problematic scenarious if CWND is = recalculated. What if the number of bytes in in-flight for the new = primary destination is equal to CWND, how fast retransmissions from the = previous primary one should be made in such case, should it be = postponed? Moreover changing the primary destination is not normally = done often and amount of fast retransmissions to the previous primary = destination will not give a big impact on CWND in comparison with all = data.=20 I think this is again splitting hairs. The loss of one opportunity to = grow the CWND in one obscure corner case where the user switched primary's (or the path died) = is not important. If the user switches primary's he is going to take a hit anyway since = the old path with a very open cwnd (possibly) will of course have much more data = going through it vs the new path that is sitting at the initial window. In the case of = path-death, well again the new path will probably be in slow start and its just a = consequence of the path switch... In fact actually the more I think on this it must be that the user = switched the primary since if the path exceeded its strike count and was marked as down, all = the packets in-flight or otherwise, must be moved to the new primary.=20 Unless of course you get a double switch back, i.e. it restores.. in = which case we are again walking a very narrow corner.=20 Again, this is why the wording is loose, to allow the implementations = the ability to add code to handle obscure corner cases if they wish. R >=20 > BR, Maxim >=20 > 2011/12/21 Michael Vittrup Larsen > I don't believe this is a correct interpretation of the articles from = Armando > et. al ([4] of RFC4460). I believe the correct interpretation is >=20 > "fast retransmissions should be sent to the destination to which > we currently are sending data" >=20 > Note that this is not the same as "...to the same destination where = initial > transmissions were sent" in case of current primary path failovers. = In fact, > if we send fast retransmissions "...to the same destination where = initial > transmissions were sent" we may in fact be sending these on a path = different > from where we currently are sending data - and this is exactly (to my > understanding) what the change in SCTP fast retransmission in RFC4960 = is all > about. >=20 > To see why we need to look behind the words used by RFC4960 and into = the > articles and the reasoning in the articles: >=20 > 1) Sending fast retransmissions (FR) on a path different from where we > currently are sending new data may be subject to excessive RTO values = on the > alternative path. Successful FRs do not update the RTT of the = alternative path > due to Karns algorithm and the RTO on the alternative path is = therefore > conservative for the majority of the association and sending FRs on = such a > path is not optimal. >=20 > 2) FRs do not benefit the cwnd of the path where we are sending new = data but > instead the cwnd of the alternative path, which is less attractive. >=20 > 3) Possible timeouts of FRs sent on the alternative path will delay = cwnd > increments on the path where we are sending new data. Since these = timeouts are > conservative the delay may be excessive. >=20 > Neither [4] nor RFC4960 explicitly in text describes the FR policy in = case > where a change of the current primary data transfer path has occurred. = But in > essence the above reasoning/discovery of [4] clearly dictates what the = correct > interpretation should be. >=20 >=20 > Regards, > Michael >=20 > On Friday, December 09, 2011 11:34:34 Michael T=FCxen wrote: > > On Dec 9, 2011, at 8:27 AM, Maxim Proshin wrote: > > > Hi experts, > > > > > > here I would like to discuss the Fast Retransmission algorithm in = RFC > > > 4960. Frankly this RFC does not describe clearly how to send (to = which > > > destination) fast retransmissions but we can find some information = in > > > RFC 4460 which says: > > > > > > " > > > 2.39. Retransmission Policy > > > > > > 2.39.1. Description of the Problem > > > > > > The current retransmission policy (send all retransmissions an > > > alternate destination) in the specification has performance issues > > > under certain loss conditions with multihomed endpoints. Instead, > > > fast retransmissions should be sent to the same destination, and = only > > > timeout retransmissions should be sent to an alternate destination = [4]. > > > " > > > > > > Reading this article my first feeling was that fast = retransmissions > > > should be sent to the same destination where initial transmissions = were > > > sent. > > > > > > So my first question is > > > > > > is my RFC interpretation correct or not? > > > > Yes. Fast retransmissions should be send to the same destination as = the > > initial transmission. Timer based retransmissions should use an = alternate > > destination. > > > > > Meanwhile, there are some more articles about retransmision = policies > > > where RFC's authors also participated. For instance, = "Retransmission > > > Policies With Transport Layer Multihoming" describes some = improvements > > > in fast retransmission policy in respect to RFC 2960 and I think = that > > > they were considered during RFC 4960 preparation. This analysis = also > > > proposes to send fast retransmissions to the same destination: " > > > In this solution, all retransmissions are sent to the > > > same destination as their original transmissions. > > > ... > > > Instead of all > > > retransmissions following the Retransmit to Same Destination > > > policy of Solution 1, only Fast Retransmissions > > > should follow this policy. > > > " > > > > > > It seems that this statement confirms my initial feeling described = above. > > > But at the same time it says about primary path: " > > > Using the same destination for retransmissions has > > > the added advantage that the primary destination's cwnd > > > bene ts from successful retransmissions. > > > " > > > and it results is some doubts. On the one hand fast = retransmissions > > > should be sent to the same destination, on the other it should be = sent > > > to the primary destination. In usual case "the same" and primary > > > destinations are equal. But RFC 4960 doesn't prevent primary = destination > > > changing by the user so it can be changed in run-time. > > > > > > So my second question is > > > > > > if the primary destination is changed in run-time, where SCTP = should > > > sent fast retransmissions which were detected for the previous = primary > > > destination? > > > > Changing the primary is normally not done at a high rate. So you are > > looking at the case where fast retransmission occur and the user = changed > > the primary in between. > > > > I guess there is no special case on the RFC for that. So the fast > > retransmission would go to the destination to which it was initially = sent. > > The same applies if the user specified a destination and therefore = the > > primary was not used. > > > > > The mentioned above article describes one advantage in respect to = sending > > > to the primay destination, this is about cwnd benets from = successful > > > retransmission. But I think that in case of fast retransmission it = will > > > not be observed or the advantage is very very low. > > > > > > At the same time sending to the primary destination results in a = big > > > disadvantage: SCTP should recalculate cwnd if it sends fast > > > retransmissions to the primary destination because RFC 4960 says: = " > > > When a Fast Retransmit is being performed, the sender SHOULD = ignore the > > > value of cwnd " > > > I think the reason is that it was considered during initial = transmission. > > > > If you do a fast retransmit, you assume that the packet has left the > > network. So you would have to subtract and add it. This means = ignoring... > > > > Best regards > > Michael > > > > > What do you think about this? > > > > > > I'm not sure whether it was discussed already or not. If yes, = please > > > provide me with discussion's results. >=20 > -- > = **************************************************************************= *************** > Michael Vittrup Larsen > Software Architect >=20 > Tieto Denmark A/S > IP Solutions, Telecom & Media > Skanderborgvej 232, 8260 Viby J, DK-Denmark > Direct Phone / Mobile +45 3091 8469 > E-mail: michael.larsen@tieto.com > = **************************************************************************= *************** > www.tieto.com >=20 > Please note: The information contained in this message may be legally > privileged and confidential and protected from disclosure. If the = reader of > this message is not the intended recipient, you are hereby notified = that any > unauthorised use, distribution or copying of this communication is = strictly > prohibited. If you have received this communication in error, please = notify us > immediately by replying to the message and deleting it from your = computer. > Thank You. >=20 >=20 >=20 > --=20 > BR, Max ----- Randall Stewart randall@lakerest.net From Michael.Tuexen@lurchi.franken.de Tue Jan 17 04:28:04 2012 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82CC021F858A for ; Tue, 17 Jan 2012 04:28:04 -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 vzCMIgBJHcuB for ; Tue, 17 Jan 2012 04:28:03 -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 66D7E21F8522 for ; Tue, 17 Jan 2012 04:28:02 -0800 (PST) Received: from [192.168.1.103] (p508FA9BF.dip.t-dialin.net [80.143.169.191]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id AC5401C0B4611; Tue, 17 Jan 2012 13:27:59 +0100 (CET) Subject: Re: Fast Retransmission in SCTP Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=windows-1252 From: Michael Tuexen In-Reply-To: <7CC7D166-F6A9-4F91-A9D1-376AEC9CBEF8@lakerest.net> Date: Tue, 17 Jan 2012 13:27:59 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <956A8682-B75D-4EBF-B72D-DAEBAE38FFAF@lurchi.franken.de> References: <201112211355.39643.michael.larsen@tieto.com> <7CC7D166-F6A9-4F91-A9D1-376AEC9CBEF8@lakerest.net> To: Randy Stewart X-Mailer: Apple Mail (2.1251.1) Cc: tsvwg@ietf.org 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, 17 Jan 2012 12:28:04 -0000 On Jan 17, 2012, at 1:01 PM, Randy Stewart wrote: > Maxim: >=20 > Being one of the authors of the paper and research and having > done a few other things on SCTP.. I will add my 2 cents ;-)=85 mostly=20= > in-line .. but out of line here too :-) >=20 > In general sending FR to where they originally were sent is a good > idea. The reason being is the ACK clock is not broken.. you just = noticed > something was lost. Once you move it to another destination you are = moving > it to somewhere that is what the first Michael below describes=85 and=20= > further more, if you do that, you can *not* do more than one fast = retransmit > per packet. So if you have an unlucky packet that gets dropped twice = but you > have not loss the ack-clock, you are going to take a full scale = time-out in > order to get it through. >=20 > I have seen this happen in real networks and have found it best then = to > keep the packet on the path it was originally sent on in general. >=20 > Now all of that is in *general true* for when > a) You have NOT switched primary's > > b) You still have an ACK-Clock. >=20 > If on the other hand, the user has switched primary's or the primary = has > died and move to another path. You may not wish to follow that advice. >=20 > The RFC very specifically left loose not adding any MUST so that an = implementation > can have some freedom if it wants to worry about these corner cases. = This is a good > thing.. since there are several corner cases that one can dream up = that then the > standard advice.. keep the packet on the same path originally sent = on.. would *not* > be a good choice. =20 >=20 I agree with Randy. The RFC considers the most common situation and uses = non binding terms (there is no MUST, MUST NOT or so) to suggest what to do. In = specific rare situations, a different behavior might be better, and is allowed by the = RFC. Best regards Michael >=20 > On Jan 17, 2012, at 5:11 AM, Maxim Proshin wrote: >=20 >> Hi, >>=20 >> it seems that your point is reasonable but it still requires some = clarfifications: >>=20 >> 1. You are talking about "current primary path failovers". What if = the user defined a destination? Should SCTP send fast retransmissions to = the primary destination anyway? >=20 > I personally would still hold the original path if the user swapped = paths since the > ack clock will slowly shut down. Unless of course you know that there = is nothing > left on that old path of course.. again this is quite a corner case. = Most FR's will > happen with no switches, no deaths, just a momentary drop by a router = in the network > to slow us down a bit. >=20 >>=20 >> 2. It is unclear how the Karns algorithm can affect RTO calculation = during FR. If the primary destination is just changed and gaps are = detected for the previous primary destination, it means that RTO could = not be changed (at least due to Karns algorithm). Could you please = clarify scenarious where it could happen? In your item 1 you are talking = about an alternative path and conservative RTO. I think you mean the = previous primary destination then it is unclear why its RTO is = conservative. >=20 >>=20 >> 3. I agree with the drawback about CWND. But as usually there are = pros and cons. How do you propose to calculate CWND in this case? Should = it be recalculated for the previous primary destination and new one (or = defined by the user and primary one)? Looks like it should be = recalculated but in such case it impacts SCTP performance and conflicts = with RFC. It seems there are also problematic scenarious if CWND is = recalculated. What if the number of bytes in in-flight for the new = primary destination is equal to CWND, how fast retransmissions from the = previous primary one should be made in such case, should it be = postponed? Moreover changing the primary destination is not normally = done often and amount of fast retransmissions to the previous primary = destination will not give a big impact on CWND in comparison with all = data.=20 >=20 > I think this is again splitting hairs. The loss of one opportunity to = grow the CWND in one > obscure corner case where the user switched primary's (or the path = died) is not important. > If the user switches primary's he is going to take a hit anyway since = the old path > with a very open cwnd (possibly) will of course have much more data = going through it > vs the new path that is sitting at the initial window. In the case of = path-death, well > again the new path will probably be in slow start and its just a = consequence of the path > switch... >=20 > In fact actually the more I think on this it must be that the user = switched the primary > since if the path exceeded its strike count and was marked as down, = all the packets > in-flight or otherwise, must be moved to the new primary.=20 >=20 > Unless of course you get a double switch back, i.e. it restores.. in = which case > we are again walking a very narrow corner.=20 >=20 > Again, this is why the wording is loose, to allow the implementations = the ability to > add code to handle obscure corner cases if they wish. >=20 > R >=20 >=20 >>=20 >> BR, Maxim >>=20 >> 2011/12/21 Michael Vittrup Larsen >> I don't believe this is a correct interpretation of the articles from = Armando >> et. al ([4] of RFC4460). I believe the correct interpretation is >>=20 >> "fast retransmissions should be sent to the destination to which >> we currently are sending data" >>=20 >> Note that this is not the same as "...to the same destination where = initial >> transmissions were sent" in case of current primary path failovers. = In fact, >> if we send fast retransmissions "...to the same destination where = initial >> transmissions were sent" we may in fact be sending these on a path = different >> from where we currently are sending data - and this is exactly (to my >> understanding) what the change in SCTP fast retransmission in RFC4960 = is all >> about. >>=20 >> To see why we need to look behind the words used by RFC4960 and into = the >> articles and the reasoning in the articles: >>=20 >> 1) Sending fast retransmissions (FR) on a path different from where = we >> currently are sending new data may be subject to excessive RTO values = on the >> alternative path. Successful FRs do not update the RTT of the = alternative path >> due to Karns algorithm and the RTO on the alternative path is = therefore >> conservative for the majority of the association and sending FRs on = such a >> path is not optimal. >>=20 >> 2) FRs do not benefit the cwnd of the path where we are sending new = data but >> instead the cwnd of the alternative path, which is less attractive. >>=20 >> 3) Possible timeouts of FRs sent on the alternative path will delay = cwnd >> increments on the path where we are sending new data. Since these = timeouts are >> conservative the delay may be excessive. >>=20 >> Neither [4] nor RFC4960 explicitly in text describes the FR policy in = case >> where a change of the current primary data transfer path has = occurred. But in >> essence the above reasoning/discovery of [4] clearly dictates what = the correct >> interpretation should be. >>=20 >>=20 >> Regards, >> Michael >>=20 >> On Friday, December 09, 2011 11:34:34 Michael T=FCxen wrote: >>> On Dec 9, 2011, at 8:27 AM, Maxim Proshin wrote: >>>> Hi experts, >>>>=20 >>>> here I would like to discuss the Fast Retransmission algorithm in = RFC >>>> 4960. Frankly this RFC does not describe clearly how to send (to = which >>>> destination) fast retransmissions but we can find some information = in >>>> RFC 4460 which says: >>>>=20 >>>> " >>>> 2.39. Retransmission Policy >>>>=20 >>>> 2.39.1. Description of the Problem >>>>=20 >>>> The current retransmission policy (send all retransmissions an >>>> alternate destination) in the specification has performance issues >>>> under certain loss conditions with multihomed endpoints. Instead, >>>> fast retransmissions should be sent to the same destination, and = only >>>> timeout retransmissions should be sent to an alternate destination = [4]. >>>> " >>>>=20 >>>> Reading this article my first feeling was that fast retransmissions >>>> should be sent to the same destination where initial transmissions = were >>>> sent. >>>>=20 >>>> So my first question is >>>>=20 >>>> is my RFC interpretation correct or not? >>>=20 >>> Yes. Fast retransmissions should be send to the same destination as = the >>> initial transmission. Timer based retransmissions should use an = alternate >>> destination. >>>=20 >>>> Meanwhile, there are some more articles about retransmision = policies >>>> where RFC's authors also participated. For instance, = "Retransmission >>>> Policies With Transport Layer Multihoming" describes some = improvements >>>> in fast retransmission policy in respect to RFC 2960 and I think = that >>>> they were considered during RFC 4960 preparation. This analysis = also >>>> proposes to send fast retransmissions to the same destination: " >>>> In this solution, all retransmissions are sent to the >>>> same destination as their original transmissions. >>>> ... >>>> Instead of all >>>> retransmissions following the Retransmit to Same Destination >>>> policy of Solution 1, only Fast Retransmissions >>>> should follow this policy. >>>> " >>>>=20 >>>> It seems that this statement confirms my initial feeling described = above. >>>> But at the same time it says about primary path: " >>>> Using the same destination for retransmissions has >>>> the added advantage that the primary destination's cwnd >>>> bene ts from successful retransmissions. >>>> " >>>> and it results is some doubts. On the one hand fast retransmissions >>>> should be sent to the same destination, on the other it should be = sent >>>> to the primary destination. In usual case "the same" and primary >>>> destinations are equal. But RFC 4960 doesn't prevent primary = destination >>>> changing by the user so it can be changed in run-time. >>>>=20 >>>> So my second question is >>>>=20 >>>> if the primary destination is changed in run-time, where SCTP = should >>>> sent fast retransmissions which were detected for the previous = primary >>>> destination? >>>=20 >>> Changing the primary is normally not done at a high rate. So you are >>> looking at the case where fast retransmission occur and the user = changed >>> the primary in between. >>>=20 >>> I guess there is no special case on the RFC for that. So the fast >>> retransmission would go to the destination to which it was initially = sent. >>> The same applies if the user specified a destination and therefore = the >>> primary was not used. >>>=20 >>>> The mentioned above article describes one advantage in respect to = sending >>>> to the primay destination, this is about cwnd benets from = successful >>>> retransmission. But I think that in case of fast retransmission it = will >>>> not be observed or the advantage is very very low. >>>>=20 >>>> At the same time sending to the primary destination results in a = big >>>> disadvantage: SCTP should recalculate cwnd if it sends fast >>>> retransmissions to the primary destination because RFC 4960 says: " >>>> When a Fast Retransmit is being performed, the sender SHOULD ignore = the >>>> value of cwnd " >>>> I think the reason is that it was considered during initial = transmission. >>>=20 >>> If you do a fast retransmit, you assume that the packet has left the >>> network. So you would have to subtract and add it. This means = ignoring... >>>=20 >>> Best regards >>> Michael >>>=20 >>>> What do you think about this? >>>>=20 >>>> I'm not sure whether it was discussed already or not. If yes, = please >>>> provide me with discussion's results. >>=20 >> -- >> = **************************************************************************= *************** >> Michael Vittrup Larsen >> Software Architect >>=20 >> Tieto Denmark A/S >> IP Solutions, Telecom & Media >> Skanderborgvej 232, 8260 Viby J, DK-Denmark >> Direct Phone / Mobile +45 3091 8469 >> E-mail: michael.larsen@tieto.com >> = **************************************************************************= *************** >> www.tieto.com >>=20 >> Please note: The information contained in this message may be legally >> privileged and confidential and protected from disclosure. If the = reader of >> this message is not the intended recipient, you are hereby notified = that any >> unauthorised use, distribution or copying of this communication is = strictly >> prohibited. If you have received this communication in error, please = notify us >> immediately by replying to the message and deleting it from your = computer. >> Thank You. >>=20 >>=20 >>=20 >> --=20 >> BR, Max >=20 > ----- > Randall Stewart > randall@lakerest.net >=20 >=20 >=20 >=20 >=20 From wes@mti-systems.com Wed Jan 18 21:11:20 2012 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6836F21F84A0 for ; Wed, 18 Jan 2012 21:11:20 -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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NWemGk+ki+F2 for ; Wed, 18 Jan 2012 21:11:20 -0800 (PST) Received: from omr10.networksolutionsemail.com (omr10.networksolutionsemail.com [205.178.146.60]) by ietfa.amsl.com (Postfix) with ESMTP id 0B7F321F849D for ; Wed, 18 Jan 2012 21:11:14 -0800 (PST) Received: from cm-omr9 (mail.networksolutionsemail.com [205.178.146.50]) by omr10.networksolutionsemail.com (8.13.8/8.13.8) with ESMTP id q0J5BBmS020712 for ; Thu, 19 Jan 2012 00:11:13 -0500 Authentication-Results: cm-omr9 smtp.user=wes@mti-systems.com; auth=pass (PLAIN) X-Authenticated-UID: wes@mti-systems.com Received: from [174.130.101.251] ([174.130.101.251:22202] helo=[192.168.1.102]) by cm-omr9 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id 8B/D3-12338-FE5A71F4; Thu, 19 Jan 2012 00:11:11 -0500 Message-ID: <4F17A5F0.4060502@mti-systems.com> Date: Thu, 19 Jan 2012 00:11:12 -0500 From: Wesley Eddy Organization: MTI Systems User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: tsvwg@ietf.org Subject: AD review of draft-ietf-tsvwg-source-quench Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: tsvwg chair , Fernando Gont 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, 19 Jan 2012 05:11:20 -0000 I think there are two small process-oriented changes that need to be made to this document prior to the IETF LC. 1 - I don't think it's proper to have a normative reference to RFC 1016. This would be a down-ref, and need to be called out that way in IETF LC, but I think the right thing to do is to not have it as normative in the first place, since not implementing a congestion response to SQ doesn't require 1016 (it un-requires it!). 2 - I think to make 1016 historic, we need "Obsoletes: 1016" in the header. Otherwise, I think this is ready to go. -- Wes Eddy MTI Systems From fernando.gont.netbook.win@gmail.com Wed Jan 18 21:46:09 2012 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB7AA21F8548 for ; Wed, 18 Jan 2012 21:46:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.466 X-Spam-Level: X-Spam-Status: No, score=-2.466 tagged_above=-999 required=5 tests=[AWL=-0.510, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_NJABL_PROXY=1.643] 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 Uk2MFIdpNMM6 for ; Wed, 18 Jan 2012 21:46:07 -0800 (PST) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id A487321F8537 for ; Wed, 18 Jan 2012 21:46:07 -0800 (PST) Received: by yenm3 with SMTP id m3so19316yen.31 for ; Wed, 18 Jan 2012 21:46:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; bh=wv6TNH4uIjR4PyjsdLdxi7Jfn7zQKX4r6vTS13S1MfE=; b=fk7UjOJOVl/7ghRvSt8Qk7coASu49/5x47GQzWotKGe2CMpAf6yHhCiQhcnXPliuV8 0ZbUQ7wBaWr2DwsaIcd5AdPtDAi45PlTpL8/Z0N20uqZtqQaC5yWjYKEbfw0kgy7hLKV pxHYXXksiuNNoz77wLA8+gcySmPAW6atiRh2I= Received: by 10.236.76.201 with SMTP id b49mr36829193yhe.11.1326951967241; Wed, 18 Jan 2012 21:46:07 -0800 (PST) Received: from [10.42.43.100] ([190.48.207.118]) by mx.google.com with ESMTPS id j16sm76580061anm.9.2012.01.18.21.46.04 (version=SSLv3 cipher=OTHER); Wed, 18 Jan 2012 21:46:06 -0800 (PST) Sender: Fernando Gont Message-ID: <4F17AE1A.2050104@gont.com.ar> Date: Thu, 19 Jan 2012 02:46:02 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.24) Gecko/20111108 Thunderbird/3.1.16 MIME-Version: 1.0 To: Wesley Eddy Subject: Re: AD review of draft-ietf-tsvwg-source-quench References: <4F17A5F0.4060502@mti-systems.com> In-Reply-To: <4F17A5F0.4060502@mti-systems.com> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: tsvwg chair , tsvwg@ietf.org 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, 19 Jan 2012 05:46:09 -0000 Hi, Wes, On 01/19/2012 02:11 AM, Wesley Eddy wrote: > I think there are two small process-oriented changes that need to be > made to this document prior to the IETF LC. > > 1 - I don't think it's proper to have a normative reference to RFC > 1016. This would be a down-ref, and need to be called out that > way in IETF LC, FWIW, my rationale for including it as "normative" was it wasn't just "additional information" (i.e., informative), but since we were moving it to historical, it was key to read it. That aside, RFC 1016 is not assigned to any track, so in some sense it was as including a normative ref to MD5 (which strictly speaking is a down ref, but which we have done in the past). > but I think the right thing to do is to not have > it as normative in the first place, since not implementing a > congestion response to SQ doesn't require 1016 (it un-requires > it!). No problem with that. > 2 - I think to make 1016 historic, we need "Obsoletes: 1016" in the > header. I seem to recall having an off-list discussion about this (with Alfred?) but do not really recall the details. I tried looking up "the Obsoletes" keyword in RFC 2026, but since its RFC-Editor metadata (?), it's not even mentioned there. That said, I agree with your suggestions. I will rev the I-D and post it today, unless I hear anything against proceeding this way. Thanks! Best regards, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From gorry@erg.abdn.ac.uk Thu Jan 19 00:37:37 2012 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6724821F86C5 for ; Thu, 19 Jan 2012 00:37:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.382 X-Spam-Level: X-Spam-Status: No, score=-102.382 tagged_above=-999 required=5 tests=[AWL=0.217, 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 v4K8XQJ-kJ8R for ; Thu, 19 Jan 2012 00:37:36 -0800 (PST) Received: from erg.abdn.ac.uk (dee.erg.abdn.ac.uk [IPv6:2001:630:241:204:203:baff:fe9a:8c9b]) by ietfa.amsl.com (Postfix) with ESMTP id 925DE21F846E for ; Thu, 19 Jan 2012 00:37:35 -0800 (PST) Received: from www.erg.abdn.ac.uk (blake.erg.abdn.ac.uk [139.133.210.30]) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id q0J8bPkB021517; Thu, 19 Jan 2012 08:37:25 GMT Received: from 212.159.18.54 (SquirrelMail authenticated user gorry) by www.erg.abdn.ac.uk with HTTP; Thu, 19 Jan 2012 08:40:11 -0000 Message-ID: <7ddcea66b6ea0c40f687935b3a8d26ac.squirrel@www.erg.abdn.ac.uk> In-Reply-To: <4F17AE1A.2050104@gont.com.ar> References: <4F17A5F0.4060502@mti-systems.com> <4F17AE1A.2050104@gont.com.ar> Date: Thu, 19 Jan 2012 08:40:11 -0000 Subject: Re: AD review of draft-ietf-tsvwg-source-quench From: gorry@erg.abdn.ac.uk To: "Fernando Gont" User-Agent: SquirrelMail/1.4.20 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-ERG-MailScanner: Found to be clean X-ERG-MailScanner-From: gorry@erg.abdn.ac.uk Cc: tsvwg chair , tsvwg@ietf.org 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, 19 Jan 2012 08:37:37 -0000 I think the obsoletes keyword will be essential and would support these two edits. Go ahead Fernando! Gorry > Hi, Wes, > > On 01/19/2012 02:11 AM, Wesley Eddy wrote: >> I think there are two small process-oriented changes that need to be >> made to this document prior to the IETF LC. >> >> 1 - I don't think it's proper to have a normative reference to RFC >> 1016. This would be a down-ref, and need to be called out that >> way in IETF LC, > > FWIW, my rationale for including it as "normative" was it wasn't just > "additional information" (i.e., informative), but since we were moving > it to historical, it was key to read it. > > That aside, RFC 1016 is not assigned to any track, so in some sense it > was as including a normative ref to MD5 (which strictly speaking is a > down ref, but which we have done in the past). > > >> but I think the right thing to do is to not have >> it as normative in the first place, since not implementing a >> congestion response to SQ doesn't require 1016 (it un-requires >> it!). > > No problem with that. > > > >> 2 - I think to make 1016 historic, we need "Obsoletes: 1016" in the >> header. > > I seem to recall having an off-list discussion about this (with Alfred?) > but do not really recall the details. I tried looking up "the Obsoletes" > keyword in RFC 2026, but since its RFC-Editor metadata (?), it's not > even mentioned there. > > That said, I agree with your suggestions. I will rev the I-D and post it > today, unless I hear anything against proceeding this way. > > Thanks! > > Best regards, > -- > Fernando Gont > e-mail: fernando@gont.com.ar || fgont@si6networks.com > PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 > > > From internet-drafts@ietf.org Thu Jan 19 02:10:59 2012 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2060A21F86C6; Thu, 19 Jan 2012 02:10:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.546 X-Spam-Level: X-Spam-Status: No, score=-102.546 tagged_above=-999 required=5 tests=[AWL=0.053, 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 ZYUP4w-5pl35; Thu, 19 Jan 2012 02:10:58 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A22EE21F86B1; Thu, 19 Jan 2012 02:10:45 -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 Subject: I-D Action: draft-ietf-tsvwg-source-quench-04.txt X-Test-IDTracker: no X-IETF-IDTracker: 3.64p1 Message-ID: <20120119101045.21400.35119.idtracker@ietfa.amsl.com> Date: Thu, 19 Jan 2012 02:10:45 -0800 Cc: tsvwg@ietf.org 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, 19 Jan 2012 10:10:59 -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 = Group of the IETF. Title : Deprecation of ICMP Source Quench messages Author(s) : Fernando Gont Filename : draft-ietf-tsvwg-source-quench-04.txt Pages : 9 Date : 2012-01-19 This document formally deprecates the use of ICMP Source Quench messages by transport protocols, formally updating RFC 792, RFC 1122, and RFC 1812. Additionally, it requests that the status of RFC 1016 be changed to "Historic". A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-source-quench-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-tsvwg-source-quench-04.txt From gorry@erg.abdn.ac.uk Thu Jan 19 04:00:41 2012 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72FC121F8574 for ; Thu, 19 Jan 2012 04:00:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.413 X-Spam-Level: X-Spam-Status: No, score=-102.413 tagged_above=-999 required=5 tests=[AWL=0.186, 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 MQrLY5saJUeu for ; Thu, 19 Jan 2012 04:00:40 -0800 (PST) Received: from erg.abdn.ac.uk (dee.erg.abdn.ac.uk [IPv6:2001:630:241:204:203:baff:fe9a:8c9b]) by ietfa.amsl.com (Postfix) with ESMTP id 51AB121F8575 for ; Thu, 19 Jan 2012 04:00:40 -0800 (PST) Received: from gorry-mac.erg.abdn.ac.uk (gorry-mac.erg.abdn.ac.uk [139.133.207.5]) (authenticated bits=0) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id q0JC0aFA025117 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 19 Jan 2012 12:00:36 GMT Message-ID: <4F1805E5.8070302@erg.abdn.ac.uk> Date: Thu, 19 Jan 2012 12:00:37 +0000 From: Gorry Fairhurst Organization: The University of Aberdeen is a charity registered in Scotland, No SC013683. User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: tsvwg WG Subject: TSVWG Status Summary -- January 2012 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ERG-MailScanner: Found to be clean X-ERG-MailScanner-From: gorry@erg.abdn.ac.uk Cc: Gorry Fairhurst X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: gorry@erg.abdn.ac.uk List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jan 2012 12:00:41 -0000 The list below shows the status of the working group documents as we see it. Please check below and comment on drafts using the list. Please do send any corrections/omissions to the chairs. Best wishes, James and Gorry (TSVWG Chairs) --- Recently published: draft-ietf-tsvwg-iana-ports was published as RFC 6335. draft-ietf-tsvwg-rsvp-security-groupkeying was published as RFC 6411. draft-ietf-tsvwg-sctpsocket was published as RFC 6458. IDs in RFC Editor Queue: draft-ietf-tsvwg-sctp-strrst Dependency on this for IPFIX document with RFC-Ed. WGLC completed. James is Shepherd. ------------------------------------------------------------------- IDs in IESG processing: draft-ietf-tsvwg-source-quench (Replaced: draft-gont-tsvwg-source-quench-01.txt) IETF-79 suggested there was interest in this topic. Comments to list in 2010 from: Fred Baker, Antonio DeSimone, James Polk, Gorry Fairhurst, Andrew Yourtchenko, and others. WG agreed the draft should be a work item. More motivation was needed to justify the SHOULD cases. WGLC completed. Gorry is Shepherd. Document write-up sent to WG (9th Jan 2012) Draft revised to add "obsoletes" line. DUE: AD review in progress ------------------------------------------------------------------- WG Drafts with Chairs: draft-ietf-tsvwg-byte-pkt-congest New editor added Jul 2010. New revision 25 Oct 2010. WG -01, June 10, 2011 IETF-81: discussed whether this should be BCP. ADs & Chairs agree to progress as a BCP Status changed to BCP (new-ID WG -05) Presented at IEWTF-82 (Taipei), request for WGLC. Gorry added as Shepherd (Jan 2012) DUE: Reviewers need to volunteer for LC DUE: WG Chairs to review document with a view to WGLC Please comment on list. ------------------------------------------------------------------- WG Drafts: draft-ietf-tsvwg-natsupp-tsvwg (Replaced: draft-stewart-natsupp-tsvw) Dependency from BEHAVE WG. Adopted as a work item 21 Sept 2010 (Gorry). WG -00, 29/11/2010 Uploaded as: draft-ietf-natsupp-tsvwg WG -01, June 1, 2011 DUE: Reviews need. draft-ietf-tsvwg-sctp-udp-encap (Replaced: draft-tuexen-sctp-udp-encap) Lars sent a note as AD agreeing to progress this work. Work to be coordinated with DCCP work on encaps. draft-tuexen-sctp-udp-encaps-06, January 10, 2011 Adopted as a work item 21 Sept 2010 (Gorry) WG -02 8 Dec 2011 DUE: New revision need. draft-ietf-tsvwg-intserv-multiple-tspec WG interest in this topic recorded at IETF-78. Charter update would be needed to progress this work. 5 Reviews needed to determine energy/technical direction. WG -05 (presented in Beijing, IETF-79) WG -06 (presented in Prague, IETF-80) RSVP directorate was consulted. 2 reviews from RSVP-DIR received (Bruce Davie, ?) 2 additional reviews promised (Ken Carlberg, Francois LeF) Chairs asked AD for a Charter update (IESG agreed) Draft discussed at IETF-80, and request to update charter agreed - AD advised 4 named reviewers will be required Adopted for progression as PS, for May 2012 draft-ietf-tsvwg-rsvp-pcn Previous version : draft-karagiannis-pcn-tsvwg-rsvp-pcn WG interest in this topic recorded at IETF-81. Individual -01, 2011-07-11 AD decision allowed this to be added to the milestones The document was adopted WG -00 8 Oct 2011 DUE: New revision need ------------------------------------------------------------------- WG action required: draft-touch-tsvwg-port-use-00 - Intended to be advice to protocol designers needing a port. 5 people have looked at this document, Prague IETF-80 Individual -01 July 2011 IETF-81 insufficient feedback from WG at this time. WG needs to assess if the new draft should be a work item. IETF-82, discussed - Chairs will ask WG to consider. DUE: Chairs need to assess energy for work on this topic. Please comment on list. draft-nishida-tsvwg-sctp-failover Individual-00 Presented in Prague, IETF-80. - understood not to conflict with draft-tuexen-tsvwg-sctp-multipath DUE: New revision need. draft-tuexen-tsvwg-sctp-multipath -00 Presented in Prague, IETF-80. - understood not to conflict with draft-nishida-tsvwg-sctp-failover -01, 2010-12-27 Please comment to list. draft-tuexen-tsvwg-sctp-sack-immediately -05, 2011-01-02 - Aug 2011, discussed on list and issues raised. DUE: Chairs need to confirm adoption (need to do work). DUE: New revision need (to address comments) Please comment on list. ------------------------------------------------------------------- The following have received recent discussion at TSVWG meetings or on the list. Inclusion in the list below does not indicate support for these specific drafts and other contributions are also warmly welcomed. draft-stewart-tsvwg-sctpecn-00 Partially replaces (draft-stewart-tsvwg-sctp-nonce) IETF-78 suggested there was interest in this topic. Please comment to list. Revised uploaded with new name. - The draft needs to be updated for multihoming (IETF-80) - new revision expected April 2011 (IETF-80) WG needs to assess if the new draft should be a work item. Please comment on list. draft-briscoe-tsvwg-ecn-encap-guidelines -00 Presented in Prague, IETF-80. - comments at IETF-80 (see minutes) WG needs to assess if the new draft should be a work item. Please comment on list. DUE: Chairs to check liaison status with other SDOs. draft-carlberg-tsvwg-ecn-reactions Reactions to Signaling from ECN Support for RTP/RTCP -00 presented IETF-82 WG needs to assess if the new draft should be a work item. Please comment on list. ------------------------------------------------------------------- draft-polk-tsvwg-rsvp-app-id-vv-profiles -01 Presented in Beijing, IETF-79. -02, 14-Mar-2011 Presented IET-80. WG needs to assess if the new draft should be a work item. Seek to coordinate with music with partner ID: draft-polk-mmusic-traffic-class-for-sdp Please comment on list. DUE: Chairs to liaise with MMUSIC WG (Gorry). draft-lefaucheur-tsvwg-rsvp-multiple-preemption RSVP directorate to be consulted. - Reviewers: Bruce Davie (awaiting other reviews) Please comment to list. draft-wing-tsvwg-happy-eyeballs-sctp This appears dead. ------------------------------------------------------------------- Related non-WG items: draft-ietf-behave-sctpnat-03.txt BEHAVE WG item linked to SCTP encapsulation work. draft-ietf-6man-udpzero Previoiusly: draft-fairhurst-tsvwg-6man-udpzero Draft was adopted by 6man, please discuss on the 6man list. A WGLC of this draft is expected in 6MAN WG. Related draft: draft-ietf-6man-udpchecksums-00 Expected to start WGLC early 2012. This draft will be LC'ed in TSVWG also. ------------------------------------------------------------------ Other news: RSVP Directorate (formed in May 2010) Charter updated Aug 2011. ------------------------------------------------------------------ From iesg-secretary@ietf.org Fri Jan 20 08:37:35 2012 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB62A21F862B; Fri, 20 Jan 2012 08:37:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.347 X-Spam-Level: X-Spam-Status: No, score=-102.347 tagged_above=-999 required=5 tests=[AWL=0.252, 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 UP4DrEyIVsBM; Fri, 20 Jan 2012 08:37:35 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FCD721F853C; Fri, 20 Jan 2012 08:37:35 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce Subject: Last Call: (Deprecation of ICMP Source Quench messages) to Proposed Standard and RFC 1016 to Historic X-Test-IDTracker: no X-IETF-IDTracker: 3.64p1 Message-ID: <20120120163735.28544.13719.idtracker@ietfa.amsl.com> Date: Fri, 20 Jan 2012 08:37:35 -0800 Cc: tsvwg@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jan 2012 16:37:35 -0000 The IESG has received a request from the Transport Area Working Group WG (tsvwg) to consider the following document: - 'Deprecation of ICMP Source Quench messages' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2012-02-03. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document formally deprecates the use of ICMP Source Quench messages by transport protocols, formally updating RFC 792, RFC 1122, and RFC 1812. Additionally, it requests that the status of RFC 1016 be changed to "Historic". The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-tsvwg-source-quench/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-tsvwg-source-quench/ No IPR declarations have been submitted directly on this I-D. From gorry@erg.abdn.ac.uk Sat Jan 21 00:52:14 2012 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB12121F8460 for ; Sat, 21 Jan 2012 00:52:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.437 X-Spam-Level: X-Spam-Status: No, score=-102.437 tagged_above=-999 required=5 tests=[AWL=0.163, 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 DKktfKdDITzZ for ; Sat, 21 Jan 2012 00:52:14 -0800 (PST) Received: from erg.abdn.ac.uk (dee.erg.abdn.ac.uk [IPv6:2001:630:241:204:203:baff:fe9a:8c9b]) by ietfa.amsl.com (Postfix) with ESMTP id 0330B21F8455 for ; Sat, 21 Jan 2012 00:52:13 -0800 (PST) Received: from ra-gorry.erg.abdn.ac.uk (ra-gorry.erg.abdn.ac.uk [139.133.204.42]) (authenticated bits=0) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id q0L8q5qj003058 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Sat, 21 Jan 2012 08:52:06 GMT Message-ID: <4F1A7CB5.60509@erg.abdn.ac.uk> Date: Sat, 21 Jan 2012 08:52:05 +0000 From: Gorry Fairhurst Organization: The University of Aberdeen is a charity registered in Scotland, No SC013683. User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: tsvwg@ietf.org Subject: TSVWG meeting minutes from IETF-82 (TAIPEI) References: <4F17E2D2.9070203@erg.abdn.ac.uk> In-Reply-To: <4F17E2D2.9070203@erg.abdn.ac.uk> X-Forwarded-Message-Id: <4F17E2D2.9070203@erg.abdn.ac.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ERG-MailScanner: Found to be clean X-ERG-MailScanner-From: gorry@erg.abdn.ac.uk X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: gorry@erg.abdn.ac.uk List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Jan 2012 08:52:15 -0000 The Chairs have checked the notes and audio record, and propose the minutes below for the Taipei TSVWG meeting. Does anyone know of any corrections to these notes, or are they acceptable to the group? Best wishes James and Gorry (TSVWG Co-Chairs) ------ TSVWG Meeting Notes IETF 82 (TAIPEI) Meeting Chair: Wes Eddy (TSV AD). WG Chairs: Gorry Fairhurst & James Polk Agenda * Working Group Drafts Jukka Manner draft-ietf-tsvwg-byte-pkt-congest * Non-Working Group Drafts Ken Carlberg - Reactions to Signaling from ECN Support for RTP/RTCP draft-carlberg-tsvwg-ecn-reactions-00 Joe Touch - Recommendations for Transport Port Uses draft-touch-tsvwg-port-use Joe Touch - Shared Use of Experimental TCP Options draft-touch-tcpm-experimental-options-00 Michio Honda - Towards Extending the TCP Option Space --- draft-ietf-tsvwg-byte-pkt-congest - Jukka Manner Document received feedback and has been updated. The authors would like to move to WGLC. --- draft-touch-tsvwg-port-use A quick hum was taken on whether or not this document should be adopted as a TSVWG working group document. The consensus of the room seemed to be YES, though this needs to be confirmed on the mailing list. Mirja Kuehlewind: Who is the document addressed to? Joe: Anybody who wishes to apply for a port number or use a port number in a new way. Brian Carpenter: I noted you mentioned deprecation of the system/user port boundary. This seems like a disjunct issue. Joe: I do not like too many documents, we should check with the WG on the best way forward. --- draft-carlberg-tsvwg-ecn-reactions-00 This draft should be taken to the mailing list for discussion; not many people in the meeting room had read it yet, though there was interest in continuing to discuss the topic. Colin Perkins noted related work on RTCweb and a related AVT draft to communicate feedback information. It is good to note the options, but we should be careful about developing new methods. Bob Briscoe (via jabber): Does it also include loss? Ken: Not at the moment, comments welcome. --- draft-touch-tcpm-experimental-options-00 Joe presented this document in TSVWG since the problem of supporting "experiments" includes other topics in addition to the TCPM options kind numbers that the document currently focuses on. Scope of this document was discussed to determine whether it should remain TCP-focused and be handled in TCPM, or whether it was more appropriate for TSVWG or an even broader group. It was also suggested that the document should motivate use of assigned ports. A hum was taken, though it may have been confusing; consensus seems to be to handle this in TCPM focused on the options issue. --- Michio Honda gave a teaser presentation on his work testing the use of TCP options through middleboxes that will be presented at the IRTF open session. ---- Notes updated by G Fairhurst from the audio archive and circulated to mailing list 19-Jan-2012. From nishida@sfc.wide.ad.jp Wed Jan 25 02:08:58 2012 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65AFC21F8615 for ; Wed, 25 Jan 2012 02:08:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.848 X-Spam-Level: X-Spam-Status: No, score=-98.848 tagged_above=-999 required=5 tests=[AWL=-0.374, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RELAY_IS_203=0.994, 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 96tiMxhcHjRA for ; Wed, 25 Jan 2012 02:08:57 -0800 (PST) Received: from mail.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [203.178.142.130]) by ietfa.amsl.com (Postfix) with ESMTP id D2B0C21F8603 for ; Wed, 25 Jan 2012 02:08:56 -0800 (PST) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 2D6172780DD for ; Wed, 25 Jan 2012 19:08:51 +0900 (JST) Received: by lahl5 with SMTP id l5so1080485lah.31 for ; Wed, 25 Jan 2012 02:08:49 -0800 (PST) MIME-Version: 1.0 Received: by 10.152.128.163 with SMTP id np3mr4625449lab.51.1327486129023; Wed, 25 Jan 2012 02:08:49 -0800 (PST) Received: by 10.112.84.10 with HTTP; Wed, 25 Jan 2012 02:08:48 -0800 (PST) Date: Wed, 25 Jan 2012 02:08:48 -0800 Message-ID: Subject: RE: I-D Action: draft-nishida-tsvwg-sctp-failover-04.txt From: Yoshifumi Nishida To: Karen.Nielsen@tieto.com, tsvwg Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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, 25 Jan 2012 10:08:58 -0000 Hi Karen, Sorry for my very slow response. I've thought about this a bit more. If you have comments or if I miss something, please let me know. First, I would like to start from a scenario which PF increases error count aggressively. Let's assume we have an SCTP association consists of 2 paths and have one outstanding packet. Now, I would like to think about the following 2 cases for this. case 1: 1 path became unavailable and after for a while the 2nd path became unavailable. case 2: 2 paths became unavailable simultaneously In case of case 1, if HB is on, SCTP detects an unavailable path and mark them as inactive eventually. consecutive error count is 0 until the 2nd path becomes unavail= able. Hence, PF and RFC4960 will have the same behavior in this case, so I think we can exclude this. Now, in case of case 1 without HB or case 2, I think RFC4960 behavior will be like this: =A0 =A01: if t3-rtx expires doubled RTO for the destination address =A0 =A02: increase consecutive error count. if it exceeds AMR, terminate the association =A0 =A03: choose one of paths (probably by round-robin) as new destination of retransmission =A0 =A04: send a retransmit packet and start t3-rtx timer. Even if the association goes into dormant state during this cycle, I think the behavior will be mostly similar. In case of PF, the behavior will be something like this: =A0 =A01: if t3-rtx expires doubled RTO (data or HB) for the destination ad= dress =A0 =A02: increase consecutive error count. if it exceeds AMR, terminate the association =A0 =A03: choose active path for new destination of retransmission. if there is no active path, choose one of paths in PF state (probably by round-robin). =A0 =A04: send a retransmit packet and start t3-rtx timer. =A0 =A05: send a HB on the path where t3-rtx is not running and start t3-rt= x. So, the step 5 is the reason for the aggressiveness. In order to address this issue, I think we have the following 3 options. Option 1: =A0 =A0Don't increment consecutive error count when HB transmission is timed out as you suggested. Option 2: =A0 =A0When we have to send data to the destination in PF state, don't send HB to any PF destination. Option 3: =A0 =A0When there's multiple paths in PF state, send one HB at one time. Here's my opinion on them. I prefer not to do option 1 in PF. It seems to me that this should be discussed for RFC4960 rather than PF. I would like to keep PF to be consistent with RFC4960 with regard to this. So, I prefer option 2 or 3 although I don't have a strong opinion yet. Or, we can adopt both option 2 and 3 if necessary. Thanks, -- Yoshifumi Nishida 2011/12/8 =A0: > Hi, > > One additional comment to the draft. > Not sure about whether it has been raised already though. > > The aggressive HBs sent on a potentially failed destination address shoul= d not contribute > to the association overall error counter. I.e., a failed HB should not in= crement the associations error counter. > > At least that it how I firmly believe that things should be as the robust= ness of the > association error count should not be impacted by the more aggressive HB = probing > (Also simply following the approach of RFC4960 Path Verification. 5.4 of = RFC4960) > > Would it be possible to have this explicitly clarified in the draft ? > > Thanks. > BR, Karen > > -----Original Message----- > From: tsvwg-bounces at ietf.org [mailto:tsvwg-bounces at ietf.org] On Beh= alf Of Yoshifumi Nishida > Sent: 16. september 2011 10:22 > To: tsvwg > Subject: Re: I-D Action: draft-nishida-tsvwg-sctp-failover-04.txt > > Hi folks, > > Based on the michael's review, we have updated the sctp failover draft. > We believe we addressed the comments we got so far. > > Please let us know if we overlook something or if you have more comments. > > Thanks, > -- > Yoshifumi Nishida > nishida at sfc.wide.ad.jp From karagian@cs.utwente.nl Wed Jan 25 02:54:44 2012 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBB8821F85AF for ; Wed, 25 Jan 2012 02:54:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.504 X-Spam-Level: X-Spam-Status: No, score=-0.504 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] 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 00x8Sol05C-m for ; Wed, 25 Jan 2012 02:54:44 -0800 (PST) Received: from EXEDGE02.ad.utwente.nl (exedge02.ad.utwente.nl [130.89.5.49]) by ietfa.amsl.com (Postfix) with ESMTP id 28CF921F8570 for ; Wed, 25 Jan 2012 02:54:44 -0800 (PST) Received: from EXHUB01.ad.utwente.nl (130.89.4.228) by EXEDGE02.ad.utwente.nl (130.89.5.49) with Microsoft SMTP Server (TLS) id 14.1.339.1; Wed, 25 Jan 2012 11:54:48 +0100 Received: from EXMBX06.ad.utwente.nl ([169.254.6.120]) by EXHUB01.ad.utwente.nl ([130.89.4.228]) with mapi id 14.01.0339.001; Wed, 25 Jan 2012 11:54:42 +0100 From: To: Subject: Solicitation for comments on draft-ietf-tsvwg-rsvp-pcn-00 Thread-Topic: Solicitation for comments on draft-ietf-tsvwg-rsvp-pcn-00 Thread-Index: AczbT7ucck4AlJY6SWO9pmbURQHAVw== Date: Wed, 25 Jan 2012 10:54:41 +0000 Message-ID: Accept-Language: nl-NL, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.89.12.129] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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, 25 Jan 2012 10:54:45 -0000 Hi all,=20 I am planning to resubmit the http://datatracker.ietf.org/doc/draft-ietf-ts= vwg-rsvp-pcn/ before the IETF meeting in Paris! I will very much appreciat= e if you read this draft and send your comments to the tsvwg mailing list b= efore the 15th of February 2012! Best regards, Georgios From gorry@erg.abdn.ac.uk Wed Jan 25 03:58:04 2012 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEFF921F8629 for ; Wed, 25 Jan 2012 03:58:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.481 X-Spam-Level: X-Spam-Status: No, score=-102.481 tagged_above=-999 required=5 tests=[AWL=0.118, 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 Dd5htGwI3+ez for ; Wed, 25 Jan 2012 03:58:04 -0800 (PST) Received: from erg.abdn.ac.uk (dee.erg.abdn.ac.uk [IPv6:2001:630:241:204:203:baff:fe9a:8c9b]) by ietfa.amsl.com (Postfix) with ESMTP id F205421F861C for ; Wed, 25 Jan 2012 03:58:03 -0800 (PST) Received: from gorry-mac.erg.abdn.ac.uk (gorry-mac.erg.abdn.ac.uk [139.133.207.5]) (authenticated bits=0) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id q0PBvwGb023836 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 25 Jan 2012 11:57:58 GMT Message-ID: <4F1FEE46.8010203@erg.abdn.ac.uk> Date: Wed, 25 Jan 2012 11:57:58 +0000 From: Gorry Fairhurst Organization: The University of Aberdeen is a charity registered in Scotland, No SC013683. User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: tsvwg WG Subject: WG call for interest to work on draft-touch-tsvwg-port-use [due: 10-Feb-12] References: <201201190012.q0J0CUEa023243@mtv-core-3.cisco.com> In-Reply-To: <201201190012.q0J0CUEa023243@mtv-core-3.cisco.com> X-Forwarded-Message-Id: <201201190012.q0J0CUEa023243@mtv-core-3.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ERG-MailScanner: Found to be clean X-ERG-MailScanner-From: gorry@erg.abdn.ac.uk X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: gorry@erg.abdn.ac.uk List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2012 11:58:05 -0000 The TSV working group is considering the possibility of adopting the topic of the below as a work item. Please send email to this list to help the WG Chairs determine if this document should proceed within the TSVWG. Recommendations for Transport Port Uses http://tools.ietf.org/html/draft-touch-tsvwg-port-use-01 This document was presented at IETF-81. At that time, but at that time there was little comment on the draft. A hum at IETF-82 indicated there may be interest in work on this topic. Therefore, the Chairs request feedback from this working group, by 10th Feb 2012. Please send email to this group (or the Chairs) in response to the following: * Have you read this version of the draft? * Do you think this is an important area of work for TSVWG? * Do you think *THIS* draft is a good a starting point for the work? * Do you plan to contribute or help write the WG draft? * Would you be willing to comment upon/review future versions of this work for the working group? All comments are welcome via the list, or directly to the WG Chairs. Gorry & James (tsvwg chairs) -- Prof Gorry Fairhurst, School of Engineering, University of Aberdeen. The University of Aberdeen is a charity registered in Scotland, No SC013683. From gorry@erg.abdn.ac.uk Sat Jan 28 01:35:59 2012 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB41B21F8537 for ; Sat, 28 Jan 2012 01:35:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.491 X-Spam-Level: X-Spam-Status: No, score=-102.491 tagged_above=-999 required=5 tests=[AWL=0.108, 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 jNz3NzemfpAK for ; Sat, 28 Jan 2012 01:35:59 -0800 (PST) Received: from erg.abdn.ac.uk (dee.erg.abdn.ac.uk [IPv6:2001:630:241:204:203:baff:fe9a:8c9b]) by ietfa.amsl.com (Postfix) with ESMTP id E177821F8531 for ; Sat, 28 Jan 2012 01:35:58 -0800 (PST) Received: from ra-gorry.erg.abdn.ac.uk (ra-gorry.erg.abdn.ac.uk [139.133.204.42]) (authenticated bits=0) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id q0S9Zfpu021614 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sat, 28 Jan 2012 09:35:42 GMT Message-ID: <4F23C16D.8050009@erg.abdn.ac.uk> Date: Sat, 28 Jan 2012 09:35:41 +0000 From: Gorry Fairhurst Organization: The University of Aberdeen is a charity registered in Scotland, No SC013683. User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: tsvwg@ietf.org, fernando@gont.com.ar, kathleen.moriarty@emc.com, gorry Fairhurst Subject: Fwd: Sec-dir review of draft-ietf-tsvwg-source-quench-04 References: In-Reply-To: X-Forwarded-Message-Id: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ERG-MailScanner: Found to be clean X-ERG-MailScanner-From: gorry@erg.abdn.ac.uk X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: gorry@erg.abdn.ac.uk List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Jan 2012 09:36:00 -0000 A SecDir review of this draft (below) has raised one issue that the group should be aware of and may wish to comment upon. We'd value advice on the suggestion: "Receipt of an ICMP Source Quench message should not be interpreted as an attempt to attack the receiver." - Let's try to quickly resolve this issue. Some things to consider are: * Silently ignoring ICMP Source Quench messages eliminates the attack vector. * Firewalls/routers/etc can log anything they wish, we don't control that. * Receipt of an ICMP SQ is unlikely to impact a host system's transport anymore, and certainly not one that is updated by this RFC. * Some legacy equipment (perhaps even vintage) may/do generate SQ messages, reacting to the message (by invoking some procedure other than log/discard) may break an otherwise working path through this device. - The current draft says *must* not be interpreted as an attempt to attack the receiver, is that right, or do we wish to consider the proposal to make this *should* not? - If you have advice, or wish to offer better text please respond during the document last call! Best wishes, Gorry (TSCWG Chair) -------- Original Message -------- Subject: Sec-dir review of draft-ietf-tsvwg-source-quench-04 Date: Mon, 23 Jan 2012 10:34:41 -0500 From: To: , Hello, I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. The document is straightforward and well written. I just have a couple of nits, but think the document is ready otherwise. Suggest replacing 'must' with 'should' since the discussion is on interpretation. Change from: Receipt of an ICMP Source Quench message must not be interpreted as an attempt to attack the receiver. To: Receipt of an ICMP Source Quench message should not be interpreted as an attempt to attack the receiver. It is already clear from the rest of the draft and this section, that there is no risk by ignoring ICMP source quench messages, which is done by 'virtually all current implementations of TCP'. Should this say, virtually all current implementations of 'IP' or 'TCP' and 'ICMP'? The discussion covers source quench being deprecated (RFC1812) by router implementations 20 years ago and now formally deprecates this within TCP. Thank you, Kathleen From cbenson@adax.com Mon Jan 30 10:05:14 2012 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DDB211E8086 for ; Mon, 30 Jan 2012 10:05:14 -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 AdFoZzDuZZaE for ; Mon, 30 Jan 2012 10:05:13 -0800 (PST) Received: from mail1.adax.com (mail1.adax.com [70.36.226.176]) by ietfa.amsl.com (Postfix) with ESMTP id A2AAB11E8081 for ; Mon, 30 Jan 2012 10:05:13 -0800 (PST) Received: from adax (adax [12.0.0.88]) by mail1.adax.com (Postfix) with ESMTP id 845CF1E119D; Mon, 30 Jan 2012 10:05:12 -0800 (PST) Received: by adax (Postfix, from userid 243) id 666468EE6D; Mon, 30 Jan 2012 10:06:32 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by adax (Postfix) with ESMTP id 5C8408EE6C; Mon, 30 Jan 2012 10:06:32 -0800 (PST) Date: Mon, 30 Jan 2012 10:06:32 -0800 (PST) From: Chris Benson X-X-Sender: cbenson@adax.adax To: Gorry Fairhurst Subject: Re: Fwd: Sec-dir review of draft-ietf-tsvwg-source-quench-04 In-Reply-To: <4F23C16D.8050009@erg.abdn.ac.uk> Message-ID: References: <4F23C16D.8050009@erg.abdn.ac.uk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: kathleen.moriarty@emc.com, tsvwg@ietf.org, fernando@gont.com.ar 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, 30 Jan 2012 18:05:14 -0000 Hi folks, I only wish to address the WORD used in the draft. I think it is not a MUST NOT because other information (perhaps about other received packets) could be used which in tandem could suggest an attack. I therefore agree with the sentiment in general, but think it should be SHOULD NOT. With thanks, from Chris Benson. On Sat, 28 Jan 2012, Gorry Fairhurst wrote: >> Date: Sat, 28 Jan 2012 09:35:41 +0000 >> From: Gorry Fairhurst >> To: , , >> , gorry Fairhurst >> Subject: Fwd: Sec-dir review of draft-ietf-tsvwg-source-quench-04 >> >> >> A SecDir review of this draft (below) has raised one issue that the group >> should be aware of and may wish to comment upon. >> >> We'd value advice on the suggestion: >> >> "Receipt of an ICMP Source Quench message should not be interpreted as an >> attempt to attack the receiver." >> >> - Let's try to quickly resolve this issue. Some things to consider are: >> >> * Silently ignoring ICMP Source Quench messages eliminates the attack >> vector. >> * Firewalls/routers/etc can log anything they wish, we don't control that. >> * Receipt of an ICMP SQ is unlikely to impact a host system's transport >> anymore, and certainly not one that is updated by this RFC. >> * Some legacy equipment (perhaps even vintage) may/do generate SQ messages, >> reacting to the message (by invoking some procedure other than log/discard) >> may break an otherwise working path through this device. >> >> - The current draft says *must* not be interpreted as an attempt to attack >> the receiver, is that right, or do we wish to consider the proposal to make >> this *should* not? >> >> - If you have advice, or wish to offer better text please respond during the >> document last call! >> >> Best wishes, >> >> Gorry >> (TSCWG Chair) >> >> -------- Original Message -------- >> Subject: Sec-dir review of draft-ietf-tsvwg-source-quench-04 >> Date: Mon, 23 Jan 2012 10:34:41 -0500 >> From: >> To: , >> >> Hello, >> >> I have reviewed this document as part of the security directorate's >> ongoing effort to review all IETF documents being processed by the >> IESG. These comments were written primarily for the benefit of the >> security area directors. Document editors and WG chairs should treat >> these comments just like any other last call comments. >> >> The document is straightforward and well written. I just have a couple of >> nits, but think the document is ready otherwise. >> >> Suggest replacing 'must' with 'should' since the discussion is on >> interpretation. >> Change from: >> Receipt of an ICMP Source Quench message must not be interpreted as an >> attempt to attack the receiver. >> To: >> Receipt of an ICMP Source Quench message should not be interpreted as an >> attempt to attack the receiver. >> >> >> It is already clear from the rest of the draft and this section, that there >> is no risk by ignoring ICMP source quench messages, which is done by >> 'virtually all current implementations of TCP'. Should this say, virtually >> all current implementations of 'IP' or 'TCP' and 'ICMP'? The discussion >> covers source quench being deprecated (RFC1812) by router implementations 20 >> years ago and now formally deprecates this within TCP. >> >> >> Thank you, >> Kathleen >> >> >> From touch@isi.edu Mon Jan 30 10:30:34 2012 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 920B321F8699 for ; Mon, 30 Jan 2012 10:30:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.429 X-Spam-Level: X-Spam-Status: No, score=-103.429 tagged_above=-999 required=5 tests=[AWL=-0.830, 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 DCRb0836xgza for ; Mon, 30 Jan 2012 10:30:34 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id 18BB121F8694 for ; Mon, 30 Jan 2012 10:30:27 -0800 (PST) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id q0UIU5mJ007593 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 30 Jan 2012 10:30:05 -0800 (PST) Message-ID: <4F26E1AD.3020400@isi.edu> Date: Mon, 30 Jan 2012 10:30:05 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: gorry@erg.abdn.ac.uk Subject: Re: WG call for interest to work on draft-touch-tsvwg-port-use [due: 10-Feb-12] References: <201201190012.q0J0CUEa023243@mtv-core-3.cisco.com> <4F1FEE46.8010203@erg.abdn.ac.uk> In-Reply-To: <4F1FEE46.8010203@erg.abdn.ac.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 WG 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, 30 Jan 2012 18:30:34 -0000 Hi, all, I'm obviously in favor ;-) That aside: As some additional context, this document intends to include some of the recommendations that were deemed out of scope for RFC 6335 (which focused on IANA procedures rather than best practices for users). These could be gentle (users are encouraged to...) or BCP-style. We can be very clear as to whether this document is intended to guide IANA decisions on port assignments (i.e., we can either suggest it is, declare that it is not, or say that we make no claim either way). Some very important issues *could* be in scope for this document (or could be declared out of scope), e.g.: - discuss and/or make a recommendation about whether to continue the system/user port space distinction (IMO, the only useful way to do this is to suggest that IANA cease allocating system ports) - discuss and/or make a recommendation about whether secure and nonsecure versions of the same service should use a single port or separate ports At the very least, this could be a useful reference to newbies who are creating services, and would be highly beneficial to the ports review team (which I currently lead). Joe On 1/25/2012 3:57 AM, Gorry Fairhurst wrote: > > The TSV working group is considering the possibility of adopting the > topic of the below as a work item. Please send email to this list to > help the WG Chairs determine if this document should proceed within > the TSVWG. > > > Recommendations for Transport Port Uses > http://tools.ietf.org/html/draft-touch-tsvwg-port-use-01 > > This document was presented at IETF-81. At that time, but at that > time there was little comment on the draft. > > A hum at IETF-82 indicated there may be interest in work on > this topic. Therefore, the Chairs request feedback from this working > group, by 10th Feb 2012. > > Please send email to this group (or the Chairs) in response to the > following: > > * Have you read this version of the draft? > > * Do you think this is an important area of work for TSVWG? > > * Do you think *THIS* draft is a good a starting point for the work? > > * Do you plan to contribute or help write the WG draft? > > * Would you be willing to comment upon/review future versions of this > work for the working group? > > All comments are welcome via the list, or directly to the WG Chairs. > > Gorry & James > (tsvwg chairs) > > From touch@isi.edu Mon Jan 30 13:09:06 2012 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C61D021F865C for ; Mon, 30 Jan 2012 13:09:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.347 X-Spam-Level: X-Spam-Status: No, score=-103.347 tagged_above=-999 required=5 tests=[AWL=-0.748, 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 mlIL449EJTgx for ; Mon, 30 Jan 2012 13:09:06 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id 3B5D621F865A for ; Mon, 30 Jan 2012 13:09:06 -0800 (PST) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id q0UL8VTd005383 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 30 Jan 2012 13:08:32 -0800 (PST) Message-ID: <4F2706CF.2020504@isi.edu> Date: Mon, 30 Jan 2012 13:08:31 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: gorry@erg.abdn.ac.uk Subject: Re: Fwd: Sec-dir review of draft-ietf-tsvwg-source-quench-04 References: <4F23C16D.8050009@erg.abdn.ac.uk> In-Reply-To: <4F23C16D.8050009@erg.abdn.ac.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: kathleen.moriarty@emc.com, tsvwg@ietf.org, fernando@gont.com.ar 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, 30 Jan 2012 21:09:07 -0000 Hi, all, On 1/28/2012 1:35 AM, Gorry Fairhurst wrote: > > A SecDir review of this draft (below) has raised one issue that the > group should be aware of and may wish to comment upon. > > We'd value advice on the suggestion: > > "Receipt of an ICMP Source Quench message should not be interpreted as > an attempt to attack the receiver." ... > - The current draft says *must* not be interpreted as an attempt to > attack the receiver, is that right, or do we wish to consider the > proposal to make this *should* not? MUST NOT seems required by MUST silently ignore (section 3). That's what "silent" and "ignore" means. Using "SHOULD NOT" leaves open this misinterpretation, and thus *opens* a vulnerability at the receiver to spoofed messages - i.e., it's inconsistent with the security implications of this doc, notably: --- Receipt of an ICMP Source Quench message must not be interpreted as an attempt to attack the receiver. --- In that section, to be clear, we should change: --- Receivers should not treat reception as an exception, error or logged event. --- to --- Receivers must not treat reception as an exception, error or logged event. --- Joe From jmpolk@cisco.com Tue Jan 31 13:20:40 2012 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2259411E8083 for ; Tue, 31 Jan 2012 13:20:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[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 LA3owmKWgPDj for ; Tue, 31 Jan 2012 13:20:39 -0800 (PST) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 4ED0D21F84CD for ; Tue, 31 Jan 2012 13:20:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jmpolk@cisco.com; l=707; q=dns/txt; s=iport; t=1328044836; x=1329254436; h=message-id:date:to:from:subject:mime-version; bh=kJZbNIZevxmi4tagHiB1vykzfBcZ+30FoNtK0GvPIKU=; b=b6EKe6zlQ/cMUpTMAFCS8oVCUxJ62VunGcwbVeOgglPdQ68MJQfzR/H/ dwaqTOCaeRrjOKFJRO5ZUC6KCQ5sI2RrmvLmOXILgE4QuS8cjyAzE/IJl dXP1Fp6ifrLGf9EP4efXsttgsOtmP/aZlOnFWKtLPiDmQxH5dOBbU07cV I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAKRaKE+rRDoI/2dsb2JhbABCrmaBBYILAQobAlY6KUQ1oGiBJwGNJpEsixoaB0wDAQQBhCsBAgIBAgEBAQEBAQEBAQGDOwSIQJ9T X-IronPort-AV: E=Sophos;i="4.71,598,1320624000"; d="scan'208";a="28039928" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-2.cisco.com with ESMTP; 31 Jan 2012 21:20:36 +0000 Received: from jmpolk-wxp01.cisco.com (rcdn-jmpolk-8711.cisco.com [10.99.80.18]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q0VLKZUR023129 for ; Tue, 31 Jan 2012 21:20:35 GMT Message-Id: <201201312120.q0VLKZUR023129@mtv-core-3.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 31 Jan 2012 15:20:33 -0600 To: tsvwg From: "James M. Polk" Subject: Call for presentations for TSVWG at IETF83 (Paris) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed 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, 31 Jan 2012 21:20:40 -0000 TSVWG This is an early call to those that plan on asking for presentation slots at the upcoming Paris IETF (83). Send in your requests to ME, you can certainly include Gorry. Include: - who will be presenting (as best as you know now) - the filename of the draft to be presented - the amount of time you are requesting (Giving out 15 min slots are rare, so expect 10 mins) Understand that once the meeting time fills up, we chairs might not have the ability to shuffle things around to make room for you. Priority will be given to WG items, or those related to WG items. What this means is to GET YOUR (complete) REQUESTS IN EARLY ;-) Humbly your chairs James & Gorry