Subject: RE: Question abouth P bit setting

From: Binny Jeshan <[email-masked]>
Date: Wed, 12 Mar 2014 21:27:03 +0200

"One could always bring the session to Up with slow 
timers, then start P-F to change to fast timers."

Hmmm, interesting. I don't see anything is wrong with this, though its another extra step in the process, but sending P bit when moving to Down State would be some extra piece of code to make things even more sophisticated. Let the software Architect and the System Engg..  decide about it , such that at least on deployment they don't get tickets raised over this method :D

Regards,
Binny.
Aricent Group, India

Sent from Nokia Lumia.

-----Original Message-----
From: "Marc Binderberger" <[email-masked]>
Sent: ‎12-‎03-‎2014 06:55 PM
To: "Jeffrey Haas" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: Question abouth P bit setting

Hello Jeff,

hmm, I'm a bit lost :-) as I don't see the problem. The Poll sequence - 
sending P, receiving F - seems orthogonal to the state machine for me. 
It's just a synchronization mechanism on top to ensure timers are set 
in the right sequence.

If you mean "stay out of grey zones and don't make assumptions" then I 
agree though :-)  One could always bring the session to Up with slow 
timers, then start P-F to change to fast timers.

Regards, Marc

On Wed, 12 Mar 2014 10:19:03 -0400, Jeffrey Haas wrote:
> On Wed, Mar 12, 2014 at 06:26:19AM +0000, Mach Chen wrote:
>> Thanks for the detail explanation, it's clear.
>> 
>> According to your and Marc's response, seems that one system could 
>> choose to set the P bit (strictly as RFC5880 says) or clear the P 
>> bit (as you said and some implementations do). The key point is that 
>> the remote system could properly process the control packet 
>> with/without P bit set.
>> 
>> Ask this question, because I saw two implementations that one set 
>> the P bit and the other does not.
> 
> The place this is problematic is that the P-bit expects the F-bit to be
> used.  It can't be wholly ignored.  But the procedure also means that if the
> F-bit is received, the poll should end.  This isn't a very good fit for the
> usual state machine changes because multiple packets may be sent and
> received as the state machine transitions.
> 
> My recommendation would be that poll sequences (sec. 6.5) should only be
> used for parameter changes outside of those part of the state machine
> transitioning to the Up state.
> 
> A reminder from section 6:
> "It is important for implementors to enforce only the requirements specified
> in this section, as misguided pedantry has been proven by experience to
> affect interoperability adversely."
> 
> -- Jeff
>