Subject: Re: [ippm] Last Call: draft-ietf-ippm-twamp-session-cntrl (Individual Session Control Feature for TWAMP) to Proposed Standard

From: Fortune HUANG <[email-masked]>
Date: Thu, 18 Mar 2010 12:55:58 +0800

Dear all,
 
I have some questions about this draft below. Sorry for being a little late.
 
1. It is not clear to me how the server or the reflector use the SID
specified in the request from the client. The SID doesn't seem to be used to
correlate the test packets and the accepted sessions because there is no SID
in the test packets. 
 
2. In section 3.3, I think the SIDs may not need to be carried back to the
client. Assuming the SID is accepted in sequence with no discrimination, the
client can figure out the list of accepted SIDs with the accepted number of
sessions.  Suppose the client requests for SID1, SID2, SID3 and SID4 in
sequence, can the server accepts only SID1, SID3 without accepting SID2? If
it can do that, how does the server differentiate SID3 and SID2? If it can
not do that, that I think the server can return a acceptance count to the
client, e.g. 2 for accepting SID1 and SID2, 3 for accepting SID1, SID2 and
SID3.
 
3. In section 3.5, What can the client do if told by the server that some
the sessions can not be stopped? To resend the stop request? But in that
case, a simpler way would be that the server could try to stop the sessions
again without any stop request resent from the client. The signalling could
be reduced in this way.

Regards,
Fortune

---

From: Al Morton <[email-masked]>
Date: Thu, 18 Mar 2010 09:55:31 -0400

At 12:55 AM 3/18/2010, Fortune HUANG wrote:

I have some
questions about this draft below. Sorry for being a little late.

1. It is not clear to me how the server or the reflector use
the SID specified in the request from the client. The SID doesn't seem to
be used to correlate the test packets and the accepted sessions because
there is no SID in the test packets.

this thread should help:

At 10:37 PM 3/17/2010, Tina TSOU wrote:

At 10:26 PM 3/15/2010, Tina TSOU
wrote:

In paragraph 3 of section 4.2,
given that there is no change to the TWAMP-test packet format, I assume
we use the exact TWAMP-test packet format as defined RFC5357, so that the
SID is not carried in the test packets. My question is that how the
reflector just whether a TWAMP-test packet belongs to the same
session/SID or not. Since per definition the testing message does not
include SID, how to differentiate the testing message of different
testing sessions after multiple testing started?
The
Request-TW-Session command includes sender address + port

and receiver address + port, and this is usually
sufficient.
Can the server identify the corresponding SID
based on sender address + port and  receiver address +
port?

Yes, the server assigns the SID with all addr+port information in
hand.

2. In section 3.3, I think the SIDs may not need to be
carried back to the client. Assuming the SID is accepted in sequence with
no discrimination, the client can figure out the list of accepted SIDs
with the accepted number of sessions.  Suppose the client requests
for SID1, SID2, SID3 and SID4 in sequence, can the server accepts only
SID1, SID3 without accepting SID2? If it can do that, how does the server
differentiate SID3 and SID2? If it can not do that, that I think the
server can return a acceptance count to the client, e.g. 2 for accepting
SID1 and SID2, 3 for accepting SID1, SID2 and
SID3.

Use of SID was decided in the OWAMP spec. We simply continue to

use it in TWAMP and it keeps the two specs similar.

3. In section 3.5, What can the client do if told by the
server that some the sessions can not be stopped? To resend the stop
request? But in that case, a simpler way would be that the server could
try to stop the sessions again without any stop request resent from the
client. The signalling could be reduced in this way.

The client can resend, but in any case, the
sender will stop sending

test packets.  At the reflector, resources are freed-up when it
stops

a test, so this scenario seems rather unusual.

IETF-wide Last Call ended on Monday,

Al

---

From: Fortune HUANG <[email-masked]>
Date: Fri, 19 Mar 2010 09:44:27 +0800

Hi Al,
 
Thank you very much for your reply. Please see my response in-line below,
indicated by [Fortune].

Regards,
Fortune

  _____  

From: [email-masked] [mailto:[email-masked]] On Behalf Of Al
Morton
Sent: Thursday, March 18, 2010 9:56 PM
To: [email-masked]
Subject: Re: [ippm] Last Call: draft-ietf-ippm-twamp-session-cntrl
(Individual Session Control Feature for TWAMP) to Proposed Standard

 

this thread should help:

At 10:26 PM 3/15/2010, Tina TSOU wrote:

In paragraph 3 of section 4.2, given that there is no change to the
TWAMP-test packet format, I assume we use the exact TWAMP-test packet format
as defined RFC5357, so that the SID is not carried in the test packets. My
question is that how the reflector just whether a TWAMP-test packet belongs
to the same session/SID or not. Since per definition the testing message
does not include SID, how to differentiate the testing message of different
testing sessions after multiple testing started?

The Request-TW-Session command includes sender address + port
and receiver address + port, and this is usually sufficient.

Can the server identify the corresponding SID based on sender address + port
and  receiver address + port?

Yes, the server assigns the SID with all addr+port information in hand. 
 
[Fortune: OK. Thanks!] 

 
[Fortune: I don't think we need redundant fields to keep the two specs
similar, but I won't fight for it anyway. But could you tell me that if the
server accepts the SID in the way as described above, please?] 

The client can resend, but in any case, the sender will stop sending
test packets.  At the reflector, resources are freed-up when it stops
a test, so this scenario seems rather unusual. 
[Fortune: If we need to consider this scenario seriously, maybe we need more
text on the behaviors of both the client and server for this scenario. But I
agree with you that this scenario seems rather unusual, and given my comment
missed the deadline of the IETF-LC, I can also accept it as it is.]

---

From: Al Morton <[email-masked]>
Date: Thu, 18 Mar 2010 22:24:21 -0400

At 09:44 PM 3/18/2010, Fortune HUANG wrote:

2. In section 3.3,
I think the SIDs may not need to be carried back to the client. Assuming
the SID is accepted in sequence with no discrimination, the client can
figure out the list of accepted SIDs with the accepted number of
sessions.  Suppose the client requests for SID1, SID2, SID3 and SID4
in sequence, can the server accepts only SID1, SID3 without accepting
SID2? If it can do that, how does the server differentiate SID3 and SID2?
If it can not do that, that I think the server can return a acceptance
count to the client, e.g. 2 for accepting SID1 and SID2, 3 for accepting
SID1, SID2 and SID3.

use it in TWAMP and it keeps the two specs
similar.

[Fortune: I don't think we need redundant
fields to keep the two specs similar, but I won't fight for it anyway.
But could you tell me that if the server accepts the SID in the way as
described above, please?]

Your scenario seems to have the Control-client assigning the SID.

That's not how the protocol works - the Server assigns the SID.

from RFC 5357, section 3.5:

The Session Identifier (SID) is as defined in OWAMP
[RFC4656].  Since
the SID is always generated by the receiving side, the
Server
determines the SID, and the SID in the Request-TW-Session
message
MUST be set to 0.

Al

---

From: Murtaza Chiba <[email-masked]>
Date: Sun, 21 Mar 2010 10:48:36 -0700

On Thu, Mar 18, 2010 at 7:24 PM, Al Morton <[email-masked]> wrote:

> [RFC4656 <http://tools.ietf.org/html/rfc4656>].  Since
Furthermore, if the Client assigns a SID it is not guaranteed to be unique
in the network. If the server assigns one, at the very least all the clients
that the server accepts connections from are guaranteed to have unique
identifiers.

Thanks,
-murtaza

> Al
>
>
> _______________________________________________
> ippm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ippm
>
>

---

From: Jerome Benoit <[email-masked]>
Date: Sun, 21 Mar 2010 21:12:18 +0100

Le Sun, 21 Mar 2010 10:48:36 -0700,
Murtaza Chiba <[email-masked]> a écrit :

Hello, 

> Furthermore, if the Client assigns a SID it is not guaranteed to be
> unique in the network. If the server assigns one, at the very least
> all the clients that the server accepts connections from are
> guaranteed to have unique identifiers.

I lurk this IETF WG since some time in order to enhance an old
measurement system (that need less naive measurements and hackers) used
by end-user to troubleshoot their connexion in France. Quiet honestly,
neither OWAMP or TWAMP can be implemented without a revamp to serve our
need. 

To be more explicit : 

- We can't trust the end-user clock for timestamping measurement, we
rely on time difference from the server clock source only (we plan to
calibrate timestamping inaccuracy); 
- The measurement agent run behind the end-user CPE, 1-to-n NATed for
IPv4 and firewalled, so measurement agent must start the probing
session and initiate the connection, same for probing configuration
fetching). 

The end-to-end delay and delay between landmarks and end host is a very
useful metric to do troubleshooting but we can't do it by strictly
following IETF RFC ... 

For measurement agent UUID handling, we plan to : 

- generate it at first agent start; 
- register it on the server that will handle the birthday paradox; 
- UUID has nothing to do with your probing session ID but it's the
quickest way to map a probing configuration to an measurement agent
on network topology criteria or other ... 

Maybe it will be useful to this WG. 

Cheers.

-- 
Jérôme Benoit aka fraggle
La Météo du Net - http://grenouille.com
OpenPGP Key ID : 9FE9161D
Key fingerprint : 9CA4 0249 AF57 A35B 34B3 AC15 FAA0 CB50 9FE9 161D

---

From: Fortune HUANG <[email-masked]>
Date: Mon, 22 Mar 2010 08:29:06 +0800

Hi Murtaza, 
Hi Al,
 
Thank you very much for the explanations. I think I've had a better view on
this draft with your help now.

Regards,
Fortune

  _____  

From: Murtaza Chiba [mailto:[email-masked]] 
Sent: Monday, March 22, 2010 1:49 AM
To: Al Morton
Cc: Fortune HUANG; [email-masked]
Subject: Re: [ippm] Last Call: draft-ietf-ippm-twamp-session-cntrl
(IndividualSession Control Feature for TWAMP) to Proposed Standard

 

[RFC4656 <http://tools.ietf.org/html/rfc4656> ].  Since

Server

message

   MUST be set to 0.

Thanks,
-murtaza

Al