Subject: [tcpm] draft-ietf-tcpm-urgent-data-06

From: Ronald Bonica <[email-masked]>
Date: Thu, 23 Sep 2010 17:10:24 -0400

Folks,

The purpose of this email is to encourage the TCPM working group to deprecate the feature described in draft-ietf-tcpm-urgent-data-06.

I understand the following statements to be true:

- The WG discourages new applications from using the feature.
- Many middle-boxes defeat the feature by removing the urgent data indicator. Therefore, when an application indicates that data is urgent, it is never sure that that indication will reach the remote TCP.
- Only three applications have been identified as using the feature. These are a proprietary application, telnet and ftp. More elegant mechanisms are available to Telnet and FTP.
- The feature is rarely implemented as specified.

Finally, there are more elegant ways to bring urgent data to applications.

IMHO, this feature should be deprecated, not enhanced. Let's not pass up this opportunity to simplify the TCP stack.

                                                           Ron

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 23 Sep 2010 15:51:03 -0600

On 9/23/10 3:10 PM, Ronald Bonica wrote:
> - Only three applications have been identified as using the
> feature. These are a proprietary application, telnet and ftp. More
> elegant mechanisms are available to Telnet and FTP.

I have not fully researched use to TCP urgent data in applications, but
here is my early reaction:

1. I'm not sure why we care over much about an unnamed proprietary
application.

2. Regarding telnet, use of TCP urgent data seems to be limited to the
TELNET SYNCH sequence. How often is that feature invoked? And who uses
telnet these days anyway?

3. Regarding FTP, use of TCP urgent data seems to be limited to the FTP
abort command. How often is that feature invoked?

> IMHO, this feature should be deprecated, not enhanced. Let's not pass
> up this opportunity to simplify the TCP stack.

+1

But I'll ping the apps-discuss list for further feedback.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: John Heffner <[email-masked]>
Date: Thu, 23 Sep 2010 21:00:49 -0400

My understanding is that deprecating urgent data is exactly what this
document is doing.  In section 5: "... new applications SHOULD NOT
employ the TCP urgent mechanism."  The rest of the document is largely
a justification for deprecating the mechanism.

  -John

On Thu, Sep 23, 2010 at 5:10 PM, Ronald Bonica <[email-masked]> wrote:
> _______________________________________________
> tcpm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpm
>

---

From: David Borman <[email-masked]>
Date: Thu, 23 Sep 2010 20:07:20 -0500

> telnet these days anyway?

As to the first question, in the BSD telnet, the TELNET SYNC mechanism is used any time you type ^C, to synchronize flushing of terminal output.

			-David Borman

---

From: Joe Touch <[email-masked]>
Date: Thu, 23 Sep 2010 19:17:45 -0700

> a justification for deprecating the mechanism.

And a clarification as to what byte the urgent data actually starts at. 
The spec doesn't match any of the implementations, and since there's no 
benefit to either variant, the WG decided to change the spec to match 
the extant implementations. See section 4.

This is NOT an enhancement, and is NOT intended to make future apps more 
likely to use the urgent mechanism. See section 6, which deprecates the 
feature.

Is there a question that, e.g., the title be updated to reflect the 
primary intent, i.e.,"Deprecating TCP's Urgent Mechanism", with a few 
other related changes (e.g., update the abstract/intro, move section 6 
forward, and then explain that the remainder of the doc is to document 
how existing apps work?)?

I could see how the current doc reads more like "we're updating the spec 
first. oh yeah, and don't use this", which seems inverted; the WG 
conclusion was more like "deprecate this. and oh yeah, here's how it 
really works in the few apps that we know of that actually use it"

Joe

>
>    -John
>
>
> On Thu, Sep 23, 2010 at 5:10 PM, Ronald Bonica<[email-masked]>  wrote:
>> Folks,
>>

---

From: "Anantha Ramaiah (ananth)" <[email-masked]>
Date: Thu, 23 Sep 2010 22:43:43 -0700

I would want to take an objective stance. 

Firstly, what happens if we don't deprecate this feature? How many
applications have been using the urgent ptr since RFC 1122 clarified the
semantics of the same?. Answer : a handful of them. I don't think by
deprecating this feature or not doing so you are achieving anything
substantial. I am not saying that this document is not needed, it is
always useful to have guidance and that's where this document stands
given my reading of it. 

If we are on the verge of deprecating this feature, then why a SHOULD
qualifier is chosen currently instead of MUST ? (since the deprecation
applies for new applications only and not existing apps which is using
them)

OTOH, if the outcome of deprecating this feature as specified today
paves way for reusing this space (urgent pointer and bit) for something
more useful in the future, then we have gotten more bang for the buck. 

$0.02,
-Anantha 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Ronald Bonica
> Sent: Thursday, September 23, 2010 2:10 PM
> To: [email-masked]
> Subject: [tcpm] draft-ietf-tcpm-urgent-data-06
> 
> Folks,
> 
> The purpose of this email is to encourage the TCPM working 
> group to deprecate the feature described in 
> draft-ietf-tcpm-urgent-data-06.
> 
> - Many middle-boxes defeat the feature by removing the urgent 
> data indicator. Therefore, when an application indicates that 
> data is urgent, it is never sure that that indication will 
> reach the remote TCP.
> feature. These are a proprietary application, telnet and ftp. 
> More elegant mechanisms are available to Telnet and FTP.
> IMHO, this feature should be deprecated, not enhanced. Let's 
> not pass up this opportunity to simplify the TCP stack.
> 
>                                                            Ron
>

---

From: Fernando Gont <[email-masked]>
Date: Fri, 24 Sep 2010 02:42:08 -0300

Hi, Ron,

> up this opportunity to simplify the TCP stack.

FWIW, this document deprecates the urgent mechanism. However, we're not
"simplifying the TCP stack" as implementations still need to implement
the urgent mechanism.

IMHO, since there are still a few applications that use it, the current
I-D is a sensible way forward.

Thanks,
-- 
Fernando Gont
e-mail: [email-masked] || [email-masked]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

---

From: Fernando Gont <[email-masked]>
Date: Fri, 24 Sep 2010 02:45:12 -0300

Hi, Peter,

> 1. I'm not sure why we care over much about an unnamed proprietary

IIRC, that application is MS SQL. I don't care about MS SQL *myself*,
but this is still a data point.

> telnet these days anyway?

I do know a number of people (from IETF circles) that use telnet in
closed environments. Whether they should be using ssh instead is a
different question.

> abort command. How often is that feature invoked?

If anything, it may be invoked when a real FTP client is used (i.e., not
a browser).

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Fri, 24 Sep 2010 04:12:15 -0300

Hi, Anantha,

> Firstly, what happens if we don't deprecate this feature? 

It is important to raise awareness that the TCP urgent mechanism is
unreliable, and thus should not be employed by new applications.

> How many
> substantial. 

Raising awareness, as indicated above?

> applies for new applications only and not existing apps which is using

I wouldn't object to that. Actually, it probably makes sense. :-)

Thanks,

---

From: David Borman <[email-masked]>
Date: Sat, 25 Sep 2010 20:27:20 -0500

Note: This message is as an individual contributor, not as a WG chair.

> unreliable, and thus should not be employed by new applications.

Folks, let's just remember that this document is dealing with the definition of the urgent pointer from the viewpoint of the specification, not from any particular implementation.  If an application is being deployed on a known set of OSes, and those OSes all have the same interpretation of the Urgent pointer, then the application can use it reliably.  Even if the OSes have different interpretations, if the application knows what the interpretation is on each side and adjusts accordingly, it can still use the Urgent pointer reliably.

But this document is not about a specific set of implementations, it is about unknown OSes that may have one of two different interpretations of the Urgent pointer, and the problems that leads to for arbitrary unknown applications running without any a priori knowledge of how the underlying OS interprets the Urgent pointer.

The document is about changing the definition of the Urgent pointer to match how the majority of implementations implemented the Urgent pointer, and to recommend against new applications using it for the stated reasons.  It isn't a MUST NOT, it is a SHOULD NOT, so as long as the application designer understands the issues, the Urgent pointer can still be used if needed, and TCP implementations still need to implement it so that it can be used.

> I wouldn't object to that. Actually, it probably makes sense. :-)

I would object to total deprecation of the Urgent pointer.  There is nothing else in TCP that provides the same functionality within a single TCP stream.  Even with the +/- one byte ambiguity in the receiving application, it is still possible to use the Urgent pointer for the functionality it was originally intended, i.e. as advance notification that there is something interesting later on in the data stream.

I like the current document; it resolves the definition vs. implementation issue with the Urgent pointer, identifies the issues of using the Urgent pointer between different implementations of the Urgent pointer, and recommends SHOULD NOT for future applications, which means that if the Urgent pointer is really the right solution for their application, they can still use it as long as they understand the potential issues.

		-David Borman

---

From: Ronald Bonica <[email-masked]>
Date: Mon, 27 Sep 2010 15:49:05 -0400

Joe,

I think that you have hit the nail on the head. Reading through Sections 1-5, I thought that we were trying to fix the feature. Only in Section 6 did I realize that we really wanted to drive a stake through its heart.

Maybe if we changed the title and added some test to the abstract and introduction, this would be better. Otherwise, people may spend time and money fixing the TCP Urgent option instead of just avoiding it.

> From: Joe Touch [mailto:[email-masked]]
> Sent: Thursday, September 23, 2010 10:18 PM
> To: John Heffner
> Cc: Ronald Bonica; [email-masked]
> Subject: Re: [tcpm] draft-ietf-tcpm-urgent-data-06
> 
> 
> 
> >> The purpose of this email is to encourage the TCPM working group to
> deprecate the feature described in draft-ietf-tcpm-urgent-data-06.
> >>
> >> - Many middle-boxes defeat the feature by removing the urgent data
> indicator. Therefore, when an application indicates that data is
> urgent, it is never sure that that indication will reach the remote
> TCP.
> >> - Only three applications have been identified as using the feature.
> These are a proprietary application, telnet and ftp. More elegant
> mechanisms are available to Telnet and FTP.
> >> IMHO, this feature should be deprecated, not enhanced. Let's not
> pass up this opportunity to simplify the TCP stack.
> >>
> >>                                                            Ron
> >>

---

From: Lars Eggert <[email-masked]>
Date: Wed, 29 Sep 2010 13:08:58 +0300

Hi,

> Maybe if we changed the title and added some test to the abstract and introduction, this would be better. Otherwise, people may spend time and money fixing the TCP Urgent option instead of just avo…

are the other IESG members with DISCUSSes (Jari & Tim) OK with this approach? If yes, would you consider having one AD hold the combined DISCUSS?

Thanks,
Lars

---

From: Jari Arkko <[email-masked]>
Date: Wed, 29 Sep 2010 13:44:36 +0300

Lars,

> are the other IESG members with DISCUSSes (Jari & Tim) OK with this approach? If yes, would you consider having one AD hold the combined DISCUSS?

I do agree that attempting to fix urgent data as opposed to indicating 
what's wrong with and recommending against its use is the root problem.

I already have a discuss on the document, I can volunteer to hold this 
viewpoint under that discuss as well.

Jari

---

From: Ronald Bonica <[email-masked]>
Date: Wed, 29 Sep 2010 12:40:32 -0400

I can clear my DISCUSS and let Jari hold it for all of us.

                              Ron

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Jari Arkko
> Sent: Wednesday, September 29, 2010 6:45 AM
> To: Lars Eggert
> Cc: [email-masked]; [email-masked] IESG; Joe Touch
> >> I think that you have hit the nail on the head. Reading through
> Sections 1-5, I thought that we were trying to fix the feature. Only in
> Section 6 did I realize that we really wanted to drive a stake through
> its heart.
> >>
> >> Maybe if we changed the title and added some test to the abstract
> and introduction, this would be better. Otherwise, people may spend
> time and money fixing the TCP Urgent option instead of just avoiding
> it.
> >>
> >
> > are the other IESG members with DISCUSSes (Jari & Tim) OK with this
> approach? If yes, would you consider having one AD hold the combined
> DISCUSS?
> >
>