qinxiaowei@cnnic.cn | 12 May 03:36 2015
Picon

Upload acceleration transport network for upstream traffics generated by end users

Hi folks,
   
Many popular cloud computing services, such as YouTube, Facebook, etc., are proliferating rapidly these days. Photos, videos and other upstream traffics generated by end users grow drastically. Existing CDNs are frequently used to deliver large-scale content from NSPs to end users while content generated by end users cannot be accelerated by them
IMO, upload acceleration transport network for upstream traffics may be need for improving user experiences , namely a content item generated by end user can be actual delivered to a NSP by caches (e.g., lower latency, bottlenecks avoided). Perhaps, the data upload throughput similarly to the CDN approach, but applying it to the opposite direction.

I am wondering whether this issue is covered in the scope of 
tsvwg WG?

Xiaowei Qin

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.

-- Sec 7.4:
The term "security" is really vague. It would help to define what is
meant by "security" or "secure service."

-- Sec 7.4 and 7.5:
Both of these sections contain recommendations that are good, but seem
out of place in this document unless they could be made more specific to
port use. The ones that jumped out at me are:

   >> New services SHOULD support security, either directly or via a
   secure transport such as TLS [RFC5246].

   >> Insecure versions of new or existing secure services SHOULD be
   avoided because of the new vulnerability they create.

   >> Version support SHOULD be included in new services.

I would say to either remove these or add in the context of what they
have to do with port number assignment (e.g., "Version support SHOULD be
included in new services rather than relying on different port number
assignments for different versions.")

-- Sec 7.7:
"Deployments that use port numbers before deployment complicate IANA
   management of the port number space."

I think this is supposed to say "before assignment" rather than "before
deployment."

-- Sec 7.8:
""Squatting" describes the use of a number from the assigned range in
   deployed software without IANA assignment. It is hazardous because
   IANA cannot track such usage and thus cannot avoid making legitimate
   assignments that conflict with such unauthorized usage.

   Such "squatted" port numbers remain unassigned, and IANA retains the
   right to assign them when requested by applicants."

This is a little confusing -- is the first sentence supposed to say
"unassigned range"? If not, what is the assigned range, and why is IANA
said to retain the right to assign numbers that are already assigned? I
would have thought squatting would be understood as using unassigned
numbers in the system and user ranges.

"In
   particular, any unassigned code from the assigned ranges will be
   assigned by IANA, and any conflict will be easily resolved as the
   protocol designer's fault once that happens (because they would not
   be the assignee). This may reflect in the public's judgment on the
   quality of their expertise and cooperation with the Internet
   community."

This seems a little over-the-top to me. I would suggest:

"IANA may assign any code from the system or user ranges to applicants
that meet all of the relevant criteria, and is not obligated to take into
consideration the existence of squatters when doing so. Squatting is
viewed as uncooperative behavior in the Internet community."

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
URL:
http://www.ietf.org/internet-drafts/draft-herbert-udp-magic-numbers-00.txt
Status:
https://datatracker.ietf.org/doc/draft-herbert-udp-magic-numbers/
Htmlized:       http://tools.ietf.org/html/draft-herbert-udp-magic-numbers-00

Abstract:
   This specification defines magic numbers in UDP which allow a node to
   determine or confirm the protocol contained in a UDP payload. This is
   primarily applicable for encapsulation and transport protocols
   encapsulated within UDP where intermediate devices, such as middle
   boxes, need to parse these protocols for providing service. Magic
   numbers can also be used to multiplex different UDP encapsulated
   protocols over the same UDP port.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

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>

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

Notes
-----
The errors actually occurred in the Table of Contents (ToC) section,
so I hope the Section: field in this form takes that value.  The links
to sections 6.1.1.2 and 19.3 were never generated in the ToC.
 --VERIFIER NOTES-- 
This errata is about the automatically generated html version of the RFC does not report any error in the RFC
itself. 

--------------------------------------
RFC3168 (draft-ietf-tsvwg-ecn-04)
--------------------------------------
Title               : The Addition of Explicit Congestion Notification (ECN) to IP
Publication Date    : September 2001
Author(s)           : K. Ramakrishnan, S. Floyd, D. Black
Category            : PROPOSED STANDARD
Source              : Transport Area Working Group
Area                : Transport
Stream              : IETF
Verifying Party     : IESG

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:

   When TCP receives a CE data packet at the destination end-system, the
   TCP data receiver sets the ECN-Echo flag in the TCP header of the
   subsequent ACK packet. 

   [...]
                                               The TCP receiver uses the
   CWR flag received from the TCP sender to determine when to stop
   setting the ECN-Echo flag.

Corrected Text
--------------
Section 6.1.3 should say:

   The TCP receiver uses the
   CWR flag received from the TCP sender to determine when to stop
   setting the ECN-Echo flag. This check has to be performed before  
   checking if the received segment is CE marked.

Notes
-----
The ordering of the text in the bullet points in section 6.1, and the text in section 6.1.3 can led to
inappropriate implementations. At least Section 6.1.3 should be strict about the handling of CE-marked CWR-segments.

If CE is checked first, and ECE set, and thereafter CWR used to disable ECE, a CE-marked CWR segment will not
result in the sending of an additional window of ECEs.

All derivatives of BSD used to 

First, set ECE because of CE
Second, reset ECE because of CWR

However, the "authorative" NS2 sample code, the TBIT tool, Windows, Solaris and Linux would

First, reset ECE because of CWR
Second, set ECE because of CE

The latter approach seems to be the sensible one, and it was quickly fixed:

http://lists.freebsd.org/pipermail/freebsd-bugs/2010-April/039450.html

--------------------------------------
RFC3168 (draft-ietf-tsvwg-ecn-04)
--------------------------------------
Title               : The Addition of Explicit Congestion Notification (ECN) to IP
Publication Date    : September 2001
Author(s)           : K. Ramakrishnan, S. Floyd, D. Black
Category            : PROPOSED STANDARD
Source              : Transport Area Working Group
Area                : Transport
Stream              : IETF
Verifying Party     : IESG

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.

Notes
-----
The receiver should not ignore any CE codepoint.
 --VERIFIER NOTES-- 
This is not an editorial fix or technical clarification, but proposes to change the processing of ECN.
Please go ahead and write a draft that works towards updating RFC 3168.

--------------------------------------
RFC3168 (draft-ietf-tsvwg-ecn-04)
--------------------------------------
Title               : The Addition of Explicit Congestion Notification (ECN) to IP
Publication Date    : September 2001
Author(s)           : K. Ramakrishnan, S. Floyd, D. Black
Category            : PROPOSED STANDARD
Source              : Transport Area Working Group
Area                : Transport
Stream              : IETF
Verifying Party     : IESG

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
   (e.g., protocols layered directly on IP or via IP-based tunnels),
   especially when these protocols do not themselves provide congestion
   control.

   If published as an RFC, this document will obsolete RFC5405.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-tsvwg-rfc5405bis/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-tsvwg-rfc5405bis-02

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-tsvwg-rfc5405bis-02

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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,
Guenter, Vodafone Group; Andreas Terzis; Sprecher, Nurit (Nokia - IL/Hod HaSharon); 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: Mobile Throughput Guidance: reading list

Folks,

When you presented these two drafts in tsvwg last week, there were a number of suggestions for further reading:
* draft-sprecher-mobile-tg-exposure-req-arch
* draft-flinck-mobile-throughput-guidance

RFC6077 "Open Issues in Internet Congestion Control" provides most if not all these references in one
place. It gives a good grounding in all the pitfalls and problems surrounding explicit-rate guidance
both from a control perspective, and the security and scalability of the various signalling approaches
that have been proposed.

Admittedly it's a little dated (it was brought up to date just before it was published in 2011, even though it
was started a few years earlier). So some issues have been partially addressed since then. 
But most are still open.

Also, you may be able to get round some of the problems by limiting applicability, e.g. by placing the source
next to the RAN, etc.

Cheers

Bob

________________________________________________________________
Bob Briscoe,                                                  BT  


Gmane