Subject: Re: [hybi] Ping/Pong body (was Re: TSV-Directorate review of draft-ietf-hybi-thewebsocketprotocol-07)

From: Piotr Kulaga <[email-masked]>
Date: Wed, 18 May 2011 19:07:24 +0000

In my opinion, ping/pong frames should not carry application payload (foo and bar strings). If the payload is not well defined (i.e. reason, timestamp, etc.) there is no way the peer would understand how it should interpret the data. I would leave this problem the a protocol well-defined extensibility mechanism. If application wants to add payload to a ping/pong frame it should negotiate extension with the server and set a reserved bit on the frame. This way the basic protocol is simple and application can send/receive additional data if necessary (and negotiated).

I am ok with the 0x00 and 0x01 proposal.

From: [email-masked] [mailto:[email-masked]] On Behalf Of Gabriel Montenegro
Sent: Tuesday, May 17, 2011 12:25 PM
To: Takeshi Yoshino; [email-masked]
Subject: Re: [hybi] Ping/Pong body (was Re: TSV-Directorate review of draft-ietf-hybi-thewebsocketprotocol-07)

[As an individual]

I don't think setting Ping/Pong as a platform for further applications is a good idea, for the same reasons that using ICMP as a platform for more intelligent applications is a good idea. Since ICMP does not follow the usual codepaths, any valid network characteristic measurements better not use, and they better use traffic that looks more closely like what an actual app would use (UDP, TCP). Similarly, I would expect Ping/Pong to not be treated as application traffic after network elements start being cognizant of Websockets. So the idea of using Ping/Pong for further apps doesn't appear very convincing to me.

I'd much rather we kept Ping/Pong intentionally limited to its original purpose of just being a bare bones mechanism, and leave any other uses as proper extensions.

The current text to say that only the last Ping need to be responded to discourages the peers from sending more than one, but it would be better to make it explicit that having more than one outstanding Ping (without its corresponding Pong) MUST NOT be done.

I think the 0x00 and 0x01 to distinguish unsolicited Pong is fine.

From: [email-masked] [mailto:[email-masked]] On Behalf Of Takeshi Yoshino
Sent: Tuesday, May 17, 2011 04:03
To: [email-masked]
Subject: Re: [hybi] Ping/Pong body (was Re: TSV-Directorate review of draft-ietf-hybi-thewebsocketprotocol-07)

Full body matching requirement has been introduced by http://tools.ietf.org/html/draft-ietf-hybi-thewebsocketprotocol-03 for both close and ping/pong. What was the original goal of this requirement for ping/pong? Is it still valid? Full body matching requirement for close frames has been thrown away after long discussion.

Now it looks like it's sufficient to have single boolean to indicate it's nop or reply in application data.

Here's relaxed version.

foo and bar mean "any string"

a) implement heartbeat by diverting Pong
- Ping would be "Ping foo"
- to reply to "Ping foo", send "Pong \x00 bar" (bar is foo by default)
- to send unsolicited Pong, send "Pong \x01 bar"

b) implement heartbeat by diverting Ping
- to send Normal-Ping, send "Ping \x00 foo"
- to send NOP-Ping, send "Ping \x01 foo"
- to reply "Ping \x00 foo", send "Pong bar" (bar is foo by default)
- just ignore "Ping \x01 foo" when received

to adopt Bruce's idea, change "(bar is foo by default)" to "(bar is foo + buz)". it implements echo and allows the receiver to send additional info.

I've removed unnecessary \x00 and \x01, but it's fine for me to keep them to keep framing symmetric.

Takeshi

---

From: Brian McKelvey <[email-masked]>
Date: Wed, 18 May 2011 13:05:52 -0700

+1
I also see no purpose for correlating ping/pong data.  Or restricting the number of outstanding pings.  If you send 5 pings, you should expect 5 pongs, end of story.  The only real purpose for them is to see if the other end is still responsive, so send a ping and if you haven't gotten a pong after a certain user-decided timeout, close the connection.  It needs no further complication.

Brian

Sent from my iPhone

On May 18, 2011, at 12:07 PM, Piotr Kulaga <[email-masked]> wrote:

> I don’t think setting Ping/Pong as a platform for further applications is a good idea, for the same reasons that using ICMP as a platform for more intelligent applications is a good idea. Since ICMP does not follow the usual codepaths, any valid network characteristic measurements better not use, and they better use traffic that looks more closely like what an actual app would use (UDP, TCP). Similarly, I would expect Ping/Pong to not be treated as application traffic after network elements start being cognizant of Websockets. So the idea of using Ping/Pong for further apps doesn’t appear very convincing to me.
> 
>  
> 
> I’d much rather we kept Ping/Pong intentionally limited to its original purpose of just being a bare bones mechanism, and leave any other uses as proper extensions. 
> 
>  
> 
> _______________________________________________
> hybi mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/hybi

---

From: Piotr Kulaga <[email-masked]>
Date: Thu, 19 May 2011 00:43:15 +0000

Personally I do not see any point of allowing multiple outstanding pings. If a sender did not get a response to first of them, sending another one probably will not increase its chances. To me, saying that only one ping is allowed is a simplification of the protocol which does not limit protocol’s functionality.

From: Brian McKelvey [mailto:[email-masked]]
Sent: Wednesday, May 18, 2011 1:06 PM
To: Piotr Kulaga
Cc: Gabriel Montenegro; Takeshi Yoshino; [email-masked]
Subject: Re: [hybi] Ping/Pong body (was Re: TSV-Directorate review of draft-ietf-hybi-thewebsocketprotocol-07)

+1

Brian

Sent from my iPhone

On May 18, 2011, at 12:07 PM, Piotr Kulaga <[email-masked]<mailto:[email-masked]>> wrote:
In my opinion, ping/pong frames should not carry application payload (foo and bar strings). If the payload is not well defined (i.e. reason, timestamp, etc.) there is no way the peer would understand how it should interpret the data. I would leave this problem the a protocol well-defined extensibility mechanism. If application wants to add payload to a ping/pong frame it should negotiate extension with the server and set a reserved bit on the frame. This way the basic protocol is simple and application can send/receive additional data if necessary (and negotiated).

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Gabriel Montenegro
Sent: Tuesday, May 17, 2011 12:25 PM
To: Takeshi Yoshino; [email-masked]<mailto:[email-masked]>
Subject: Re: [hybi] Ping/Pong body (was Re: TSV-Directorate review of draft-ietf-hybi-thewebsocketprotocol-07)

[As an individual]

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Takeshi Yoshino
Sent: Tuesday, May 17, 2011 04:03
To: [email-masked]<mailto:[email-masked]>
Subject: Re: [hybi] Ping/Pong body (was Re: TSV-Directorate review of draft-ietf-hybi-thewebsocketprotocol-07)

Here's relaxed version.

Takeshi

_______________________________________________
hybi mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/hybi

---

From: Greg Wilkins <[email-masked]>
Date: Thu, 19 May 2011 11:15:41 +1000

On 19 May 2011 10:43, Piotr Kulaga <[email-masked]> wrote:
> Personally I do not see any point of allowing multiple outstanding pings. If
> a sender did not get a response to first of them, sending another one
> probably will not increase its chances. To me, saying that only one ping is
> allowed is a simplification of the protocol which does not limit protocol’s
> functionality.

I agree that multiple outstanding pings do not initially appear useful.

But then I don't see why we need to restrict it to only 1.    Either
it will not have a use and thus nobody will send multiple pings,  or
somebody will discover a use and we should let them.

cheers

---

From: Brian McKelvey <[email-masked]>
Date: Wed, 18 May 2011 18:23:59 -0700

Indeed.. It's simpler for the protocol to state that a pong should be sent in response to a ping and leave it at that.

Sent from my iPhone

---

From: Patrick McManus <[email-masked]>
Date: Wed, 18 May 2011 21:42:39 -0400

> Indeed.. It's simpler for the protocol to state that a pong should be sent in response to a ping and leave it at that.

agreed - I'm not seeing a compelling reason to make any particular
change from -07, though I would expect implementations to use it much
more conservatively than is allowed. And that's ok.

---

From: Jamie Lokier <[email-masked]>
Date: Fri, 20 May 2011 00:28:27 +0100

> somebody will discover a use and we should let them.

Naturally I have a use, and it came up in my very first application
for WebSocket.  What follows is an example.

A server needs to know which clients are currently "online" for the
purpose of reporting this to other clients, detecting dead clients etc.

"Online" is defined (in this example) as "received something in the
last 30 seconds".  This ensures it's fairly up to date, which is
important in a number of applications.

No guarantees can be made about the network, but we choose to treat a
delay of up to 10 seconds in the client-to-server direction as acceptable.
(This is based on 3G experiences, which commonly delay for that long.)

Therefore the client sends 1 ping message every *20* seconds, if there
is no other client-to-server data.

The client must send another ping after 20 seconds even if it hasn't
had a pong for the previous ping yet.

Pongs can be delayed quite a lot due to queueing behind other
messages already queued from server-to-client, plus network delays.

If the client had to wait for pong before sending another ping, that
would cause spurious "offline" statuses whenever there was a lot of
data transiting in server-to-client direction.  Or we'd have to use a
custom keepalive protocol to avoid the restriction.  Or we couldn't
provide such an up to date measure.

(In reality we'll probably use a custom keepalive protocol anyway, to
reduce the amount of packets needed, but that's a separate issue.)

-- Jamie

---

From: Gabriel Montenegro <[email-masked]>
Date: Thu, 19 May 2011 23:44:35 +0000

This usage is supported in revision 07, which only has text on the responder (the "Pingee"?) allowing it to respond only to the latest Ping, but it has no constrain on the initiator (the "Pinger"), which is currently free to send more than one (which you indicate might actually make sense in your case). 

I'm curious, if a Pong has not been received in such long time, why is the course of action to Ping again versus declaring that node gone or down and unavailable? I thought your goal was to detect dead nodes. Wouldn't this constitute a dead node?

> -----Original Message-----
> From: Jamie Lokier [mailto:[email-masked]]
> Sent: Thursday, May 19, 2011 16:28
> To: Greg Wilkins
> Cc: Piotr Kulaga; [email-masked]; Gabriel Montenegro
> > > Personally I do not see any point of allowing multiple outstanding
> > > pings. If a sender did not get a response to first of them, sending
> > > another one probably will not increase its chances. To me, saying
> > > that only one ping is allowed is a simplification of the protocol
> > > which does not limit protocol’s functionality.
> >
> >
> Naturally I have a use, and it came up in my very first application for WebSocket.
> What follows is an example.
> 
> A server needs to know which clients are currently "online" for the purpose of
> reporting this to other clients, detecting dead clients etc.
> 
> "Online" is defined (in this example) as "received something in the last 30
> seconds".  This ensures it's fairly up to date, which is important in a number of
> applications.
> 
> No guarantees can be made about the network, but we choose to treat a delay
> of up to 10 seconds in the client-to-server direction as acceptable.
> Therefore the client sends 1 ping message every *20* seconds, if there is no
> other client-to-server data.
> 
> The client must send another ping after 20 seconds even if it hasn't had a pong
> for the previous ping yet.
> 
> Pongs can be delayed quite a lot due to queueing behind other messages already
> queued from server-to-client, plus network delays.
> 
> If the client had to wait for pong before sending another ping, that would cause
> spurious "offline" statuses whenever there was a lot of data transiting in server-
> to-client direction.  Or we'd have to use a custom keepalive protocol to avoid
> the restriction.  Or we couldn't provide such an up to date measure.
> 
> (In reality we'll probably use a custom keepalive protocol anyway, to reduce the
> amount of packets needed, but that's a separate issue.)
> 
> -- Jamie

---

From: Salvatore Loreto <[email-masked]>
Date: Fri, 20 May 2011 09:55:41 +0300

> more conservatively than is allowed. And that's ok.
(as individual)

I am OK with the 0x00 and 0x01 proposal to distinguish unsolicited pings

and with the fact that to simplify the current spec and let room for 
future extensions
  the ping/pong frames (in the current spec) should not carry any 
application payload
  and so no need to correlate ping/pong data

and yes I agree with the Brian text proposal (above)

cheers
/Sal

-- 
Salvatore Loreto
www.sloreto.com

---

From: Pieter Hintjens <[email-masked]>
Date: Fri, 20 May 2011 12:08:29 +0200

On Fri, May 20, 2011 at 1:28 AM, Jamie Lokier <[email-masked]> wrote:

> data transiting in server-to-client direction.

We had exactly this problem in AMQP and resolved it quite effectively
by treating _any_ incoming data as a liveness indicator. Any reason
you'd not do this?

-Pieter Hintjens

---

From: Jamie Lokier <[email-masked]>
Date: Fri, 20 May 2011 22:26:18 +0100

> by treating _any_ incoming data as a liveness indicator. Any reason

(I was going to agree, but then I remembered complicated things from
coherent systems that had hoped to avoid here.  So yes and no!)

That's better, but it addresses a different issue than this thread.

That's a good way to keep a TCP connection alive.  Optimal seems to be
to decouple directions, and (for each direction) a one-way keepalive
when there hasn't been any transmission for a fixed time; all received
data indicates liveness.

But keeping a connection alive isn't quite the same as reliably
detecting a dead one!  (To reconnect, break a transaction, etc.)

With the example timings I gave, the client has to send keepalives
every 20 seconds _even if_ it treats any data from the server as
indicating liveness, otherwise the server will flag the client as
"offline" spuriously.

For "quiet" connections, explicit ping/pong work, but the the client
must send pings 20 seconds apart from _each other_, not wait 20
seconds after receiving a pong (an easy coding error).

If we discard the whole concept of ping/pong, I think you and I are
in sharp agreement.

But this sub-thread is about whether it's ever useful to overlap
ping/pong.  My reply is:

   If you insist on using ping/pong, perhaps feeling the need to use
   the features of WebSocket draft -07 instead of inventing your own,
   then yes sometimes they need to overlap.  But it's even better to
   abandon ping/pong and use a more robust keepalive method.

In a way, you have highlighted a problem with the explicit ping/pong
strategy implicitly advocated in draft -07.

Unfortunately, treating all data as liveness has a different set of
problems (good for keeping a connection alive, but unreliable at
detecting connection loss in a bounded time), which is often
ignorable, but breaks things that depend on "confirm the client was
definitely alive in the last 30 seconds".  Think about variable
network delays.  The only robust solution I've come up with combines
all-data-liveness and round-tripped sequence stamps.  Hence yes and no
to your question.

-- Jamie

---

From: Jamie Lokier <[email-masked]>
Date: Fri, 20 May 2011 23:17:45 +0100

Gabriel Montenegro wrote:
> This usage is supported in revision 07, which only has text on the
> responder (the "Pingee"?) allowing it to respond only to the latest
> Ping, but it has no constrain on the initiator (the "Pinger"), which
> is currently free to send more than one (which you indicate might
> actually make sense in your case).

That's a good reason for a ping/pong body.

If the responder only has to respond to the last ping, the sender may
need to know which ping is being responded to make assertions about
when the responder was alive and estimate or bound the RTT.

> I'm curious, if a Pong has not been received in such long time, why
> is the course of action to Ping again versus declaring that node gone
> or down and unavailable? I thought your goal was to detect dead
> nodes. Wouldn't this constitute a dead node?

See Pieter Hintjens reply, and my reply to that.  If there is bulky
data being transmitted, it can delay a pong, potentially for a long
time (depending on how your queues work), but it doesn't mean the
connection is dead.  Quite the contrary.

I don't mean to advocate that ping/pong is always appropriate anyway.

(As Pieter points out, watching the data is better.  Another reason:
Asymmetric timeouts.  If you need keepalive just to stay "subscribed"
to a message source, then the keepalive bandwidth can greatly exceed
actual data!!  Dropping pongs, and using _different_ timings for
server and client can reduce keepalive bandwidth while maintaining a
required level of "subscriber up-to-dateness".)

But if you feel the need to use ping/pong (perhaps to feel like you're
making more use of the WS spec, and less wheel invention), when you
have short keepalive timing constraints, that would push towards
overlap sometimes.

-- Jamie

---

From: Pieter Hintjens <[email-masked]>
Date: Sat, 21 May 2011 01:26:58 +0200

> coherent systems that had hoped to avoid here.  So yes and no!)

...

Thanks for the detailed answer, Jamie.

-Pieter

---

From: Bruce Atherton <[email-masked]>
Date: Sun, 22 May 2011 12:47:56 -0700

It seems there are still a number of issues around Ping/Pong. Here are 
my thoughts on them:

1) Should multiple Pings be allowed before a response Pong is received?

Surely this is the business of the implementation/application and not 
the specification. If someone has a use for such a thing, why not allow it?

2) Should Ping and Pong be allowed to have a body?

I think it is a useful and desirable feature. It allows matching Pongs 
to Pings, as well as being an area for experimenting with new ideas in 
how the Ping and Pong are used.

The argument has been brought up that the bodies are useless without a 
standard way of interpreting them. This is absolutely true. Why not 
allow experimentation so that people can come up with standards for them?

What is the downside to allowing it?

3) Should there be an indicator for unsolicited Pongs and/or Pings that 
need no response.

I don't see why this is necessary or desirable so long as the body of 
the Pong in some way indicates the Ping it is responding to. Allowing 
unsolicited Pongs removes any usecase for Pings without responses as far 
as I can see. As far as unsolicited Pongs go, if the Pong body does not 
match a Ping that was sent out, then surely it can be assumed to be an 
unsolicited Pong.

What is the marker trying to indicate? That if we have a Pong that 
claims to be solicited and does not match the Ping body that there is a 
bug in the server implementation, or perhaps that the server is mistaken 
in the client it thinks it is communicating with? Is this really necessary?

4) Should we allow the Pong body to contain extra data beyond just 
echoing the Ping body?

Again, I think this is a harmless way to allow experimentation on uses 
for Ping and Pong. I don't see any reason for disallowing it.

It has been claimed that there could not be any value in allowing 
additional information because Ping/Pong frames run at a higher priority 
than other Websocket traffic, and so any data they carry on network 
characteristics would not reflect the behaviour of other data in the 
channel. This makes a couple of assumptions that I think are 
questionable. First, are all possible uses of Ping and Pong concerned 
with network characteristics? Even if so, are all possible network 
characteristics rendered moot by higher priority traffic? I don't see it 
necessarily follows that these two assumptions are valid.

So if it were up to me, I would just change the spec to indicate that 
the Pong must respond with the Ping body, but is allowed to add any data 
it wishes to afterward. In fact, you could even change it to respond 
with just a hash of the Ping body followed by any other data it wanted 
to (SHA1 + Base64 for consistency).

I wouldn't add in a flag for unsolicited vs. solicited Pongs since the 
Pong response does that for us by indicating the Ping it is responding 
to, but if others wanted it then I wouldn't stand in their way. 
Although, if you are going to specify a byte for a single flag then you 
may want to indicate the other 7 bits are reserved for future use.

---

From: Takeshi Yoshino <[email-masked]>
Date: Mon, 23 May 2011 13:37:01 +0900

> I don't see why this is necessary or desirable so long as the body of the
> Pong in some way indicates the Ping it is responding to. Allowing
> unsolicited Pongs removes any usecase for Pings without responses as far as
> I can see.

I think so. What I'm proposing is doing either of adding flag to Ping or
adding flag to Pong. Not both.

Here, I'll reply to your comments assuming we add flag to Pong.

> As far as unsolicited Pongs go, if the Pong body does not match a Ping that
> was sent out, then surely it can be assumed to be an unsolicited Pong.
>
>
It's possible that A sends an unsolicited Pong with the same body as a Ping
sent by B. How do you choose Pong body for unsolicited Pong? As initially
most of implementors are not interested in using the body of Ping and
unsolicited Pong, they'll try to use an empty string. Some may choose non
empty string X for its Ping body but some other may also use the same string
X for its unsolicited Pongs' body. It will be quickly out of control.

So then, Pings can be often acked by unsolicited Pongs. It's not so harmful
as the only weird thing we'll see is the very very small RTT for such Pings
for now, but I prefer to mark them in the spec level to reduce the
possibility of problems in the future extension.

> What is the marker trying to indicate? That if we have a Pong that claims
> to be solicited and does not match the Ping body that there is a bug in the
> server implementation, or perhaps that the server is mistaken in the client
> it thinks it is communicating with? Is this really necessary?
>

That's not the case I was arguing. Pong that claims to be unsolicited and
does match the Ping body is what I have concern over.

---

From: Bruce Atherton <[email-masked]>
Date: Tue, 24 May 2011 12:48:20 -0700

I see. Thanks for the clarification. I take your point. It is perhaps 
because the body is so under-specified that this problem arises. You 
could get around it by, for example, requiring PING to always start with 
a timestamp and requiring an unsolicited PONG not to. Or you could 
require a UUID from both PING and unsolicited PONG.

But any of those ideas is no better (and probably worse) than your 
solution, so I'm happy to support it.

On 22/05/2011 9:37 PM, Takeshi Yoshino wrote:
>
> That's not the case I was arguing. Pong that claims to be unsolicited 
> and does match the Ping body is what I have concern over.
>

---

From: Patrick McManus <[email-masked]>
Date: Tue, 24 May 2011 21:04:53 -0400

On Mon, 2011-05-23 at 13:37 +0900, Takeshi Yoshino wrote:

> 
> It's possible that A sends an unsolicited Pong with the same body as a
> Ping sent by B. How do you choose Pong body for unsolicited Pong?

I think that's looking at it backwards.

If B cares about having the mandatory pong reply be matched to B's ping
then B can simply create a non-predictable payload that -07 already
requires to be echoed in the pong. 

No change to the protocol is necessary, right?

>  As initially most of implementors are not interested in using the
> body of Ping and unsolicited Pong, they'll try to use an empty string.
> Some may choose non empty string X for its Ping body but some other
> may also use the same string X for its unsolicited Pongs' body. It
> will be quickly out of control.
> 

If the implementor cares about such things then those bodies are
extremely poor implementation decisions. It makes sense to add some
guidance to the text to help them out, but there is no reason to add
constraints here or change the existing protocol imo. If the implementor
changes their mind about being interested in such things they can change
the implementation of their ping body at the same time.

---

From: Takeshi Yoshino <[email-masked]>
Date: Wed, 25 May 2011 12:08:35 +0900

Hi,

> requires to be echoed in the pong.

Hmm, I feel that having 1 byte pre-specified indicator rather simplifies
this and is cheap enough. Yes, preparing something unpredictable solves
this. I think it's fine when user-agents and servers for the service are
under one vendor/people's control. A and B can just negotiate and use
different body. But this is interoperability problem between user-agents and
servers provided by various vendors/people. To be sure that the possibility
of collision between body X which I use for my user-agent and any of server
A, server B, ..., etc. is low enough, maybe I would use random bytes of 3 or
more byte long. It costs than indicator.

> extremely poor implementation decisions. It makes sense to add some

Yes.

> guidance to the text to help them out, but there is no reason to add

Agreed. At least some advice should be given.

> the implementation of their ping body at the same time.

Punting this and decide later is one option, but I'm not sure if it works
with small effort of code/spec change and coordination. Different from
extension etc. which will be defined in the future and then implemented,
Ping/Pong will be implemented by everyone based on the current text.

Thanks,
Takeshi

---

From: Takeshi Yoshino <[email-masked]>
Date: Wed, 25 May 2011 12:10:47 +0900

On Wed, May 25, 2011 at 04:48, Bruce Atherton <[email-masked]> wrote:

> because the body is so under-specified that this problem arises. You could
> get around it by, for example, requiring PING to always start with a
> timestamp and requiring an unsolicited PONG not to. Or you could require a
> UUID from both PING and unsolicited PONG.
>

Yeah. I'm fine if anything by which I can distinguish them is specified by
the spec.

---

From: Patrick McManus <[email-masked]>
Date: Tue, 24 May 2011 23:37:36 -0400

On Wed, 2011-05-25 at 12:08 +0900, Takeshi Yoshino wrote:

> . Yes, preparing something unpredictable solves this.

right, without further changes to the protocol. Then we could ship
websockets and people could start writing applications instead of
documents. Stability is a worthwhile goal.

> But this is interoperability problem between user-agents and servers
> provided by various vendors/people

I disagree, because [see below]

>  enough, maybe I would use random bytes of 3 or more byte long.

right. The ping-generating-peer doesn't need cooperation from the other
peer in order to create a unique payload. Interoperabiity does not
require that each end use the same algorithm - either the client or the
server can be the ping generating peer.

---

From: Willy Tarreau <[email-masked]>
Date: Wed, 25 May 2011 06:38:32 +0200

Hi Patrick,

> server can be the ping generating peer.

I would add that if one peer randomly sends pong messages, it's just
deliberately trying to get its communication degraded. Ping/pong may
be used in order to improve quality of service by detecting quickly
that a connection seems to be broken. There's nothing to win by fooling
this. It's similar to ICMP ping : instead of wondering what would happen
if Google sends me fake echo reply messages when I ping them to check if
my DSL line is OK, I prefer to ask why would they do this in the first
place and for what purpose ?

Here it's the same. We could similarly have peers that randomly send
crap just because it's fun, or send wrong size message on purpose, we
can imagine anything. It just has no use for the one sending that crap,
so basically I4d say that unsollicited pong messages must be ignored,
and that even if the other end fakes a perfect pong that you take for
valid, we should't care. This fake pong will lead to wrong RTT estimates
and the valid one will be ignored, end of the story.

In ICMP we have a sequence number in ping messages. This might be useful
to ensure we're getting the association right, and it's easier to recommend
using a counter than sending a random message. Some users might prefer to
send a timestamp in the message maybe.

Regards,
Willy

---

From: Takeshi Yoshino <[email-masked]>
Date: Wed, 25 May 2011 15:31:35 +0900

> documents. Stability is a worthwhile goal.

I really care the time of shipment, too. I don't want this to be show
stopper, but want to get attention to this point from people who want to use
some extended Ping, unsolicited Pong, etc. to get this thought out enough.

Yes.

> server can be the ping generating peer.

Sorry, I couldn't get you. A and B don't have to use the same algorithm, but
in fact those algorithms need coordination. A's algorithm must choose X for
its Ping where X != Y which B's algorithm chooses for its unsolicited
Pong. Well, I agree that I'm saying something paranoid, but it's true.

How about this? Semantically a bit smaller change.
"Body of Ping and unsolicited body can be empty. IF Ping or unsolicited Pong
have non-empty body, they must start with 0x00 and 0x01"
This doesn't break interoperability with -07 or add new constraint to body
as long as the user-agent doesn't have any data to be put into body. When
some peer want to disambiguate them, it can safely do it by prefixing body
with 0x00 or 0x01 without any new negotiation, coordination or randomness.

For any foobar,
0x00 foobar != 0x01 foobar
0x00 foobar != ""
0x01 foobar != ""

---

From: Patrick McManus <[email-masked]>
Date: Wed, 25 May 2011 07:10:12 -0400

On Wed, 2011-05-25 at 15:31 +0900, Takeshi Yoshino wrote:

> 
> Sorry, I couldn't get you. A and B don't have to use the same
> algorithm, but in fact those algorithms need coordination. A's
> algorithm must choose X for its Ping where X != Y which B's algorithm
> chooses for its unsolicited Pong. Well, I agree that I'm saying
> something paranoid, but it's true.

But if A's algorithm is "unpredictable random sequence" then B cannot
realistically match A's value even if they are uncoordinated. Just make
the random space sufficiently large - these are infrequent events after
all.

> "Body of Ping and unsolicited body can be empty. IF Ping or
> unsolicited Pong have non-empty body, they must start with 0x00 and
> 0x01"
> This doesn't break interoperability with -07 or add new constraint to

that does break interoperability, though. a Ping of "0x23 0x24 0x25
0x26" is legal under -07 and invalid under that text. s/must/SHOULD
would repair that, I suppose.

If we need to change the text then let's do it. But really, is any
serious problem being solved that an implementation cannot solve for its
self with the selection of an unpredictable body in the ping using the
-07 rules? It's time to ship the protocol already.

---

From: Brian McKelvey <[email-masked]>
Date: Wed, 25 May 2011 09:54:03 -0700

Sent from my iPhone

On May 25, 2011, at 4:10 AM, Patrick McManus <[email-masked]> wrote:

> -07 rules?

No.  This is, IMO, totally unimportant.  It's fine exactly the way it is.

> It's time to ship the protocol already.

:-)

---

From: Greg Wilkins <[email-masked]>
Date: Thu, 26 May 2011 08:48:43 +1000

+1 to all this.

On 23 May 2011 05:47, Bruce Atherton <[email-masked]> wrote:
> It seems there are still a number of issues around Ping/Pong. Here are my
> thoughts on them:
>
> Surely this is the business of the implementation/application and not the
> specification. If someone has a use for such a thing, why not allow it?
>
> I think it is a useful and desirable feature. It allows matching Pongs to
> Pings, as well as being an area for experimenting with new ideas in how the
> Ping and Pong are used.
>
> standard way of interpreting them. This is absolutely true. Why not allow
> experimentation so that people can come up with standards for them?
>
> 3) Should there be an indicator for unsolicited Pongs and/or Pings that need
> no response.
>
> I can see. As far as unsolicited Pongs go, if the Pong body does not match a
> Ping that was sent out, then surely it can be assumed to be an unsolicited
> Pong.
>
> What is the marker trying to indicate? That if we have a Pong that claims to
> be solicited and does not match the Ping body that there is a bug in the
> 4) Should we allow the Pong body to contain extra data beyond just echoing
> the Ping body?
>
> Again, I think this is a harmless way to allow experimentation on uses for
> Ping and Pong. I don't see any reason for disallowing it.
>
> It has been claimed that there could not be any value in allowing additional
> information because Ping/Pong frames run at a higher priority than other
> Websocket traffic, and so any data they carry on network characteristics
> would not reflect the behaviour of other data in the channel. This makes a
> couple of assumptions that I think are questionable. First, are all possible
> uses of Ping and Pong concerned with network characteristics? Even if so,
> are all possible network characteristics rendered moot by higher priority
> traffic? I don't see it necessarily follows that these two assumptions are
> valid.
>
> So if it were up to me, I would just change the spec to indicate that the
> Pong must respond with the Ping body, but is allowed to add any data it
> wishes to afterward. In fact, you could even change it to respond with just
> a hash of the Ping body followed by any other data it wanted to (SHA1 +
> Base64 for consistency).
>
> I wouldn't add in a flag for unsolicited vs. solicited Pongs since the Pong
> response does that for us by indicating the Ping it is responding to, but if
> others wanted it then I wouldn't stand in their way. Although, if you are
> going to specify a byte for a single flag then you may want to indicate the
> other 7 bits are reserved for future use.
>

---

From: Takeshi Yoshino <[email-masked]>
Date: Thu, 26 May 2011 13:34:56 +0900

> the random space sufficiently large - these are infrequent events after

Yes. I know.

My point is the trade off between "please choose and implement some
algorithm (e.g. random 3, 4 or more octet) that very possibly never
generates body which collide with others' by yourself when necessary" and
"the spec clearly disambiguates them by 1 octet indicator".

I think the former works practically. But that's not what something called
"specification" should do I think in principle. Things people may leave
under-specified are things that defined in lower or under layer which have
their own agreement/spec, or extensions that has negotiation mechanism by
which entities can coordinate their behavior. This is not the case.

> would repair that, I suppose.

Yes. For non-empty cases, it does break.

> -07 rules? It's time to ship the protocol already.

I'm ok with this shipped without adding indicator if no one else thinks it's
necessary. It's time to ship, yes. Personally I have no plan to use
non-empty ping/pong body.

As Bruce listed, there're some other issues raised recently. Here are my
thoughts on them.

a) Allow multiple in-flight Pings?
Yes. Harmless. Jamie's opinion makes sense. Keep the current text.

b) Allow Ping and Pong to have a body?
Yes. Harmless. Keep the current text.

b-yes-1) Disambiguate solicited and unsolicited Pong by the spec?
I can live without this, but I think we should.

b-yes-2) Allow the Pong body to contain extra data beyond just echoing the
Ping body?
OK. Harmless. I don't have any preference on this. This needs text change.

c) Have solicited Pong respond to only the most recent Ping?
I don't understand why we allow this kind of unsynchronized behavior
purposely. It's not a good way to discourage multiple in-flight Pings. If
it's good to disallow multiple in-flight Pings, the spec should say
"multiple in-flight Pings MUST not be sent" directly. I think most of
implementation would handle received data frame-by-frame. Once it sees a
Ping frame, it will enqueue a Pong to its sending queue, forget it and move
on the next frame. This text looks just confusing.
Again, I can live with this.

Thanks,
Takeshi

---

From: Gabriel Montenegro <[email-masked]>
Date: Thu, 26 May 2011 16:44:53 +0000

After discussion with Salvatore, this is our take on this:

The only thing that absolutely needs to change, then is this:

b-yes-2) Allow the Pong body to contain extra data beyond just echoing the Ping body?
OK. Harmless. I don't have any preference on this. This needs text change.

And the corresponding change is in section 4.5.3 on Pong:

OLD:
The message
   bodies (i.e. both the Extension data (if any) and the Application
   data) of the Ping and Pong MUST be the same.
NEW:
 The message body's Application data of the Ping and Pong MUST be the same.

Thanks,

Gabriel

From: [email-masked] [mailto:[email-masked]] On Behalf Of Takeshi Yoshino
Sent: Wednesday, May 25, 2011 21:35
To: Patrick McManus
Cc: [email-masked]
Subject: Re: [hybi] Ping/Pong body (was Re: TSV-Directorate review of draft-ietf-hybi-thewebsocketprotocol-07)

On Wed, May 25, 2011 at 20:10, Patrick McManus <[email-masked]<mailto:[email-masked]>> wrote:
But if A's algorithm is "unpredictable random sequence" then B cannot
realistically match A's value even if they are uncoordinated. Just make
the random space sufficiently large - these are infrequent events after
all.

Yes. I know.

My point is the trade off between "please choose and implement some algorithm (e.g. random 3, 4 or more octet) that very possibly never generates body which collide with others' by yourself when necessary" and "the spec clearly disambiguates them by 1 octet indicator".

I think the former works practically. But that's not what something called "specification" should do I think in principle. Things people may leave under-specified are things that defined in lower or under layer which have their own agreement/spec, or extensions that has negotiation mechanism by which entities can coordinate their behavior. This is not the case.

I'm ok with this shipped without adding indicator if no one else thinks it's necessary. It's time to ship, yes. Personally I have no plan to use non-empty ping/pong body.

As Bruce listed, there're some other issues raised recently. Here are my thoughts on them.

b-yes-2) Allow the Pong body to contain extra data beyond just echoing the Ping body?
OK. Harmless. I don't have any preference on this. This needs text change.

c) Have solicited Pong respond to only the most recent Ping?
I don't understand why we allow this kind of unsynchronized behavior purposely. It's not a good way to discourage multiple in-flight Pings. If it's good to disallow multiple in-flight Pings, the spec should say "multiple in-flight Pings MUST not be sent" directly. I think most of implementation would handle received data frame-by-frame. Once it sees a Ping frame, it will enqueue a Pong to its sending queue, forget it and move on the next frame. This text looks just confusing.
Again, I can live with this.

Thanks,
Takeshi