Subject: [tsvwg] FW: Review of draft-ietf-tsvwg-gre-in-udp-encap-11

From: "Black, David" <[email-masked]>
Date: Sat, 7 May 2016 05:57:46 +0000

FYI, with thanks to Donald for reviewing this draft and also providing a bunch of editorial comments directly to the draft authors.

Thanks, --David

From: Black, David [mailto:[email-masked]]
Sent: Saturday, May 07, 2016 1:49 AM
To: Donald Eastlake; [email-masked]
Cc: [email-masked]
Subject: RE: Review of draft-ietf-tsvwg-gre-in-udp-encap-11

Donald,

Belated thanks for this review.   On the one technical point:

> In Section 2, 1st paragraph, last sentence and Section 2.1.1 there seems to be an overly broad assertion that
> "IP traffic" is congestion controlled. Section 8 is more correct, although worded in a slightly confusing way,
> to admit that general Internet IP traffic is generally not congestion controlled and that even the GRE-in-UDP
> traffic might not be. This should all be a bit clearer and more consistent.

The wording in Section 8 (“IP traffic is generally assumed to be congestion controlled”) and section 2.1.1 should use similar wording.   This statement comes from the discussion of UDP tunnels  in the rfc5405bis draft (section 3.2.10  in -12, but this section number may change in -13), and was originally made in RFC 5405 (section 3.1.3).

I would rephrase the language in Section 8 to indicate that  the rfc5405bis draft is the source of this statement (e.g., “ As stated in [RFC5405bis], IP traffic is generally assumed ...”).

> Section 3.2.1, last paragraph, should probably provide a reference to where the flow entropy value requirements are specified in the draft.

That makes sense.

> Section 6.2, last paragraph on page 15, would be confusing to a reader who didn't really understand the sense
> of "accumulate" here or what was being "accumulated". For example perhaps the first sentence, instead of just
> "accumulate incorrect state" should say something like "accumulate incorrect transport layer state due to apparent false flows".

Yes, that does need attention, as the  restatement above is not what was intended - GRE protocol state is  intended, and  that should be made clear:

OLD
   Generic Router Encapsulation (GRE) does not accumulate incorrect
   state as a consequence of GRE header corruption. A corrupt GRE
   packet may result in either packet discard or forwarding of the
   packet without accumulation of GRE state.
NEW
   Generic Router Encapsulation (GRE) does not accumulate incorrect
   GRE protocol state as a consequence of GRE header corruption. A corrupt GRE
   packet may result in either packet discard or forwarding of the
   packet without accumulation of GRE protocol state.

> Section 7, page 16, seems to assume that things are binary. Either you use the source port for full
> entropy or, for the reasons discussed, disable that and use a single source port. It seem to me that
> there might be cases where there would still be significant benefit to the handling of a fat flow if
> you could use a small number of source ports, for example 4 values, to provide a little entropy based
> on the traffic being tunneled. So I think there is a trade off here and the possibility of using a much
> reduced number of source ports, but more than one, should be mentioned.

The problem here is that there really isn’t any good way to probe middlebox behavior (e.g., whether 4 ports are acceptable), so the result is this simple binary recommendation - if it hurts  to use multiple source ports for entropy, don’t do that.

Thanks, --David

From: Donald Eastlake [mailto:[email-masked]]
Sent: Wednesday, April 13, 2016 2:40 PM
To: [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Fwd: Review of draft-ietf-tsvwg-gre-in-udp-encap-11

Sorry, screwed up on the draft authors address below... Re-sending

Thanks,
Donald
=============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 [email-masked]<mailto:[email-masked]>

---------- Forwarded message ----------
From: Donald Eastlake <[email-masked]<mailto:[email-masked]>>
Date: Wed, Apr 13, 2016 at 2:35 PM
Subject: Review of draft-ietf-tsvwg-gre-in-udp-encap-11
To: [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Hi,

I did a careful review of this draft. It seems admirably correct and complete. I do have a bunch of minor wording suggestions which I will send to the authors separately. There are a couple of places where the draft could be a bit clearer and I have one technical point, as follows:

In Section 2, 1st paragraph, last sentence and Section 2.1.1 there seems to be an overly broad assertion that "IP traffic" is congestion controlled. Section 8 is more correct, although worded in a slightly confusing way, to admit that general Internet IP traffic is generally not congestion controlled and that even the GRE-in-UDP traffic might not be. This should all be a bit clearer and more consistent.

Section 3.2.1, last paragraph, should probably provide a reference to where the flow entropy value requirements are specified in the draft.

Section 6.2, last paragraph on page 15, would be confusing to a reader who didn't really understand the sense of "accumulate" here or what was being "accumulated". For example perhaps the first sentence, instead of just "accumulate incorrect state" should say something like "accumulate incorrect transport layer state due to apparent false flows".

Section 7, page 16, seems to assume that things are binary. Either you use the source port for full entropy or, for the reasons discussed, disable that and use a single source port. It seem to me that there might be cases where there would still be significant benefit to the handling of a fat flow if you could use a small number of source ports, for example 4 values, to provide a little entropy based on the traffic being tunneled. So I think there is a trade off here and the possibility of using a much reduced number of source ports, but more than one, should be mentioned.

Feel free to forward this review or post it elsewhere if you want.

Thanks,
Donald
=============================
 Donald E. Eastlake 3rd   +1-508-333-2270<tel:%2B1-508-333-2270> (cell)
 155 Beaver Street, Milford, MA 01757 USA
 [email-masked]<mailto:[email-masked]>