Subject: [Int-area] draft-bonica-intarea-gre-mtu and ECN

From: Ronald Bonica <[email-masked]>
Date: Tue, 6 Aug 2013 17:34:13 +0000

Folks,

At our meeting in Berlin, someone (Lars?) came to the microphone to suggest that draft-bonica-intarea-gre-mtu consider handling of the ECN bits. The purpose of this message is to seek clarification on that comment.

Section 5.3 of RFC 3168 specifies procedures for handling the ECN bit when reassembling fragmented packets. These rules must be observed by any device that reassembles fragmented packets, including tunnel egress routers. It would be reasonable to make note of this in draft-bonica-intarea-gre-mtu.

Section 9.1 of RFC 3168 as well as RFC 6040, specify procedures for propagating ECN bits between the tunnel payload and delivery header. These rules apply to all tunneled packets, regardless of whether they are fragmented. Because the scope of draft-bonica-intarea-gre-mtu is limited to MTU and fragmentation issues, a discussion of these rules seems to be beyond the scope of draft-bonica-intarea-gre-mtu.

Do folks agree?

--------------------------
Ron Bonica
vcard:       www.bonica.org/ron/ronbonica.vcf

---

From: "Eggert, Lars" <[email-masked]>
Date: Wed, 7 Aug 2013 14:20:48 +0000

Hi,

> Section 5.3 of RFC 3168 specifies procedures for handling the ECN bit when reassembling fragmented packets. These rules must be observed by any device that reassembles fragmented packets, including…

agreed. You should also talk about what happens with the DSCP.

> Section 9.1 of RFC 3168 as well as RFC 6040, specify procedures for propagating ECN bits between the tunnel payload and delivery header. These rules apply to all tunneled packets, regardless of whe…

Agreed. However, given that the GRE spec predates the ECN spec, what are GRE implementations actually doing with the ECN/DSCP fields? Unfortunately, 3168 did not update 2784, although GRE can also provide an IP-in-IP tunnel type. 

Lars

PS: CC'ing Bob, who also commented.

---

From: Ronald Bonica <[email-masked]>
Date: Wed, 7 Aug 2013 15:32:49 +0000

Hi Lars,

We have a decision to make. Currently, the scope of the document is limited to MTU and fragmentation issues. So, the reassembly issues in Section 5.3 of 3168 are clearly within scope.

However, DSCP handling has nothing to do with MTU and fragmentation. We could include them, but that would mean expanding the scope of the document. Does the WG want to do this?

Opinions?

                        Ron

> -----Original Message-----
> From: Eggert, Lars [mailto:[email-masked]]
> Sent: Wednesday, August 07, 2013 10:21 AM
> To: Ronald Bonica; Bob Briscoe
> Cc: Internet Area
> Subject: Re: [Int-area] draft-bonica-intarea-gre-mtu and ECN
> 
> Hi,
> 
> > Section 5.3 of RFC 3168 specifies procedures for handling the ECN bit
> when reassembling fragmented packets. These rules must be observed by
> any device that reassembles fragmented packets, including tunnel egress
> routers. It would be reasonable to make note of this in draft-bonica-
> intarea-gre-mtu.
> 
> > Section 9.1 of RFC 3168 as well as RFC 6040, specify procedures for
> propagating ECN bits between the tunnel payload and delivery header.
> These rules apply to all tunneled packets, regardless of whether they
> are fragmented. Because the scope of draft-bonica-intarea-gre-mtu is
> limited to MTU and fragmentation issues, a discussion of these rules
> seems to be beyond the scope of draft-bonica-intarea-gre-mtu.
> 
> Agreed. However, given that the GRE spec predates the ECN spec, what
> are GRE implementations actually doing with the ECN/DSCP fields?
> Unfortunately, 3168 did not update 2784, although GRE can also provide
> an IP-in-IP tunnel type.
> 
> Lars
>

---

From: Bob Briscoe <[email-masked]>
Date: Wed, 7 Aug 2013 18:41:58 +0100

Lars, Ron,

At 15:20 07/08/2013, Eggert, Lars wrote:
> > Section 5.3 of RFC 3168 specifies procedures for handling the ECN 
> bit when reassembling fragmented packets. These rules must be 
> observed by any device that reassembles fragmented packets, 
> including tunnel egress routers. It would be reasonable to make 
> note of this in draft-bonica-intarea-gre-mtu.
>
>agreed.

+1

>You should also talk about what happens with the DSCP.

It is possible that different fragments of a packet will get 
different DSCPs (e.g. if some packets are re-marked due to being out 
of contract in a DS policer). However, RFC2474, RFC2983 (Diffserv & 
Tunnels) and RFC2597 (Diffserv AF) all fail to mention anything about 
what to do on re-assembly.

So I wouldn't open this can of worms, given no-one else has. It 
probably doesn't matter greatly which of the DSCPs on the fragments 
ends up being used for the reassembled packet, but I guess most 
implementations will use the DSCP on the first fragment, even if they 
haven't consciously thought about it.

It wouldn't take much to update 2474 to just say that - if someone 
has some spare clock cycles to waste.

> > Section 9.1 of RFC 3168 as well as RFC 6040, specify procedures 
> for propagating ECN bits between the tunnel payload and delivery 
> header. These rules apply to all tunneled packets, regardless of 
> whether they are fragmented. Because the scope of 
> draft-bonica-intarea-gre-mtu is limited to MTU and fragmentation 
> issues, a discussion of these rules seems to be beyond the scope of 
> draft-bonica-intarea-gre-mtu.
>
>Agreed.

+1

>However, given that the GRE spec predates the ECN spec, what are GRE 
>implementations actually doing with the ECN/DSCP fields? 
>Unfortunately, 3168 did not update 2784, although GRE can also 
>provide an IP-in-IP tunnel type.

Yes, I would be interested in an answer to that. Particularly given 
recent ideas on using GRE tunnels in data centres to turn on ECN 
edge-to-edge. See draft-briscoe-conex-data-centre-01 or 
<http://www.ietf.org/proceedings/87/slides/slides-87-conex-4.pdf>

PS. We also have an individual draft that clarifies that the RFC6040 
propagation of ECN should be used by all the different tunnelling 
protocols, including GRE: 
<http://tools.ietf.org/html/draft-briscoe-tsvwg-ecn-encap-guidelines-02>

Bob

>PS: CC'ing Bob, who also commented.

________________________________________________________________
Bob Briscoe,                                                  BT

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Wed, 7 Aug 2013 20:18:37 +0000

Hi, Lars,

> agreed. You should also talk about what happens with the DSCP.

I am not sure I agree. RFC 3168 is broadly applicable and Section 5.3 specifies requirements for IP reassembly (and fragmentation) so that congestion information is not lost. However, that does not imply that this needs to be repeated in any document that talks about fragmentation and reassembly. Frankly, I see these as orthogonal issues. 

In other words, noting S5.3 of RFC 3168 in draft-bonica-intarea-gre-mtu does not add as compared to not noting it -- the requirement already exists, and is applicable to any frag/reassembly, including GRE, any other tunnel, or any other protocol, as the ECN considerations at the IP layer. RFC 3168 specifies transport considerations for TCP and not for GRE also.

> Agreed. However, given that the GRE spec predates the ECN spec, what are GRE implementations actually doing with the ECN/DSCP fields? Unfortunately, 3168 did not update 2784, although GRE can also…

Section 9.3 covers GRE, and now draft-briscoe-tsvwg-ecn-encap-guidelines is clarifying the area previously left for further study.

Net-net, in my humble opinion, since draft-bonica-intarea-gre-mtu concerns itself with fragmentation strategies for GRE, these two ECN issues (ECN at reassembly and tunnels) seem orthogonal to the scope and goal of the document, and better dealt with in a separate place instead of intertwining them in draft-bonica-intarea-gre-mtu.

Thanks,

-- Carlos.

> _______________________________________________
> Int-area mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/int-area

---

From: "Eggert, Lars" <[email-masked]>
Date: Thu, 8 Aug 2013 07:25:53 +0000

Hi,

> In other words, noting S5.3 of RFC 3168 in draft-bonica-intarea-gre-mtu does not add as compared to not noting it -- the requirement already exists, and is applicable to any frag/reassembly, includ…

you're correct. In practice, however, not everyone is familiar with the contents of all related RFCs when implementing a given protocol extension, and I think pointing implementors at relevant related specs - esp. when mandatory to support - is a courtesy.

> Net-net, in my humble opinion, since draft-bonica-intarea-gre-mtu concerns itself with fragmentation strategies for GRE, these two ECN issues (ECN at reassembly and tunnels) seem orthogonal to the…

Which document specifies the reassembly of fragments carried in GRE?

Lars

---

From: Ronald Bonica <[email-masked]>
Date: Thu, 8 Aug 2013 18:00:54 +0000

Folks,

I think that we have agreed to the following:

- We should include a reference to S5.3 of RFC 3168, reminding implementers that when reassembling a packet, if any packet has ECN set, the reassembled packet MUST have ECN set. While this may be orthogonal to the draft, it is included as a courtesy.

- We don't need to add any text about copying DSCP or ECN bits back and forth between the payload and delivery headers, as this issues are beyond the scope of the document.

Have we in fact agreed on this?

                                       Ron

> Sent: Thursday, August 08, 2013 3:26 AM
> To: Carlos Pignataro (cpignata)
> Cc: Ronald Bonica; Bob Briscoe; Internet Area
> > In other words, noting S5.3 of RFC 3168 in draft-bonica-intarea-gre-
> mtu does not add as compared to not noting it -- the requirement
> already exists, and is applicable to any frag/reassembly, including
> GRE, any other tunnel, or any other protocol, as the ECN considerations
> at the IP layer. RFC 3168 specifies transport considerations for TCP
> and not for GRE also.
> 
> you're correct. In practice, however, not everyone is familiar with the
> contents of all related RFCs when implementing a given protocol
> extension, and I think pointing implementors at relevant related specs
> - esp. when mandatory to support - is a courtesy.
> 
> > Net-net, in my humble opinion, since draft-bonica-intarea-gre-mtu
> concerns itself with fragmentation strategies for GRE, these two ECN
> issues (ECN at reassembly and tunnels) seem orthogonal to the scope and
> goal of the document, and better dealt with in a separate place instead
> of intertwining them in draft-bonica-intarea-gre-mtu.
>

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Thu, 8 Aug 2013 21:22:21 +0000

Hi, Lars,

> you're correct. In practice, however, not everyone is familiar with the contents of all related RFCs when implementing a given protocol extension, and I think pointing implementors at relevant rela…

I agree in principle with this, although there's a degree of relevance for these informational and contextual "reminder" pointers. Yes, I've also seen then be of help in practice as well, but I wouldn't want to cite every mandatory RFC related to fragmentation.

In this case, draft-bonica-intarea-gre-mtu is more about fragmentation than reassembly, while S5.3 of RFC3168 concerns itself with reassembly mostly, which is why I think the correlation is tenuous. On the other side, I do not see any harm with adding it (it's not a major distraction from the main topic), and I can see potential benefit with awareness raising.

> Which document specifies the reassembly of fragments carried in GRE?

RFC 791 and RFC 2460 (if I understood your question correctly :-). If IP fragments are carried in GRE, after decapsulation, IP is exposed. As far as ECN propagation and behavior, I think the best is http://tools.ietf.org/html/draft-briscoe-tsvwg-ecn-encap-guidelines-02#section-4.1

Thanks,

-- Carlos.

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Thu, 8 Aug 2013 21:23:04 +0000

Hi Ron,

This sounds good to me. Thanks!

-- Carlos.