Subject: Re: [Taps] I-D Action: draft-ietf-taps-transports-07.txt

From: Brian Trammell <[email-masked]>
Date: Thu, 12 Nov 2015 15:47:10 +0100

hi Karen,

Thanks for the comments and review! Commentcomments inline, anything not remarked on is accepted into -08 as-is.

> On 28 Oct 2015, at 13:16, Karen Elisabeth Egede Nielsen <[email-masked]> wrote:
> 
> HI,
> 
> Please accept the following comments.
> Use them as/if you see fit.
> (Given my wretched, non-twistable, arms you are allowed not to take them
> too seriously)
> 
> Section 3.1.1:
> 
> 6'th paragraph:
> 
> " In addition, a congestion control
>   mechanism may react to changes in delay as an early indication for
>   congestion."
> 
> I think one will need to give a reference to this as it is not covered by
> the reference to RFC5681.
> Possibly this statement is better given in the context of the next
> paragraph referring to extensions.
> 
> [I am aware that I have given this comment before. The reason that this
> continues to be an issue for me is that
> delay based CC alg's also are applicable to, e.g., SCTP (and have been
> applied there, though I don't know much
> about real deployment of them for SCTP).
> I am not sure if the solution to this is to have a special common section
> about congestion control algorithms - referring possibly
> to that these special CC als mostly are in deployment for TCP].

It does seem to me that CC algorithms as deployed in the Internet are somewhat orthogonal to the mechanics of the underyling transport protocol, so this is probably not a bad idea... I'll have a look at how this could be easily refactored out of the document, probably into a new section 4 (before the present section 4)...

> 9'th paragraph:
> 
> Reference to push flag:
> 
> The sentence:
> 
> "TCP provides a push and a urgent function to enable data to be
>   directly accessed by the receiver without having to wait for in-order
>   delivery of the data."
> 
> Should be revised I think. It is not very clear what the push flag
> contribute with in this sentence. The PUSH flag helps to release a "tail"
> packet from a  TSO/GRO function/temporary packet buffering function. This
> feature of TCP might be significantly enough to describe the
> PUSH flag function as an implicit and internal protocol implementation
> optimization making TCP "push" tails through
> intermediate buffering functions. But the PUSH function is not really a
> "function" that TCP stacks provide to the ULP today
> (even if this is described as an optional possibility in RFC1122) - Or is
> it ?

I've never seen it treated as one; to my knowledge inconsistent treatment has led to PSH being largely ignored/ignorable, but there are probably people with more thorough knowledge on this list...

> The urgent flag is not recommended ... so does it belong here ?

It does provide a (not very functional) out of order delivery mechanism, though its deprecation should be referenced here here. Will do so in -08.

> Section 4.1:

Section 4.1 has been removed, in the interests of getting the document out the door. The hierarchical list in Section 4 replaces it.

> I wonder if SCTP Reliability could be Full/Partial/None

This is captured in the present (GitHub) revision of the list.

> I wonder if unordered delivery should be added as a row.

Unordered delivery is an entry in the list.

> I am not sure if ECN for SCTP should be marked as TBD. Applicability of
> RFC3168 to SCTP is described in RFC4960.

We don't have a line item for ECN in the list yet, perhaps we should.

> I personally don’t know of any deployment of this.

By "no deployment" you mean "no implementation" or "it's not turned on"?

Thanks again, cheers,

Brian

---

From: Karen Elisabeth Egede Nielsen <[email-masked]>
Date: Fri, 13 Nov 2015 10:06:21 +0100

HI,

Thanks a lot.

Please find inline below.
Nothing outstanding as far as I can tell :-)

BR, Karen

> -----Original Message-----
> From: Brian Trammell [mailto:[email-masked]]
> Sent: 12. november 2015 15:47
> To: Karen Elisabeth Egede Nielsen <[email-masked]>
> Cc: [email-masked]; Mirja Kühlewind <[email-masked]>;
> Michael Tuexen <[email-masked]>
> Subject: Re: [Taps] I-D Action: draft-ietf-taps-transports-07.txt
>
> hi Karen,
>
> Thanks for the comments and review! Commentcomments inline, anything
> not remarked on is accepted into -08 as-is.
>
> > (Given my wretched, non-twistable, arms you are allowed not to take
> > them too seriously)
> >
> > Section 3.1.1:
> >
> > 6'th paragraph:
> >
> > I think one will need to give a reference to this as it is not covered
> > by the reference to RFC5681.
> > [I am aware that I have given this comment before. The reason that
> > this continues to be an issue for me is that delay based CC alg's also
> > are applicable to, e.g., SCTP (and have been applied there, though I
> > don't know much about real deployment of them for SCTP).
> > I am not sure if the solution to this is to have a special common
> > section about congestion control algorithms - referring possibly to
> > that these special CC als mostly are in deployment for TCP].
>
> It does seem to me that CC algorithms as deployed in the Internet are
> somewhat orthogonal to the mechanics of the underyling transport protocol,
> so this is probably not a bad idea... I'll have a look at how this could
> be easily
> refactored out of the document, probably into a new section 4 (before the
> present section 4)...
>
[Karen Elisabeth Egede Nielsen] This would be great, _I_ think.

> > packet from a  TSO/GRO function/temporary packet buffering function.
> > This feature of TCP might be significantly enough to describe the PUSH
> > flag function as an implicit and internal protocol implementation
> > optimization making TCP "push" tails through intermediate buffering
> > functions. But the PUSH function is not really a "function" that TCP
> > stacks provide to the ULP today (even if this is described as an
> > optional possibility in RFC1122) - Or is it ?
>
> I've never seen it treated as one; to my knowledge inconsistent treatment
> has led to PSH being largely ignored/ignorable, but there are probably
> people
> with more thorough knowledge on this list...
>
[Karen Elisabeth Egede Nielsen] Yes.
Unfortunately we have had outtages (killing services in regions - not a
small issue..) recently as some applications
had put trust into the PUSH bit. That's why I would not like the document to
point to this as valid service provided by TCP
to ULP.
Except for what I wrote above.

> It does provide a (not very functional) out of order delivery mechanism,
> though its deprecation should be referenced here here. Will do so in -08.
>
[Karen Elisabeth Egede Nielsen] super.
> > Section 4.1:
>
> Section 4.1 has been removed, in the interests of getting the document out
> the door. The hierarchical list in Section 4 replaces it.
>

[Karen Elisabeth Egede Nielsen] ok thanks.
> By "no deployment" you mean "no implementation" or "it's not turned on"?
[Karen Elisabeth Egede Nielsen] It is not turned on.

One of the Ericsson SCTP SW bases (there are two) implements the feature
following the
"traditional" approach of RFC3168/RFC4960.  This is the SCTP SW base with
the largest deployment base/footprint.
But we don't know of anywhere were it is active.
Likely in many nodes the feature has not even made it to the O&M api. I.e.,
the applications has chosen not to
expose the feature to the operators even if it _is_ exposed at SCTP API.
Hopefully this will change.

[A different issue of course is that the ECN in itself may change]