Hi Joe.
see below...
On 30.01.2015 20:23, Joe Touch wrote:
Hi, Mirja,
On 1/30/2015 3:46 AM, Mirja Kühlewind wrote:
Hi Joe,
I reply to the TCP part in this mail... see below.
On 19.12.2014 00:39, Joe Touch wrote:
Some feedback below. Although I focus on some TCP and UDP specifics,
some observations apply to other transports as well.
Joe
-----
3.1.1
TCP segments fit into IP packets, but those packets are not
necessarily constrained to fit into a lower-layer frame.
They can be source fragmented.
>
Yes, but this is handled by IP and not by the transport. Therefore I
believe that does not need to be mention here...?
The problem is in the first sentence:
TCP partitions a continuous stream of bytes into segments, sized to
fit in IP packets, constrained by the maximum size of lower layer
frame.
The first part is true (TCP fits into IP), but the second is not (IP is
NOT constrained by the max size of the lower-layer frame). IP is
constrained only by the ability of IP (i.e., of L3 to reassemble at the
destination).
Okay, I've just removed the second part of the sentence to avoid confusion
because it is actually not important in this doc. That's okay for you?
PathMTU discovery is supported by TCP but may be inhibited
by network conditions (ICMP blocking); PLMTUD is supposed
to be supported as well.
>
I added PLMTUD separately as well as the respective RFCs for both.
However, I'm not sure if we actually need to distinguish which mechanism
is used than rather just saying TCP supports path MTU discovery. (The
notation in the draft current is PathMTU discovery which references to a
specific mechanism but that be changes...).
"Path MTU discovery" is ambiguous; it can refer to any mechanism that
allows the path MTU to be known, or it can refer to the specific
mechanism by that name in RFC 1191.
If you mean the more general concept, it would be better to use a term
that is unambiguous in referring to both (e.g., discovery of the path
MTU). Once you tie the words together as "path MTU discovery", it could
be misinterpreted as meaning only RFC 1191.
However, IMO, in this doc it would be better to be more clear and
explicit by naming both mechanisms.
K. Done.
...
3.1.3
TCP provides a byte-ordered reliable stream. How that
is delivered - e.g., by segments - is irrelevant, if only
because TCP can change those segment boundaries during
operation (e.g., with path MTU updates).
>
Yes but it is still something that TCP implements as a component.
TCP definitely does not. There is no required correlation between SEND
boundaries and segment boundaries.
Some TCP implementations do, but there is nothing to ensure that
boundaries controlled by the sending application are exposed to the
receiving application.
I don't think this doc should discuss how implementations go astray in
this way.
I think this is again a terminology problem. We agreed that a (transport
protocol) component is something that a transport protocol implements. I don't
think there are any TCP implementations that do not implement segmentation...?
So it's a component.
A transport feature is something that you would reveal to the application. This
is currently not the case and will probably also in future not be the case for
segmentation. (However if you would want to reveal it, the functionality is
already there you just need a different API...)
However, in this document we should still list all TCP components and then add a
discussion which of these components should be revealed to the app and in which
from. This discussion is not there yet, because I'd like to get the first step
right for as much protocols as possible first.
Does this make sense to you?
...
additionally, the ports ought to be discussed in more detail.
ports in the SYN have a different meaning that ports in other
segments. The SYN destination port indicates the receiving
` service, which typically involves BOTH demuxing to a process
within a host AND indicating the format of the stream. Ports
there and in all other segments are only demultiplexing
indicators.
>
Added one sentence in section 3.1.1. and extended the connection setup
up point to
"connection setup with feature negotiation and application-to-port
mapping"
Does that make sense to you?
The sentence does, but that doesn't sufficiently (IMO) address the
feedback I gave above.
TCP has two portions:
- connection establishment
feature negotiation
service-to-port mapping
connection identification
- established connection data transfer
which continues to use the connection identifier
At this point in the document it is not important for me anymore to have in mind
with bit in the header is used for with kind of functionality. Therefore being
able to identify a connection (or as we named it: 'port multiplexing') is one
component while 'connection establishment' is another. As in your list
'connection identification' shows up in both bullets, I'd say it's sensible to
list this as an own component. However, 'negotiation' and 'service-to-port
mapping' are always bounded to the setup. Therefore it's not an own component.
We already discussed if we need a finer granularity than components; Brian has
been calling this an aspect... I'm still not convinced that declaring another
confusion term will make our life easier...
So the only real different that see to what you propose above is that the
currently list does not name 'data transfer' as a component. For me that's
implicit a task of every transport protocol, so I would name it explicitly.
I'd like to leave it as it is for now and will be waiting for further options on
this.
Mirja
Joe
_______________________________________________
Taps mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/taps
--
------------------------------------------
Dipl.-Ing. Mirja Kühlewind
Communication Systems Group
Institute TIK, ETH Zürich
Gloriastrasse 35, 8092 Zürich, Switzerland
Room ETZ G93
phone: +41 44 63 26932
email: [email protected]
------------------------------------------
_______________________________________________
Taps mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/taps
