Subject: RE: TCP Mapping

From: "Liu, Hong" <[email-masked]>
Date: Mon, 1 Jul 2002 09:42:13 -0500

Eric,

Given the input we gathered from the list, we (my coauthors and I) decided
to adopt Scott's suggestion and forgo the "P"-bit option. I don't feel the
need to dwell on this subject any longer. 

Our draft is forth-coming. So please stay tuned...

--Hong

-----Original Message-----
From: Eric Brunner-Williams in Portland Maine
[mailto:[email-masked]]
Sent: Monday, July 01, 2002 7:04 AM
To: Liu, Hong
Cc: [email-masked]'; [email-masked]
Subject: Re: TCP Mapping 

Hong,

You've answered a flow-control (dualing endpoints flipping P-BITS) query.

You've answered a payload (same as <poll> elements, and unspec else) query.

For reasons I'm unclear on, your comments across several items of mail
suggest that these are mutually exclusive mechanisms for "tagging" some
"server-pushed message". (See also "careful reading" below).

Am I correct in guessing that if your preferred method of signaling (P-BIT)
is the mechanism, that the payload data could be marked up as <poll> data,
with some as yet unspecified additional content?

To correctly decode <poll>, a client would have to first determin the value
of P-BIT?

Or is XML even present in the P-BIT signaled payload data?

A question I don't seem to have seen answered is how you are proposing
to modify a transport draft that has no options, and which itself is not
optional in the protocol draft. 

Are the properties you've described unique to implementations that elect
to implement them (MAY), or are they common to all implementations (MUST)?

There are business reasons why a client implementation of 6/4 over tcp
wouldn't connect to a NeuStar server implementation of 6/4. Are there also
technical reasons why the same two implementations couldn't be capable of
error-free interoperation?

There has been prior discussion of a <push> command.

Looking back over your messages I see that I wasn't carefull enough reading.
I missed the fact that you proposed to use 8 bits to signal directionality,
not one (mail of 28 June). Either that mail, or your reply to my edit of
tcp-04 (mail of 29 June), which referenced a single bit, but not both, can
be correct.

Which is it? 8 bits, or 1 bit? If 8 bits, are the remaining 7 bits
"reserved"
for some future signaling or differentiation mechanism, or are they "don't
care" (ignore)?

Eric

---

From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Date: Mon, 01 Jul 2002 11:39:45 -0400

Hong,

I'm sure Scott will be gratified.

Some observations:

	o NeuStar's rtk packages may need only minor or no modification to
	  skip the tcp header length error check, and not discard a message
	  which appears to be corrupted,

	o Liberty's rtk package's also may be easily modified to skip the
	  same apparent error condition,

	o It is unlikely that ordinary interoperability testing would ever
	  initiate a transfer of size 2^^24 bits, as you observed in your
	  initial note, and discover an unexpected return value,

	o I expect that the NeuStar's rtk packages can be modified to
	  reduce the probability of triggering a "large" return, exceeding
	  the 2^^24 bit size limit (or 2^^31 for that matter), quite possibly
	  it can't support large messages anyway,

	o I expect that ICANN could be pursuaded that "very large" queries
	  (made by non-NeuStar rtks, should any be used to connect to the
	  NeuStar registry, lacking the above "throttling limit"), are not
	  good policy, and so may be truncated (or discarded) at the whim
	  of the registry (or near 2^^24 bits).

In short, if you were willing to create an exception to the eventual status
docs this WG may produce, and simply require that length-based error check
not be used when clients connect your server, no one would ever have known
that NeuStar is using one or more low-probability-of-use bits in the tcp
header.

It used to be necessary to turn off udp checksums to run nfs (version 2) on
any kind of network. Turning off length-based error checking when connecting
to the NeuStar registry would be no stranger to experienced operators. It is
hard to distinguish from turning off parser validation.

I look forward to a draft.

Eric