draft-polk-tsvwg-intserv-multiple-tspec-06

James and Subha,

here is a more detailed review of the draft.  The following are a combination of nits, general comments, and
questions.  You can decide as to their importance. 

page 3, 4'th paragraph.  In the previous paragraph, you denote the direction of the ADSPEC as being
"downstream".  for the sake of completeness, you should probably denote the direction of the RESV.

page 4, 1'st paragraph.  Break up the first sentence.  it runs waaaaaay to long with too many thoughts
entwined in it.

page 4, 5'th paragraph.  You should qualify the last sentence to say that dynamically adapting data streams
during reservation set up.

page 5.  Figure 1.  This figure (along with Figure 4 and Figure 6) repeat information in existing RFCs.  I have a
preference to have this information removed and simply refer the reader to the appropriate RFCs.  While it
may be helpful when first writing the first multi-tspec draft for the initial reading (and people reading
it at its first presentation , I don't think anything is gained by repeating the information in future
versions of the draft.  Shame on the reader for being too lazy to look up the info.

page 5, 1'st paragraph.  For the sake of completeness, you may want to point out that Section 5 deals with
security considerations.

Section 3.  There is no mention of a maximum number of Multi-tspec entries (you do make mention of this in
4.10, but as an open issue).  I know this has been brought up in previous meetings, and I'd like to
re-advocate the idea of putting a cap on the number of entries.  Poorly developed code, or malicious
behavior, could conceivably send tspec in the hundreds (thousands?), which would seem at the very least
to represent an attack vector for RSVP capable nodes.  How about something like a recommendation of at most
4 entries of the multi_tspec object, and a max of 10?  The thing to note is that if you decide to add a maximum
amount, you'll probably need/want to slightly change the format of your multi_tspec object.

Re: draft-polk-tsvwg-intserv-multiple-tspec-06

Thanks Ken - good to see more comments on this draft.

You may be pleased to know that I put the case to our ADs some weeks ago 
to consider a charter update that would enable the WG to consider such 
work. I'm expecting them soon to conclude and we can then move forward.

Best wishes,

Gorry

On 16/05/2011 18:59, ken carlberg wrote:
> James and Subha,
>
> here is a more detailed review of the draft.  The following are a combination of nits, general comments, and
questions.  You can decide as to their importance.
>
>
> page 3, 4'th paragraph.  In the previous paragraph, you denote the direction of the ADSPEC as being
"downstream".  for the sake of completeness, you should probably denote the direction of the RESV.
>
> page 4, 1'st paragraph.  Break up the first sentence.  it runs waaaaaay to long with too many thoughts
entwined in it.
>
> page 4, 5'th paragraph.  You should qualify the last sentence to say that dynamically adapting data
streams during reservation set up.
>
> page 5.  Figure 1.  This figure (along with Figure 4 and Figure 6) repeat information in existing RFCs.  I have
a preference to have this information removed and simply refer the reader to the appropriate RFCs.  While
it may be helpful when first writing the first multi-tspec draft for the initial reading (and people
reading it at its first presentation , I don't think anything is gained by repeating the information in

Regarding Cumulative TSN Ack in the SACK after peer re-start

Re: Regarding Cumulative TSN Ack in the SACK after peer re-start

Re: Regarding Cumulative TSN Ack in the SACK after peer re-start

Re: Regarding Cumulative TSN Ack in the SACK after peer re-start

Re: Regarding Cumulative TSN Ack in the SACK after peer re-start

On May 23, 2011, at 9:34 AM, Padmalochan Moharana wrote:

> Hi Randy,
> 
> Thanks for the response. In this case ENDPOINT A send INIT after sending one DATA with TSN 100 to peer. So
should end point B send SACK for the received message after sending INIT ACK to endpoint A. Or Endpoint
should not send any SACK for the DATA received before restart of endpoint A.

When the new INIT is sent it is the same as a brand new association. Endpoint B
will NOT SACK about 100.. its the same as Endpoint B receiving an ABORT and then
a new INIT.

In fact it is very very difficult to get Endpoint B NOT to receive an ABORT.

In your scenario, what you would more likely see is

-----DATA(TSN=100)---------------->
<crash/restart>
  <---------SACK(TSN=100)---------
------ABORT(NO-TCB FLAG)---------->
------INIT---------------->

In past interop's the only way to get the restart to occur is to unplug
the endpoint that you restart so it won't get a Heartbeat or a SACK to
cause it to generate an ABORT..

R

> 
> Thanks,
> Padmalochan
> 
> On Mon, May 23, 2011 at 6:30 PM, Randy Stewart <randall <at> lakerest.net> wrote:
> Padmalochan:
> 
> I see the restart occur, but in your picture
> I see no data sent... Until data is sent after
> the restart you would not see a sack..
> 
> A restart is like a new association. After all the
> other side most likely crashed and started back up again.
> 
> So IF your restarted endpoint had sent:
> 
> -----DATA:TSN=200----->
> 
> Which it would have since thats the initial TSN it declared in its INIT
> 
> You would get back
> 
> <--------SACK:200
> 
> But only after a data message had been sent.
> 
> R
> 
> 
> On May 23, 2011, at 6:47 AM, Padmalochan Moharana wrote:
> 
> > Hi ,
> >
> > I have a doubt regarding the value of the "Cumulative TSN Ack" in the SACK message after restart of the peer.
> >
> > what should be the value of the "Cumulative TSN Ack" in SACK message for the DATA message received before
> >
> > peer re-started.
> >
> > Please find the call flow for the scenario for more information.
> >
> >
> > Thanks,
> > Padmalochan
> > <Screenshot-1.png>
> 
> -----
> Randall Stewart
> randall <at> lakerest.net
> 
> 
> 
> 
> 

-----
Randall Stewart
randall <at> lakerest.net

Re: Regarding Cumulative TSN Ack in the SACK after peer re-start

Padmalochan:

I see the restart occur, but in your picture
I see no data sent... Until data is sent after
the restart you would not see a sack..

A restart is like a new association. After all the
other side most likely crashed and started back up again.

So IF your restarted endpoint had sent:

-----DATA:TSN=200----->

Which it would have since thats the initial TSN it declared in its INIT

You would get back

<--------SACK:200

But only after a data message had been sent.

R

On May 23, 2011, at 6:47 AM, Padmalochan Moharana wrote:

> Hi ,
> 
> I have a doubt regarding the value of the "Cumulative TSN Ack" in the SACK message after restart of the peer.
> 
> what should be the value of the "Cumulative TSN Ack" in SACK message for the DATA message received before 
> 
> peer re-started.
> 
> Please find the call flow for the scenario for more information.
> 
> 
> Thanks,
> Padmalochan
> <Screenshot-1.png>

-----
Randall Stewart
randall <at> lakerest.net

Re: Regarding Cumulative TSN Ack in the SACK after peer re-start

On May 23, 2011, at 12:47 PM, Padmalochan Moharana wrote:

> Hi ,
> 
> I have a doubt regarding the value of the "Cumulative TSN Ack" in the SACK message after restart of the peer.
> 
> what should be the value of the "Cumulative TSN Ack" in SACK message for the DATA message received before 
> 
> peer re-started.
When B processes the INIT, it does not change its state.
I can only assume that the SACK is sent, for example,
based on the SACK timeout or a window update. So cum_tsn
would be 100.

Please note that due to a vtag mismatch, endpoint A will
silently discard the SACK.

Best regards
Michael
> 
> Please find the call flow for the scenario for more information.
> 
> 
> Thanks,
> Padmalochan
> <Screenshot-1.png>

Re: Regarding Cumulative TSN Ack in the SACK after peer re-start

On May 23, 2011, at 4:10 PM, Randy Stewart wrote:

> 
> On May 23, 2011, at 9:34 AM, Padmalochan Moharana wrote:
> 
>> Hi Randy,
>> 
>> Thanks for the response. In this case ENDPOINT A send INIT after sending one DATA with TSN 100 to peer. So
should end point B send SACK for the received message after sending INIT ACK to endpoint A. Or Endpoint
should not send any SACK for the DATA received before restart of endpoint A.
> 
> When the new INIT is sent it is the same as a brand new association. Endpoint B
> will NOT SACK about 100.. its the same as Endpoint B receiving an ABORT and then
> a new INIT.
If B receives an INIT, it will not change its state. The SACK might be sent, because
due to the reception of the DATA chunk (TSN 100) a T2 timer was started. So
the SACK would have cum_tsn = 100.
> 
> In fact it is very very difficult to get Endpoint B NOT to receive an ABORT.
Really?
If A is restarting (using the same port number as before), it would receive
a SACK with incorrect v-tag, but there is an association. So it would be
silently discarded. Or am I missing something?
> 
> In your scenario, what you would more likely see is
> 
> -----DATA(TSN=100)---------------->
> <crash/restart>
>  <---------SACK(TSN=100)---------
> ------ABORT(NO-TCB FLAG)---------->
> ------INIT---------------->
Correct. But if the INIT was sent before the SACK was received, the SACK is
silently discarded.

Best regards
Michael
> 
> 
> In past interop's the only way to get the restart to occur is to unplug
> the endpoint that you restart so it won't get a Heartbeat or a SACK to
> cause it to generate an ABORT..
> 
> R
> 
> 
>> 
>> Thanks,
>> Padmalochan
>> 
>> On Mon, May 23, 2011 at 6:30 PM, Randy Stewart <randall <at> lakerest.net> wrote:
>> Padmalochan:
>> 
>> I see the restart occur, but in your picture
>> I see no data sent... Until data is sent after
>> the restart you would not see a sack..
>> 
>> A restart is like a new association. After all the
>> other side most likely crashed and started back up again.
>> 
>> So IF your restarted endpoint had sent:
>> 
>> -----DATA:TSN=200----->
>> 
>> Which it would have since thats the initial TSN it declared in its INIT
>> 
>> You would get back
>> 
>> <--------SACK:200
>> 
>> But only after a data message had been sent.
>> 
>> R
>> 
>> 
>> On May 23, 2011, at 6:47 AM, Padmalochan Moharana wrote:
>> 
>>> Hi ,
>>> 
>>> I have a doubt regarding the value of the "Cumulative TSN Ack" in the SACK message after restart of the peer.
>>> 
>>> what should be the value of the "Cumulative TSN Ack" in SACK message for the DATA message received before
>>> 
>>> peer re-started.
>>> 
>>> Please find the call flow for the scenario for more information.
>>> 
>>> 
>>> Thanks,
>>> Padmalochan
>>> <Screenshot-1.png>
>> 
>> -----
>> Randall Stewart
>> randall <at> lakerest.net
>> 
>> 
>> 
>> 
>> 
> 
> -----
> Randall Stewart
> randall <at> lakerest.net
> 
> 
> 
> 
>