Black, David | 24 Nov 00:51 2015

TSVWG WGLC: draft-ietf-tsvwg-behave-requirements-update-05 - ends Dec 12

This email announces a TSVWG Working Group Last Call (WGLC) on:

   Network Address Translation (NAT) Behavioral Requirements Updates

This WGLC will be for just under 3 weeks, ending at midnight US Eastern
Time on Saturday, December 12.  Comments should be sent to the tsvwg <at>
list, although purely editorial comments may be sent directly to the authors
at draft-ietf-tsvwg-behave-requirements-update <at> - please cc: the WG
chairs at tsvwg-chairs <at>

The WG chairs express our thanks to Brandon Williams for his recent review
of the -04 version of this draft.  We're looking for at least a couple more
reviews during WGLC - please email the chairs (tsvwg-chairs <at> if
you're interested and willing to review this draft (otherwise, we'll have
to go "beat the bushes" for reviewers).

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

lloyd.wood | 23 Nov 21:43 2015

Re: UDP guidelines draft (5405bis) -07 - update

> Another recommendation might be to reconsider default coverage length. > RFC3228 recommends that the default is to checksum over the entire > packet, but then this basically becomes UDP so why not just use UDP?
Because Lite was designed as an in-situ replacement of UDP, the IESG gotcold feet, and punted it to a different protocol number. It's the safe default.

(Once it was at a different protocol number, it didn't have to look likeUDP at all. But by that time the document was written and approved. Theseare the wonders of the standards process.)

> For the case of tunneling at least, maybe the recommendation should be > that the UDP-Lite checksum only covers the pseudo header and UDP > header, i.e. the minimum coverage to compensate for lack of IP header > checksum in IPv6.

It doesn't cover for the lack of IP header checksum,
unless you're suggesting it be checked at each hop.
Covering the minimum of UDP-Lite/IP pseudoheader does
nothing for what is carried - a tunneller can argue that,
from his perspective, he gains nothing over zero-checksum
UDP and doesn't care about polluting other ports, so
why not simply use UDP and turn off UDP checksums?

Where Lite has an advantage is that it can and should
also cover encap headers not otherwise covered end to end
(e.g. MPLS stack in MPLS-in-UDP, or a GRE shim without
a GRE checksum, or RTP headers) but that is case-specific
and requires engineering judgement to select. And that
also offers a subtle benefit to the tunneller.

Again, full checksum coverage is the safe default for
people who don't think about this.

> Besides that, we are > pushing vendors to get rid of protocol specific offloads

But not for offloading TCP or UDP, eh?

> For instance, when receiving a packet > we prefer that a device just gives us the checksum as calculated over > the whole packet, it is then easy for the stack to apply that value to > verify any UDP, TCP, GRE checksums etc. in the packet (please look at >

Tom Herbert, "UDP Encapsulation in Linux" netdev 0.1,
Ottawa Canada, Feb 2015.

Your paper doesn't mention Lite - sigh. But hey,
different protocol number...

This assumes that other inner one's complement checksums
are good if the outer one is good - imo a bit risky,
because one's complement is so weak.
And of even less use for assuming stronger tunnelled CRCs
are good. (an outer Eth CRC has a different link scope to
the full path of tunnelled devices, so is not that good an
indicator the content is safe.)

Lloyd Wood lloyd.wood <at> 
Black, David | 23 Nov 03:39 2015

UDP guidelines draft (5405bis) -07 - update

As WG chair: 

I think this version is reasonably good wrt my concerns, but I'd like to
hold it in the WG for a few weeks before making the publication request in
order to provide time for additional reviews (e.g., Erik Nordmark promised
to check this against the encapsulation draft in RTGWG).

<WG chair hat OFF>

The following text was added to help with the difficulties encountered in
dealing with UDP zero-checksum for IPv6:

		To protect	
 	      from misdelivery, new encapsulation designs SHOULD include an	
 	      integrity check at the transport layer that includes at least the	
 	      IPv6 header, the UDP header and the shim header for the	
 	      encapsulation, if any [RFC6936].	

I'd like to add a warning here to designers of what may happen if that SHOULD is
not followed, e.g. (borrowing some of RFC 2119's choice of words):

		Not including such a check can be expected to require significant
		effort to understand and carefully weigh the full implications
		and provide alternative assurances that misdelivery is unlikely.
		While this is possible (see Sections 3.1 and 3.2 of [RFC7510]
		for an example), use of an integrity check is RECOMMENDED.

Continuing (nit)
 	   o  One way to help satisfy the requirements of [RFC6936] may be to	
 	      limit the usage (e.g., to constrain traffic to an operator network
 	      Section 3.6, as in [RFC7510]).
		or set of closely cooperating networks, as further described in
		Section 3.6 below, see [RFC7510] for an example of this approach).

</WG chair hat OFF>

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

Black, David | 23 Nov 03:00 2015

Circuit-breaker -09

This is looking good.  The one serious issue here is that the discussion
of the perils of ECN needs to be aligned with the Tunnel Congestion Feedback

I also would like to see what Bob Briscoe thinks of the changes in -09.

-- Section 1

The first paragraph in Section 1 (Introduction) is a good fit to that
section (it was moved there from Section 6.1), but it should not be the
first paragraph in Section 1.  I would move it down to become the third
paragraph, so that the introduction starts with an introduction to circuit

-- Nit (Section 1):

   The introduction of a congest control in TCP
   The addition of congestion control to TCP

[at a minimum, "a congest" -> "congestion"]

-- Nit (Section 1.1)

   o  Fast-Trip Circuit Breakers: The relatively short timescale used by
      this form of Circuit Breaker is intended to provide protection for
-->   network traffic of a single non-responsive flow or related group
      of non-responsive flows.

"of a single non-responsive flow" -> "from a single non-responsive flow"
(undo unintended side effect of primary edit to add "non-responsive")

-- Section 4

   o  A Circuit Breaker REQUIRED to define a measurement function to
      measure the level of congestion or loss.  This does not have to
      detect individual packet loss, but MUST specify a way to know that
      packets have been lost/marked from the traffic flow.  If Explicit
      Congestion Notification (ECN) is enabled [RFC3168], an egress
      meter MAY also count the number of ECN congestion marks/event per
      measurement interval, but even if ECN is used, loss MUST still be
      measured, since this better reflects the impact of persistent
      excessive congestion.  In this context, loss represents a reliable
      indication of congestion, as opposed to the finer-grain marking of
      incipient congestion that can be provided via ECN.

"REQUIRED" -> "is REQUIRED" in the first line.

Beyond that, the discussion of ECN in this paragraph needs to be aligned
with the Tunnel Congestion Feedback draft, as that draft uses ECN as part
of a measurement mechanism that could be used to drive a circuit breaker.
I think the Tunnel Congestion Feedback draft should be cited here as an
example of ECN-based measurements that could be used to drive a circuit
breaker if certain things are done to use the measurements correctly.

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

internet-drafts | 18 Nov 10:13 2015

I-D Action: draft-ietf-tsvwg-circuit-breaker-09.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           : Network Transport Circuit Breakers
        Author          : Godred Fairhurst
	Filename        : draft-ietf-tsvwg-circuit-breaker-09.txt
	Pages           : 25
	Date            : 2015-11-18

   This document explains what is meant by the term "network transport
   Circuit Breaker" (CB).  It describes the need for circuit breakers
   for network tunnels and applications when using non-congestion
   controlled traffic, and explains where circuit breakers are, and are
   not, needed.  It also defines requirements for building a circuit
   breaker and the expected outcomes of using a circuit breaker within
   the Internet.

The IETF datatracker status page for this draft is:

There's also a htmlized version available at:

A diff from the previous version is available at:

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

Internet-Drafts are also available by anonymous FTP at:

Black, David | 16 Nov 22:20 2015

Mirja's comments on the circuit breaker draft

<WG chair hat OFF>

Mirja Kuehlewind reviewed the circuit breaker draft during the Yokohama
meeting week - I have no idea how she found that time ;-). 

As she's offline now, I'm passing along her comments - this is my summary
of an earlier discussion w/her ('>'d text) followed by her elaboration,
which I'm prepared to defend/explain in her absence.

There are a few points that could use some attention:


> The notion of "persistent congestion" is not well-defined - a single
> TCP connection running over a link that constrains its throughput will
> drop packets on an ongoing basis.  There seems to be an operational
> characteristic to this - it's abnormal congestion caused by traffic
> that is non-responsive to network conditions (e.g., drops, ECN
> congestion indications) ... and in that description, both 'abnormal'
> and 'non-responsive' have some dependency on the network and the
> nature of the traffic that it normally carries.

Yes, persistent congestion is not only not well defined, it's really the
wrong word, because congestion can be persistent under normal operation.
The level of congestion (over time) is actually important.

Further the draft uses persistent congestion nearly as equivalent to
congestion collapse. However, a congestion collapse happens if the demand
is increasing/network is always fully loaded while the goodput decreases
to zero (just because the demand is permanently increasing this situation
will not resolve on its own -> collapse). So there is the notion that the
congestion level over time is actually increasing (until no goodput is
possible anymore). So the use of the term congestion collapse is also
not fully correct I believe.

> We discussed a measurement concern - a key goal here is to avoid
> tripping a circuit breaker in response to a brief traffic spike or
> two.


> The concern about shutting down traffic as a consequence of loss of
> circuit breaker control path connectivity is already in the process
> of being addressed.

Actually as a side note, the draft says a couple of time that traffic
or flows should be "shut down" or the aggregate rate should be reduced.
Maybe if some hint about how much it should be reduced at once might
also be useful. Not thinking about a number, but say something like,
if the time-scale when those actions are take is rather large you
might reduce more, while at a lower time-scale you'd could star
with a very small reduction?


</WG chair hat OFF>

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

lloyd.wood | 14 Nov 04:10 2015

on UDP encapsulation

I finally noticed that RFC7510, on MPLS in UDP encap, has
been published. Do take a look at all of section 3, which
laboriously goes through the nuances of when to choose
between UDP checksums, for safety, and turning them off,
for speed, at slight risk. That section and the RFCs it
refers to are quite the complex read. And that's just on
UDP checksums and whether to choose to turn them off. (It
gives dull security documents a run for their money.)

What's odd is that this is standards track, and the third
option, use standards-track UDP-Lite to provide checksum
protection of the UDP/IP pseudoheader to avoid zero-checksum
port pollution on the host (on IPv4) or anywhere pollution
(IPv6) is not mentioned as an alternative - particularly as
UDP-Lite's partial payload coverage can cover the MPLS stack 
s well.

In some cases the Lite checksum is just a precomputed value
across a generated header that doesn't change, at no encode
cost and little decode cost, and within corporate private
networks the barriers to running UDP-Lite are less.

It's unfortunate that UDP-Lite is the ideal approach for
this, yet doesn't deserve consideration. Going back further
in time, one might argue it's unfortunate that UDP-Lite was
pushed to a separate protocol number, dooming it to oblivion.
And, further back, that it was unfortunate that designers of
IPv6 thought leaving the pseudo-header demux check up to
separate transports that could then skip it, while insisting
UDP always have its checksum on, which was always going
to be relaxed, was a good idea for consistent error-detecting

One might argue it's unfortunate. With the benefit of perfect
hindsight, I favour 'bloody stupid' myself.

Does the IETF no longer work on UDP-Lite? Should UDP-Lite be
moved to Historic, along with SCTP and DCCP, because
they're not TCP or UDP - even though delivery of tunnelled
payloads with demux protection is UDP-Lite's ideal application?



Lloyd Wood 
Black, David | 14 Nov 00:59 2015

Draft TSVWG Yokohama minutes


Please send corrections, comments and/or changes to the chairs (and
to the list if appropriate).

Many thanks to Pasi Sarolahti and Aaron Falk for taking notes.

I've added a couple of additional elaborations to the minutes that I'll
repeat here:

a) WRT to existing magic numbers for demux within the UDP encapsulation
	used by Web RTC, see draft-ietf-avtcore-rfc5764-mux-fixes, as that
	draft corrects some serious problems in RFC 5764:

b) The DSCP mapping to/from 802.11 that was driven by compatibility with mobile
	networks is in Section 4.2 of RFC 7561:

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

Pat (Patricia) Thaler | 6 Nov 03:15 2015

DSCP and 802.1Q prioirty

After the discussion on DSCP mapping to IEEE 802.1Q priority yesterday, I realized that there is something that I should have mentioned.


In IEEE 802.1Qcd, we added the ability to use the Application Priority TLV (an LLDP TLV defined originally in IEEE 802.1Qaz for Data Center Networking Configuration Exchange, DCBX) to indicate mapping from DSCP to  802.1Q Priority.


DCBX was created partly because bridges/switches are often configured by network administration but end nodes often aren’t so this gives a way for the end node to get the information on how the priorities are used when it attaches to the network.


This TLV would be something to mention if there is an RFC developed on relationship between DSCP and 802.1Q prioiries.




Bob Briscoe | 5 Nov 03:19 2015

Fwd: Re: Promises to review draft-...-tcpm-accurate-ecn

tcpm note-takers, and the list,

Pls shout if I missed anyone, or if you were scratching your head rather than putting up your hand.


-------- Forwarded Message -------- Subject: Date: From: To: CC:
Re: Promises to review draft-...-tcpm-accurate-ecn
Thu, 5 Nov 2015 10:18:40 +0900
Pasi Sarolahti <pasi.sarolahti <at>>
Bob Briscoe <research <at>>
Mirja Kühlewind <mirja.kuehlewind <at>>, Richard Scheffenegger <rs <at>>, Yoshifumi Nishida <nishida <at>>, Michael Scharf <Michael.SCHARF <at>>

Thanks, very helpful! (you could also post it to list, so people know they are tagged :-) - Pasi On 05 Nov 2015, at 10:14, Bob Briscoe <research <at>> wrote: > Mirja, Richard, > > I noted the following promises to review AccECN (I'll check this gets into the minutes): > > Gorry Fairhurst > Praveen Balasubramian > Koen De Schepper > Brian Trammell > Tommy Pauly > Karen Nielsen? > > Promise to test: > CableLabs guy (sorry don't know his name) > > > Bob > > > -- > ________________________________________________________________ > Bob Briscoe >

Eggert, Lars | 5 Nov 05:16 2015

Port randomization RFC

Lucy, as I just said I think you can simply refer to RFC6056.