[Tsvwg] Comments about the PKTDROP SCTP extension

[[e-mail]]

	Hi all!

	I have just read the Packet Drop Reporting extension for SCTP (http://www.ietf.org/internet-drafts/draft-stewart-sctp-pktdrprep-00.txt) and I have some quite many comments (as usual ;->):

	- Page 3, last paragraph, a typo: "middle box peer can be *can be* located..."

	- Page 5, new chunk diagram: This is maybe a matter of style and taste but I liked the way flags are described in other SCTP documents (I mean in the drawing). What about something like
        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | Type = 0x81   |Reserved |T|B|M|      Chunk Length             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+?

	- Page 5: I think that the field "Truncated Length" is a little bit confusing, since it is the length of the datagram before truncating it. What about "Original SCTP Datagram Length"?

	- Page 6, beginning, T flag definition: It says that you get the original packet length "from the IP header". That's really confusing, as later it is clear that only the SCTP datagram is included (without the header). I think you should change that and make clear that it is only the SCTP datagram what's copied in the PKTDROP chunk. Also, up to this point it is not completely clear whether that length also includes the SCTP common header...

	- Page 7, Data Field definition: I think you could make clearer here that when you speak about the packet you mean just the SCTP packet NOT including the header...

	- Section 5.1.1: There are some chunks that a middle box shouldn't send back to the sender. These are the INIT ACK, SHUTDOWN COMPLETE and any packet containing an ABORT. It shouldn't because that doesn't make sense: the sender of such a packet does not have any TCB about that association any more. So, the PKTDROP would be an OOTB datagram and that would only originate that an ABORT is sent to the other peer.

	In fact, in the case the original packet contained an ABORT, the above might make sense.

	If it was a SHUTDOWN COMPLETE, it will basically speed up the fatal destiny of the association (the peer would otherwise retransmit the SHUTDOWN ACK and get a SHUTDOWN COMPLETE similar to the ABORT it will get if the middle box sends the PKTDROP). Receiving an ABORT with the *right* VT and still with the T flag set, instead of a SHUTDOWN COMPLETE with the T flag set and the reverse VT might be a little bit confusing though...

	But if the INIT ACK was lost, that would cause that the establishment phase is aborted, and that's not good.

	- Section 5.1.2: The above comment also works for this section. And I was also thinking if when receiving a corrupted HEARTBEAT ACK it would make much more sense simple sending back a new HEARTBEAT than the PKTDROP. Same happens with the SHUTDOWN ACK: better to resend the SHUTDOWN instead of the PKTDROP since that would speed up the processing of the datagram at the peer side.

	I'm not sure but maybe the same happens with corrupted COOKIE ACK and ASCONF ACK chunks... :-/

	- Section 5.2: There are many chunk names written in lower case, such as "heartbeat", "shutdown acknowledgement", "cookie-ack", "Packet Drop"... and more. I think they should be written with capital letters (and the "official" name).

	- Section 5.2: What happens if one receives a PKTDROP containing an ASCONF ACK? I think that after carefully checking the serial number, the receiver of the PKTDROP could resend the ASCONF ACK (at least in the quite probable case that it stores a copy of the last ASCONF ACK sent).

	- Section 5.2, page 9: The calculation of "rtt" is very confusing. What are those values there? Besides, there is a bracket missing...

	- Section 5.2., page 10: In the formula for bw_avail, you could mention that dividing the result by 1000 is because the rtt is in milliseconds. I might be too clumsy but I was wondering whether that value was because you wanted to give a share of one thousandth to each peer... :-/

	- Section 6, Security considerations: I suppose that you have already though about this, but, as said at the beginning of page 6, middle boxes are allowed to send a PKTDROP just to state the bandwidth value. What if the peer wants to speed up the transmission and sends a fake PKTDROP as being sent by any middle box in between? This can be perfectly done... I'm not sure whether you should allow any increase in the cwnd at all... :-/



	Ok, that's all (by now! ;->)

	BR Iván Arias Rodríguez

	PS: I suppose this is the right list to send this mail..

_______________________________________________
tsvwg mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/tsvwg