Re: [tsvwg] [OPS-DIR] Opsdir last call review of draft-ietf-tsvwg-sctp-ndata-12

[Stefan Winter <[e-mail]>]

Hi,

>> The chapter IANA considerations mentions four bits to be registered: E,B,U,I.
>> In the main body, only three of those are actually defined and used (End of
>> fragmented message, Beginning of fragmented message, Unordered/Ordered
>> message). Please add a definition of the I bit or remove the IANA registration
>> request for that bit.
> The I bit is defined in RFC 7053 and that is the reason why we state
> "DATA chunk defined in [RFC4960]and [RFC7053]". In addition to that it is
> not mentioned (in contrast to the U, B and E bit), since the delaying of the
> SACK is not specific to the I-DATA chunk.
>
> I have added the following text to the body of Section 2.2:
>
> <t>The handling of the I bit for the I-DATA chunk corresponds to the handling
> of the I bit for the DATA chunk described in <xref target='RFC7053'/>.</t>
>
> to improve the description of the I bit. See
> https://github.com/sctplab/sctp-idata/commit/f16308ffe0e67ce5deb957bd40c25c5a0e691b82
> Does that address your issue?

Yes, thank you.


>> And the rest are only musings not needing any action if the authors don't want
>> to action on them:
>>
>> The introduction presents a good use case, quoting: "e.g., when the
>> transmission of an urgent
>>   message is blocked from transmission because the sender has started
>>   the transmission of another, possibly large, message".
>>
>> The later queueing example in figure 1 has three SIDs being queued
>> simultanseously. It is not clear which of those "has already started" and which
> There is actually one message queued for stream 0, three messages for stream 1,
> and one message for stream 2.
>> are the important ones being delayed. For a better understanding of the reader,
> The figure is about in which sequence they are put on the wire. So no
> transmission has startet. This examples also does not deal with the case
> of one stream having a higher priority than another. That would be an
> example using a priority scheduler. This examples illustrates the round
> robin scheduler.
> The point here is that a single scheduler (the round robin scheduler, for
> example) behaves differently when user message interleaving is used or not.
> That is an important point: You can even use the schedulers with regular
> DATA chunk, i.e. with user message interleaving being negotiated.
>> it might be useful to revise the figure so that the head-of-line blocking
>> happens for SID 1 because transmission of  0 and 2 has already started (and
>> declare SID 1 to be the "important" message). The ASCII art would just have to
>> indent SID 1 content a bit (placing 0 and 2 earlier in time), and the resulting
>> serialisation would then put all the SID 1 messages at the very end, when 0 and
>> 2 have been completely submitted (right?).
> One could think about adding another example based on the priority scheduler
> and giving stream 1 a higher priority. But for illustrating the point of
> schedulers behaving differently depending on the negotiation of user message
> interleaving this seems not necessary.

That second example might indeed be useful.

It's simply a bit strange that in the introduction you speak about an
"urgent" message (something deserving a higher-priority sending) and
that another transmission has already started - but then the example has
none of those two.

In fact I wonder why you speak about urgent things in the introduction
at all. Neither the scheduler nor the interleaving are designed to help
urgent things to be sent earlier.

All they do is make the transmission fairer so that *all* chunks get a
more even serialised distribution on the wire.

So, rather than saying that the spec helps urgent things to be sent
earlier, it should maybe rather state that the spec helps every message
getting an equal, and equally distributed, share of the medium.

>> In 2.2.3, is there any particular reason why the "protocol violation" error
>> cause is only a MAY? As it enables debugging on the remote end, a SHOULD seems
>> useful.
> This is for consistency with other SCTP specifications. There is always the balance
> between providing more information to help diagnosing the problem and providing more
> information to an attacker. This allows implementers to do what they prefer.
> For interoperability it is not important if the error cause is included or not.

That's fine, thanks.

Greetings,

Stefan

-- 
Stefan WINTER
Ingenieur de Recherche
Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche
2, avenue de l'Université
L-4365 Esch-sur-Alzette

Tel: [phone]
Fax: [phone]

PGP key updated to 4096 Bit RSA - I will encrypt all mails if the recipient's key is known to me

http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC0DE6A358A39DC66