Hi Scott, wouldn't such accelerators in effect implement a full TCP stack (on the tcp end)? I doubt that they "tunnel" TCP encapsulated data (or any arbitraty tcp / ip header bits) from site to site, but terminate the TCP session locally, unpack the data, send it via their proprietary transport protocol over, and then set up a different tcp session (albeit which looks at casual inspection identical, as the 4-tuple would be the same) there...
Depending on the ID-Reuse field use, I think these bits would need to be consumed also locally (for the tcp session terminating with those boxes), so that you'd deal with a legacy tcp stack, in effect. Regards, Richard Scheffenegger > -----Original Message----- > From: Scott Brim [mailto:scott.b...@gmail.com] > Sent: Dienstag, 29. März 2011 17:38 > To: int-area@ietf.org > Subject: [Int-area] testing concern about IPv4 ID (Joe and Bob et al) > > I have a question about reusing the IPv4 ID field. In theory it all > looks good, but how sure are we that middleboxes are doing the right > thing now? A particular concern is TCP "accelerators". I'm most > familiar with them in cellular networks, where they often come with > client and server pairs and proprietary communications between them. > They compete on tricks to enhance TCP behavior while reducing > bandwidth use. What tests have been done particularly across cellular > networks? Can arbitrary ID values get across? How about the reserved > bit flag? If you don't think we need testing please reassure me. > > Scott > _______________________________________________ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area _______________________________________________ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
