PING payload

[jpinner]

In the current draft, the PING frame requires the server to resend an arbitrarily large payload.

Perhaps restrict the length of the PING frame to 0, allow any stream identifier in the header require the server to echo the identifier?

I'm not sure what benefit being able to echo arbitrary contents provides.

[martinthomson]

Ever used ICMP ping? Same reason.

Maybe we need to explicitly allow an endpoint (not just the server) to
truncate a PONG if it finds it to be too large.

On 18 April 2013 11:13, Jeff Pinner notifications@github.com wrote:

In the current draft, the PING frame requires the server to resend an
arbitrarily large payload.

Perhaps restrict the length of the PING frame to 0, allow any stream
identifier in the header require the server to echo the identifier?

I'm not sure what benefit being able to echo arbitrary contents provides.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/68
.

[jpinner]

ping flood

Guess we want more than just a liveness check from the PING mechanism now?

[martinthomson]

There's specific text in there to support the use of PING as a way to
measure RTT. That's not new. It might not be useful, but it's certainly
not new.

On 18 April 2013 15:52, Jeff Pinner notifications@github.com wrote:

ping flood

Guess we want more than just a liveness check from the PING mechanism now?

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/68#issuecomment-16617492
.

[jpinner]

RTT can be measured without the arbitrary payload size.

My gut reaction is that allowing the server to truncate is equivalent or perhaps worse than not allowing a payload.

Not trying to be difficult here -- just finally got around to trying to implement the framing layer.

[martinthomson]

If you want to perform an RTT measurement without having to do lockstep
(wait for response before sending next ping), then it helps to put a small
amount of context in the payload. Otherwise, correlation of ping and pong
has to rely on ordering (ICMP doesn't have that feature, so they really
need payload echo). In most genuine cases, truncation is easy to detect.
I'm not sure what you would do if you detected truncation, but that's
another thing.

The only reason the payload is there is to replace a feature that was
removed when the header "identifier" was turned into a "stream
identifier". Maybe this can go too.

On 18 April 2013 15:59, Jeff Pinner notifications@github.com wrote:

RTT can be measured without the arbitrary payload size.

My gut reaction is that allowing the server to truncate is equivalent or
perhaps worse than not allowing a payload.

Not trying to be difficult here -- just finally got around to trying to
implement the framing layer.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/68#issuecomment-16617876
.

[jpinner]

Yep -- so maybe either allow "stream identifier" to be "identifier" or make the payload 4 bytes of "identifier" instead of an arbitrary packet.

The aesthetician in me like the uniformity of "stream identifier" being 0 for session based frames so I would prefer the latter :)

[martinthomson]

It's not just a correlator that would be needed. If I'm just doing timing,
the only thing that I care about is when the PING was sent, so I might like
to include a timestamp in the payload, probably using whatever form my
programming environment supports best. That might be an NTP timestamp, a
time_t, an IEEE 754 double, a string, or anything. Allowing a modest
payload lets me do any of these things. Anything more than a handful of
bytes would be nuts, but I can imagine some people wanting 128bits.

On 18 April 2013 16:24, Jeff Pinner notifications@github.com wrote:

Yep -- so maybe either allow "stream identifier" to be "identifier" or
make the payload 4 bytes of "identifier" instead of an arbitrary packet.

The aesthetician in me like the uniformity of "stream identifier" being 0
for session based frames so I would prefer the latter :)

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/68#issuecomment-16619376
.

[mnot]

Please summarise this on the mailing list and look for input there before finishing. Thanks,

[jasnell]

See: #91

[mnot]

James' proposal from #91:

PING frames MAY contain no more than 8 bytes of additional frame data. Receivers of
a PING send a response PING frame with the PONG flag set and precisely the same 
sequence of frame data octets back to the sender as soon as possible.

[mnot]

Discussed at SF interim; fix PING to 8 bytes.

[willchan]

Current text already says "In addition to the frame header, PING frames MUST contain 8 additional octets of opaque data. A sender can utilize this payload in any manner it wishes but MUST include the octets even if they are unused. Receivers of a PING send a response PING frame with the PONG flag set and precisely the same sequence of octets back to the sender as soon as possible."

We can close this, right?

[mnot]

What should a recipient do if it receives a PING with other than 8 bytes?

[jpinner]

session error

[mnot]

Yep - but it needs to be spec'd.

[martinthomson]

I think that we got it all. Closing!