Subject: [sfc] Mirja Kühlewind's Discuss on draft-farrel-sfc-convent-05: (with DISCUSS and COMMENT)

From: Mirja Kühlewind <[email-masked]>
Date: Fri, 02 Feb 2018 09:34:55 -0800

Mirja Kühlewind has entered the following ballot position for
draft-farrel-sfc-convent-05: Discuss

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 https://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:
https://datatracker.ietf.org/doc/draft-farrel-sfc-convent/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

This spec enables an SC node to create new packets and therefore must provide
congestion control consideration to avoid network overload from these packets,
e.g. in the simplest case requiring a maximal sending rate/minimal time
interval between to packets.

I also requested an additional TSV-ART review for further feedback and
recommendations for a potential solution.

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I think this document should update RFC8300 as it does not only register an new
protocol but also changes some of the process for this specific case.

---

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 2 Feb 2018 18:25:47 -0000

Hi Mirja, 

Thanks for the review.

>From the Discuss...

> interval between to packets.

You say "consideration" and not "mechanism" and that sounds about right.

I think we should require rate-limiting on transmission and also on
receipt/forwarding.

At 30,000 foot we should look at this like ICMP, so rate limits are reasonable.

I am slightly worried that an application here might be OAM (although that is
still open for debate in the WG) and so rate limiting might be
counter-productive.

Consider, if you will, BFD. There *is* rate limiting in BFD, but the rate may be
pretty fast.

Anyway, if we construct some text that advises implementations:
- why to rate limit
- how to rate limit
- what rates may be appropriate
would you review it for us?

For the Comment...

> protocol but also changes some of the process for this specific case.

I am not going to get between the IESG and its  regular discussion of what an
"update" is ;-)
Once upon a time "B updates A" meant you cannot implement A without also
implementing B.
It was not my intention that anything in this spec changed the behaviour of an
implementation of 8300. If we have inadvertently made that happen, could you
point it out so we can fix it.

Thanks,
Adrian

---

From: "Mirja Kuehlewind (IETF)" <[email-masked]>
Date: Fri, 2 Feb 2018 21:14:58 +0100

Hi Adrian,

> Am 02.02.2018 um 19:25 schrieb Adrian Farrel <[email-masked]>:
> 
> Hi Mirja, 
> 
> Thanks for the review.
> 
> From the Discuss...
> 

Yes to all of this.

> point it out so we can fix it.

Yes, this was more a comment for the AD. However, it is still not true that „updates“ means „must implement“, maybe „must read“ or „must have a look at to figure out if it should be implemented as well“. But I also have to say it's on my todo for a while to write draft for clarification here, so I take all the blame. However, this is also just a comment, so one opinion that does not need to be addressed.

Mirja

---

From: "Mirja Kuehlewind (IETF)" <[email-masked]>
Date: Fri, 2 Feb 2018 21:25:28 +0100

Forgot to mention that probably a pointer to RFC8085 might also be helpful. These UDP usage guidelines are probably applicable here as well and the RFC discusses different cases depending on the traffic model. I guess 3.1.3 is most relevant but I actually don’t know what traffic characteristics you are expecting; so maybe addition discussion/consideration would be needed.

Mirja

> Am 02.02.2018 um 21:14 schrieb Mirja Kuehlewind (IETF) <[email-masked]>:
> 
> Hi Adrian,
> 
>

---

From: Martin Stiemerling <[email-masked]>
Date: Tue, 6 Feb 2018 23:03:06 +0100

Hi Adrian,

Jumping in here, as the TSVART reviewer:

The document is good modulo what Mirja mentioned about congestion control:

Am 02.02.18 um 19:25 schrieb Adrian Farrel:
[...]
> would you review it for us?

and it is probably explicitly noteworthy that one incoming packet can 
trigger one (or even multiple ?) new packet which may increase the 
number of packets related to the incoming flow by a factor of 2.

BFD (RFC 5880) might be a good start (but only...) when it comes to text 
about congestion control, i.e., to make the implementers and operators 
aware of the issue.

However, as you've written the reasons about why, how and what is much 
better.

I can do the review and help with the text.

Cheers from Southern Europe ;)

   Martin

---

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 8 Feb 2018 20:46:57 -0000

Thanks Martin and Mirja,

> number of packets related to the incoming flow by a factor of 2.

Well, it might be possible to create a use case that does that. OAM, for example, might cause a one-for-one copy. But one might as well say that this is a concern with IP because the payload protocol might result in one packet creating multiple replies.

But since this document is somewhat open-ended about how the is used, we should certainly flag up the concern with two mitigations:
1. Applications using this mechanism should be careful about this issue
2. Implementations should rate limit to:
  a. Protect against simple volume attacks (and accidents)
  b. Protect against amplification

I'll send some text SOON.

Cheers,
Adrian