Subject: [tcpm] draft-eggert-tcpm-historicize-00

From: Lars Eggert <[email-masked]>
Date: Wed, 9 Jun 2010 19:28:14 +0300

Quite possibly the most boring RFC ever. But at least it's short. Comments welcome.

http://tools.ietf.org/html/draft-eggert-tcpm-historicize

Begin forwarded message:
> Filename:	 draft-eggert-tcpm-historicize
> Revision:	 00
> Title:		 Moving the Undeployed TCP Extensions RFC1072, RFC1106, RFC1110, RFC1145, RFC1146, RFC1263, RFC1379, RFC1644 and RFC1693 to Historic Status
> Creation_date:	 2010-06-09
> WG ID:		 Independent Submission
> Number_of_pages: 4
> 
> Abstract:
> This document recommends that several TCP extensions that have never
> seen widespread use be moved to Historic status.  The affected RFCs
> are RFC1072, RFC1106, RFC1110, RFC1145, RFC1146, RFC1263, RFC1379,
> RFC1644 and RFC1693.

Lars

---

From: Ron Bonica <[email-masked]>
Date: Wed, 9 Jun 2010 13:19:53 -0400

I applaud this effort. I think that we should all take a sweep through
our registries and RFCs to get rid of some old cruft.

                                             Ron

---

From: Hagen Paul Pfeifer <[email-masked]>
Date: Wed, 9 Jun 2010 19:35:56 +0200

>Quite possibly the most boring RFC ever. But at least it's short. Comments

Lars, I thought about RFC 1145 "TCP Alternate Checksum Options", there are no
real shortcomings in the RFC. It is not _widely_ deployed but there is no real
security concern like say T/TCP.

I thought only superseded or defective RFCs can be declared historic? I mean
TCP Alternate Checksum Options _can eventually_ useful in the future for
example Interplanetary TCP. Maybe some military sites already employ RFC
1145.

HGN

---

From: "Anantha Ramaiah (ananth)" <[email-masked]>
Date: Wed, 9 Jun 2010 11:07:00 -0700

+1

FWIW, there is a recent proposal which talks about enhancing TCP
checksums as well :-

http://datatracker.ietf.org/doc/draft-anumita-tcpm-stronger-checksum/

The above proposal tries to leverage on the TCP alternate checksum
option. My thinking it may be useful to have a "TCP generalized checksum
option" which can give the flexibility for a TCP stack to choose from a
set of checksum algorithms (of course the default stays what it is today
;-) 

-Anantha

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Hagen Paul Pfeifer
> Sent: Wednesday, June 09, 2010 10:36 AM
> To: Lars Eggert
> Cc: [email-masked] Extensions
> Subject: Re: [tcpm] draft-eggert-tcpm-historicize-00
> 
> Lars, I thought about RFC 1145 "TCP Alternate Checksum 
> Options", there are no real shortcomings in the RFC. It is 
> not _widely_ deployed but there is no real security concern 
> like say T/TCP.
> 
> I thought only superseded or defective RFCs can be declared 
> historic? I mean TCP Alternate Checksum Options _can 
> eventually_ useful in the future for example Interplanetary 
> TCP. Maybe some military sites already employ RFC 1145.
> 
> HGN
> _______________________________________________
> tcpm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpm
>

---

From: Joe Touch <[email-masked]>
Date: Wed, 09 Jun 2010 11:21:20 -0700

Hi, Ananth,

> http://datatracker.ietf.org/doc/draft-anumita-tcpm-stronger-checksum/

I was wondering why this didn't just use the alternate checksum option (they
talk about it, but it's not clear why they don't just assume that path).

> set of checksum algorithms (of course the default stays what it is today

The question is whether we need a "generalized" such option, or whether the
current alternate checksum is basically sufficient, given a table of appropriate
algorithms and algorithm IDs. There are already 253 available ID values left ;-)

Joe

---

From: Lars Eggert <[email-masked]>
Date: Wed, 9 Jun 2010 21:27:46 +0300

Hi,

> security concern like say T/TCP.

true. But nobody has bothered to ship it in twenty years, AFAIK.

> I thought only superseded or defective RFCs can be declared historic?

See Section 4.2.4 of RFC2026: 

   A specification that has been superseded by a more recent
   specification or is for any other reason considered to be obsolete is
   assigned to the "Historic" level.

RFC4614 has classified this extension as Historic for "lack of interest" in 2006. This ID just nails the coffin shut.

> I mean
> example Interplanetary TCP.

Sure, but it hasn't been in use in twenty years, and the Interplanetary TCP is also not immediately around the corner.

> Maybe some military sites already employ RFC 1145.

If you know of deployments, I'm all ears. But even if we do declare it Historic, that does *not* mean that folks that are running it shouldn't run it anymore. The code points, for example, do remain assigned.

Lars

---

From: Lars Eggert <[email-masked]>
Date: Wed, 9 Jun 2010 21:30:24 +0300

Hi,

On 2010-6-9, at 21:07, Anantha Ramaiah (ananth) wrote:
> option.

I've skimmed through this draft when it first came out. I may be missing something, but why isn't TLS the right solution here? Sure, it may be overkill, but it's readily available.

Lars

---

From: <[email-masked]>
Date: Wed, 9 Jun 2010 20:15:09 +0100

> example Interplanetary TCP.

Unlikely.

TCP is usable (albeit slow) up until 1.5 light seconds, which just about
encompasses the Moon. Beyond that, interactions of the path delay with
TCP timers degrade performance considerably.

Long-distance interplanetary communication is more likely to be scheduled
and continuous, carefully managed, rather than just throwing a bunch of
competing flows down a pipe and out a dish and trusting TCP endpoints to
do anything useful with the bandwidth their algorithms prevent them from
using effectively. (The old 'loss due to channel corruption is not loss
due to congestion, so don't back off sending' problem.) Long-distance
interplanetary communication may use IP, but it won't use TCP.

Some details in
http://personal.ee.surrey.ac.uk/Personal/L.Wood/publications/index.html#protocol-radius
Lloyd Wood, Cathryn Peoples, Gerard Parr, Bryan Scotney, Adrian Moore,
'TCP's protocol radius: the distance where timers prevent communication,'
peer-reviewed conference paper, International Workshop on Space and
Satellite Communications (IWSSC '07), Salzburg, Austria, September 2007.

In any case, the TCP/UDP checksum often acts as a final demux check at
the endpoint thanks to the pseudo-header coverage; lower-layer frame
checksums detect transmission errors, while higher-layer
checksums or digests across e.g. files detect errors after reassembly
on final delivery.

> Maybe some military sites already employ RFC 1145.

Unlikely.

SCPS-TP (a 'restandardising' of TCP by other bodies aimed at the US
Department of Defense and others way back when) has found a niche
in PEP acceleration for satellite in US military networks - and that
only has the TCP checksum. (A rare example of stuff being left out in
restandardising, rather than being added in.)

If you want TCP behaviour but with a stronger checksum, use SCTP.
See RFC4960. (Won't help with large jumbo SCTP frames, though;
longer lengths need stronger checks, and CRC32c weakens after
about 14Kbytes of payload.)

Lloyd Wood
[email-masked]
http://sat-net.com/L.Wood

---

From: "Duke, Martin" <[email-masked]>
Date: Wed, 9 Jun 2010 12:25:38 -0700

Long overdue!

Is the intent to eventually free up those TCP option numbers for future use? 

> Behalf Of Lars Eggert
> Sent: Wednesday, June 09, 2010 10:28 AM
> To: [email-masked] Extensions
> Subject: [tcpm] draft-eggert-tcpm-historicize-00
> 
> > Title:		 Moving the Undeployed TCP Extensions 
> RFC1072, RFC1106, RFC1110, RFC1145, RFC1146, RFC1263, 
> RFC1379, RFC1644 and RFC1693 to Historic Status

---

From: Joe Touch <[email-masked]>
Date: Wed, 09 Jun 2010 12:27:24 -0700

Lars Eggert wrote:
> I've skimmed through this draft when it first came out. I may be missing
> something, but why isn't TLS the right solution here? Sure, it may be overkill,
> but it's readily available.

Hi, Lars,

I don't know if they say it in detail, but:

TLS doesn't protect TCP against errors which result in bad segments not being
retransmitted at the TCP layer; TLS secures, but does not retransmit lost info
(it's not a 'reliability' layer). Further, TLS would interpret a bad MAC as an
attack and would drop the connection, AFAICT (RFC 5246, see "bad_record_mac").
With large frames, TCP's checksum would allow false positives (bad segments
would get sent to TLS), and TLS would fail.

Joe

---

From: Hagen Paul Pfeifer <[email-masked]>
Date: Wed, 9 Jun 2010 22:00:53 +0200

>> example Interplanetary TCP.

I read exactly the same number of papers where people analysed TCP and come to
the conclusion that TCP is suitable at general but timers must be adjusted to
meet the requirements, ok this statement is a little bit exaggerated, but I
cannot resist to post it. ;-) Anyway, I don't want to start a debate if TCP
is suitable for interplanetary communication. Be creative and think about
another environments where TCP may be adequate but the user simple require a
stronger checksum. My second example are therefore, attention: Sensor
Networks. ;-)

Lloyd, thank you for the in-deep elucidations!

My point was and is why to move a itself not defective nor overhauled RFC to
historic. But as Lars already pointed out that this does not affect already
existing implementations I am fine with it. I am general fine with Lars
postings, so consider it as a question, not a objection. ;-)

Best regards, Hagen

---

From: <[email-masked]>
Date: Wed, 9 Jun 2010 21:13:34 +0100

On 9 Jun 2010, at 21:00, Hagen Paul Pfeifer wrote:

> meet the requirements

I've read such papers. They tend not to discuss the initial SYN/ACK handshake
and the timer related to that (probably because their simulation tools default
to not simulating SYN/ACK), or consider the implications of TCP slow start with
long propagation delays.

> , ok this statement is a little bit exaggerated, but I

the sensor networks I'm familiar with use IP, but don't use TCP, for
many of the same underlying reasons.
http://sat-net.com/L.Wood/dtn/saratoga

Lloyd Wood
[email-masked]

---

From: Hagen Paul Pfeifer <[email-masked]>
Date: Wed, 9 Jun 2010 22:33:15 +0200

>to not simulating SYN/ACK), or consider the implications of TCP slow start with

It is a little bit off-topic, but can you comment on the actual problems of
the initial SYN/ACK handshake and the timer interplay? Linux for example use
the same RTO timer for the initial handshake and the ongoing connection. If
you tune the RTO timer you will also tune it for the initial three way
handshake (this statement is not 100% sure, I hide some petite differences,
but the effect is insignificant). Why differs the handshake so much in your
eyes? And yes, don't trust any simulation models that you have fully
developed by your own. ;-)

>http://sat-net.com/L.Wood/dtn/saratoga

Yes, the characteristics and problems are nearly the same. The papers I read
("Making TCP/IP Viable for Wireless Sensor Networks", "Hop-by-Hop TCP for
Sensor Networks", ...) are pure academic papers and I personally saw no sensor
network TCP implementation in the wild.

Hagen

---

From: Alejandro Acosta <[email-masked]>
Date: Wed, 9 Jun 2010 16:51:33 -0430

+1

---

From: "Anantha Ramaiah (ananth)" <[email-masked]>
Date: Wed, 9 Jun 2010 15:59:01 -0700

> 
> The question is whether we need a "generalized" such option, 
> or whether the current alternate checksum is basically 
> sufficient, given a table of appropriate algorithms and 
> algorithm IDs. There are already 253 available ID values left ;-)

I agree, I was just stating in the context of the current proposal (Lars
draft). If what we have already accommadates this situation, then we are
good.

-Anantha

---

From: "Scheffenegger, Richard" <[email-masked]>
Date: Thu, 10 Jun 2010 00:53:03 +0100

To further this discussion:

I believe the suggestion using Alternate Checksum Option has the highest
merits:

O) no new tcp option number would be needed
O) only an additional checksum option type would need to be defined (and
there are still plenty left; I found no evidence so far, that any other
value than 0 and 1 were ever used - scanning though the I-D archives).

To make this proposal compatible with existing middleboxes, which might
not understand the option, but choose to simply forward it, my
suggestion would be to *NOT* include the TCP pseudo-header in that
alternate checksum, but *only* cover the data section. This would make
it also possible to traverse NAT/PAT gateways, which are agnostic to
this option.

Furthermore, as Koopman has demonstrated, the Hamming distance is a
function of data bits covered - the fewer bits covered, the higher the
HD. Also, As TCP CRC-32 can detect *every* corruption affecting an
uneven number of bits, yet another CRC-32 could be choosen that works
especially well only for even bit corruptions...

The combination of CRC-32 + "CRC-32E" might have even better compound
properties than CRC-32C.

However, the drawback would be to do two calculations (one for the
standard TCP CRC-32, and one for CRC-32C covering only the data
portion).

Also, to stay with Alternate Checksum semantics, if that option is
negotiated once, it should be kept for the remainder of the session -
even if PMTUD / BH decide to start sending only small (MTU<=1500)
packets at some point.

Further, I have spent some time looking for research on the
effectiveness of SACK - as this option would reduce the typical number
of SACK fields from a maximum of 3 down to 2. But from what I learned,
it seems that the number of SACK fields in an ACK have the property of
diminishing returns. You gain a lot from the 1st field; somewhat from
the 2nd, a bit from the 3rd, and having a 4th is surplus :). Besides, if
that option would only be valid for data-carrying segments, it could be
omitted if no data is to be carried - but still kept in "enabled" mode
instead of disabling.

Other than that, only a few nit-picks in wording and definitions (can be
addressed in a later version).

Richard Scheffenegger

> From: Joe Touch [mailto:[email-masked]] 
> Sent: Mittwoch, 9. Juni 2010 21:27
> To: Lars Eggert
> Cc: [email-masked]; Anantha Ramaiah (ananth)
> Subject: Re: [tcpm] draft-anumita-tcpm-stronger-checksum
> 
> 
> 
> Lars Eggert wrote:
> > Hi,
> > 
> > I've skimmed through this draft when it first came out. I may be 
> > missing something, but why isn't TLS the right solution 
> here? Sure, it 
> > may be overkill, but it's readily available.
> 
> Hi, Lars,
> 
> TLS doesn't protect TCP against errors which result in bad 
> segments not being retransmitted at the TCP layer; TLS 
> secures, but does not retransmit lost info (it's not a 
> 'reliability' layer). Further, TLS would interpret a bad MAC 
> as an attack and would drop the connection, AFAICT (RFC 5246, 
> see "bad_record_mac").
> With large frames, TCP's checksum would allow false positives 
> (bad segments would get sent to TLS), and TLS would fail.
> 
> Joe
> 
> 
>

---

From: Joe Touch <[email-masked]>
Date: Wed, 09 Jun 2010 17:45:38 -0700

Some notes below...

> it also possible to traverse NAT/PAT gateways, which are agnostic to

Middleboxes will be a problem no matter what you do.

Some will drop the segment simply because it has an option they don't understand.

Some will drop the option, which will result in drops at the receiver.

Many (most) will try to validate the TCP checksum, which is zero or contains
part of the alternate checksum when the alternate checksum is present, so
they'll drop the segment in that case.

As a result, it's not particularly useful to tailor this option to work through
middleboxes.

Further, RFC 1146 defines the option to work over the same fields as the TCP
checksum; I don't think it would be appropriate to use that option with merely a
different algorithm and redefine the bits covered.

Finally, if the TCP header isn't protected, it's no longer a TCP checksum - it's
a data checksum, at which point TLS is probably more appropriate.

I don't think the other suggestions (two checksums, issues of how many bits are
covered, etc.) are important. If the above doesn't work, the rest is moot anyway.

Joe

---

From: <[email-masked]>
Date: Thu, 10 Jun 2010 07:45:09 +0100

On 10 Jun 2010, at 00:53, Scheffenegger, Richard wrote:
> the 2nd, a bit from the 3rd, and having a 4th is surplus :).

That's probably because TCP's dupack threshold is three, after which
fast recovery is invoked.

Lloyd Wood
[email-masked]

---

From: <[email-masked]>
Date: Thu, 10 Jun 2010 10:39:54 +0100

See section IIc of our protocol radius paper.

-----Original Message-----
From: Hagen Paul Pfeifer [mailto:[email-masked]] 
Sent: 09 June 2010 21:33
To: Wood L Dr (Electronic Eng)
Cc: [email-masked]; [email-masked]
Subject: Re: [tcpm] draft-eggert-tcpm-historicize-00
Importance: High

* [email-masked] | 2010-06-09 21:13:34 [+0100]:

>I've read such papers. They tend not to discuss the initial SYN/ACK 
>handshake and the timer related to that (probably because their 
>simulation tools default to not simulating SYN/ACK), or consider the 
>implications of TCP slow start with long propagation delays.

It is a little bit off-topic, but can you comment on the actual problems of the initial SYN/ACK handshake and the timer interplay? Linux for example use the same RTO timer for the initial handshake and the ongoing connection. If you tune the RTO timer you will also tune it for the initial three way handshake (this statement is not 100% sure, I hide some petite differences, but the effect is insignificant). Why differs the handshake so much in your eyes? And yes, don't trust any simulation models that you have fully developed by your own. ;-)

---

From: "Scheffenegger, Richard" <[email-masked]>
Date: Thu, 10 Jun 2010 10:39:42 +0100

My understanding was, that it has more to do with the reliability of
your back channel (ACK/SACK dropped on their way to the receiver).

But SACK is not required to have "perfect" state shared between receiver
and sender; if multiple consecutive SACKs are dropped, and due to the
lower number of SACK fields some of that info never comes to the sender,
it might unnecessarily retransmit segments, which the receiver did in
fact already receive properly.

Just an edge issue, really, causing behaviour more like Reno (non-SACK)
retransmissions. But even having just one SACK field should already
serve to conserve much bandwidth (and responsiveness, as fewer RTTs are
necessary to re-send all missing data) over NewReno.

Richard Scheffenegger

> From: [email-masked] [mailto:[email-masked]] 
> Sent: Donnerstag, 10. Juni 2010 08:45
> To: Scheffenegger, Richard
> Cc: [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]; [email-masked]
> That's probably because TCP's dupack threshold is three, 
> after which fast recovery is invoked.
> 
> Lloyd Wood
> [email-masked]

---

From: "Scheffenegger, Richard" <[email-masked]>
Date: Thu, 10 Jun 2010 10:52:27 +0100

Hi Joe,

I think you mentioned that a checksum violation in TLS will cause the
connection to be aborted - rather than the corrupted packet to be
resent...

If keeping the standard TCP CRC intact (and covering TCP header & data)
and having an RFC1146 alternate checksum that works differently than
defined therein, perhaps it would be better to make it a new TCP option
then.

During handshake, the CRC-32C capable sender would need to do the proper
think (retry one or two times with all options, and then retry with the
minimum options); For agnostic middleboxes (and NAT/PAT routers
currently deployed), not covering the pseudo-header seems to me to be
the only option, to make this feature work with existing gear... 

Again, if the group feels that this is better not called "Alternative
Checksum" (re-using preexisting TCP options), but rather "TCP Stronger
Data Checksum", that's fine :).

The key is to keep the TCP state and retransmission behaviour intact, as
re-negotiating a new, TLS-protected TCP stream after corruption might
not be good enough these days (too high latency impact). 

As there exist HW that implements SCTP checksum offloading (as well as
segmentation) nowadays, new appliactions could probably make use of
that. However, applications would have to revert back to TCP (with small
segments), if the other side wouldn't support SCTP.

Richard Scheffenegger

> Sent: Donnerstag, 10. Juni 2010 02:46
> Cc: Lars Eggert; [email-masked]; Anantha Ramaiah (ananth)
> > O) only an additional checksum option type would need to be defined 
> > (and there are still plenty left; I found no evidence so 
> far, that any 
> > other value than 0 and 1 were ever used - scanning though 
> the I-D archives).
> > 
> > To make this proposal compatible with existing middleboxes, which 
> > might not understand the option, but choose to simply 
> forward it, my 
> Many (most) will try to validate the TCP checksum, which is 
> zero or contains part of the alternate checksum when the 
> alternate checksum is present, so they'll drop the segment in 
> that case.
> 
> As a result, it's not particularly useful to tailor this 
> option to work through middleboxes.
> 
> Further, RFC 1146 defines the option to work over the same 
> fields as the TCP checksum; I don't think it would be 
> appropriate to use that option with merely a different 
> algorithm and redefine the bits covered.
> 
> Finally, if the TCP header isn't protected, it's no longer a 
> TCP checksum - it's a data checksum, at which point TLS is 
> probably more appropriate.
> 
> I don't think the other suggestions (two checksums, issues of 
> how many bits are covered, etc.) are important. If the above 
> doesn't work, the rest is moot anyway.
> 
> Joe
> 
>

---

From: Joe Touch <[email-masked]>
Date: Thu, 10 Jun 2010 06:53:36 -0700

Hi, Richard,

> connection to be aborted - rather than the corrupted packet to be

Yes - TLS operates at the application layer, not in conjunction with TCP.

> defined therein, perhaps it would be better to make it a new TCP option

Defined therein where? The alternate checksum isn't TLS; TLS is an
application-layer security protocol.

> the only option, to make this feature work with existing gear... 

RFC1146 defines a handshake behavior, during which only a short label is
exchanged and confirmed, and the conventional TCP checksum is used. This is more
appropriate for TCP; options in the SYN should not render the rest of the SYN
unintelligible to parties that don't support the option.

As to retry with or without options, that is not typically defined at the level
of a TCP option. That too is application behavior - i.e., to try to open a TCP
connection with certain parameters, and to try a different attempt if the first
fails. Having an option redefine core TCP protocol behavior (such as timeouts,
retries, etc.) seems more than just an option. Options should extend, not
redefine, that core behavior.

...
> segments), if the other side wouldn't support SCTP.

Yes. But that's what you've described above when the TCP handshake fails - i.e.,
that's no different. It's worth thinking further about that, as a result.

Joe

---

From: "Biswas, Anumita" <[email-masked]>
Date: Thu, 10 Jun 2010 11:31:30 -0700

> Sent: Wednesday, June 09, 2010 5:46 PM
> > other value than 0 and 1 were ever used - scanning though the I-D 
> > archives).
> > 
If middleboxes are not RFC compliant, then yes.

> Some will drop the segment simply because it has an option 
I guess our goal is not to solve the problem for workaround middleboxes
that do not follow RFC 1122 interoperability mandate in 4.2.2.5. 

I am more worried about the bigger problem of losing data integrity for
packet MTUs greater than 1500. Today we are storing peta bytes of data
in a single storage bin. Imagine copying peta bytes of data over the
network to that bin. The likelihood of bit errors going undetected just
increased probably by many magnitudes. 

The other day I was listening to someone from probably the most largest
software company talk about copying data over the network and seeing bit
corruptions going unnoticed. Bit corruptions will go unnoticed when you
send a large amount of data on the wire. This Internet Draft is just a
small beginning in improving the rate of error detection. 

Also, the cost of costly cryptographic operations have to be weighed
against simpler CRC checksum algorithms that are already offloaded to
modern NICs for SCTP. If we standardize the CRC-32C for TCP, then NIC
vendors can offload them to newer versions of NICs and we get rid of the
in-software computations.

> algorithm and redefine the bits covered.
Agreed. 
 
> probably more appropriate.
Based on comments I received from Richard Scheffenegger offline, we have
to continue to put in the summation based 16-bit checksum in the TCP
header so that we don't break the existing standard of what the TCP
checksum is expected to be. 

However, I am a bit skeptical about the comment that the 16-bit
summation based checksum is adequate to pass off as protecting the TCP
header. In theory it does protect the TCP header, but in practice, when
the checksum spans MTU sizes larger than 1500 bytes, it is not going to
catch the random bit flip in the sequence number, ack number etc.
Instead, the draft proposes a stronger tcp checksum  

The draft also only debates over whether the psuedoheader must be added
to the TCP checksum. But it states that the TCP header + Data must be
included in the CRC 32C checksum.

Again, these are details that can be worked out if the WG thinks that
this draft is worth taking up by the WG for further consideration.

---

From: "Biswas, Anumita" <[email-masked]>
Date: Thu, 10 Jun 2010 11:35:20 -0700

> Sent: Thursday, June 10, 2010 6:54 AM
> > If keeping the standard TCP CRC intact (and covering TCP header & 
> > data) and having an RFC1146 alternate checksum that works 
> differently 
> > than defined therein, perhaps it would be better to make it 
> a new TCP 
> > option then.
> 
> Defined therein where? 

Section 3 - "Negotiating the use of CRC 32C"

The alternate checksum isn't TLS; TLS 
> is an application-layer security protocol.
> 
> > During handshake, the CRC-32C capable sender would need to do the 
> > proper think (retry one or two times with all options, and 
> then retry 
> > with the minimum options); For agnostic middleboxes (and NAT/PAT 
> > routers currently deployed), not covering the pseudo-header 
> seems to 
> > me to be the only option, to make this feature work with existing 
> > gear...
> 
> RFC1146 defines a handshake behavior, during which only a 
> short label is exchanged and confirmed, and the conventional 
> TCP checksum is used. This is more appropriate for TCP; 
> options in the SYN should not render the rest of the SYN 
> As to retry with or without options, that is not typically 
> defined at the level of a TCP option. That too is application 
> behavior - i.e., to try to open a TCP connection with certain 
> parameters, and to try a different attempt if the first 
> fails. Having an option redefine core TCP protocol behavior 
> (such as timeouts, retries, etc.) seems more than just an 
> option. Options should extend, not redefine, that core behavior.
> 
> ...
> > that. However, applications would have to revert back to TCP (with 
> > small segments), if the other side wouldn't support SCTP.
> 
> Yes. But that's what you've described above when the TCP 
> handshake fails - i.e., that's no different. It's worth 
> thinking further about that, as a result.
> 
> Joe
> 
>

---

From: Joe Touch <[email-masked]>
Date: Thu, 10 Jun 2010 14:15:16 -0700

Hi, Anumita,

> If middleboxes are not RFC compliant, then yes.

I don't know what that means, FWIW. NATs by their very definition violate RFC
1122 and 1812, but we don't need to rehash that here. My view is that it's not
sensical to talk about "laws for the lawless", and AFAICT most middleboxes
*want* to violate the standards.

> that do not follow RFC 1122 interoperability mandate in 4.2.2.5. 

This is an issue more with, e.g., RFC 1812. The middlebox isn't an endpoint, so
it has no business caring about or modifying such options. RFC 1122 is only
about endpoints.

However, my point is that this is the common behavior of many middleboxes,
AFAICT. Ignoring that is saying "we don't expect it to work at all anyway."

> increased probably by many magnitudes. 

There are two separate issues:

1- integrity of the data

2- coordinating that integrity with TCP

TLS gets you #1, if you deal with retries at the application layer (you need to
write your own "file transfer over TLS" protocol.

#2 - which is better, AFAICT, since TCP will do the retries - can be achieved
various ways with existing protocols using any other IP encapsulation that
provides similar strength, e.g., using IPsec or SEAL E2E. That would ensure bad
segments would be dropped before TCP processing, and then TCP's retransmission
would fix the hole.

Another trick is to build a wrapper on some other system, e.g., using Java and
FTP. FTP the files, use Java to do a local stronger whole-file check, and resend
if the check fails.

So although I appreciate the problem, it's not at all clear TCP is the
appropriate or easiest place to fix it, IMO.

...
> checksum is expected to be. 

You can't do this without redefining RFC 1146 - i.e., that's not RFC 1145
anymore. That may be OK, but that's a limit of this approach.

> Instead, the draft proposes a stronger tcp checksum  

A single random bit flip will be caught by the TCP checksum; it's certain
patterns of multiple flips that won't.

> included in the CRC 32C checksum.

FWIW, the TCP header *includes* the IP pseudoheader. It's an artifact of how TCP
and IP were split that the info isn't copied into the TCP header. The only way
around that is to have some other crypto state shared at the endpoints that
identifies the connection - e.g., this is why I suggested we could drop some of
the pseudoheader for TCP-AO support over NATs (draft-touch-tcp-ao-nat).

> this draft is worth taking up by the WG for further consideration.

I think what you're hearing (the WG chairs can correct me if not) is that some
of these details may need working out in order to make that decision.

Joe

---

From: Joe Touch <[email-masked]>
Date: Thu, 10 Jun 2010 14:19:46 -0700

Biswas, Anumita wrote:
...
> Section 3 - "Negotiating the use of CRC 32C"

There are two differences:

a) different processing rules
	computed over different portions of the segment
	and
	different rules for what happens to the original TCP checksum area
	and
	different rules for what to do when the option fails on SYNs

These are hard to fix without rewriting RFC-1146, which is feasible only if
there is a real need.

b) different algorithm
	this is easily fixed without modifying RFC-1146, by
	defining a new algorithm

	this assumes only the algorithm changes, though

Joe

---

From: Lars Eggert <[email-masked]>
Date: Mon, 14 Jun 2010 16:20:19 +0300

Hi,

> Quite possibly the most boring RFC ever. But at least it's short. Comments welcome.

I wanted to clarify that I'm not personally against (or for) any of the TCP extensions mentioned in the draft, especially the alternate checksum option. The criteria for including these RFCs here is that we had consensus to tag them as Historic when we published RFC4614. We can certainly change our mind about any of these extensions.

Lars

> Lars<smime.p7s><ATT00001..txt>

---

From: Hagen Paul Pfeifer <[email-masked]>
Date: Mon, 14 Jun 2010 22:36:37 +0200

* Lars Eggert | 2010-06-14 16:20:19 [+0300]:

>I wanted to clarify that I'm not personally against (or for) any of the TCP
>extensions mentioned in the draft, especially the alternate checksum option.
>The criteria for including these RFCs here is that we had consensus to tag
>them as Historic when we published RFC4614. We can certainly change our mind
>about any of these extensions.

I am fine with that document, IMHO it is all said.

Hagen

---

From: David Ros <[email-masked]>
Date: Tue, 15 Jun 2010 14:08:36 +0200

Hi,

FWIW, the Contiki OS for sensors does have a TCP implementation (albeit with a lot of limitations, it seems). I don't know if it's used by anybody :-), but it's already there in the code.

Regards,

David.

=================================================================
David ROS
http://www.rennes.enst-bretagne.fr/~dros/

I love deadlines. I like the whooshing sound they make as they fly by. -- Douglas Adams

---

From: Lars Eggert <[email-masked]>
Date: Thu, 24 Jun 2010 09:40:51 +0300

Hi,

since we're not meeting in Maastricht, I might as well ask this now: Do folks believe we should go forward with making these extensions historic? In that case, I'll ask the chairs to do a consensus poll on adopting this document as a WG work item.

Lars

---

From: Alexander Zimmermann <[email-masked]>
Date: Thu, 24 Jun 2010 09:27:06 +0200

Am 24.06.2010 um 08:40 schrieb Lars Eggert:

> Hi,
> 
> since we're not meeting in Maastricht,

:-(

> I might as well ask this now: Do folks believe we should go forward with making these extensions historic?

Ja/yes/oui

> In that case, I'll ask the chairs to do a consensus poll on adopting this document as a WG work item.
> 
> Lars

Alex

---

From: Yuchung Cheng <[email-masked]>
Date: Thu, 24 Jun 2010 10:04:21 -0700

On Wed, Jun 23, 2010 at 11:40 PM, Lars Eggert <[email-masked]> wrote:

> Hi,
>
> since we're not meeting in Maastricht, I might as well ask this now: Do
> folks believe we should go forward with making these extensions historic? In
> that case, I'll ask the chairs to do a consensus poll on adopting this
> document as a WG work item.
>
+1 yes vote.

---

From: "Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]" <[email-masked]>
Date: Thu, 24 Jun 2010 12:33:50 -0500

>From: [email-masked] [mailto:[email-masked]] On Behalf Of
>Lars Eggert
>Sent: Thursday, June 24, 2010 2:41 AM
>folks believe we should go forward with making these extensions
>historic? In that case, I'll ask the chairs to do a consensus poll on
>adopting this document as a WG work item.
>

Ok, consider the mail from Lars the opening of this consensus to adopt
poll. :)  In the next two weeks, if people could respond whether they:

1) Support this document for development towards publication as an
Informational RFC via the TCPM working group

2) Do not support the document as a TCPM work item.

3) Have other thoughts ...

--
Wes Eddy
MTI Systems

---

From: "Anantha Ramaiah (ananth)" <[email-masked]>
Date: Thu, 24 Jun 2010 11:17:19 -0700

> Behalf Of Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]
> Sent: Thursday, June 24, 2010 10:34 AM
> To: Lars Eggert; [email-masked] Extensions
> Ok, consider the mail from Lars the opening of this consensus 
> to adopt poll. :)  In the next two weeks, if people could 
> respond whether they:
> 
> 1) Support this document for development towards publication 
> as an Informational RFC via the TCPM working group
> 

I have already communicated earlier that the TCP alternate checksum
option needs to be removed from this list. Reason being it is still
being used and there are proposals out there that is trying to make use
of this option. Other than that point I am fine with this draft moving
forward.

-Anantha

---

From: Joe Touch <[email-masked]>
Date: Thu, 24 Jun 2010 11:47:27 -0700

> of this option. Other than that point I am fine with this draft moving

I agree with Anantha, except that I think the doc might have a short section
explaining *why* the alt checksum isn't in the list.

Joe

---

From: "Scheffenegger, Richard" <[email-masked]>
Date: Fri, 25 Jun 2010 12:30:54 +0100

I'd support that, based on the recent discussions that the alternate
checksum option is not a viable method for better payload protection
anyway :)

Richard Scheffenegger

> From: Lars Eggert [mailto:[email-masked]] 
> Sent: Donnerstag, 24. Juni 2010 08:41
> since we're not meeting in Maastricht, I might as well ask 
> this now: Do folks believe we should go forward with making 
> these extensions historic? In that case, I'll ask the chairs 
> to do a consensus poll on adopting this document as a WG work item.
> 
> Lars
>

---

From: "Scheffenegger, Richard" <[email-masked]>
Date: Fri, 25 Jun 2010 16:07:12 +0100

Anantha,

I think for purposes of documenting "legacy" implementations, the
RFC1146 would still be valid.

I will try to define the goal of that recent proposal again, at least as
far as I understand this, so that we are all on the same page here.

Our expirience has shown, that TCP often runs over links with much
higher error rates, than intended for the technology (ie. Design goal of
BER <= 1E-12 over Ethernet often has an actual BER >> 1E-12). If such
error-prone links are running at a high speed and with large segment
sizes (jumbo / giant frames), there exists the real problem that within
a short timeframe (weeks to months), TCP will deliver corrupted data, as
CRC-16 was not able to catch the error.

>From my point of view, I understood the recent discussions around
RFC1146 in such a way, that for the intended purpose, which is to
provide a stronger payload checksum (equivalent to SCTP levels), a new
option would be required rather than reusing the alternate checksum
option. The reasoning is that currently deployed gear, especially NAT /
PAT gateways - which have to re-calculate the TCP Checksum as the
Pseudo-Header is changed - might know about the originally defined
alternate checksum algorithms, but not the new ones.

Furthermore, RFC1146 specifically requires the Pseudo Header to be
included - which one wouldn't want to do if only payload CRC is
required.

Providing a Payload-only CRC (ie. as the first TCP option), would enable
the transparent forwarding of such a new option by NAT/PAT gateways
without any problems.

Of course, if RFC1146 could be extended to include algorithms which
actually "violate" some of the specs of it, but maintain using the same
TCP options with a new algorithm codepoint, that would be fine with me.

But this would probably ask for a new RFC obsoliting RFC1146 anyway (in
effect making it again historic :) ).

Does that make sense?

Thanks for your comments!

Richard

> From: Anantha Ramaiah (ananth) [mailto:[email-masked]] 
> Sent: Donnerstag, 24. Juni 2010 20:17
> To: Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]; Lars 
> Eggert; [email-masked]
> I have already communicated earlier that the TCP alternate 
> checksum option needs to be removed from this list. Reason 
> being it is still being used and there are proposals out 
> there that is trying to make use of this option. Other than 
> that point I am fine with this draft moving forward.
> 
> -Anantha

---

From: Joe Touch <[email-masked]>
Date: Fri, 25 Jun 2010 11:36:47 -0700

Richard,

> CRC-16 was not able to catch the error.

Just to confirm, is this a measured problem or a mathematical one? I.e., have
you seen this actually occur (i.e., TCP with invalid CRC-16 but valid checksum)
in the wild, in a lab, or have you never seen it but consider it important anyway?

> alternate checksum algorithms, but not the new ones.

NATs would recalculate the TCP checksum, which, for packets using alternate
checksums as per 1146, would remain valid. The NAT would destroy the alternate
checksum, though, since it is defined by 1146 over the pseudoheader and TCP
header, so any changes to IP addresses or ports would result in an incorrect
alternate checksum unless corrected by the NAT (which is, as you note, unlikely).

So no matter how you proceed, you're better off with RFC 1146's version of how
the existing checksum field is calculated. (your current proposal puts part of
the new checksum in the TCP header field, which the NAT would interpret as
invalid and drop). Which means you're calculating TWO checksums for every packet
- the current one (which the NAT will update), and the new (alternate) one
(which NATs won't/can't update).

Agreed.

> the transparent forwarding of such a new option by NAT/PAT gateways

TCP options are not ordered. Their processing may be suggested, when defining
how the option interacts with other options, e.g.

> TCP options with a new algorithm codepoint, that would be fine with me.

That would involve writing two docs (IMO):
	- one specifying a new algorithm you'd like to use
	- one specifying an alternate way to calculate the alt-cs value
	as a change to RFC1146

These are, in effect, two different issues.

> effect making it again historic :) ).

It doesn't need to obsolete 1146; it does need to explain how an implementer
knows the difference between just a new algorithm and a different way to compute
it (i.e., over different data bits). That might be by redefining the codes so
that some codes mean "skip the header" and others don't, etc. The group would
need to discuss this as a legacy issue.

An interesting question is why you care that the payload doesn't get
accidentally altered, but you don't care if the port or address does (and you
don't notice), though.

Joe

---

From: Fernando Gont <[email-masked]>
Date: Sat, 26 Jun 2010 04:17:53 -0300

> in the wild, in a lab, or have you never seen it but consider it important anyway?

IIRC, wasn't this sort of what the SIGCOMM (?) paper "when the checksum
and CRC disagree" (authored by J. Stone) was about?

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

---

From: <[email-masked]>
Date: Sat, 26 Jun 2010 09:50:01 +0100

Ethernet uses CRC-32, TCP's existing 16-bit checksum
isn't a CRC. So I'm a bit puzzled by the question.

The link CRC and TCP checksum can disagree. See

Stone, J., Greenwald, M., Hughes, J., and C. Partridge,
"Performance of checksums and CRCs over real data", IEEE
Transactions on Networks vol. 6 issue 5, pp. 529-543,
October 1998.

Stone, J. and C. Partridge, "When the CRC and TCP Checksum
Disagree", Proceedings of ACM SIGCOMM , September 2000.

---

From: Joe Touch <[email-masked]>
Date: Sat, 26 Jun 2010 11:09:19 -0700

> The link CRC and TCP checksum can disagree. See

*can*. The paper below did mathematical analyses, but didn't observe them either
in a lab or in the wild. I.e., that work didn't see places where it *did*. Thus
my question.

I'm not asking whether this is important to address, just what the current
motivation is. The work below suggests using application-layer checksums. That
seems prudent for large transfers, but I don't see a motivation for needing this
fixed at the TCP layer...

Joe

---

From: <[email-masked]>
Date: Sat, 26 Jun 2010 19:31:10 +0100

Joe,

can you at least read the cited papers before making claims about them?

>From the abstract of Stone's SIGCOMM paper:

Traces of Internet packets from the past two years show that between 1 packet in 1,100 and 1 packet in 32,000 fails the TCP checksum, even on links where link-level CRCs should catch all but 1 in 4 billion errors. 
[..]
Much of our time has been spent negotiating access to data.

s/*can*/*was observed to over two years in the wild*.

TCP is supposed to provide a *reliable* transfer to application writers. With jumbo frames and the one's complement checksum, that is no longer true... and application writers don't necessarily have control over frame sizes.

Needs fixing imo.

Lloyd Wood
[email-masked]

---

From: Joe Touch <[email-masked]>
Date: Sat, 26 Jun 2010 12:05:08 -0700

[email-masked] wrote:
> Traces of Internet packets from the past two years show that between 1 packet
> in 1,100 and 1 packet in 32,000 fails the TCP checksum, even on links where
> link-level CRCs should catch all but 1 in 4 billion errors.
> [..] Much of our time has been spent negotiating access to data.
> 

See Section 4.3.

End hosts that compute bad TCP checksums, or alter packets after the checksums
are validated aren't fixed by adding another checksum they can incorrectly
implement.

The only errors that appear to be happening due to paths were due to a faulty
router. Those errors were single bit errors, likely in memory of the router (as
per their observation, Sec 4.3.4). I.e., the authors believe the router was
accepting a valid CRC in, modifying the packet, and transmitting one with a
(different) valid CRC out. The end receiver thus saw a packet with a valid CRC
but would have seen an invalid TCP checksum.

Their methodology captured packets at the link layer, (Sec 3.1):

"For each complete packet, the software calculates
the checksum and if the checksum fails, the entire packet
is saved."

Later they note how they find out of the segment was faulty due to a
retransmission without the fault:

"If the IP datagram contains a TCP segment, the capture
program records what bytes were in the segment (on the as-
sumption that the sequence numbers are correct!) and then
looks for valid retransmissions of those bytes."

The do not seek, nor did they find in the wild, a single packet where the CRC
was valid and the TCP checksum was valid, but the packet had changed in
contents. That could have been attempted (perhaps with greater computational
power), but was not.

Joe

---

From: <[email-masked]>
Date: Sat, 26 Jun 2010 20:16:41 +0100

> contents.

Before going any further - did you really mean to write that?

Lloyd Wood
[email-masked]

---

From: Joe Touch <[email-masked]>
Date: Sat, 26 Jun 2010 12:16:50 -0700

>> in the wild, in a lab, or have you never seen it but consider it important anyway?

To clarify, what I'm seeking is:

a TCP segment that:
	has a valid TCP checksum
	actually has been received in the lab or wild
	would have an invalid CRC-16 as proposed in the ID

i.e., this is a case where the ethernet or other link checksum would have
succeeded on all the hops, and the TCP checksum succeeds, so an error would NOT
have been caught.

That's the only case where we need to consider replacing the TCP checksum.

So far, it appears that the only reported evidence (the 2000 Sigcomm paper)
looked only for real packets where the TCP checksum already failed.

The case where both the link and TCP checks fail is in Sec 4.4 (I had mistyped
that as 5 previously), and is only a mathematical analysis of probability.

Joe

---

From: Joe Touch <[email-masked]>
Date: Sat, 26 Jun 2010 12:25:41 -0700

> Before going any further - did you really mean to write that?

Yes. FWIW, the CRC I'm referring to above is the link CRC (CRC32 for Ethernet).

The only way a packet is accepted erroneously at a receiver, but would cause an
problem, would be:
	link check OK
	TCP (1s compl) checksum OK
	new checksum FAIL

I.e., the only reason a new TCP checksum would be useful is in this case. If
either of the link or existing TCP checks succeed, there's no new problem.

Please see draft-ietf-tcpm-anumita-tcp-stronger-checksum-00, e.g., in the
abstract, or Sec 1. In fact, the case they're considering is where real link
errors occur that are not detectable - not TCP/IP implementation errors or
router memory errors, as were the only ones seen in the wild in the Sigcomm paper.

Joe

---

From: "Biswas, Anumita" <[email-masked]>
Date: Sun, 27 Jun 2010 11:19:44 -0700

Hi Joe,

> Sent: Saturday, June 26, 2010 12:26 PM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]; Biswas, Anumita
> >> The do not seek, nor did they find in the wild, a single 
> packet where 
> >> the CRC was valid and the TCP checksum was valid, but the 
> packet had 
> >> changed in contents.
> > 
> The only way a packet is accepted erroneously at a receiver, 
> but would cause an problem, would be:
> 	link check OK
> I.e., the only reason a new TCP checksum would be useful is 
> in this case. If either of the link or existing TCP checks 
> succeed, there's no new problem.
> 
> Please see draft-ietf-tcpm-anumita-tcp-stronger-checksum-00, 
> e.g., in the abstract, or Sec 1. In fact, the case they're 
> considering is where real link errors occur that are not 
> detectable - not TCP/IP implementation errors or router 
> memory errors, as were the only ones seen in the wild in the 
> Sigcomm paper.
> 
Although the draft specifically calls out link errors, the draft by no
means does not discard other sources of errors as are mentioned in those
papers and are also referenced in the draft. I think the only reason the
link errors were called out is because we *know* that is possible to
have bad cables that can have higher BER than advertised. It is very
hard to "detect" "undetectable" errors in the wild (actually by
definition itself) and that is why it is worrisome to me. Its only
possible to have a measurement like "Probability of undetected errors"
rather than "X is the number of the undetected errors" in such cases.  

I have heard only anecdotal evidence of a very large company doing very
large copies of data (about a Tera Byte) across a local network and then
finding bit corruptions in the data received on the other end - clearly
the link CRC and the TCP 1s compl summation checksum failed to catch
those errors. 
In my own company, I have seen a case where a very large block (1460
bytes - a packet size) of data was replaced and gone undetected and we
could not root cause the problem - the problem just disappeared after
showing up for a few weeks - but in this case, it is possible that the
corruption occurred before the data was sent by TCP itself. 

So to me, to hinge whether we support a new TCP CRC based checksum or
not, on practical experience in the wild, is probably not a safe
approach. Ofcourse, if we had multiple proven examples of this in the
wild, we'd feel more motivated to do this. 

Also, I am more worried about packet sizes greater than 1500 bytes -
where the Ethernet CRC checksum becomes weaker. Typical ethernet MTUs
across the internet does not exceed 1500 bytes today - so right now, the
problem scope is limited to Data Centers and other such local LANs where
the end to end PMTU is greater than 1500 bytes.

Based on comments from Richard Scheffenegger on the issue of
middleboxes, I am planning to upload a new version of the draft that
only checksums the data portion. 

I also think TCP is *the* place for a stronger checksum, so that upper
layers do not have to reinvent checksumming after rediscovering the
weaknesses of the lower layer "reliable" checksums. It also allows for
easy offloading to NICs as the TCP 16 bit checksum is offloaded today so
that software gets rid of the computational overheads of a stronger
checksum. It is much harder, almost impossible for an application layer
checksum to be offloaded off to NICs. As NIC vendors, for obvious
reasons, prefer only to offload standards based computation, and only in
case where performance matters hugely are ready to offload work like TCP
segmentation offload and receive side coalescing. 

Thanks,
Anumita

---

From: Joe Touch <[email-masked]>
Date: Sun, 27 Jun 2010 11:51:16 -0700

Hi, Anumita,

Biswas, Anumita wrote:
...
> the link CRC and the TCP 1s compl summation checksum failed to catch

Well, that's the point. It's not so clear that the checks are what failed. It
could easily have been a bug in the implementation, or an error in the hardware
that corrupted data after it was received correctly. I.e., no matter how good
these checks, there are other ways in which data can be corrupted.

> corruption occurred before the data was sent by TCP itself. 

Yes, that's my concern.

> wild, we'd feel more motivated to do this. 

I don't follow this logic. We have no measured evidence of this ever occurring.
The evidence we have to date is that the end system software is more likely the
problem.

Everything so far points to the need for an application protocol check, i.e., a
final, total transfer checksum on each large transaction (i.e., the whole file).
That was one conclusion of the 2000 paper, FWIW.

> the end to end PMTU is greater than 1500 bytes.

That should be verifiable. Then again, if the CRC32 fails on jumboframes, why
would adding CRC16 at TCP help? other than the fact that it's a 'different' sum?
 Your argument suggests that such data centers need different *ethernet*
checksums, not different TCP ones. Then the data centers can leverage - and
reuse - that where necessary.

Joe

---

From: "Biswas, Anumita" <[email-masked]>
Date: Sun, 27 Jun 2010 12:22:24 -0700

> Sent: Sunday, June 27, 2010 11:51 AM
> To: Biswas, Anumita
> Cc: [email-masked]; [email-masked]; [email-masked]
> > I have heard only anecdotal evidence of a very large company doing 
> > very large copies of data (about a Tera Byte) across a 
> local network 
> > and then finding bit corruptions in the data received on 
> the other end 
> > - clearly the link CRC and the TCP 1s compl summation 
> checksum failed 
> > to catch those errors.
> 
> Well, that's the point. It's not so clear that the checks are 
> what failed. It could easily have been a bug in the 
> implementation, or an error in the hardware that corrupted 
> data after it was received correctly. I.e., no matter how 
> good these checks, there are other ways in which data can be 
> corrupted.
> 
> I don't follow this logic. We have no measured evidence of 
> this ever occurring. The evidence we have to date is that the 
> end system software is more likely the problem.
> 
> Everything so far points to the need for an application 
> protocol check, i.e., a final, total transfer checksum on 
> each large transaction (i.e., the whole file). That was one 
> conclusion of the 2000 paper, FWIW.
> 
I mentioned the advantage of being able to offload a TCP based checksum
to the NIC. If I were to extend your argument that end system software
is more likely the problem - a checksum over the whole file could also
be prone to error. 

I think we are only trying to deploy a "stronger" checksum - we are not
making claims that it will find all problems in end to end software -
and as such is not the strongest checksum.

> > across the internet does not exceed 1500 bytes today - so 
> right now, 
> > the problem scope is limited to Data Centers and other such 
> local LANs 
> > where the end to end PMTU is greater than 1500 bytes.
> 
> That should be verifiable. Then again, if the CRC32 fails on 
> jumboframes, why would adding CRC16 at TCP help? other than 
> the fact that it's a 'different' sum?  
The draft suggests using the Castagnoli 32-bit polynomial used in the
"CRC 32C" algorithm which generates a 32 bit checksum quantity. No
mention of CRC16.
The draft specifies using a different "space" in the TCP options area,
to transfer this checksum. It does not suggest using the 16-bit TCP
checksum space for this value. It does debate over what to do with the
16-bit summation checksum. Now, after many discussions, it is more clear
that we do need the 16-bit checksum as well to prevent middleboxes from
breaking. 

http://tools.ietf.org/html/draft-anumita-tcpm-stronger-checksum-00

Please read why the Castagnoli polynomial based CRC checksum is stronger
than the Ethernet CRC32 checksum carried by the Ethernet frame. 

Your argument suggests 
> that such data centers need different *ethernet* checksums, 
> not different TCP ones. Then the data centers can leverage - 
> and reuse - that where necessary.
The ideal way to do this would be to have Ethernet frames include the
CRC32C checksum instead of the CRC32 checksum. But changing the Ethernet
standard across the board is impossible due to backward compatibility
issues. But TCP options provides a much easier path to introducing a
stronger checksum as it does not break backward compatibility and can be
offloaded to the NIC as well. 

Data Centers are one place where Jumbo frames are deployed - but there
could be others. So I don't understand what you mean by "data centers
can leverage and reuse that where necessary".

---

From: Joe Touch <[email-masked]>
Date: Sun, 27 Jun 2010 14:00:02 -0700

Hi, Animita,

> is more likely the problem - a checksum over the whole file could also

That's true too, but it would catch errors at all other places in the stack,
e.g., even errors that would not be caught by errors actually seen (e.g., in the
2000 paper).

> and as such is not the strongest checksum.

My point above is that 'stronger' won't fix the flaws actually seen thus far.

...
> than the Ethernet CRC32 checksum carried by the Ethernet frame. 

I have no question about that. This is a great argument to raise to the Ethernet
community.

> issues. 

That's no more true for ethernet than for TCP.

> But TCP options provides a much easier path to introducing a

That may all be true, but as I've noted repeatedly, the errors *actually seen*
thus far would not be solved by a new, stronger TCP sum. Only an application sum
would have caught those errors.

> can leverage and reuse that where necessary".

I'm suggesting that this is a jumboframe problem. Fix it in the implementation
of jumboframes, and all users of jumboframes will eventually benefit - i.e., fix
this at the Ethernet vendor level, and it can be used in all data centers that
use jumboframes.

Note that those vendors *do* deploy new capabilities - e.g., see the IETF TRILL WG.

Joe

---

From: <[email-masked]>
Date: Mon, 28 Jun 2010 09:35:37 +0100

> either of the link or existing TCP checks succeed, there's no new problem.

An example of that scenario is an echo server:
http://en.wikipedia.org/wiki/Echo_protocol
http://www.faqs.org/rfcs/rfc862.html
http://www.faqs.org/rfcs/rfc2075.html

which swaps source and destination addresses. These are covered by the pseudo-header
check; the 1's complement checksum is oblivious to the byte swapping, and the
echoed packet is still considered valid, even though it has been altered.
A stronger TCP checksum would detect this modification, and have to be recomputed.
much as payload checksums are recomputed through NAT boxes.

Lloyd Wood
[email-masked]

---

From: Joe Touch <[email-masked]>
Date: Mon, 28 Jun 2010 09:28:54 -0700

> http://www.faqs.org/rfcs/rfc862.html

This RFC defines TCP and UDP echo services. Both loop data back to the source,
but at "layer 7" to the transport protocols. Both create new transport packets
to send data back - in fact, the TCP variant might have different segment
boundaries, e.g., if the return path MTU is different. Both thus compute a new
transport checksum, so errors in either would not be detected by a stronger
transport checksum per se.

> check; 
...
> A stronger TCP checksum would detect this modification, and have to be
> recomputed. much as payload checksums are recomputed through NAT boxes.

The pseudoheader is not covered by the current proposal, specifically to support
NAT traversal. Any device that recomputes the checksum on traversal (explicitly,
or because that calculation is buried in the NIC and done automatically) will
defeat the ability of the checksum to detect errors inside that node.

The only L7-L7 protection would be a full transfer checksum, which is not being
proposed.

Joe

---

From: rick jones <[email-masked]>
Date: Mon, 28 Jun 2010 18:52:48 -0700

> this at the Ethernet vendor level, and it can be used in all data  

JumboFrames (9000 bytes or better) in "Ethernet" appeared back in the  
mid to late 1990's with the Alteon AceNIC right? (at least that is my  
first conscious memory of them) They are still outside the IEEE  
framework.  Frame sizes going extra-IEEE is one thing, I'm rather more  
skeptical of CRC's being able to go extra-IEEE.  Given there is  
perhaps a snowball's chance of the IEEE blessing JumboFrames, I  
suspect there is less than a snowball's chance of them blessing  
another CRC to address anything presented as "a jumboframe problem."   
So, to push a fix down to the link-layer is to effectively assert it  
is something that need never be fixed.

rick jones
http://homepage.mac.com/perfgeek

---

From: Joe Touch <[email-masked]>
Date: Mon, 28 Jun 2010 19:46:32 -0700

rick jones wrote:
> skeptical of CRC's being able to go extra-IEEE.  Given there is perhaps
> a snowball's chance of the IEEE blessing JumboFrames, I suspect there is
> less than a snowball's chance of them blessing another CRC to address
> anything presented as "a jumboframe problem."  So, to push a fix down to
> the link-layer is to effectively assert it is something that need never
> be fixed.

I'm claiming there are only two issues that have been raised:

	- a real, measured problem with intermediate devices
		which won't be fixed with a link or transport solution
		but could be addressed with an L7 transfer sum

	- a hypothetical link problem for some links (i.e., jumboframes)
		which ought to be fixed by the vendors who support jumboframes

		Note that I didn't say "IEEE" here. The same vendors that have
		a de-facto standard for jumboframes are the ones who can fix
		their mess with a jumboframe CRC ;-)

Neither one warrants a TCP solution, IMO.

Joe

---

From: rick jones <[email-masked]>
Date: Tue, 29 Jun 2010 08:09:43 -0700

> 		their mess with a jumboframe CRC ;-)

I think that is a place where one should be careful what one wishes  
for. If the NIC vendors become too accustomed to going off the  
standard body reservation at the link-layer, chances are they and the  
other vendor types with which they interact won't make much of  
distinction for transport.

rick jones

---

From: Joe Touch <[email-masked]>
Date: Tue, 29 Jun 2010 09:47:58 -0700

rick jones wrote:
> I think that is a place where one should be careful what one wishes for.
> If the NIC vendors become too accustomed to going off the standard body
> reservation at the link-layer, chances are they and the other vendor
> types with which they interact won't make much of distinction for
> transport.

They already are going "off the reservation" with jumboframes. Those are either
useless (as you imply above, e.g., because of lack of interoperability), or
important to support properly.

If jumboframes aren't used, AFAICT there's no problem to solve. If they are
used, the problem lies in the jumboframes themselves using an insufficient CRC.

Joe

---

From: Lars Eggert <[email-masked]>
Date: Tue, 29 Jun 2010 18:15:18 +0100

Hi,

> effect making it again historic :) ).

yes, that was my thinking too. I don't think we can fix RFC1146 in a way that is backwards compatible, so we might as well make it historic and then decide if we need a new piece of work in this space.

Lars