search

mpiraux / draft-piraux-tcpls

Other
0 stars 0 forks source link

Stream Frame #9

Closed frochet closed 2 years ago

frochet commented 3 years ago

Instead of:

Stream frame {
  Type (7) = 0x01,
  FIN (1),
  Stream ID (32),
  Offset (64),
  Length (16),
  Stream Data (...),
}

we should do:

Stream frame {
  Stream Data (...),
  Type (7) = 0x01,
  FIN (1),
  Stream ID (32),
  Offset (64),
  Length (16),
}

and constraining 1 Stream frame per record.

That allows implementing zero-copy easily. Or it is just making the same mistakes than Quic IMO.

obonaventure commented 3 years ago

I don't see why we should constrain one frame per record, especially for control frames like ack frames. This is only important for bulk transfers that are not necessarily the most important use cases. For the ordering of the information, this is an interesting point to discuss.

mpiraux commented 3 years ago

It's not as straightforward as frames are Type-values unit so one has to find the type of the Stream frame.

mpiraux commented 3 years ago

Btw @obonaventure, it's only constraining records to have at most one stream frame, starting with the data.

frochet commented 3 years ago

I don't see why we should constrain one frame per record, especially for control frames like ack frames. This is only important for bulk transfers that are not necessarily the most important use cases. For the ordering of the information, this is an interesting point to discuss.

Ok, let me try to be more clear. We should not constraint 1 frame per record, we should contraint 1 frame that contains APPDATA per record. That means some record can contain any number of control frame, and we can have also any number of control frame after a data frame within the same record (but not before). This has significant performance benefit