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

From: Takeshi Yoshino <[email-masked]>
Date: Fri, 13 May 2011 15:00:55 +0900

(Detaching from TSV review thread)

Greg,

I see. Sounds ok to use assignment like that. As you said "it's over
reliable transport" in reply to my message, we don't need to use sequence
number as ping/ICMP does since there's no loss or reorder. Maybe just \x00
(reply to ping) or \x01 (unsolicited) would be fine.

Basically, I don't think it's good idea to make it duty of implementor or
service designer to choose body for Ping and unsolicited Pong properly. That
should be covered by the spec to reduce what to be cared by user if
possible. What do you think about specifying some rule for the body strings
to be used for Ping and unsolicited Pong in the spec?

- application data of Ping must start with \x00
- application data of in-reply-to Pong MUST have the same body as the
received Ping
- application data of unsolicited Pong must start with \x01

I think the following is clearer.

- when received Normal-Ping (Ping with its application data starting with
\x00), reply with Pong with the same body
- when received NOP-Ping (Ping with its application data starting with
\x01), just ignore it

On Fri, May 13, 2011 at 07:29, Greg Wilkins <[email-masked]> wrote:

> Takeshi,
>
> what I have seen before is the use of sequence numbers where the
> client side uses even and the server side uses odd, so can tell by the
> seq number in a pong where it was generated and thus tell if it is a
> response or unsolicited.
>
> cheers
>
>
> On 13 May 2011 04:36, Takeshi Yoshino <[email-masked]> wrote:
> >>   Obviously there is a chance that a unsolicited pong matches a ping,
> >> but some careful design of payloads can easily fix that.
> >
> > I see. Coordinating body value assignment so that unsolicited one and
> reply
> > one don't conflict each other (e.g. "ABC" and "XYZ" as you said) is one
> > possible solution.
> > This should be discussed well when we add some keep alive feature to
> browser
> > that sends Ping to the server. If we prepare some API for JavaScript to
> tell
> > the browser what string to use for Ping, service designers may coordinate
> > assignment by themselves. If we don't, we should reserve some string to
> be
> > used for Ping/unsolicited Pong by browsers to avoid collision.
> > ----
> > Isn't it simpler to reserve some string, say "NOOP" (or "\x00" to save
> > bytes), for Ping body and require endpoints to ignore such Ping rather
> than
> > diverting Pong for heartbeat?
> > Thanks,
> > Takeshi
>

---

From: Salvatore Loreto <[email-masked]>
Date: Fri, 13 May 2011 09:31:03 +0300

<as individual contributor>

I agree with the fact that coordinating Ping and Pong body value assigment,
so that unsollicited Pong and reply Pong do not conflict each other,
should be clearly specified in the spec instead of leave this duty to 
the implementors or service designers.

More I share the concern Magnus has on the text in Section 4.5.2;
the text reduce significantly the possibility to develop future 
extensions based on ping/pong.
If people think that it is OK, I won't oppose, but I want to be sure 
that people are well aware of this fact.

    On 4/29/11 8:00 PM, Magnus Westerlund wrote:

    28. Section 4.5.2:

    The message
        bodies (i.e. both the Extension data (if any) and the Application
        data) of the Ping and Pong MUST be the same.

    I find the fact that the extension body data needs to be the same to be
    an issue. If one develops an extension that actually has to do with the
    frames and their transport then not being able to change the data will
    be an issue. As an example could be a Websocket RTT measurement
    extension where you like to include in the PONG both the PING sending
    time from the PING message and the amount of time between receving PING
    and sending PONG. Thus requiring one to add additional data.

-- 
Salvatore Loreto
www.sloreto.com

> reliable transport" in reply to my message, we don't need to use 
> sequence number as ping/ICMP does since there's no loss or reorder. 
> Maybe just \x00 (reply to ping) or \x01 (unsolicited) would be fine.
>
> Basically, I don't think it's good idea to make it duty of implementor 
> or service designer to choose body for Ping and unsolicited Pong 
> properly. That should be covered by the spec to reduce what to be 
> cared by user if possible. What do you think about specifying some 
> rule for the body strings to be used for Ping and unsolicited Pong in 
> the spec?
>
> - when received Normal-Ping (Ping with its application data starting 
> with \x00), reply with Pong with the same body
> On Fri, May 13, 2011 at 07:29, Greg Wilkins <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     Takeshi,
>
>     On 13 May 2011 04:36, Takeshi Yoshino <[email-masked]
>     <mailto:[email-masked]>> wrote:
>     > I see. Coordinating body value assignment so that unsolicited
>     one and reply
>     > This should be discussed well when we add some keep alive
>     feature to browser
>     > that sends Ping to the server. If we prepare some API for
>     JavaScript to tell
>     > assignment by themselves. If we don't, we should reserve some
>     string to be
>     > bytes), for Ping body and require endpoints to ignore such Ping
>     rather than

---

From: Bruce Atherton <[email-masked]>
Date: Fri, 13 May 2011 09:53:32 -0700

I agree with you and Magnus that there will be lots of times you want 
the body of the Pong to be able to vary from the Ping. But perhaps a 
compromise could be reached. What if the body of the Pong must begin 
with the body of the Ping, but can have additional information after that?

---

From: Takeshi Yoshino <[email-masked]>
Date: Tue, 17 May 2011 20:03:25 +0900

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: Gabriel Montenegro <[email-masked]>
Date: Tue, 17 May 2011 19:25:23 +0000

[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.

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