Re: draft-bouazizi-rmt-alcframing-00.txt

Hello Stephan and Imed,

> please find attached a short I-D which I will be presenting on behalf  
> of the author in today's session.  We missed the -00 deadline, but  
> after consultation with the chairs, we thought that last minute  
> circulation by reflector is better than no document at all.  The  
> draft is rather short -- 7 pages including boilerplate.  Feel free to  
> spoil your lunch by reading it.

Generally speaking, I agree that sooner or later deploying ALC over
TCP will be needed. So the I-D is useful.
Concerning the document, I have a few comments:

** section 2, Framing method:
Why do you restrict yourself to a 16bit LENGTH field?
First it breaks the 32bit alignment of the ALC/LCT header. Second,
since TCP will fragment the ALC packet as required by the PMTU,
there is no real motivation for limiting the ALC packet size. It's a
completely different situation than when ALC runs on top of UDP
since big UDP packets will be fragmented by IP which is considered
harmfull.
There's probably situations where an ALC packet will go through TCP
tunnels (using the proposed method) and then will perhaps continue its
travel over UDP after crossing a dedicated middlebox. Then it makes
sense to restrict ourselves to ALC packets of size < 65535.
But there are also situations where one would like to go beyond this
threshold.

** Section 4, Further considerations:
It is said:

       The framing method defined in this memo may be applied in an end-to-
       end system or at certain paths of the end-to-end system, where 
       tunneling over TCP is required. This has the following consequences: 
       o The order of the packets cannot be guaranteed. 
       o Packet loss may occur and SHOULD be detected based on the EXT FTI 
          header by detecting gaps in Source Block Number and Encoding 
          Symbol IDs. 

I find this section confusing. It explains that packets could get
misordered and lost... That's the case when you consider use-cases
where packets will go through TCP tunnels __and__ UDP areas as
it is explained. BUT this I-D is devoted to ALC over TCP, and in
this case there's no problem. So this note should not be highlighted
as it is, in the middle of the I-D, but rather moved at the end of the
document, in a small note.

** Section 7, Congestion Control:
It is said:

       ALC and FLUTE MAY make use of the congestion control building block. 
       Furthermore, the deployment over TCP ensures that the ALC/FLUTE 
       session competes fairly with other TCP connections. 

This text is confusing. Over the TCP tunnel, there's no reason to use
the CC building block. Otherwise it's obvious that TCP is fair with
TCP ;-) In fact I don't see the point here.

** Section 8, Security Considerations
I don't understand the motivations for the discussion about the
LENGTH field and associated attacks. Can you be more explicit?

Regards,

   Vincent