Alissa Cooper | 25 Apr 00:14 2015
Picon

Alissa Cooper's No Objection on draft-ietf-tsvwg-port-use-11: (with COMMENT)

Alissa Cooper has entered the following ballot position for
draft-ietf-tsvwg-port-use-11: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
http://datatracker.ietf.org/doc/draft-ietf-tsvwg-port-use/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thanks for addressing my DISCUSS!

---

I think I may have some overlapping comments with Barry, but I wrote this
before I saw his comments, so my apologies.

-- Sec 5:
"Port numbers can also be useful for other purposes."

I would suggest s/useful/used/ because whether the purposes listed in the
previous paragraph (e.g., monitoring, blocking, etc. based on port
number) are considered "useful" is in the eye of the beholder.
(Continue reading)

Tom Herbert | 24 Apr 18:16 2015

Fwd: New Version Notification for draft-herbert-udp-magic-numbers-00.txt

Hello,

This draft generalizes the concept of magic numbers in UDP payloads
like in the SPUD protocol prototype. These are 64 bit constants that
should allow middleboxes to correctly identify the type of a UDP
payload with high confidence. This would be applicable with several
UDP encapsulated protocols that are of interest to middleboxes to
parse.

Posting to tsvwg and spud lists.

Thanks,
Tom

---------- Forwarded message ----------
From:  <internet-drafts <at> ietf.org>
Date: Fri, Apr 24, 2015 at 8:41 AM
Subject: New Version Notification for draft-herbert-udp-magic-numbers-00.txt
To: Tom Herbert <tom <at> herbertland.com>, Lucy Yong <lucy.yong <at> huawei.com>

A new version of I-D, draft-herbert-udp-magic-numbers-00.txt
has been successfully submitted by Tom Herbert and posted to the
IETF repository.

Name:           draft-herbert-udp-magic-numbers
Revision:       00
Title:          UDP Magic Numbers
Document date:  2015-04-24
Group:          Individual Submission
Pages:          11
(Continue reading)

Black, David | 21 Apr 17:25 2015

Dallas tsvwg minutes posted

Many thanks to the scribes, and to Gorry for pulling these together.

https://www.ietf.org/proceedings/92/minutes/minutes-92-tsvwg

Comments and corrections are welcome.

Thanks,
--David
----------------------------------------------------
David L. Black, Distinguished Engineer
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
david.black <at> emc.com        Mobile: +1 (978) 394-7754
----------------------------------------------------

gorry | 21 Apr 09:58 2015
Picon
Picon

WGLC for draft-ietf-tcpm-rtorestart-07 : To end 6th May 2015

TCP and SCTP RTO Restart
https://tools.ietf.org/html/draft-ietf-tcpm-rtorestart-07

The above draft is being evaluated for publication as an Experimental RFC.
It describes a proposed new method for TCP and SCTP.

TSVWG, please note this WGLC in the TCPM WG is also a request for comments
and feedback from the TSVWG.  The end of this WGLC period is 6th May.
Please CC the TCPM WG list in any emails on this topic.

Gorry Fairhurst
(TSVWG Chair)

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

Hi all,

This email starts a WGLC for draft-ietf-tcpm-rtorestart-07, running until
May 6.

Please review the latest version and please let us know if there are any
comments.

Thanks a lot!

Michael
RFC Errata System | 17 Apr 21:15 2015

[Errata Rejected] RFC3168 (4302)

The following errata report has been rejected for RFC3168,
"The Addition of Explicit Congestion Notification (ECN) to IP".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=3168&eid=4302

--------------------------------------
Status: Rejected
Type: Editorial

Reported by: Greg Skinner <gds <at> alum.mit.edu>
Date Reported: 2015-03-15
Rejected by: Martin Stiemerling (IESG)

Section: ToC

Original Text
-------------
6.1.1.2.  Robust TCP Initialization with an Echoed Reserved
Field. 17

19.3.  Non-ECN-Based Methods of Subverting End-to-end
Congestion Control....................................................
<a href="#page-54">54</a>

Corrected Text
--------------
<a href="#section-6.1.1.2">6.1.1.2</a>.  Robust TCP Initialization
with an Echoed Reserved Field. <a href="#page-17">17</a>
(Continue reading)

RFC Errata System | 17 Apr 21:13 2015

[Errata Verified] RFC3168 (3639)

The following errata report has been verified for RFC3168,
"The Addition of Explicit Congestion Notification (ECN) to IP". 

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=3168&eid=3639

--------------------------------------
Status: Verified
Type: Technical

Reported by: Richard Scheffenegger <rs <at> netapp.com>
Date Reported: 2013-06-05
Verified by: Martin Stiemerling (IESG)

Section: 6.1 / 6.1.3

Original Text
-------------
Section 6.1 says:

      * The receiver receives the packet with the CE codepoint set, and
        sets the ECN-Echo flag in its next TCP ACK sent to the sender.
[...]

      * The sender sets the CWR flag in the TCP header of the next
        packet sent to the receiver to acknowledge its receipt of and
        reaction to the ECN-Echo flag.

Section 6.1.3 says:
(Continue reading)

RFC Errata System | 17 Apr 21:11 2015

[Errata Rejected] RFC3168 (3680)

The following errata report has been rejected for RFC3168,
"The Addition of Explicit Congestion Notification (ECN) to IP".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=3168&eid=3680

--------------------------------------
Status: Rejected
Type: Technical

Reported by: Mirja Kühlewind <mirja.kuehlewind <at> ikr.uni-stuttgart.de>
Date Reported: 2013-07-12
Rejected by: Martin Stiemerling (IESG)

Section: 6.1.1.

Original Text
-------------
If the TCP connection does not
wish to use ECN notification for a particular packet, the sending TCP
sets the ECN codepoint to not-ECT, and the TCP receiver ignores the
CE codepoint in the received packet.

Corrected Text
--------------
If the TCP connection does not
wish to use ECN notification for a particular packet, the sending TCP
sets the ECN codepoint to not-ECT.

(Continue reading)

internet-drafts | 8 Apr 14:25 2015
Picon

I-D Action: draft-ietf-tsvwg-rfc5405bis-02.txt


A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Transport Area Working Group Working Group of the IETF.

        Title           : UDP Usage Guidelines
        Authors         : Lars Eggert
                          Godred Fairhurst
                          Greg Shepherd
	Filename        : draft-ietf-tsvwg-rfc5405bis-02.txt
	Pages           : 42
	Date            : 2015-04-08

Abstract:
   The User Datagram Protocol (UDP) provides a minimal message-passing
   transport that has no inherent congestion control mechanisms.
   Because congestion control is critical to the stable operation of the
   Internet, applications and other protocols that choose to use UDP as
   an Internet transport must employ mechanisms to prevent congestion
   collapse and to establish some degree of fairness with concurrent
   traffic.  They may also need to implement additional mechanisms,
   depending on how they use UDP.

   This document provides guidelines on the use of UDP for the designers
   of applications, tunnels and other protocols that use UDP.
   Congestion control guidelines are a primary focus, but the document
   also provides guidance on other topics, including message sizes,
   reliability, checksums, middlebox traversal, the use of ECN, DSCPs,
   and ports.

   Some guidance is also applicable to the design of other protocols
(Continue reading)

Caitlin Bestler | 2 Apr 19:50 2015

Re: Circuti Breaker as BCP or as compulsory standard


On 4/2/15 10:09 AM, Matt Matthis wrote:
>
> For CBR applications, the correct answer to "What mandatory congestion
> control are you using?" should be "A circuit breaker".  I believe that this
> requires standards track.
>
> On Thu, Apr 2, 2015 at 7:41 AM Magnus Westerlund <
> magnus.westerlund <at> ericsson.com> wrote:
>
>
A BCP strikes me as fitting. It will also be far easier to reach consensus
that this document represents the best common practices than it will
be to reach consensus on what MUST be provisioned for all flows.

For example, we have reference architectures where customers are
expected to apply L2 rate shaping to limit the aggregate storage flows
in each L2 subnet. Coming up with MUST/SHOULD language that is
inclusive of this type of solution as well as per-flow end-to-end metering
will be very difficult even though both serve the same goal of protecting
"other" traffic from the subject traffic getting out of control.

Re: Mobile Throughput Guidance: reading list

Hi Bob,

Indeed, many thanks for the advice here and at Dallas!

 <at> All:
As well as RFC 6077 I would recommend browsing Bob's publications at: http://bobbriscoe.net/pubs.html 

Cheers
Kevin

-----Original Message-----
From: Sprecher, Nurit (Nokia - IL/Hod HaSharon) [mailto:nurit.sprecher <at> nokia.com] 
Sent: 01 April 2015 11:37
To: ext Bob Briscoe; Arunachalam, Swaminathan (Nokia - US/Irving); Helen Parsons; Shahid Akhtar; Smith,
Kevin, (R&D) Vodafone Group; Ankur Jain; Cosimini, Peter, Vodafone Group; Flinck, Hannu (Nokia -
FI/Espoo); Klas, Guenter, Vodafone Group; Andreas Terzis; Gopal, Ram (Nokia - US/Mountain View);
Szilagyi, Peter 1. (Nokia - HU/Budapest); Vulkan, Csaba (Nokia - HU/Budapest)
Cc: tsvwg IETF list; iccrg IRTF list; Ben Niven-Jenkins
Subject: RE: Mobile Throughput Guidance: reading list

Thank you Bob for the reference and the good comment during the meeting.
We will look into the document (and may come with questions/ thoughts, etc.).
Best regards,
Nurit

-----Original Message-----
From: ext Bob Briscoe [mailto:bob.briscoe <at> bt.com]
Sent: Wednesday, April 01, 2015 1:17 PM
To: Arunachalam, Swaminathan (Nokia - US/Irving); Helen Parsons; Shahid Akhtar; ext Smith, Kevin, (R&D)
Vodafone Group; Ankur Jain; Cosimini Peter, Vodafone Group; Flinck, Hannu (Nokia - FI/Espoo); Klas,
(Continue reading)

Scheffenegger, Richard | 1 Apr 13:41 2015
Picon

Review draft-ietf-tsvwg-ecn-encap-guidelines

Hi Bob, Pat, John,

 

I’ve reviewed this document; As is well known, I’m a big fan of ECN and support this draft.

 

A few nits and word-smithings:

 

Sec 1, 3rd para:

 

s/(v4 & v6)/(v4 and v6)/

 

 

5th para:

 

However, this has often be more due to the inability of the original

   TCP protocol to saturate the links”

 

Better:

 

However, this has often more to do with the inability of the TCP protocol in the (New)Reno variant to saturate the links.

 

8th para:

s/most tricky aspect/most delicate aspect/

 

s/congestion would just deteriorate further/congestion would build up further/ (deteriorating congestion may not be unambiguous; same 2 sentences further)

 

Sec 2, PDU

 

s/&/and/

 

Move the definition of Load Regulator forward by 2 items (ECN-PDU refer to that).

 

 

Sec 4,

 

Definition of “Null”

 

Would that include networks which are virtually loss-less (eg. FibreChannel with credit-based transmission schemes [FCVI and FC-IP are two schemes to run IP over this type of network]), or (theoretical) optimal Flow-Control enabled Ethernet networks, and perhaps Infiniband (not too familiar with that)? I’m trying to decipher what packet network nodes “cannot experience congestion”. Perhaps a slightly expanded text giving an concrete example would help here. Reading section 4.4 seems to indicate my examples might be the ones you had in mind.

 

Sec 4.1., 2nd para

 

s/3 & 4/3, and 4/

 

7th para:

 

s/“However, in ATM, this is only as part “ / … only a part/

 

s/ layer--the/layer -- the/

 

Sec 4.3, 2nd para:

 

s/approaching congestion or congested/approaching congestion or is congested/

 

 

Sec 5.4, last para:

 

s/future use through new standards actions./… new standards body actions./

 

 

Section 7:

 

Would there be any value in discussing a hypothetical “feed-back and up” mode? Without loss for non-ECT-PDUs and marking of inner headers for ECT-PDUs?

 

 

 

 

 

 

 

 

 

 

 

 

 

Richard Scheffenegger


Gmane