Subject: Re: [tsvwg] partial review of draft-ietf-tsvwg-gre-in-udp-encap-03

From: Bob Briscoe <[email-masked]>
Date: Mon, 26 Jan 2015 13:47:23 +0000

David,

Apologies for the ultra-long RTT. Inline...

At 19:03 21/11/2014, Black, David wrote:
>Bob,
>
> > 1) Regarding congestion control, I do not share the position of some
> > others in tsvwg. Congestion responsiveness is determined by how the
> > source spaces out the packets (i.e. their instantaneous rate). Just
> > because a tunnel ingress encapsulates a packet with a UDP header does
> > not suddenly make it unresponsive to congestion. The spacing between
> > packets is still determined by the source. So there is no need to
> > even mention congestion control considerations in a tunneling
> > document, except to say in the scoping at the start that the addition
> > of tunnel headers is completely orthogonal to congestion avoidance and
> > control.
>
>Unfortunately, it's not "completely orthogonal" because UDP goes many
>places that the encapsulated protocols can't.  Hence "can't get there
>from here" protection in NATs and other middleboxes that drop the
>unencapsulated protocol won't stop non-congestion controlled UDP-
>encapsulated traffic from getting into places that it shouldn't and
>causing damage.  Also, please take note of the text in the mpls-in-udp
>draft that recommends filters to block such traffic from going where
>it shouldn't, which restores some of these protections.

OK, that's correct, but I should have phrased my concern differently.

Advice on where an operator should not deploy tunnel endpoints is a 
run-time concern, for which it is appropriate to advise operators 
(and maybe users). A specification like Lucy's is surely solely for 
an implementer audience. Unless we can say there is something that 
must be implemented along with the tunnel encap/decap, surely we 
should not hold Lucy back.

Yes, we should work on circuit breakers for tunnels. But that's for 
the operator audience. We should not take out our frustrations with 
operators on implementers. We should not hold Lucy and others like 
her back for this. She is innocent in this battle.

Bob

>Thanks,
>--David
>
> > -----Original Message-----
> > From: Bob Briscoe [mailto:[email-masked]]
> > Sent: Friday, November 21, 2014 12:30 PM
> > To: Lucy yong
> > Cc: Black, David; [email-masked]
> > Subject: partial review of draft-ietf-tsvwg-gre-in-udp-encap-03
> >
> > Lucy,
> >
> > I'll wait for David's promised proposal to the list before commenting
> > on the checksum issue.
> >
> > 1) Regarding congestion control, I do not share the position of some
> > others in tsvwg. Congestion responsiveness is determined by how the
> > source spaces out the packets (i.e. their instantaneous rate). Just
> > because a tunnel ingress encapsulates a packet with a UDP header does
> > not suddenly make it unresponsive to congestion. The spacing between
> > packets is still determined by the source. So there is no need to
> > even mention congestion control considerations in a tunnelling
> > document, except to say in the scoping at the start that the addition
> > of tunnel headers is completely orthogonal to congestion avoidance and
> > control.
> >
> > 2)
> > Please replace:
> >     Tunnel end points that support
> >     ECN MUST use the method described in [RFC6040] for ECN marking
> >     propagation.
> > With:
> >     Tunnel end points need to use the method described in [RFC6040]
> > for ECN marking
> >     propagation.
> > Rationale:
> >     i) There is no such thing as a tunnel end point that does not
> > support ECN - it has to put something in the ECN field, and it would
> > not be appropriate to put anything in there other than what RFC6040 says.
> >    ii) Generally it is not a good idea to fill one draft with
> > normative statements that repeat normative statements made in other
> > drafts. Otherwise updating an RFC gets very difficult - we have to
> > update all the other RFCs that gratuitously repeat what it says.
> >
> > 3) Nit in section 3.1.
> >     Section 5 of RFC6936 [RFC6936] specifies the additional requirements
> >     that implementation of UDP zero-checksum over IPv6 MUST compliant
> >     with. To compliant with it, the following additional requirements
> >     apply
> > s/compliant/comply/ (twice)
> >
> > There are other nits, but they can be dealt with later.
> >
> >
> > Cheers
> >
> >
> > Bob
> >
> >
> >
> >
> > ________________________________________________________________
> > Bob Briscoe,                                                  BT

________________________________________________________________
Bob Briscoe,                                                  BT

---

From: "Black, David" <[email-masked]>
Date: Tue, 27 Jan 2015 08:37:06 +0000

> A specification like Lucy's is surely solely for
> an implementer audience.

With my OPS Directorate member hat on (and WG chair hat off), I
definitely disagree ...

... we routinely review all drafts for appropriate operational
considerations - see RFC 5706, and in particular Appendix A.1,
which is definitely applicable to this draft.

Thanks,
--David

> Sent: Monday, January 26, 2015 8:47 AM
> To: Black, David
> Cc: [email-masked]
> Subject: RE: partial review of draft-ietf-tsvwg-gre-in-udp-encap-03
> 
> David,
>

---

From: Bob Briscoe <[email-masked]>
Date: Thu, 29 Jan 2015 15:23:46 +0000

David,

OK. Understood.

Bob